svn commit: r220982 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/mips/malta sys/pc98/conf sys/powerpc/conf sys/sparc64/conf sys/sun4v/conf

[John Baldwin]

On Sunday, April 24, 2011 3:41:08 pm Alexander Motin wrote:
> On 24.04.2011 21:59, Bjoern A. Zeeb wrote:
> >> What's about creating some kind of symlinks, it could be nice if it
> >> worked, but I don't see the way to do it on disk(9) or GEOM layers
> >> without breaking device's access counters and as result further random
> >> problems.
> >
> > I had been pondering devfs "link"s myself, the problem is that from the rc
> > framework they come too late.  If you can add a simple .ko that does it
> > programmatically on 9 that would be great.  The problem is that after booting
> > the new kernel you don't know whether people had ATA_STATIC on or not, so
> > we'd have to go with the defaults, that were in 8.x (and an extra tunable to
> > flip the logic maybe)?
> 
> Devfs links won't help users with hardcoded provider names in gmirror, 
> etc -- from GEOM PoV there will be no such providers. Also to create 
> proper mapping that module should have real-time information from CAM 
> about ATA controller details. And looking that it will have to link in 
> real time any derivative providers also (ad4s1a -> ada0s1a) I worry if 
> it is possible at all. Some devfs expert needed here.

I think the biggest goal is to make /etc/fstab migration easiest.  I wonder if
you could leverage the device cloning callback in devfs to create symlinks
on the fly as name lookups were done (so if mount tries to use /dev/ad4<blah>
from /etc/fstab the symlink would be created on the fly).  This would allow
you to handle arbitrary suffixes (i.e. just make sure it matches 'adX(.*)'
and generate 'adaY\1' as the link target) without having to modify any of
gpart, etc. to create a forest of symlinks.

The only possible issue with this is that the devfs cloning eventhandler wants
you to return a dev_t, not a symlink.  That might still work fine (you might
have to do a namei() lookup to find the adaX.* devfs entry), but then you
would not get /dev/adX.* entries listed in /dev when you did an ls.  Instead,
trying to open those old names would just transparently "work".  You could maybe
print a message on the console warning that you were remapping an old name to a
new one.

-- 
John Baldwin