The c0b0t0u0 names are also good for when you don't have UUIDs:
i.e. when setting up.
> Fundamentally, I disagree with Richard Gooch that persistence is a "side
> issue". Being able to assign groups and permissions is a fairly
> fundamental part of /dev, and how system administrators allow who's
> allowed to access a modem, a tape drive, a printer, etc. To make it an
> afterthought in the design is in my opinion a big mistake, and it's one
> of the reasons why I consider devfs a hack. Running tar on /devfs at
> shutdown time is at least ten times as ugly as indirecting through a
> lookup table for resolving major/minor devifs numbers. :-)
The reason I think that persistence is a side issue is because adding
it will not change the API nor the way the devfs internal management
is done. However, I expect we'll continue to disagree on this point.
That said, I'd rather look to the future. I'm currently considering
two options for persistence:
- using a block device
- peeking through to the underlying disc-based inodes.
Ted, do you have any particular preferences/suggestions on this?
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.altern.org/andrebalsa/doc/lkml-faq.html