Date: Mon, 25 Apr 2011 13:23:36 -0400 From: John Baldwin <jhb@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, "Bjoern A. Zeeb" <bz@freebsd.org>, Robert Watson <rwatson@freebsd.org>, src-committers@freebsd.org Subject: Re: 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 Message-ID: <201104251323.36510.jhb@freebsd.org> In-Reply-To: <4DB47CD4.9060300@FreeBSD.org> References: <201104240858.p3O8wwqT024628@svn.freebsd.org> <CD028561-B550-4896-BE65-7C827BE6A34A@FreeBSD.org> <4DB47CD4.9060300@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201104251323.36510.jhb>