From owner-freebsd-hackers Thu Sep 23 11:18:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2C38914E2C for ; Thu, 23 Sep 1999 11:18:10 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA29093; Thu, 23 Sep 1999 11:18:05 -0700 (PDT) (envelope-from dillon) Date: Thu, 23 Sep 1999 11:18:05 -0700 (PDT) From: Matthew Dillon Message-Id: <199909231818.LAA29093@apollo.backplane.com> To: Christopher Sedore Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mbufs, external storage, and MFREE References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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 gets written, that's your problem. I :take it that vfs.ioopt stuff is something like a temporary mmap() effect, :since in the socket case once the data had been put in the buffer, I'd :remove the kernel mapping and thus not be able to tweak it. Yes and no. Sometimes changing data out from under the kernel can cause bad things to happen. For example, changing TCP data out from under the TCP protocol will screw up checksums, and making changes to a buffer undergoing DMA might screwup a device protocol crc or do something worse. The kernel thus needs to ensure that nothing the user does can screw it (the kernel) up. :> For user memory, the only way such a mechanism can currently be :> implemented is by obtaining the underlying pages and busy'ing them :> for the duration of their use by the system, causing anyone trying to :... :> : :I had been thinking about this in the context of async io operations, :where its OK to have the operation not complete until the data has :actually been ack'd by the remote end. With synchronous write() calls, :this can be more problematic since it would significantly increase latency :in cases where the original coder might not expect it. It might actually :be nice to (optionally) have the same effect with async writes to disk, :where the operation wouldn't actually complete until the data was known to :be on the platter. : :-Chris I think asynchronous I/O is the way to go with this too. An asynchronous API formally disallows changing data backing an I/O while the I/O is in progress (though it may not necessarily physically prevent the process from doing so). There is much less chance of the programmer making a mistake. Almost all of my embedded projects use asynchronous event-oriented I/O and simply eat the data out of the user process's memory space directly. Buffer copying is *really* expensive on a 68K cpu. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message