[RFC] change in /proc/devices

[Alexander Viro]

On 24 Jan 2000, david parsons wrote:

> root en downbelow# ls -l /dev/sdq
> ls: /dev/sdq: No such file or directory
> root en downbelow# ls -l /dev/sdq*
> ls: /dev/sdq*: No such file or directory
> root en downbelow# 
> 
>     I presume that /dev/sdq will be living on Yet Another major to get
>     around the bizarre type-of-device numbering of scsi devices?  I'll
>     just start shuddering now and avoid the rush.

Already does. See Documentation/devices.txt for gory details. 

> >> >This change is needed if we want to avoid (a) races and (b) major suckage
> >> >with exporting spinlocks, etc.
> >> 
> >>     Why?
> >
> >One word: rmmod.
> 
>    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 ;-<
is not too hard). So that stuff _really_ needs fixing - the races are 
pretty real and lead to Bad Things(tm). Moreover, methods should not live
on per-major level. I have a fix (testing the sucker right now), but it
changes quite a bit of block_dev.c and kills the array of pairs
name/methods...

> >Umm... Will /proc/drivers/block/<driver>/ranges make you happy? I.e.
> >$ 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?

-- 
It's not like the switch to CIDR happened yesterday...


-
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/