lkml.org 
[lkml]   [1999]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: kiobuf using kernel pages
Date
On Fri, 12 Nov 1999 14:33:52 +0000 (GMT), 
"Stephen C. Tweedie" <sct@redhat.com> wrote:
>On Fri, 12 Nov 1999 16:30:23 +1100, Keith Owens <kaos@ocs.com.au>
>said:
>> User I/O: sys_write->sd_raw_fops.write->sd_raw_write->sd_raw_rw
>> Kernel I/O: vmdump->sd_raw_fops.write->sd_raw_write->sd_raw_rw
>
>That's the wrong way to do it.
>
>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. 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.

We already use the f_mode flags to decide if we are doing read or
write. Adding another flag for user vs. kernel seems the smallest
change and is compatible with the current usage of f_mode.


-
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.045 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site