Re: [ANNOUNCE] block device interfaces changes

From: Kai Henningsen (kaih@khms.westfalen.de)
Date: Sun Jan 09 2000 - 04:32:00 EST


viro@math.psu.edu (Alexander Viro) wrote on 07.01.00 in <Pine.GSO.4.10.10001072200560.14766-100000@weyl.math.psu.edu>:

> * They have methods (struct block_device_operations). Currently
> the set is { open, release, ioctl, revalidate, check_media_change }. For
> now (and it's going to change) types are the same as in file_operations.
> However, in the near future they are going to become
> int (*open)(struct block_device *bdev, mode_t mode, unsigned flags);
> int (*release)(struct block_device *bdev);
> int (*ioctl)(struct block_device *bdev, unsigned cmd, unsigned
> long arg);
> int (*revalidate)(struct block_device *bdev);
> int (*check_media_change)(struct block_device *bdev);

Hmm. Shouldn't there also be some interface for handling actual I/O? That
is, some sort of request queue interface?

As for ioctl: Yes, the current interface is a mess, but a simple I/O
interface is not always a good equivalent.

I thought that in a recent discussion, an interface approximately like the
following was found to be useful:

[User mode interface]
int devicecontrol(int filehandle, unsigned command,
                  size_t insize, void *inbuf,
                  size_t outsize, void *outbuf);

That is, the parameters clearly indicate which access is allowed to what
memory, and how big buffers are. The old ioctl() interface could translate
old calls to use the new interface. Using some tables would probably work.

Now, this particular patch is probably not the time to make that change,
but it might be good to remind people ...

MfG Kai

-
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/



This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:14 EST