> Broken behavior in one filesystem is not the "weight of years of
> accumulated cruft".
No, obviously not. But if you apply the same principles to everything else,
that's what you'll end up with.
> Hey, if I could take 2.2.x device drivers and plug them into
> 1.2.13, I'd do that and get 220k back on my install floppies.
Well, if we let the cruft build up, that 220k could be even larger. This is
the point. I doesn't just take up space on boot floppies, it eats unpagable
memory, too..
> oddly enough, there have been 4 releases of the kernel since then
> with 4 different device driver interfaces (and nothing but paranoia
> and contempt for any attempts to publish a driver interface), so
> nothing will work without massive hackery.
I think last sentence sums it up. The driver interfaces (generally) don't get
broken for fun: it's done for a reason. If it was easy to convert a 2.2 driver
to a 1.2 one, then that would indicate that the interface was changed for no
good reason. The fact that it would need 'massive hackery' indicates that the
interface probably changed for a good reason. Without examining the code and
knowing if you're talking about net, block, char or some other drivers I don't
feel able to say for sure, but that's certainly the way I feel.
> But why the devil should I reward sloppy coding practices by taking
> all my toys and playing with a different crowd?
I'm not sure I got that. Whose sloppying coding practices are you referring to?
> Even if Linux wasn't Unix's only hope,
I don't think it is. *BSD seem to be doing pretty well, and I also don't feel
that Linux == Unix. I don't feel that Unix compatibility is the ultimate goal
now; if new APIs have to be invented to implement cool new features, I expect
it will happen.
> there are massive benefits to making it
> easy to upgrade to new kernels.
The *BSD crowd have an advantage there. If, for example, they drop a duplicated
interface from the kernel, they can implement it in user space, happy in the
knowledge that people upgrade their libc when they upgrade their kernels.
The things I don't want to see happening a few years down the road are a dozen
different entry points for the same functionality all with slightly different
parameters, nor loads of horrible structures with fields for the structure
size and version. That's fine in user space, but you don't want it in the
kernel.
Thought:
Would it be worth having a library _under_ libc which contained functionality
which was basically user space parts of the system API? libc used to be just
that - the _C_ standard library, for C programs; a library of utility functions
designed for programs written with the C mentality. Programs written in other
languages shouldn't have to link against libc, but at the moment they'd miss
out on a huge wodge of system functionality.
I'd see things like fopen, fprintf, atoi, strcmp, etc., stay in libc, but
for all the system level stuff like syscall wrappers, user / group / service
database funcs, resolver stuff, etc., in a libsys or liblinux or something.
That could be maintained alongside the kernel, and be pretty small.
Admittedly, it wouldn't be truly language independent because of calling
conventions, but am I right in thinking that C style conventions are pretty
much a de facto standard now?
Do you remember the system libraries on the Amiga? That's what I'm aiming for.
-- I do not find in orthodox Christianity one redeeming feature. - Thomas Jefferson- 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/