Date: Mon, 1 Dec 1997 16:21:30 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: templin@erg.sri.com (Fred L. Templin) Cc: toor@dyson.iquest.net, freebsd-hackers@freebsd.org, templin@erg.sri.com Subject: Re: copyout()/copyin() Message-ID: <199712012121.QAA04154@dyson.iquest.net> In-Reply-To: <199712012114.NAA10819@grayling.erg.sri.com> from "Fred L. Templin" at "Dec 1, 97 01:13:57 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Fred L. Templin said: > > I was actually checking into physio() when your message arrived. physio() > seems to be appropriate for "semi-synchronous" activities like reading/writing > from a raw tape device. The process calling physio() basically posts a raw > buffer to the device then sleeps until the device driver calls "iodone" which > issues the wakeup(). My scenario calls for the process to post many buffers to > the kernel; each of which will be serviced asynchronously. I'm fine with > locking the process virtual memory (by setting the "P_PHYSIO" flag?) > That won't keep the process from paging. You'll have to specifically lock memory with either the userland mlock, or add it to some kind of ioctl or read request that would do the right things in the kernel. > >but > am I asking for trouble trying to manage multiple small buffers this way > rather than one monolithic buffer as is done for physio()? > Not really. Look at what I am doing with the AIO code (vfs_aio in -current as of today.) > >Also, what happens > if my process crashes after I've mapped the pages into kernel space? > Unpleasant things like pages being freed with bad hold count crashes. You'll likely want to write a driver that gets called when the process exits (e.g. when the driver is closed.) You might try some kind of rundown mechanism. -- John dyson@freebsd.org jdyson@nc.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712012121.QAA04154>