Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Fri, 12 Nov 1999 16:23:16 +0000 (GMT) | Subject | Re: kiobuf using kernel pages |
| |
Hi,
On Sat, 13 Nov 1999 02:04:48 +1100, Keith Owens <kaos@ocs.com.au> said:
> On Fri, 12 Nov 1999 14:33:52 +0000 (GMT), >> We need a new file_operations entry, rw_kiovec. So it looks like >> >> sys_write-> block_rw_kiovec->sd_raw_write->sd_raw_rw >> and vmdump->make_dump_kiovec->sd_raw_write->sd_raw_rw >> >> The kiobuf management should _all_ be done at the level where we are >> originating the block IO, not in the per-device operations.
> Do we want to add yet another file operation entry? Especially when > the *only* different between the two cases is whether to use user or > kenrel mappings.
The low level raw code should know about address mappings *at all* in the first place.
The whole reason for adding kiobufs was to remove all traces of VM knowledge from the driver-specific IO functions. That implies that you need to be able to pass around the memory references as kiobufs instead. Linus has spoken --- the kiobuf abstraction was the only reason he accepted the raw IO patches (and you'll see that the underlying IO function in raw IO, brw_kiovec, doesn't know a single thing about address mappings).
> I added FMODE_KERNBUF to the filp mode flags, normal code does not set > this flag, vmdump sets it when creating its dump filp. sd_raw_write > looks at that flag and maps the kiobuf accordingly.
The sd driver should be a consumer, not a provider, of kiobufs. That is the reason the kiobuf abstraction was added.
--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/
| |