------_=_NextPart_001_01BE7AC4.952F4BE0
Content-Type: text/plain;
charset="iso-8859-1"
But there are various other horrible problems. If it were that easy, I'm
sure the kernel would have supported it long ago.
1) What to do if the process is killed while the pages are locked?
2) What if you have multiple threads trying to access the buffer
simultaneously, or, worse yet, you're using asynchronous DMA reads and
writes?
3) What if multiple DMAs are trying to access the same buffer? Who should
win?
I'm writing more robust code for character and streaming drivers that
attempts to address these issues. Stephen Tweedie (sct@redhat.com) has some
patches already available that will do direct I/O by wrapping block drivers.
His code is at ftp://ftp.linux.org.uk/pub/linux/sct/fs/raw-xxxxxxxx.tar.gz.
-- Eric Lowe elowe@systran.com Software Engineer Co-op, Systran Corporation 937-252-5601 x330 (( my apologies for the HTML attached, my stupid e-mail gateway is doing it, I can't stop it.. ))> > I am not familiar with Linux code. > > But a solution to DMA'ing to user-space will be > a) lock the relevant user range into memory. > b) touch them to fault the pages in. > c) Then trap into the kernel using an ioctl to set up > kernel address for this > range. ( I bet there must be some VM calls to acheive > that ). What i mean > is that get the pages behind the locked user-address > behind the kernel address. > d) Do the DMA to these pages. > e) Release the kernel-mappings. > > This helps in zero-copy DMA. Also the user-pages are still > swappable, once the DMA is > done and after they are unlocked. >
------_=_NextPart_001_01BE7AC4.952F4BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: Address spaces on a i386 - Getting Confused But there are various other horrible problems. = If it were that easy, I'm sure the kernel would have supported it long = ago.
1) What to do if the process is killed while the = pages are locked?
2) What if you have multiple threads trying to = access the buffer simultaneously, or, worse yet, you're using = asynchronous DMA reads and writes?3) What if multiple DMAs are trying to access the = same buffer? Who should win?
I'm writing more robust code for character and = streaming drivers that attempts to address these issues. Stephen = Tweedie (sct@redhat.com) has some patches already available that will = do direct I/O by wrapping block drivers. His code is at ftp://ftp.linux.org.uk/pub/linux/sct/fs/raw-xxxxxxxx.t= ar.gz.
--
Eric Lowe
elowe@systran.com
Software Engineer Co-op, Systran Corporation
937-252-5601 x330
(( my apologies for the HTML attached, my stupid = e-mail gateway is doing it, I can't stop it.. ))>
------_=_NextPart_001_01BE7AC4.952F4BE0--
> I am not familiar with Linux = code.
>
> But a solution to DMA'ing to = user-space will be
> a) lock the relevant = user range into memory.
> b) touch them to fault = the pages in.
> c) Then trap into the = kernel using an ioctl to set up
> kernel address for this
> = range. ( I bet there must be some VM calls to acheive
> that ). What i mean
> is = that get the pages behind the locked user-address
> behind the kernel address.
> d) Do the DMA to these = pages.
> e) Release the = kernel-mappings.
>
> This helps in zero-copy DMA. Also = the user-pages are still
> swappable, once the DMA is
> done and after they are = unlocked.
>- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/