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 577984
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Comment by shmerl
by Alfman on Thu 5th Dec 2013 09:11 UTC in reply to "RE[5]: Comment by shmerl"
Alfman
Member since:
2011-01-28

lucas_maximus,

"This is the problem with the Linux community, cannot and will not listen to any criticism no matter how valid."

Well, some people don't like hearing criticism of the communities they belong to. However it's no more true for linux than for other communities. You get the same kind of flack for criticizing microsoft and apple.


For what it's worth, I think linux should adopt a stable ABI. I've given it a lot of thought and in my mind a good compromise exists by making the ABIs stable between minor versions and allowing them to break between major ones.

Keep in mind that even though the windows kernel maintains long term kernel API/ABI, microsoft has never the less broken many existing drivers using those stable APIs due to new kernel restrictions (especially with win vista/7). Even with win8 I discovered the dameware mirror driver broke from win7. So from a practical user point of view, windows users sometimes have to go through similar kernel driver breakages (regardless of the underlying cause).


So for a linux example: a driver could be compatible with specific major versions like linux 3.x. A new driver build will be needed for linux 4.x. This allows linux to have most of the benefits of stable interfaces. Additionally linux would not get stuck with long term cruft in legacy interfaces that no longer make sense or aren't optimal for exposing the features of new hardware. Hardware manufacturers could stop worrying about individual kernel builds, only the major ones.

I think this is a very reasonable approach, but alas I am not in charge.

Reply Parent Score: 3

RE[7]: Comment by shmerl
by lucas_maximus on Thu 5th Dec 2013 09:30 in reply to "RE[6]: Comment by shmerl"
lucas_maximus Member since:
2009-08-18

Tell Linus that.

Reply Parent Score: 4

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

lucas_maximus,

"Tell Linus that."

This is not to change the subject, you can criticize linus all you want. However too often this criticism seems hypocritical. I have no more control over linus than I do over bill gates, and I've certainly got many complaints for him as well for the numerous times I've cussed at windows for not performing as well as I thought it should. All platforms have pros and cons. Anyone who only recognizes the pros of one platform and the cons of another is being biased. Can we agree on this?

Edited 2013-12-05 10:12 UTC

Reply Parent Score: 3

RE[7]: Comment by shmerl
by oiaohm on Thu 5th Dec 2013 10:35 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