Re: nvidia

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
========================================================================


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux