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/