Request for new block_device_operations function pointer

Request for new block_device_operations function pointer

[Matt D. Robinson]

I'd like to see if there's any issue with the inclusion of a new
function pointer for block_device_operations.

I'd like to see something like:

struct block_device_operations {
        /* ... */
        int (*dump) (kdev_t, char *, size_t, loff_t *);
};

This would allow projects such as LKCD to use a specific dump
device associated to a block device driver.  This dump driver
writes data out directly to disk at a specific offset.  The
reason for having it in the block_device_operations table is
to directly attach it to the lower-level disk driver rather
than going through the file_operations table.  In theory, I'd
also like to see something similar for character devices, but
there is no table mechanism for this currently beyond
file_operations.

Then we could add our own IDE dump function pointer into ide_fops,
for example, and inevitably put our code into the IDE disk driver
without changing the rest of the driver functionality, but allowing
direct writes to the disk.  The same would apply to SCSI disks.
Then all maintainers can approve the dump mechanisms before
including them into any driver release.

It would also mean that dumping wouldn't be allowed to devices
that don't have a dump function pointer, which is better than
trying to use the standard write() path for all devices.

The patch for the function pointer is the easy part, the dump
function pointer code is obviously more significant.  Either
way, I can get started on those.

The arguments to dump can be different, it's the purpose that
I'm concerned with.  Any other suggestion is fine ...

Thoughts?

--Matt

Re: Request for new block_device_operations function pointer

[Alexander Viro]

On Tue, 18 Sep 2001, Matt D. Robinson wrote:

> This would allow projects such as LKCD to use a specific dump
> device associated to a block device driver.  This dump driver
> writes data out directly to disk at a specific offset.  The

... while submit_bh()... writes data out directly to disk at a specific
offset.  Amazing, isn't it?

Notice that you _will_ need to deal with IO in driver's queue, no matter
how you implement the thing.  submit_bh() already does it.

Re: Request for new block_device_operations function pointer

[Matt D. Robinson]

On Tue, 18 Sep 2001, Alexander Viro wrote:
|>On Tue, 18 Sep 2001, Matt D. Robinson wrote:
|>
|>> This would allow projects such as LKCD to use a specific dump
|>> device associated to a block device driver.  This dump driver
|>> writes data out directly to disk at a specific offset.  The
|>
|>... while submit_bh()... writes data out directly to disk at a specific
|>offset.  Amazing, isn't it?
|>
|>Notice that you _will_ need to deal with IO in driver's queue, no matter
|>how you implement the thing.  submit_bh() already does it.

... and deals with interrupt state, and any special device
requirements?  Actually, we don't want to deal with any
outstanding I/O.  You don't want to flush any outstanding
requests if you're crashing (which is what LKCD is for).
Sure, submit_bh() when things are running fine.  But not when
you're crashing.  And also, this is intended at some point in
the future to work to raw devices as well.

I don't want to deal with b_end_io(), blk_get_queue(),
generic_make_request() or any of that stuff.  This is
supposed to be raw data to the disk.

Again, the point here is to create a device operation that
allows the driver to enter a dumping state and write out
data raw to the device.  It's not intended for the normal
block operations path.

Thanks,

--Matt