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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
