From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200602021816.k12IGrSH080631@gate.bitblocks.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Van Jacobsen's network stack restructure In-reply-to: Your message of "Thu, 02 Feb 2006 18:01:41 GMT." <5fe0afe15e6022332c471d92c932f4ce@vitanuova.com> From: Bakul Shah Date: Thu, 2 Feb 2006 10:16:53 -0800 Topicbox-Message-UUID: ef9f2716-ead0-11e9-9d60-3106f5b1d025 > >> one disadvantage of the library approach in the unix environment is that > >> you're once again back having to know which `access method' to use, > >> to pass the file descriptor or handle to the right library. > >> i might easily have misunderstood something though. > > > [reasonable explanation deleted] > > I bet they do something along these lines. > > yes, i supposed it could be something along those lines but i didn't make my > point clear. > if it is along those lines, it breaks something that even sockets didn't brea > k. > at the moment, i get a file descriptor that i can pass to anything that does > read and write. > now i've got something that i can only mmap, and even the mmap refers to a > non-trivial data structure shared with the kernel, and the recipient of the f > ile descriptor > must invoke special calls in a special library (ie, the `access method'). > i suppose you could call it TCAM Once you have mmap (and most versions of Unix do these days) you have already bought into the associated complexity. If you pass a file descriptor with an associated mmap to a process, what happens is determined by mmap flags used when the mapping was created. So all I am saying is that there is nothing "special" about it. It is no more "broken". And at least this is a useful extension (in that it can make the kernel simpler without losing performance if they take out any compatibility crap). If you exclusively used mmap for files, even more stuff can potentially be taken out of the kernel -- just pass the received data map directly to the file server process.