Re: [Utopia] persistent partition naming

[David Zeuthen <david fubar dk>]

On Fri, 2004-04-23 at 17:43 +0200, Kay Sievers wrote:
> > This example just uses the major/minor numbers to create mount point names
> > a'la /mnt/hal/disk-%d-%d- which is, ahem, not nice.
> 
> Looks promising. Oh, I don't care about the name, it's removed anyway after
> disconnect.
> 

Yeah. IMHO the mount point name shouldn't really appear anywhere in
GNOME, but some people like the shell (I'm one of them :-) and it
doesn't hurt having a nice name there.

> > So, my answer would be to implement this as a hal callout that examines all
> > the information exported by HAL (btw, the spec is far behind the code
> > (I'll change this soon) so the best source is the source-code) and possibly
> > maintain a database for remembering the the volume name.
> 
> Ahh, this may be the reason why OSX creates files on the volume after
> the first mount?
> 

I hadn't thought about storing the mount point name on the volume -
that's an interesting idea.

> > An open question
> > is whether the mountpoint name is tied to the actual volume or the reader
> > in which the volume is inserted? 
> 
> Hmm, maybe hal looks at the filesystem LABEL and takes it, if nothing
> valuable is found, the name of the reader is used?
> 

There's a lot of options basically - I've actually just hacked in some
code a few weeks ago that set's block.volume_name for FAT filesystems,
so this is indeed possible.

> > Oh, and IMO an audioplayer application shouldn't have to remember the path
> > to the device. A mp3 player device should be matched with a fdi file 
> > (possibly the user can use a device browser to match it manually) and be
> > marked with the capability 'music_player'. This way g-v-m can automatically
> > start the application. Here's how I match my non-usb-storage based camera
> > 
> >  http://freedesktop.org/cgi-bin/viewcvs.cgi/hal/hal/fdi/20freedesktop/canon-digital-ixus-v.fdi?rev=1.1&view=auto
> 
> Ok, but I have static playlists with hardcoded paths :(
> 

Hopefully that application will change in the future so paths reference
something more stable :-). Don't know. But that doesn't mean we
shouldn't try to provide stable mount point names.

> > [1] : In fact, AFAIK it's not possible to identify stuff like memory_stick,
> > compact_flash or smart_media. But we can use a device information file to
> > remedy this sitution. Here's an example for my 6in1 card reader
> > 
> >  http://freedesktop.org/cgi-bin/viewcvs.cgi/hal/hal/fdi/20freedesktop/6in1-card-reader.fdi?rev=1.1&view=auto
> 
> Nice, I really like the idea of having a device database permanentely
> installed on the system. What is the bigger picture here:
> If in the near future the vendors are natively supporting linux :), what kind
> of ".INF" file should they provide?
> 

The idea is that information like this goes in the hal spec but that
document kind of needs updating. Fortunately, few devices need files
like that. 

An interesting idea would be to let vendors provide an icon or some
other branding for the device. Maybe it's far fetched, but perhaps that
would be an incitement for them to support free operating systems.

Cheers,
David