lkml.org 
[lkml]   [1999]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectWhy Linux is doomed (was: Re: FENRIS (nwfs) 1.4.2 Source Code Available)
In local.linux-kernel, you wrote:
> > just saying we should try to assess the impact on the commercial Linux
> > vendors, and try to give them adequate warning, but progress also has a
> > price and I agree it's difficult tightrope to walk.
> i think we can assume that the Linux filesystem architecture goes only
> 'forward', so things will keep getting cleaner and it will be more and
> more easy to integrate new filesystems.

Oh yeah?
To me, this is the complete opposite of what I have seen in the past.
Yes, there are a lot of file systems out there. BUT:

reiserfs fails to compile all the time. First the dentry stuff
broken, then the semaphore initialization broke, now the buffer
cache stuff, tomorrow what?

Please have a look at reiserfs. It looks like a great file system, and
Hans is paying someone else to do the coding. Now, he _should_ just be
able to concentrate on coding his file system and tree knowledge and use
the well-publicized kernel API.

Wait, did I say well-publicized kernel API? The kernel API is not just
not well-publicized, it changes all the time! Hell, how can it be that
a supposedly stable kernel release does not even _compile_ without
syntax error on non-x86 platforms?! This is not only embarassing, it is
much more unprofessional than Windows NT needing BIOS support to install
on Alpha.

Let me reiterate some things that happened to me recently:

1. I have an Alpha here. The vendor ships it with Redhat 5.2, which
IMHO stinks. It has an old library, an old egcs, ...
But my vendor (Quant-X, btw., whom I can not praise enough in
public) installed a working 2.2.5 for me.
2.2.7 came out, I untarred the distribution, it did not compile. I
had to fix some trivial things that _anyone_ must have seen who
tried to compile the kernel, like an include file that was not
included somewhere. I cannot understand how a kernel like this can
even be put on an FTP site without even trying to compile it on all
platforms.
Anyway, 2.2.7 compiled with minor massaging, but randomly hung at
boot time with a "spinlock stuck" message. I tried to get rid of
that and tried to install 2.2.8. It would not compile. 2.2.9. It
would not compile. I then switched to 2.3.6-ac1 that actually
compiled.
2. I have a laptop. pcmcia is a vital kernel part for laptop users.
And frankly, I cannot understand why this is not part of the
standard kernel. I marvel at the quick turnaround time of the
pcmcia guy at stanford who manages to adapt to kernel problems
within hours after the new kernel comes out. Anyway, once it
didn't work. Again, the semantics of something changed.
3. ALSA. ALSA is a must for me at home. The kernel sound driver for
my 1370 not only clicks and pops all the time, it can also suddenly
die off completely. So, I need ALSA. The ALSA guys recently did a
new release that also works with the new semaphore stuff, but
before that release came out, I had to fix things manually. So I
looked at the kernel diffs but the resulting ALSA still crashed.
For some enlightenment about how painful their compatibility layers
have become so that ALSA compiles on many kernel versions, please
look into the header files of the alsa-driver package. I can
almost feel their pain when I see those macros.
4. FAT. 2.3.7 does not compile with FAT file system. Excuse me?
This is the single most frequently used file system besides ext2,
and 2.3.7 does not compile with it? Because of a syntax error?!
5. Modules. I get unresolved symbols every other kernel. Does nobody
try to compile everything in once and everything as module once
before releasing a kernel? Yes, that is work. But how can you
tell Ziff Davis that Linux is a professional enterprise-ready
operating system if blunders like these happen?

Management summary: stuff like this sucks. I am but a programmer with a
SMP box that likes to run the latest kernel. And yes, I expect all the
kernels to compile out of the box. I don't think that this is too much
to ask.

Nowadays, people do not compile their kernels anymore. Their
distribution comes with a kernel, and they use that one. This shields
us and Linux from most of the blame, since people think it's their fault
if the new kernel does not compile. But this is no good situation. I
can practically see before my mental eyes a Microsoft sales weasel
showing people "make config" and then compiling a kernel where FAT does
not compile! I mean, just the normal compilation messages look like
martian cryptography to normal people, but if you tell them "see, now it
broke", _nobody_ in the audience will actually tell you "but you have
the source, you can fix it if you are smart enough".

Thus, I propose these changes:

1. No More Function Renaming.
People are actually using your test kernels.
Yes, you warned them, but what does that help the user?
I, for example, have to use a 2.3 kernel, because the 2.2 kernel
just freezes when I NFS-mount my laptop.
2. No more incompatible changes.
The whole idea with the VFS was that you could develop a file
system modularly. If I wrote a file system (and I thought about
this for a while), I would be royally pissed if I had to spend my
development time working around changes in the kernel.
Of course, there is the necessity to change things from time to
time. But if you rename(!) a function in the kernel, is it too
much to ask to do a global search-and-replace in the rest of the
kernel?
3. Create some decent abstractions.
You can change all the semaphore stuff you want when you give the
programmers some macros to create a consistent, non-changing
interface.
4. When you do a change in the kernel, DOCUMENT IT.
Let's create a new directory, Documentation/incompatible-changes.
There you just create a new file for each change that says "if you
get an undeclared symbol foo_bar then edit this file and rename it
in your code to bar_foo". Then a driver developer can just grep
there and be done. You don't actually expect a driver developer to
read all the kernel patches and see if the same problem hit someone
else before, do you?

Felix

-
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:52    [W:0.068 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site