Messages in this thread | | | From | (Alan Cox) | Subject | Re: PATCH: Raw device IO for 2.1.131 | 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/
| |