In article <linux.kernel.Pine.GSO.4.10.10001241018410.27195-100000@weyl.math.psu.edu>,
Alexander Viro <viro@math.psu.edu> wrote:
>[I said]
>> So the output of /proc/devices will be out of date if an rmmod is done
>> just after the code trawls over the registry entry for the offending
>> device. Is this important?
>Umm... Not really. There is a bunch of nastier races around the whole
>thing (and insmod sucks too - figuring out results of the following
> open /dev/foo
> request_module
> module_init
> register_blkdev
> pointer to methods table set
> initializing disk/controller
> open /dev/foo
> found the pointer
> success
> read from the thing
> woops!
> finish initialization... too late ;-<
It strikes me that this is a flaw in the driver, if wants to be
ready before it announces itself, but it's announcing itself
before it's actually ready.
open /dev/foo
request module
module init
register_blkdev_but_not_yet_okay?
initializing disk/controller
open /dev/foo
found the pointer
not ready? Dum de dum dum
finish initialization
okay_im_ready_now
Yayy!
>> >$ cat /proc/drivers/block/ide/ranges
>> >0300(80)
>> >1600(80)
>> >2100(80)
>> >2200(80)
>> >$ cat /proc/drivers/block/ide/hdb/range
>> >0340(40)
>>
>> No. That's a pretty awful scheme there.
>>
>> ____
>> david parsons \bi/ so now I need to make a zillion system calls to figure
>> \/ out which major is affiliated with which hdx device?
>
>Arrgh. Could we please forget about major:minor split?
Sure. As soon as I don't have to use the major/minor kludge to
access devices I'd be happy to forget about it. Unfortunately
that happy day isn't here yet, so we're stuck with the current
basket of kludges.
If, to set up the device entries, I need to pick an array out of
one table, then iterate through /proc/drivers/block/ide/*/range to
partition that table, I'm doing a whole bunch of work that I would
bet would become obsolete with the next major release of the
kernel. The klunky old /proc/devices works just as well.
____
david parsons \bi/ Some days the kernel feels a whole bunch more
\/ researchy than other days.
-
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 : Mon Jan 31 2000 - 21:00:12 EST