lkml.org 
[lkml]   [1999]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.047 / U:0.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site