Matthew Dillon wrote...
> :I have the following question:  Let's say that I have a block of user
> :memory which I've mapped into the kernel, and would like to send on a
> :network socket.  I'd like to simply grab an mbuf, point to the memory as
> :external storage, and queue it up for transmission.  This would work fine,
> :except that when MFREE gets called, I have to write an deallocator that
> :maintains a table of all the different cases where I've done this, and do
> :a reverse mapping back to the original block, and then deal with sending
> :more, unmapping, etc.  In other words, having MFREE call a deallocator
> :with just the data pointer and the size is inconvenient (actually, it
> :would make my scenario quite inefficient given the number of mappings back
> :to the original block that would have to be done).
> :
> :Am I missing another mechanism to handle this?  Does it not come up enough
> :to matter? 
> :
> :-Chris
> 
>     This is almost precisely the mechanism that the sendfile() system call
>     uses.  In that case it maps VMIO-backed data rather then user memory,
>     but it is a very similar problem.
> 
>     There has been talk of implementing this type of mechanism not only for
>     sockets, but for file read()/write() as well.  In fact, John Dyson had
>     delved into the issue with his vfs.ioopt stuff before he ran out of time.
> 
>     The one problem with using direct VM page mappings is that currently there
>     is no way for the socket to prevent the underlying data from being 
>     modified in the middle of a transmission.  And, in the same respect for
>     vfs.ioopt, no way to prevent the data the user ostensibly read() into
>     his 'private' buffer from changing out from under the user if the
>     underlying file is modified.

How about marking the page copy-on-write?  That way, if the user modifies
the page while it is being transmitted, it'll just be copied, so the
original data will be intact.

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to