Messages in this thread | | | Date | Thu, 15 Jul 1999 00:04:10 +0100 | From | Steve Dodd <> | Subject | Re: [Call For Wartectomy] CRLF conversion out of kernel |
| |
On Wed, Jul 14, 1999 at 02:50:52PM -0700, david parsons wrote:
> 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/
| |