Messages in this thread | | | From | Keith Owens <> | Subject | Re: kiobuf using kernel pages | Date | Sat, 13 Nov 1999 02:04:48 +1100 |
| |
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/
| |