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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
