Messages in this thread | | | Date | Wed, 27 May 1998 13:29:11 -0400 | From | Jim Nance <> | Subject | Documentation/NotInKernel Was Re: oh woe |
| |
Donald Becker <becker@cesdis.gsfc.nasa.gov> writes: > > On a loosely related flame: As a community we are doing a very bad job at > minimizing kernel bloat. It's too easy to add new code, and few people that > add code are willing to support it for more than a few months. No one is > saying "that feature is neat, but it's not useful for most users. Keep it > as a seperate kernel patch". Example: years ago we made a decision not to > implement BPF, because the interpreted packet-filter "language" wasn't a > good design to put into a kernel. But that decision was reversed by someone > that apparently thought "oohhh, it doesn't have this feature. Lets add it." > How can we keep a greatly-needed-void empty?
Part of the problem is probably that decisions get made about what not to do, and there is no mechanism to pass this information to new people.
Perhaps we need a file in the Documentation directory that tells people things that we dont want in the kernel as opposed to things we would like but no one has written yet. To be really useful, it would be good to also give pointers to ways to work around the missing features. I could probably maintain such a list if people want it, but I dont have the political clout to decide whats going to be on the list.
My suggestions for items to include in the list, along with information I need about these items includes:
1) Why arn't STREAMS in the kernel? - Need pointer to kernel STREAMS patch - Need pointer to user space STREAMS implementation 2) Why doesn't Linux have nice boot graphics? - I think we have decided this belongs in the boot loader? - Is anyone working on putting this in a boot loader? 3) Why don't we rewrite the kernel in assembly language?
If you have more ideas, send them to me, or post them to linux-kernel.
Thanks,
Jim
PS On the subject of bloat. When I first started reading alt.os.linux there was a very heated debate raging about whether adding a system call to the kernel to read the process table for ps was worth the increase in kernel size. This was a long time before /proc. Its interesting how things develop.
-- ---------------------------------------------------------------------------- Jim Nance Avant! Corporation (919) 941-6655 Do you have sweet iced tea? jim_nance@avanticorp.com No, but theres sugar on the table.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |