Re: [ANNOUNCE] block device interfaces changes

From: Andries.Brouwer@cwi.nl
Date: Sat Jan 08 2000 - 09:29:21 EST


    From viro@math.psu.edu Sat Jan 8 04:49:23 2000

        Folks, there are changes underway in block device interface and
    some of them made it into 2.3.38.

        * New type (struct block_device) is defined. We have a cache of
    such objects, indexed by dev_t. struct block_device * is going to replace
    kdev_t for block devices. Handling of the cache is done in fs/block_dev.c

Good!
What do you mean by dev_t?

[dev_t is a type used for communication with userspace,
for example in the stat system call; we want to change
the stat system call to provide a dev_t with more bits;
I think the smoothest way to change such things is by
adding the system call versioned_stat (I posted the patch
a few times) - that settles things once and for all,
instead of having a sequence oldstat, stat, newstat,
stat64 etc. Kernel-internally we can use whatever we want,
but it may be a bit confusing to give the kernel-internal
handle the same name as the thing in userspace that today
has a different number of bits. What about calling it devno?
Don't forget to include the bdev/cdev bit in devno.]

        * 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);

I needed a little more stuff.
One thing is that the kernel does not need names for files,
but it needs names for devices since it uses device names in
printk. Thus you need something like
        char (*devname)(struct block_device *bdev);

Another thing is that I used two types, let us call them here
major_struct and minor_struct, where a kdev_t was a pointer to
a minor_struct, and the major_struct had a method
        kdev_t getdev(major_struct *dev, int minor);
to retrieve a minor if it existed or create it if not.
Probably this is part of your open, but it is not clear to me
how you handle the difference between major_struct and minor_struct.
They are rather different.

A bug in Linux at present is that there are alias problems
between block m of a partition and N+m of the entire disk.
Thus one gets strange failures of fdisk and mkswap.
(And the loop device is worse in this respect.)

        Character devices are not affected at all - IMO using the same
    type both for block and character device was a mistake. So their handling
    remains as-is. Probably something should be done for them too, but that's
    completely different story.

You follow Linus here, but I do not really agree.
There is the interface with userspace, and that is completely
identical in both cases. And kernel-internally you also want
open(), release(), ioctl() (and devname()) for character devices.
My point of view would be more: there is this great unstructured
mass of devices. The userspace interface is uniform, and part of
the kernel stuff is uniform. But there is a subclass of that of
devices, namely that of block devices, that can be handled
uniformly one level deeper. There may be other such subclasses.

Andries

-
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:12 EST