:
: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
If it were a normal page we could, but the VM system currently cannot
handle pages associated with vnode
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 transmissio
:> 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.
:
:Isn't this a case that the programmer has to handle? That is, if you mess
:with the data before it actually
On Thu, 23 Sep 1999, 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
: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,
:excep
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 th
6 matches
Mail list logo
