Linked by Thom Holwerda on Wed 4th Dec 2013 18:06 UTC
Linux

"Joining the Linux Foundation is one of many ways Valve is investing in the advancement of Linux gaming," Mike Sartain, a key member of the Linux team at Valve said. "Through these efforts we hope to contribute tools for developers building new experiences on Linux, compel hardware manufacturers to prioritize support for Linux, and ultimately deliver an elegant and open platform for Linux users."

Mark my words: Valve will do for Linux gaming what Android did for Linux mobile. Much crow will be eaten by naysayers in a few years.

Thread beginning with comment 577994
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: Comment by shmerl
by oiaohm on Thu 5th Dec 2013 10:35 UTC in reply to "RE[6]: Comment by shmerl"
oiaohm
Member since:
2009-05-30

Lets take an Linux example of equally broken driver.
ATI in case when Linux Kernel Lock was removed. Alfman

Was it possible to get the ATI drivers back working again on Linux. The same binary blobs that were used in the past. Yes it was. Why there were interfaces for wrappers to be placed on top of the driver to allow for the new kernel limitation. Did this require AMD or ATI to fix the issue on abandoned hardware. No it did not.

This is the big problem. Windows 7 to Windows 8. How can you fix it to get your hardware back working.

The binary blob with source wrapper that Linux classes as it minimum acceptable driver allows drivers to operate longer. Even nvidia 8K requirement causing failures on kernel build with 4k pages also could be wrapped over if Nvidia never fixed the driver.

There is just case after case of where mostly binary blob Linux drivers have been able to be brought back to life by altering the wrapper code over it.

Hardware makers also don't worry about particular kernels with Linux that much. If 1 kernel version does not work they publish use a different one for a while.

The nvidia and AMD wrapped binary blobs are more compadible than just 3.x they in fact support 2.6 and 2.4 kernels as well. So yes all the way back to 2001.

Any API exported to userspace from kernel space on the stable list cannot be broken/fixed must remain functioning exactly how it use to.

The selection to forbid solid blob drivers keeps the kernel cleaner. If there is a issue with a blob with Linux the wrapper to fix it only has to be loaded if the driver requiring it is being used.

Before you can consider binary only drivers with Linux something else need to be done. Implement the means to re-link a binary blob. Why so wrappers can be inserted the way they currently are.

Yes your Windows 7 to windows 8 problem also comes about because Microsoft Windows driver tools don't have any way to relink a fix object into a existing driver.

Linus will not allow the change unless same quality of support for old unsupported by maker hardware can be maintained after the change.

Alfman the Linux kernel back in 2.2 did have binary drivers support. The feature was intentionally disabled. List of reasons.
1 gcc versions passing arguments differently.
2 Alteration in API in kernel space would leave no way to repair driver. So forcing either the kernel to grow in size with emulation parts or require binary drivers without wrapper to be for-bin.

If binutil ld had means to relink a binary with wrappers were required both 1 and 2 could be addressed.

Alfman like it or not the Linux stand on no binary drivers is grounded in operation and build tool limitations.

Reply Parent Score: 2

RE[8]: Comment by shmerl
by Alfman on Thu 5th Dec 2013 16:32 in reply to "RE[7]: Comment by shmerl"
Alfman Member since:
2011-01-28

oiaohm,

"Alfman the Linux kernel back in 2.2 did have binary drivers support. The feature was intentionally disabled. List of reasons. 1 gcc versions passing arguments differently."

That happened back in 1999? That's really more of a very rare issue with GCC than the linux kernel per say. Changes to argument passing in GCC would break lots of binary interfaces and not just those in the kernel anyways. This is a great example of a breaking change that I would perform between major linux versions. Under a scheme where there isn't any expectation of API/ABI compatibility between major versions, then this case becomes a none issue.


"2 Alteration in API in kernel space would leave no way to repair driver. So forcing either the kernel to grow in size with emulation parts or require binary drivers without wrapper to be for-bin."

You do understand I wasn't suggesting we keep fixed legacy interfaces over a long term, right? Just make changes at more predictable intervals. This gives devs much more time to come up with good interfaces and more time to write drivers for them. If an interface is so broken that it warrants immediate changes, then I would allow it, but that really should be the exception rather than the norm.


"Alfman like it or not the Linux stand on no binary drivers is grounded in operation and build tool limitations."


