Re: (Semi-random) thoughts on device tree structure and devfs

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Fri, Mar 12, 2010 at 7:34 AM, Greg A. Woods <woods%planix.ca@localhost> 
wrote:
> At Thu, 11 Mar 2010 10:22:29 +0900, Masao Uebayashi 
> <uebayasi%gmail.com@localhost> wrote:
> Subject: Re: (Semi-random) thoughts on device tree structure and devfs
>> I think labels should be resolved by some name service.  It's not
>> different than /etc/hosts -> IP address.
>
> Sorry, but I'm flabbergasted!   What the heck does that mean in this
> context of filesystem identification?
>
> Do you really want to add more complexity, goo, and mess, and places for
> errors to happen by adding a translation layer?
>
> First off, there's really nowhere to store your magical mappings.
>
> K.I.S.S.  Please!
>
> We do have a place to store a human readable/meaningful filesystem
> identifier.
>
> Let the human provide this label.
>
> If the system finds duplicate labels then tell the human which devices
> have conflicting labels and where those filesystem were last mounted and
> let the human decide which device should be used.  (i.e. the labels do
> need to be unique for a successful automatic initialisation of the
> system, but there needs to be a manual way to work around them not being
> unique regardless of what data they consist of)
>
> In my opinion the fs_id value is truly useless anywhere outside of the
> on-disk storage of a single filesystem copy where its sole valid use is
> (IIUC) to help to match valid backup superblock copies.  The fact I'm
> not even sure it's safe or sane to derive the NFS filesystem filehandle
> from it in any way.

I want to simplify path namespace.  I want labels and other
"referencial" informations to be accessed via file, like procfs's
doing.

# cat wd0/.info

Masao