Date: Fri, 7 Jan 2000 22:49:18 -0500 (EST) From: Alexander Viro <viro@math.psu.edu> To: linux-kernel@vger.rutgers.edu Subject: [ANNOUNCE] block device interfaces changes 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 * 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); * ->revalidate() and ->check_media_change() disappeared from file_operations. * register_blkdev() takes block_device_operations instead of file_operations now. For one thing, it means that block devices are more or less insulated from all future changes in file_operations (Good Thing(tm)). For another, it means that drivers should be modified. I did the change for all drivers in the main tree, see the patch for details. It's pretty easy. * blkdev_open() doesn't change ->f_op. def_blk_fops has all needed methods (open, release and ioctl call the methods from block_device_operations, indeed). * Inodes got a new field: i_bdev. Filesystems should not worry about it - just remember to call init_special_inode() when you are initializing device/fifo/socket in-core inode (in foo_read_inode() or in foo_mknod(); all filesystems in the tree are doing it now). Contents of this field: pointer to struct block_device if it is a block device inode, NULL otherwise. * Superblocks got a new field: s_bdev. Handled by code in fs/super.c, points to the struct block_device if the mount is device-backed, NULL otherwise (i.e. for NFS, CODA, procfs, etc.). * do_mount() first argument is struct block_device * now. It does the right thing for non-device mounts - just pass NULL and it will work (allocate the anonymous device, etc.) * Instead of calling get_blkfops(), use ->bd_op in struct block_device. Moreover, better use blkdev_get()/blkdev_put()/ioctl_by_bdev() (see examples in mm/swapfile.c, drivers/char/raw.c, fs/super.c, fs/isofs/inode.c, fs/udf/lowlevel.c). * Thing that is probably going to happen RSN: instead of struct gendisk per major we may want to go for struct gendisk per _disk_. It would mean that at some point near ->open() we will put the pointer to it into the struct block_device. One obvious consequence being that partitions-related ioctls() will become completely generic. Notice that it is _not_ the same as devfs (and not a beginning of moving devfs into the main tree). It just provides the backplane - no namespace, no nothing. Inodes (either in normal filesystems or in devfs) point to such animals. That's it. Eventually things like ->b_dev, ->b_rdev, ->i_dev, ->rq_dev, etc. are going to become pointers to such objects, but it will be done step-by-step - otherwise we'll end up with a moby patch and moby breakage in bargain... 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. Cheers, Al - 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/