Messages in this thread | | | Date | Mon, 24 Jan 2000 10:32:41 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [RFC] change in /proc/devices |
| |
On 24 Jan 2000, david parsons wrote:
> root@downbelow# ls -l /dev/sdq > ls: /dev/sdq: No such file or directory > root@downbelow# ls -l /dev/sdq* > ls: /dev/sdq*: No such file or directory > root@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@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |