On Tue, 30 Oct 2007, Les Mikesell wrote: > Robert P. J. Day wrote: > > On Tue, 30 Oct 2007, Les Mikesell wrote: > > > > > Robert P. J. Day wrote: > > > > > > The difference is that closed source OS's rarely change their > > > > > > driver interfaces, so it would be extremely unusual for > > > > > > something that already works and I have put into production to > > > > > > suddenly fail due to an update. > > > > > I find this an astonishing assertion. Surely the Linux kernel > > > > > interface changes reasonably often? > > > > um ... no. the kernel *internal* interfaces may change, but the > > > > interface that is presented to the outside world is very stable. > > > > > > > > http://lxr.linux.no/source/Documentation/stable_api_nonsense.txt > > > > > > > That's fine if you believe that the linux kernel will always > > > include every device driver, filesystem, and feature you'll ever > > > want. Don't ask me to join you in that leap of faith (or > > > arrogance, or whatever it is that makes you think > > > interoperability is unnecessary)... > > > > what are you babbling about, les? all i did was clarify the > > distinction between the stability of the *internal* kernel > > interface and that of the *external* kernel interface. i said > > nothing whatsoever about driver support or interoperability. > > Errr, what? How can you say that the internal kernel interface does > not relate to the drivers that use them? errr ... did you actually *read* the document for which i provided a URL, les? ***of course*** changing the internel kernel interfaces will undoubtedly affect the drivers which have been written to those interfaces. and when those interfaces change, ***of course*** those drivers will have to be updated to conform to the new interfaces. from the document above: "Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. If they do that, they then fix the current interfaces to work better. When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked. If this happens, all of the instances of where this interface is used within the kernel are fixed up at the same time, ensuring that everything continues to work properly." see how that works, les? when enough people in the kernel development community decide that an internal interface needs to change, everyone (theoretically) works together to make that transition as seamless and trouble-free as possible. and (note well) that all of that should be invisible to the outside world -- only driver developers need care. so what's your problem? what exactly bothers you about this process? rday p.s. also note, les, that if a given driver is in-tree, that driver's author doesn't even need to know about this, since it's the duty of those people making the change to *also* take care of all code that calls that interface. did you seriously think that someone might change an internal kernel interface and just leave all the broken calls to it hanging around in the kernel source tree? -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ======================================================================== -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
