Messages in this thread | | | Date | 23 Jun 1999 14:16:35 -0000 | From | leitner@converge ... | Subject | Why 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/
| |