lesmikesell at gmail.com
Tue Oct 30 13:02:37 UTC 2007
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.
>>>> 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
Yes, I read it. That doesn't make it true, and my response applies.
> 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
> 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?
Exactly what I said before which apparently you didn't read. Neither
experience nor blind faith lead me to believe that Linux will ever
include all the drivers I might want. When Linus was just out of
college he might have used the lack of experience to justify not wanting
to freeze an interface because he might get it wrong. At this point I
no longer believe that excuse. Interfaces should be treated as
contracts among programmers that aren't whimsically ignored.
> 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?
Yes, using fedora I have had things break frequently. If you don't
actually use an assortment of different hardware perhaps you haven't
noticed. Even if I only used Linux on common hardware today, I would be
concerned about depending on it and being unable to move to hardware
with only vendor binary drivers in the future should that be the best
hardware choice. And in my opinion this is the most significant reason
that the majority of computers today don't run Linux.
lesmikesell at gmail.com
More information about the users