lkml.org 
[lkml]   [1999]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: dso loading question
Date
Ralf writes:
> On Sun, May 30, 1999 at 03:11:23PM -0400, Albert D. Cahalan wrote:

>> 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.525 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site