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/