[RFC] change in /proc/devices

[david parsons]

In article <linux.kernel.Pine.GSO.4.10.10001241018410.27195-100000 en weyl.math.psu.edu>,
Alexander Viro  <viro en 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 en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/