Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Thu, 11 Nov 1999 11:31:35 +0000 (GMT) | Subject | Re: kiobuf using kernel pages |
| |
Hi,
On Thu, 11 Nov 1999 22:05:31 +1100, Keith Owens <kaos@ocs.com.au> said:
> The problem is that sd_raw_{read,write} can be called from kernel or > user space and those routines need some simple way of telling what > buffers their caller is using.
No, that's the wrong way to think about it.
The _whole_ point about kiobufs is that they contain pages of kernel-addressable memory, without _any_ information about where those pages came from.
A raw read/write function which uses kiobufs should never even think about virtual memory. It should use the kernel addresses in the kiobuf for the IO and then return. If the IO is coming from user space, then the syscall interface that the user IO is using can do a map_user_kiobuf() to map a user virtual address range into a kiobuf for the duration of the IO.
Think about http acceleration, for example. You want to be able to allocate and populate completely independent kiobufs for the http header and for the file data. The file data may come from a kiobuf mapping some portion of the page cache; the header may come directly from user space. The goal is to be able to pass the kiovec of those two kiobufs straight to the tcp layers. The networking stack shouldn't care that part of the memory is from user space and part from kernel space: all it sees is plain kernel pages inside kiobufs.
> What about a flag in the filp saying "this filp uses kernel buffers"?
That's an entirely separate issue. The user API which interfaces to kiobufs will need to know things like this. The kiobuf IO functions like sd_raw_rw() most definitely should not.
--Stephen
- 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/
| |