Hello again Greg,
Hi (you forgot a "-" in my name :) well, GMail also represents you that way, without "-". So I follow the Google-friend :)
OK, let's leave the philosophical discussions aside between GPL and non-GPL drivers, for now.
Keeping up with Linux changing takes up driver developer's time.
Yes.
I believe having stable kernel ABI can save many work hours of driver developer's, because they won't need to update their drivers every time when someone else broke something.
I'm sorry you feel this way, but you haven't justified why this is so. If you get your driver into the main kernel tree, any changes to the ABI are done automatically for you. So that means that it saves the driver developer's time even more that way, as they do not need to ever update their driver again, which is not something that any other operating system can provide.
This also provides a more secure, and better product for the user in the end. They never need to worry about external drivers, and everything "just works" for them automatically.
This is a problem. Think of a developer. An OSS GPL one :) It takes 100 hours to make a driver (LKM), plus 1 hour per month to update it. But what happens, when he decided to move to another project ? If there are users to his project, but no developers among them, they are in trouble, because no-one will help them. 1. They could support themselves, if there was a stable API+ABI. 2. That developer wouldn't need spend extra hour per month just to update his driver, because it would "just work". Now - the newbie user: It is *really* daunting to update a kernel and find, that Nvidia driver (and X.org) do not run on my desktop anymore. The newbies among us will have to reformat&reinstall, because X.org won't start - no NVIDIA driver - and X doesn't have auto-fallback (which is a problem in itself, but not related), and they will end up booting into black-screen. And unlike Window's Blue Screen, here "reset" won't help. Proprietary company: 1. It is possible to talk to those companies, but again, they usually do not release their drivers as Open-Source, if they release at all. 2. Even if they release it as Open-Source, it may be outdated, and won't compile on new kernels - again users won't be able to use this driver. 3. Most proprietary companies understand that supporting out-of-tree LKM is very difficult, and may refuses to develop one for this reason. But it differently, with better API/ABI stability, more companies will invest in developing Linux drivers. I believe it is unfair model, where users need to waste a lot of time to fight problems, that shouldn't even exist.
And kernel interfaces are changing too fast.
How do you measure "too fast"? What rate of change would be acceptable for you? Can you quantify that based on the need for change in the market and environment that Linux is in?
Do you even know what our rate of change is? I just ran the numbers last week, and they are much larger than has ever been reported in the past...
Yes I know... ~2 million lines of code per month, or ~6m lines of code per kernel release (3 months). Any rate is acceptable by me, and no need to slow-down. Linux gains features very quickly now. But I'm not speaking about that - but about changes that break things. Other OS kernels (Windows NT 5.x, Solaris UNIX) have also hi rate of changes, yet they manage to stay more compatible.
I believe development can go without breaking _already working_ things. At least not every micro-release.
Please explain, in detail, how this can happen.
Also, please explain how the different points that are expressed in the file, Documentation/stable_api_nonsense.txt are not correct, and can somehow be handled with your proposed stable api.
I do not propose APIs/ABIs yet :( I should try to ask some serious kernel hackers beforehand. Otherwise I lack your "in detail" part of question, and I will miss the point. Sorry, cannot answer on this question fully this time. But generally, I can tell how it can happen: we need to look after ourselves and see which kernel commit requires other LKM developers most pain - i.e. most broken modules (both in-kernel LKMs and third-party, out-of-tree), then revert those changes back. Sounds stupid, but with time we will be able to guess-ahead what kinds of changes/commits makes problems to others, and try not to break those parts. This may work not like "stable API", but more like trial-n-error - "scientific method to stability". Again, I would like to discuss possible solutions... -- -Alexey Eremenko "Technologov" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org