[LWN Logo]

From:	alan@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: PATCH: Raw device IO for 2.1.131
To:	mingo@chiara.csoma.elte.hu (MOLNAR Ingo)
Date:	Sun, 13 Dec 1998 18:02:17 +0000 (GMT)

> With mmap()+copyfd() we dont ever copy the data, we just start off DMA
> requests straight from kernel-space. (lets assume we have fixed the
> page-cache stupidity of copying on writeout, and lets assume we have a
> smart copyfd())

Let me explain why I need DMA to user space (Or I think I do) in some
detail. Perhaps Ingo and Linus have a better suggestion for how to do this.

You cannot mmap a stream source only block objects. Also you are then forced
to work in the block sizes of the device, which can be huge causing massive
resource management problems. The actual data that is used for the zero
copy needs to end up in a pageable resource and pinned only when needed.
Thus if you map a 2Mb video capture image you want it to end up on the
user side. You can then sendfile/write that to disk or a network

So I need the low level DMA to user space but I don't need raw disk. What
happens then is

	lock 2Mb
	blast data (<2mS)
	unlock 2Mb

	sendfile it (undefined completion time)
	[possible swapping I/O etc occurs during this]

Right now we pin a big chunk of vmalloc memory and map it into the user
process for long periods of time. This sucks. The NT capture driver is
an order of magnitude cleaner than the Linux one which is definitely bad news.

SCSI generic is a similar example where we want to DMA into user pages or
from user pages in large chunks (scanners like their I/O in megabyte
sized chunks or bigger).

The issue to me therefore is character devices that input or output very
large blocks of data in each operation.

> zero-copy for the VFS, who will develop 2G+ file support and extent-based
> allocation for ext2fs? 

2G+ file support in ext2fs works. 2G+ file support in Linux 32bit can be
made to work - there's a working example which while not totally clean
and without mmap() does prove the point

Alan


-
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/