lkml.org 
[lkml]   [1999]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Linux headed for disaster?
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > > I see no reason to kill Linux by re-enacting proprietary OS history
> > > with a free OS.
> >
> > number of devices that Linux supports. A *real* operating system is
> > just not going to be able to survive unless some procedures and
> > policies are put in place to ensure future compatibility with legacy
> > hardware.
>
> We've put procedures in place. Its called *SOURCE CODE*. The NCR
> 5380 for example is the most godawful pile of crud scsi controller
> on the planet. Its old while good for its time nowdays is a joke.
>
> Because we have this *SOURCE CODE* stuff it still works in Linux
> 2.3.30pre6 and people have extended it to support other platforms.
> So its extensible, its adaptable.
>
> Its also *maintainable* which is the most important item of all. I
> can take a bug report and look at the controller source and say "ok
> thats a driver bug".

What I am trying to get across is that binary portable modules help
to solve driver compatibility problems when you do new releases of
the Linux kernel. I am not trying to say that the source code should
be closed. Obviously the Open Source nature of the NCR 5380 driver is
what allows it to continue to be supported.

Binary portable drivers are important to ensure compatibility between
builds of the Linux kernel. If you don't have some kind of binary
driver mechanism, regression tests and well designed device driver
API's, every time you recompile the Linux kernel you may well
introduce new problems that need to be fixed.

I am however not sure it is worth continuing to argue this anymore,
because I don't think anyone developing for the Linux kernel really
understand these issues. Everyone seems to keep regurgitating the
classic reasons for advocating Open Source, instead of understanding
that I am talking about methodologies to help solve compatibility
problems with the existing Open Source drivers.

> > as something against binary portable drivers. Pure source drivers are
> > adversely affected by compiler compatibilty concerns, and unless the
> > user is bulding the updated sources with the *exact* same compiler
> > revision and kernel source code, you don't really have any idea
> > whether it will work. It should work, but how many times have you
>
> Which you can package in with the build rules. They do
> dependancies. You can do a compiler dependancy. Debian for example
> pacakages gcc 2.7.2.3 for the same reasons you give. Not a
> problem.

And that is a good thing. I am glad to know that mechanism exists in
Linux. But how many people actually have multiple gcc revisions
installed on their systems so they can do repeatable rebuilds of the
kernel?

One thing that has always bugged me is that when I get a new Red Hat
distribution, I can compile the kernel sources that come with it and
expect that it will probably work as well as the pre-built kernels
that came with in the box. However if I upgrade my compiler, upgrade
my kernel sources and start upgrading random pieces that Red Hat has
not specifically tested, then it all starts to fall apart. How can I
feel confident that it will really work, when the vendor I pay money
for support can't possibly have tested my particular configuration?

The only solution of course is to stick with the official Red Hat
distribution and only do official upgrades. But then I can't reliably
take advantage of a new device driver until Red Hat gets around to a
new version.

> > Sure I would like to see binary portable drivers in the Linux kernel
> > so we can better support our products (of which some don't fit at all
>
> Feel free to take the source tree, build a binary only compatible
> environment and distribute it. Just keep to the GPL terms and don't
> expect anyone in the mainstream community to do anything with bug
> reports versus it but bounce them to you

We will do that for what small things we need in the Linux kernel for
our products. But what if I build a mechanism that will allow for
this to be done even for Open Source projects? Last time we spoke via
email you indicated that such patches would never be accepted into
the Linux kernel.

Regards,

+---------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+---------------------------------------------------------------+
| Kendall Bennett | Email: KendallB@scitechsoft.com |
| Director of Engineering | Phone: (530) 894 8400 |
| SciTech Software, Inc. | Fax : (530) 894 9069 |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+---------------------------------------------------------------+


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.197 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site