Messages in this thread | | | Date | Tue, 07 Dec 1999 01:08:07 +0100 | From | Martin Dalecki <> | Subject | Re: PATCH for 2.3.29: block device setup cleanup. |
| |
Andries.Brouwer@cwi.nl wrote: > > Linus writes: > > > I do want character devices too, but I think we should consider block > > devices and character devices to be completely separate things. > > > Not only are the number mappings different: character device X,Y is NOT > > necessarily the same as block device X,Y at all > > Both you and Marcin sound as if you haven't seen this my letter on this topic > from a few months ago - see > > http://www.uwsg.indiana.edu/hypermail/linux/kernel/9910.0/0926.html > > : At present MKDEV is just a simple arithmetical operation, but the new > : MKDEV must return the struct that belongs to the given major and minor. > : But there are two of them! A block device and a character device. > : Presently this last bit of information is implicitly present - > : in drivers/block one talks about block devices, in drivers/char > : about character devices. But we'll need it explicitly. > : Thus, I have patches like > : > :--- ../linux-1.3.84/linux/arch/sparc/kernel/setup.c Mon Mar 4 07:49:56 1996 > :+++ ./linux/arch/sparc/kernel/setup.c Mon Apr 8 01:17:42 1996 > :... > :- ROOT_DEV = MKDEV(UNNAMED_MAJOR, 255); /* NFS */ > :+ ROOT_DEV = MKBDEV(UNNAMED_MAJOR, 255); /* NFS */ > : > : that change all calls of MKDEV() into either MKBDEV() or MKCDEV() > : or MKXDEV(), where the latter occurs in a fs context, reading > : special device nodes. > > You see, this is again an intermediate stage of the kind you disliked: > saying explicitly everywhere in the source whether a MKDEV makes a block device > or a character device, while, for the time being, while the rest of the work > is not done yet, each of MKBDEV, MKCDEV and MKXDEV have the same definition, > namely the present definition of MKDEV. > Doing this is a single pass over the kernel source, completely trivial work. > It does not achieve anything in itself, but makes it possible to do the real > work touching only a few source files. Later one wants to remove almost all > calls to MK[BC]DEV (since these are expensive now). This mostly involves not > forgetting what we know already. This also implies that the pointer to the > entire block device must be easily obtainable from the pointer to a partition, > a favourite reason for doing MKDEV is MKDEV(MAJOR(dev),MINOR(dev)&~mask), > and such calls must be entirely eliminated. I think the final result is more > efficient than our present code.
So what's the problem? I'm starting to eat this fish from the back, so you could start doing it at *the* *same* time from the head. However I would personally like to wait with any changes to the interface exposed to the user-land, until all the pieces inside the kernel are in place.... In what I will arrive at is that basically your MKBDEV will just return a pointer to the blk_dev_struct See: unplug_device() for example. However only util I'm done with the sutff in ll_rw_blk.c and fs/buffer.c I can be 100% sure whatever it really will work out all that nicely. As you mention it alredy in the archived post: There are many things which *did* change in the time between. Like: rd.c, md.c, raw.c to make the most obvious examples. They will need some carfull addressing too.
--Marcin
- 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/
| |