lkml.org 
[lkml]   [1999]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux headed for disaster?
* Kendall Bennett said:

> > > are portable between kernel versions, *even* for Open Source drivers,
> > > some of which are:
> >
> > Not really. The binary format is dependant on compiler,
> > architecture, SMPness and a dozen other things. The source is not.
>
> As I said above, all these problems are solveable. You can solve
> these problems easily by making sure your interfaces handle things
> correctly. There are ways to normalise differences between compilers,
> and compatibility tests are what you should use to check this.
As Alan said, this only makes the interfaces more cumbersome, slower, harder
to maintain and extend. You have to constantly think about being backward
compatible - just as Windows 9x is backward compatible with DOS 2.0
software, which kills 70% of its would-be potential.

> Take XFree86 4.0 for instance. They support binary loadable modules
> and they don't have these problems.
XF86 is a user-level program which has no idea of many issues kernel has to
worry about - I mean low-level stuff, like SMP, fs access etc. XF86 has
high-level, user-level interfaces which are much easier to deal with than
the low-level driver stuff.

> > Binary compatibility killed windows. Windows 98 could have been a
> > much nicer OS without back compatibility.
>
> Sorry, I completely disagree here. Backwards compatibility in Windows
> 9x was a choice that Microsoft made to sell the OS (and it worked;
> OS/2 would have killed NT otherwise).
Yes, it worked - but the price for any serious user of their OS was way to
high - they traded stability for backward compatibility.

> The binary driver model has *absolutely* nothing to do with the
> stability of the Windows platform, and given the amount of respect I
> have for you, I feel you should understand this quite well. The
> Windows 9x platform is unstable because the foundation it was built
> on (the 16-bit Windows 3.1 kernel) was not well designed to begin
But what you describe *is* binary driver model compatibility! Being based on
old, horribly designed DOS overlay, Win9x is itself just a more capable
overlay with all the problems stemming from the *binary* (as the source
compatibility really doesn;t matter with Windows) compatibility.

> with. Win32 services were wrapped around an inherently archaic, 16-
> bit kernel. Windows NT is a totally different story, and a hell of a
> lot more stable than Windows 9x.
Win32 itself is changing a lot and there are cases when binary Win95 drivers
won't work with the later 9x versions. WinNT is more stable than Win9x,
because it has almost *no* binary compatibility with previous versions on
the driver and lower levels.

> Windows NT supports binary drivers, but you didn't say that binary
Hmm... Take a look at any driver floppy coming with WinNT supported software
- you have separate drivers for WinNT 3.x and WinNT 4+ - why? Because the
driver model has changed. This is *not* binary compatibility. And why so
much hardware doesn't work with NT? Because there are *no* older and
compatible drivers that work with NT 4.

> drivers killed Windows NT? OS/2 has binary drivers, and OS/2 is
> probably one of the most stable OS'es around (Warp Server for e-
> Business is incredibly stable). One reason why OS/2 is so much more
> stable than Windows NT is because IBM takes binary compatibility and
> conformance/regression testing *very* seriously (I know, because we
> license our technology to IBM).
And you have to admint OS/2 is much slower? I'd attribute that to too many
layers which exist to provide the binary compatibility.

> > I see no reason to kill Linux by re-enacting proprietary OS history
> > with a free OS.
>
> It got nothing to do with this. It is all about what mechanisms can
> be put in place to allow for better compatibility with the vast
> 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.
Somehow Linux survived several long years without what you propose, and is
still really well - more, it's getting better. With source code availability
you, as the concerned vendor, can setup a dedicated compilation server with
your drivers precompiled for the most common and the latest Linux kernels
and provide your users with a service to download, upgrade and install your
drivers without hassle. If there's no version of your drivers for their
particular platform - just ask them several simple questions (architecture,
compiler used to compile their kernel etc.) in a nice web-based form and
after several seconds give them a ready binary package. This *ALL* can be
nicely done in the user space without messing with the kernel.

> > rpm --install emu10k.i386.rpm
> >
> > and have it build my a SBLive! module for my system and do the
> > dependancies. Ditto for dpkg.
>
> You miss one very important point which you did bring up briefly as
> 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
> seen compatibility problems where something should work (and did work
> before) but a minor change, compiler bug or something else stopped it
> from working in a future revision?
What's the problem? You always KNOW what version the kernel was compiled
with. The only information missing would be what optimizations were used to
compile the kernel, but its rather easy to embed this info in the kernel if
need arises.

[snip]
> component was written 5 years ago with MSC 6.0c, it is re-built with
> MSC 6.0c for the latest Warp Server for e-Business platform. Why?
> Because that is one way to ensure repetable results.
As said above, you *CAN* do the same without modifying the kernel.

[snip]
> I am more interested in the future stability of Linux. I want to see
> Linux succeed, but it needs better support for compatibility and
> regression testing IMHO.
Binary compatibility != stability. Binary compatibility == problems, and it
was chosen by MS because of their closed-source model. In OpenSource it is
not necessary - it can be done in other ways, more clean, nicer and elegant.

[snip]
> Imagine how bad the compatibile of XFree86 would be if no-one
> bothered to ensure that the latest servers work properly on the old
> S3 Vision chipsets? You can be sure no-one at S3 wants to help
> support those boards, because they would much rather upgrade you to a
> Savage2000. But developers on the XFree86 list have those boards, and
> do reguarly test them to ensure backwards compatibility.
You're giving examples from a completely different fairy tail. XF86 has a
much easier case to deal with.

regards,

marek
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.158 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site