>> Putting all the above into the kernel would reduce overall bloat.
>> Think about it. Every damn executable has the same startup code.
>> We'd save a page (few pages?) of code and data on every executable,
>> as well as all the system calls:
>>
>> All open() and close() calls are junk.
>> All mmap() calls may be replaced by direct VM manipulation.
>> All munmap() and mprotect() calls are junk.
>> The fstat() call is junk, since the kernel can just look.
>> The personality() call is junk. (directly read it)
>> The getpid() call is junk. (provide it in user-readable memory)
>>
>> On every exec, that kills 16 system calls and a bit of IO.
>
> The same arguments could be used to put every application into the kernel.
Well then, let's do it! :-)
No. Any app that isn't constantly in memory fails "reduce overall bloat".
That leaves init, /bin/sh, and X. Some systems actually do put those in
the kernel. We leave out init because performance doesn't matter much,
and it doesn't really _run_ very much. It just sits in swap. We leave
out /bin/sh because it is untrusted and already-bloated FSF code.
We leave out X because the server is a monolithic old beast that won't
cooperate with kernel memory management.
Look at every case individually. There are tradeoffs to consider.
I'm _not_ saying this is surely a win, but it might be one.
-
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/