Re: [Utopia] persistent partition naming

[Kay Sievers <kay sievers vrfy org>]

On Fri, Apr 23, 2004 at 02:19:43PM +0200, David Zeuthen wrote:
> On Fri, Apr 23, 2004 at 11:27:35AM +0200, Kay Sievers wrote:
> > Hey, nice to have this 'good place' instead of zapping through the blogs.
> > ("utopia" can be read as the greek "eu topos" and means "good place", or
> > "ou topos" which means "no place") :)
> > 
> 
> Heh, nice to see you here Kay.

I was just looking for nice people :)

> > I would really like a feature in the device handling stack,
> > that mounts the partition of a removable device everytime on the same
> > place in the filesystem, regardless of the connection order.
> > 
> > If I plug in my usb-stick-mp3-player, it would be nice if my favorite
> > audio player can access the filesystem by remembering the path to it.
> > Yes, I use a udev-rule, but the average user is not expected to do this.
> > 
> > I tried a udev callout which handles all uncatched partitions, generates
> > a name for a symlink and finally creates a rule-file in /etc/udev/rules.d/
> > with the device serial number. So the next time the device appears, this
> > rule will catch it.
> > But I'm not really happy with it. What is the right place to do something
> > like this?  What do you think?
> > 
> 
> I really agree it would be nice to have both persistent and sane mount point
> names. The thinking right now is to use hal-callouts; for a very simple
> example see here
> 
>   http://freedesktop.org/cgi-bin/viewcvs.cgi/hal/hal/tools/callouts/fstab-update.sh?rev=1.4&view=auto
> 
> 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.

> 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?

> 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?

> 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 :(

> [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?

thanks,
Kay