[ On Friday, July 28, 2000 at 16:09:32 (-0600), Chris Torek wrote: ]
> Subject: Re: mmap (was Re: bin/10625: /usr/bin/cmp)
>
> Theoretical exercises for you: :-)
> 
> - When and why would read() necessarily be any different from
>   mmap()-and-access?  

In what sense?  :-)

If read() were implemented in such a way that the kernel could map the
user-supplied buffer into its own space so that the device driver
(perhaps even through DMA) could fill it directly then there would be
literally no difference in the underlying behaviour between read() and
mmap().

> - When and why would write() necessarily be any different from
>   mmap()-and-access-and-munmap()/exit/otherwise lose reference
>   to page(s)?

Well in NetBSD the difference is, for the time being, and if I
understand correctly, that a process using mmap() and another process
simultaneoulsy using write(), both to the same file, will not
necessarily co-operate in the same manner as two using mmap() or two
using write().

> and then:
> 
> - Is it possible, feasible, and/or desirable to have the kernel
>   implement read()s on page-and-block boundaries in a manner that
>   makes them largely indistinguishable from mmap()-and-access?

Well the question is all about alignment and size now isn't it!

When I first saw readv() and writev() I briefly wondered why they hadn't
been implmented in more the way of mmap(), i.e. why readv() in
particular didn't provide pointers to storage that had been mapped
directly into the process  I suppose this might be easier to do in this
way if one could get malloc() [or whatever] to co-operate with a an
mmap()-style interace and thus share the same heap.

> (The 4.4BSD stdio already works fairly hard to cause reads to happen
> on block boundaries contained exactly within whole pages.)

Indeed, and as I understand it Sfio is able to take even better
advantage of the same techniques when using mmap() as it can also
avoid the extra memory shuffling.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>