tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On Fri, Mar 12, 2010 at 7:34 AM, Greg A. Woods <> 
> At Thu, 11 Mar 2010 10:22:29 +0900, Masao Uebayashi 
> <> 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

# cat wd0/.info


Home | Main Index | Thread Index | Old Index