[PATCH] libvolume_id fixes for solaris

[Artem Kachitchkine]

> How would that possibly look like for Solaris? On Linux it looks like
> this and we will probably just use that output (only needed for a few
> cases, cause the event from the kernel, which is tunneled through udev
> usually contains exactly that data already)
> 
>   $ /sbin/vol_id -x /dev/sda2
>   ID_FS_USAGE=filesystem
>   ID_FS_TYPE=ext3
>   ID_FS_VERSION=1.0
>   ID_FS_UUID=067972bb-8f72-4946-9e44-a3799ca6d8b3
>   ID_FS_LABEL=root
>   ID_FS_LABEL_SAFE=root

The idea is that a filesystem vendor supplies not only the filesytem kernel 
module, but also a set of tools that Solaris filesystem infrastructure requires: 
e.g. fs-specific backends for the mount command. Similarly to mount, Solaris has 
'fstyp' command with a bunch of fs-specifi backends. The command simply prints 
filesytem type on stdout:

# fstyp /dev/dsk/c0d0s0
ufs

With the -v option, it will print a boatload of additional information:

# fstyp -v /dev/dsk/c0d0s0
ufs
magic   11954   format  dynamic time    Tue Mar  7 02:17:14 2006
sblkno  16      cblkno  24      iblkno  32      dblkno  824
sbsize  2048    cgsize  8192    cgoffset 32     cgmask  0xffffffc0
ncg     1491    size    78138144        blocks  76933376
bsize   8192    shift   13      mask    0xffffe000
fsize   1024    shift   10      mask    0xfffffc00
frag    8       shift   3       fsbtodb 1
minfree 1%      maxbpg  2048    optim   time
...

What I might end up doing, is add another option that will print something 
vol_id in Solaris.

libvolume_id tells me about filesystems my OS doesn't support: that's pretty 
cool for diagnosis and stuff, but I guess most people only care if they can 
mount a filesystem or not. Going back to your iPod example: why would any 
application would support iPods with FAT and not with HFS or XYZFS, as long as 
the OS can mount it and there is valid data in .iPod_Control? The only ones 
outside HAL who care about fs type are sysadmins and fs management tools.



-Artem.