nvidia

[Karl Larsen]

Robert P. J. Day wrote:
> 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?
>
>   
    A while ago a very smart man told me that you NEVER change a kernel 
unless you need something the new kernel provides. If the one I have now 
that I got 1 day ago really do ME more good? NO.

-- 

	Karl F. Larsen, AKA K5DI
	Linux User
	#450462   http://counter.li.org.