You are welcome to that opinion, those are some of the reasons this debate exists. However in truth there are both pros and cons for adopting stable API/ABIs and this is exactly why I called my earlier solution a "compromise".

Reply Parent Score: 4

RE[9]: Comment by shmerl
by oiaohm on Thu 5th Dec 2013 22:16 in reply to "RE[8]: Comment by shmerl"
oiaohm Member since:
2009-05-30

Alfman Linux kernel does not use normal exporting and importing of functions from the ko objects. This is why its exposed to gcc optimisation altering how things work on it even using not gcc. Last screwup in this regard happened only 4 years ago.

Alfman this is the problem fixed at predictable intervals means that you have drivers fail past repair at each of those change points unless you have someway to wrap them.

By forcing a wrapper the ABI is not required to remain fixed but the driver can remain working. This is why with Linux you are talking about drivers that can be made work over a very huge life span.

The life span of Linux offical Stable ABI/API is kernel major number with the exception of 2.6 and 3.0 where there was no function stripping. So all the Stable ABI/API that existed in 2.6.0 still exists and works the same way in the last one released in the 3 series. 18 December 2003 was the release of 2.6.0. We are talking over 10 years of stability.

Yes the official stable ABI/API is the one exported to user-space. But it is completely operational in kernel space.

The issue the Linux kernel has had a lot where binary drivers break is simply internal only items been hooked up on. Better in recent years with declaring functions GPL only. Kinda keeps the closed source driver makers out of the prototype area.

Alfman the reason why Linux is such a problem with closed source driver makers is the fact it open source. So closed source driver makers see something and use it when its only a prototype being tested. All new API/ABI ideas have to be tested somewhere. What seams like a good idea might fail completely in real life.

Microsoft and other closed source OS's get to hide the prototype stuff they are working on. Open source OS does not have the means todo this.

The big kernel lock issue was not only closed source driver developers gone wrong it was open source as well disobey how it should be used. Even so it was still repairable.

Lot of embedded use Linux userspace drivers. Why these are stable and work across a huge range of Linux kernels without requiring rebuilding. Even so a userspace driver can in many cases be wrapped if something has changed. Yes userspace drivers on the Linux kernel do have a full Stable ABI. There have been only a handful of cases mostly userspace drivers using insecure solutions. Like using /dev/mem to interface with device instead of something that only got permission for a limited address range.

You say compromise. The reality acceptable compromise to the Linux kernel developers has been done. This is user-space drivers.

Its the point 2. You want kernel space stable ABI in the Linux kernel this required working out how to fix the linker to allow relinking of them. Linux world is really after closed source drivers with a 15+ year life span even if the company making the driver goes by by. By 15 years most of the hardware is dieing due to old age. This is the big problem.

Alfman basically to have your compromise be acceptable to Linux kernel developers a re-linker of binary object has to exist for Linux. Other wise the Linux kernel developers will stick to the almost forever stable userspace API/ABI for userspace drivers and wrapper stub for closed source kernel space drivers.

Unless you address the very reason why the Linux Kernel Developers are refusing you cannot expect them to change. Yes the I want kernel ABI is not answering I want to use all my hardware until it physically dies with the latest and most secure kernel.

You might call Linux Developer cheap in there wish to us all there hardware until it dies.

Everyone overlooks that the Linux kernel did have stable ABI for kernel space drivers. The major reason for giving it up was long term operation of drivers.

In fact a lot of hardware makers don't like the idea particularly that uses will use their hardware until it physically dies. They want you buying new hardware sooner.

Think of it this way if Linux ever does provide a stable kernel space ABI and it has the wrapping they want the life span of drivers will remain the same as it is now. Where the driver becomes useless when the hardware no longer works.

Linux core developers don't want the issues windows has were a new version of windows can equal having to go out and buy new hardware.

Clearly note its not that a Linux kernel space ABI is not possible. Its the conditions required for the Linux kernel developers to accept it are not been meet.

The driver must be able to work for 15 years no matter what has changed in the kernel even if it means a wrapper. This is one hell of a requirement. This is why every push to get a stable Kernel ABI in the Linux kernel is failing.

Alfman you are thinking way too small of time frame. You are thinking time frames that are acceptable to Microsoft. The Linux world is the Linux world they have a complete different view on the problem.

Reply Parent Score: 1