[LWN Logo]

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/