On Thu, Jan 24, 2008 at 11:25:23AM +0200, Janne Karhunen wrote: > On Jan 23, 2008 11:08 PM, Greg KH <[EMAIL PROTECTED]> wrote: > > > 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. > > API tweaking might be done for you automatically, but > certainly _not_ maintenance or testing. Or don't tell me > you have every piece of hardware supported by Linux > available and that you actually do test if you broke > them :)
API changes are almost always made in such a way that they break when the code builds. So if you fix up the build, the code will work properly. And no, I don't have all the hardware at all, that's impossible. I've written drivers for devices where I have never seen the hardware, and they work just fine (or so I'm told.) Having the hardware, or even access to it is not a requirement at all to do development and/or maintenance. > So most certainly maintenance is not done. And actually, > most of the testing effort done against the original driver > was just rendered useless with the API tweak. No, not at all. That's just not how the Linux kernel development process works, sorry. I can go into the whole testing process if you really want to know, but that has nothing to do with the change of APIs. I find it odd that people who do not have experience in doing Linux kernel development and API changes would insist that the current model we are using is broken... > > > > 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. > > Joe Random Hacker can, regular user can't. rpm -ihv new_kernel_package.rpm zypper install new_kernel_package.rpm or use some gui tool. People do it all the time. And they help us out with testing in ways that we developers can not do. So yes, "regular user" can do this, and they do, every single day. > That, and I don't think SUSE would be too happy supporting > 2.6.23.14 for SLED10 either. Andreas, would you be happy > with it :) ? But we do support it for openSuSE, right? I have argued that the SLED model is broken in the past, so let's not bring that up here again. The "enterprise" model does not lend itself to changing the kernel like this I know, and that is one reason I do not think it is viable over the long term. But again, that has nothing to do with the issue at hand. If Novell wants to continue to support SLED, then they will do the backporting for you, and then you just install a new kernel (like you do for security updates, which also happen to suck in a lot of driver updates at the same time.) > > 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 :) > > OK, try asking your auntie to do the same thing ;) My anutie doesn't run RHEL3, she's smarter than that :) > > > 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. > > With current design this would probably be impossible :/ Ok then, so you are asking for something that is impossible :( But why do you think we have made it so impossible, could it be that this model happens to be better? Nah, those kernel developers, they don't really know what they are doing at all... Gotta love the trust... greg k-h -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
