Craig Armour writes:
> I've been running it devfs'd now for a few months and have a few changes
> I'd like to see/impliment but won't bother if they would fall on deaf
> ears
>
> problem:
> * /dev-state is a cludgy way of keep file permsions consistent
Actually, it's really neat and preserves existing Unix semantics for
those who want it.
> * my laptop has 2 cdroms which are replaceable with a floppy drive (
> internal ). devfsd will number the drives in the order they are
> probed each time. This becomes a hassle when you go to mount
> /dev/cdroms/cdrom1
/dev/cdroms is where all CD-ROMs are placed. If you want persistent
device names, then don't use /dev/cdroms.
> you might say that I would be biased in my solution to the above, but
> has the idea of a path_to_inst been explored?
>
> a possible layout could be for example
>
> ### FUll Device Path ################# Mode ############ device type
> /dev/ide/host0/bus0/target0/lun0/disc , 400 , hd
> /dev/scsi/host0/bus0/target0/lun0/cd , 400 , cdrom
>
> etc...
>
> each time the system boots with a new device, if the device isn't in
> the path_to_inst, it gets appended. /dev tree can then be created
> based on the path_to_inst and not the probe order for each boot. In
> this case, the cdrom listed will always be listed as cdrom0 as it is
> the first cdrom in the path_to_inst, even if an ide cdrom is added
> later.
Nope, this is a horrible idea. If you want to point at the SCSI
CD-ROM, then use the name under /dev/scsi. These automatically growing
databases of "convenient" names are a bad idea. They are fragile and
develop cruft over time.
> I believe that is a much better solution then the current /dev-state
> method.
I disagree, most strongly.
> I realise I could probably do something similar through devfsd.conf
> etc... but I believe this should be a core devfs thing. If no-one
> is interested and/or willing to test such things, then I may not go
> to much further than "it's just an idea". But if there is some
> interest, I would be willing to put the time in to produce some code
> to do the above. The devfsd code seems very easy to read and I
> don't think it would be too hard to impliment such changes
A "core devfs thing" is a kernel hack. There is absolutely no way in
hell that some kind of file-based database will ever be managed by the
kernel. That kind of code belongs in user-space. And if it's in
user-space, then devfsd is the logical place to put it.
However, I don't like the idea of such a database, so I'm not going to
implement such a hack for devfsd either. You're welcome to do it
yourself (even though I think the idea is flawed), but I hope you
don't. I think it's entirely the wrong approach. I would prefer to
implement solutions that solve real problems cleanly.
I've had the growing-database argument with people from another old
Unix vendor, and I think that "solution" reflects an outmoded way of
looking at things. Some "problems" should be solved by user
re-education, not by gross hacks. I realise that as a vendor, it's
hard to say "no" when users scream for something (especially if they
wave lots of money at you). However, in the Linux community we can
and do say "no, do it this way instead".
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|