lkml.org 
[lkml]   [1999]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.053 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site