I don't see how a hardware-based name like
/kernel/devices/pci/adapecc2980_0/... is any better than one that
includes the host#, bus# and so on.
> But this is a straw-man argument, because it ignores the persistence
> problem with a dynamic disc-based /dev which is managed with a user
> space daemon. This is a problem that's been overlooked.
>
> Consider what happens if your daemon creates and deletes device
> entries based on information from the kernel as to what devices are
> installed (and drivers loaded). When a new device is plugged in, *what
> permissions should be given*? OK, say you get some default. So the
> sysadmin does chmod(1) to change this.
>
> What happens if a device is removed? The daemon deletes the device
> entry. Then the device is plugged back in again. *What permissions
> will be given*?
>
> What makes you think the daemon should delete the device entry? I
> wouldn't. I would keep it there, since the device entry is cheap,
> and most of the time when a device is removed it's likely to come
> back later. In the rare case where hardware is being physically
> removed and it will never come back, the system administrator can
> simply delete the device for good later.
I'd want it removed, since it's clutter if there hardware isn't there.
> Again I'll ask the question I've already asked a number of times. How
> would you cleanly support a construct like this:
> opendir ("/dev/ide/cd");
> loop;
>
> 1) I don't think this is useful.
Yes it is.
Regards,
Richard....
-
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/