[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

Re: Fwd: Linux headed for disaster? >> My thoughts <<



Hi

These are just some of my thoughts.

> > From: KendallB@xxxxxxxxxxxxxxx (Kendall Bennett)
>
> Every single problem that has been mentioned as reasons not to implment 
> Binary Portable modules for the Linux kernel is solvable. In fact there 
> are *lots* of incredibly sound reasons for why the Linux kernel should be 
> re-worked to support binary loadable modules that are portable between 
> kernel versions, *even* for Open Source drivers, some of which are:
> 
>  1. A later version of a kernel may well have introduced new bugs into a 
> previously stable driver. Solving this problem currently requires the 
> user to revert back to an older kernel revision. Doing so may not be 
> desireable because the new kernel version may have updates and fixes that 
> are desired. With binary portable modules, the module a previous kernel 
> that did work could be used in place without problems (ie: it is expected 
> to work if unless there is an interface change).

Well I have 2 statements about it.

a) A NONBINARY SOURCE module can also solve this problem. If one finds that the
new driver code in a new kernel is not working properly, He can ALWAYS try
compiling the old driver source with the new kernel. 

However there is a problem here (i.e using Old driver with New Kernel core,
irrespesctive of SOURCE or BINARY) i.e if there is some major change in the way
things like Interrupts or Memory or PCI subsystem (etc. etc..) is handled by
the kernel core and the driver is using these Then the old source may not work
or for that matter may not even compile, but in such a situation I DON'T find
the Binary ONLY Module working either.

But if one has the SOURCE one can TRY FIXING the problem in the code and if he
hits the BULLS EYE he can GIVE IT TO OTHERS. Where as with a binary only driver
we are stuck for sure till the company gives us a updated driver.

I had faced this problem in Bangalore IT.COM when setting up the Diskless m/cs
and network cards. But as I had the source for the driver I could make a UGLY
PATCH!!!, but ONE WHICH WORKED :-) in 5 minutes. Well can one expect such a
solution from a Binary Only driver in such a short time.

b) Well even with BINARY ONLY DRIVERS its not always the case that it will work
with the newer kernel even if the INTERFACE hasn't changed ( I think Win2000
betas and also some WDM drivers could be a case in point here).  This is what
this guy means if I am not wrong when he says "i.e its EXPECTED to work if
unless there is an interface change." ( I made expected capitalized :-)


> 
>  2. Binary portability requires more solid and clearly defined interfaces 
> between the kernel internals and the modules themselves. By requiring 
> that there be a clear separation or 'firewall' between drivers and the 
> kernel internals, you can more easily avoid the classic problems of 
> coupling where changes in some other part of the code affect other code 
> that should not be affected. Specifically it makes it impossible for a 
> driver to implement a 'quick hack' solution by accessing the internals of 
> some other driver or the kenerl directly. However the *only* way to 
> enforce this is to design device type specific binary API's, and 
> *require* that the only way a device driver can talk to the kernel is via 
> these API's. 

If I may say so most of the kernel subsystems are well structured and have well
defined interfaces if one wishes to use them.  This is more to do with writing
CLEAN sources, which is also a requirement in Binary only drivers also.

> 
>  3. Binary portability means much less regression testing is required for 
> new kernel versions. If the driver itself does not get re-compiled, it 
> does not need to be thoroughly re-tested. If the case of the Linux 
> monolithic kernel approach, every driver is compiled into each new kernel 
> version. How do you *really* know that a driver is functioning properly 
> when a final release of 2.2.100 is made, unless *every* single device 
> that is supported is properly tested with that particular version?
> 

I don't see how a Binary only driver solves this problem. This is more to do
with CLEAN coding than anything else. With Source drivers we are at an
advantage as I have stated in argument for Point 1.

I hope he is not stating that re-compiling introduces errors, well this can
only occur if the compiler is screwed up.  I MEAN I can't take the argument
that "if the driver itself doesn't get re-compiled, it does not need to be
thoroughly re-tested. ". I mean I can NATURALY if I may say so EXTEND this
argument to say that if the DRIVER SOURCE hasn't changed then It doesn't need
to be thoroughly re-tested. Then WHAT IS his problem regarding testing.

> 
> The specific example Linus used in his response above was 3dfx. 3dfx is 
> opening up their information because it makes sense for them to do so, 
> not because they are being forced to do so. The information is being used 
> to implement XFree86 drivers, which are *not* GPL'ed, so obviously it 
> isn't a GPL requirement that is making them open up their specifications. 
> XFree86 is under the X/MIT license which specifically allows for use in 
> commercial projects (same license used by FreeBSD). More importantly 
> XFree86 4.0 is designed around the concept of user land binary portable 
> modules, specifically to solve the above mentioned compatibility 
> problems. On top of this, there are commercial X-server vendors for Linux 
> that 3dfx could have had implement their drivers, and continued to keep 
> them closed source. They didn't do that because they realised it is 
> cheaper and makes more sense to have those drivers be Open Source rather 
> than closed source.
> 

Well thats my (for that matter most peoples) point also. i.e It MAKES MORE SENSE
for hardware vendors to have open sourced  drivers in the LONG RUN if they are
having a product thats to be used by the Linux community or for that matter
which ever community its i.e Windows or Solaris or whatever. It finaly helps
the END USERS who aren't worried about all these AS WELL AS the NIGHT OIL ones.

Thus I can sum up this persons mail as a mearly COMMERCIALY MOTIVATED stuff
than anything else.

---------
Keep :-)
HanishKVC
http://hanishkvc.tripod.com/