Now that the horse is out of the barn, the following might be a little late (unless we unpull the trigger for a month).
But what if we warned that / was on a device name, and not on a 'named' device. Complain if it was on /dev/da0, but not if it was on /dev/ufs/fred-root. Users would see this warning and react. Next best thing: make installkernel check for devices on /dev/adX and refuse to install the kernel if they are (unless REALLY_THIS_IS_RIGHT is defined :). This won't help the binary upgrader, but will prevent massive footshooting in the mean time. Warner On Apr 24, 2011, at 1:41 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. > >>> Looking now on these "do or revert" demands to keep old device naming, >>> I'll try to make some hacks to CAM and ada(4) driver to mimic old "adX" >>> names. I see it in form of some loader tunable, disabled by default (as >>> it should be on newly installed systems), but that could be set prior to >>> upgrade if user doesn't want to bother with device names at that moment. >>> It should partially hide problem for some time. >> >> It would need to be in and on by default for the lifetime of 9 as it's not >> in the last 8.x release (which would need it the other way round anyway. >> MIght it be a good idea to do that as well afterwards providing ada links >> on the next 8.x release?). > > I wouldn't like to keep that ugly numbering on by default till the 9.x EoL > even for new installations. Also remember about number of people already > using new ATA, for whom requirement to disable that tunable may also be > uncomfortable. > >> The user could disable it after the conversion happened though with a tunable >> to get rid of the extra /dev/* noise. We could even check for it being on >> and check fstab and warn/pester the user then that he'll need to migrate >> (on boot from rc.d, in weekly mails, ...). > > It would be fine if it was just devfs noise, but I have some doubts about it > (above). > >> If we have both information available (old from the kernel transition code) >> and new we could even provide a script to do it. >> >> The reason we might not want to do it automatically is that if the user will >> decide to boot kernel.old because the new kernel panics after 2 days, she'll >> be facing the new ada entries in fstab with an 8.x kernel and that would not >> work either. So it's a decision users need to make eventually themselves >> during the lifetime of 9.x when upgrading from an older release. > > Reasonable. > >>> Will such solution be acceptable? >> >> I think any solution will be acceptable if it (mostly) works and gets the >> possible fallout rate (significantly) down and thanks a lot for picking it >> up now! > > But that solution should not include setting tunables before upgrading? Can't > we teach mergemaster or whatever else to set it depending on whet disks are > now present in system? > >> PS: And I think you'll find a lot of testers the next days/weeks on current@ >> when people update their kernels and forgot to read UPDATING or fail to >> do the conversion properly.;) > > I can always say: "read UPDATING" (for log: I am not completely serious here. > :)). > > -- > Alexander Motin > > _______________________________________________ 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"
