On Wed, Jan 23, 2008 at 10:27:38PM +0200, Janne Karhunen wrote: > On Wed, 2008-01-23 at 09:00 -0800, Greg KH wrote: > > > 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... > > No-one really cares what the rate of change is provided that > amount of regressions stays relatively low. Surprisingly, it > has. And that _has_ to be major surprise for everyone.
Yes, a very pleasant one :) > > > 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. > > If it's really trivial driver; otherwise you have to commit > yourself to be the maintainer and constant API tweaker anyway. No, not at all. If I change an internal kernel api (like I just did in the kobject core), then it is up to me to fix up all users of that api in the kernel so that nothing breaks. The original developer does not have to do any work. Lots of developers go away after they get their driver into the kernel tree, never to be seen again. And their code keeps on working just fine. I can name hundreds of drivers like this. In the end, the development time for a driver developer for Linux is less than that of other operating systems as the maintaince is done for them for all future versions, and the ammount of code they have to write in the first place is smaller. What's not to like about that? :) > > 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. > > As I told you before, this is a nice idea but 'in real life' > it's load of bollocks :). If we don't make it possible for > users to install 'out-of-tree' drivers (and just drivers, > nothing else) they are forced to do major kernel update > after each new gadget bought. And that, in real life terms, > means totally new OS to install. Plug and play, you say? No, not at all. You should be able to drop in a new kernel just fine, with only minor package updates at times. As proof that this works, I was just talking with a very large company that relies on Linux last week. They use RHEL 3 on almost all of their systems. But as RHEL 3 is 2.4 based, and doesn't support a lot of new hardware, and has lots of other issues, they just drop in the latest 2.6 kernel on their own, and their developers never even notice the difference, except that their machines work better. So, in the "real life" it isn't a load of bollocks, sorry :) > IMHO the whole concept of providing complete kernel in one > huge blob is flawed. Optimal case would be to break it into > pieces with no dependencies. I'd be interested in seeing your patches to attempt such a thing. > > > 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. > > It's not incorrect, it's just that you have basically ruled > out regular users to serve joe random hacker (a guy that > doesn't mind installing new OS twice per year). I'm fine > with that, but I doubt that was the original strategy. > > That said, IMHO kernel is doing great. It's the Linux > userland that sucks. Hey, patches always are gladly accepted :) thanks, greg k-h -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
