On Apr 25, 2011, at 1:16 PM, Garrett Cooper wrote: > On Apr 25, 2011, at 9:29 AM, Alexander Motin <m...@freebsd.org> wrote: > >> Warner Losh wrote: >>> On Apr 25, 2011, at 7:45 AM, Pawel Jakub Dawidek wrote: >>>> On Sun, Apr 24, 2011 at 06:59:40PM +0000, Bjoern A. Zeeb wrote: >>>>> 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)? >>>> We do know that people have ATA_STATIC_ID, because if they don't, this >>>> means they have their custom kernel config which doesn't contain ATA_CAM >>>> and when they will use it next time they recompile their kernel they >>>> will still have /dev/adX entries. >>>> >>>> Also, as Alexander already noted, because of all the problems with ATA >>>> naming over the years and for other reasons too, people often hardcode >>>> provider name in various GEOM classes metadata, so symlink won't help. >>> >>> Do we have a short list of the places to look? >> >> Quick man pages grepping shows that at least gmirror, gstripe, graid3, >> gjournal, gvirstor, gconcat, gshsec support provider names hardcoding. >> For gmirror and graid3 present status can be obtained by: `gXXX list | >> egrep "Flags: .*HARDCODED"`. For gvirstor, gshsec, gstripe and gconcat: >> `gXXX dump adX | egrep "Hardcoded provider: ad"`. For gjournal: >> `gjournal dump adX | egrep "hcprovider: ad"`. >> >>> A lot of this could be done with a script that gets run at installworld and >>> boot time to hunt down the old cases and report them to the user before >>> they upgrade their kernel (but this would mean backing out the GENERIC >>> change for a while to give people a chance to upgrade to label-based >>> provisioning... >> >> If I understand idea right, independently of how much we delay it, there >> will be some people who not updated during that window to get in code >> detecting it during boot. Hardly many people of target auditory updating >> their systems each month. Same time some checks indeed could be done in >> installkernel. > > For people like me who install multiple kernels and boot them at will, > especially when there are other features under a large degree of development, > this kind of action isn't acceptable because it shoots you in the foot when > moving between the different kernels.
No it doesn't. (a) There will be an override flag, if you really don't want to. WITHOUT_FSCK_SANITY_CHECK=t and we're done. (b) The /dev/ufsid/*,/dev/gpt/*, /dev/ufs/* naming works on both flavors of kernel. > I'd prefer having an UPDATING note with all of the affected areas so that > people can understand what needs to change and adjust their systems > accordingly. As far as geom based hardcoding is concerned: maybe this can > serve as a good lesson of what shouldn't be done and what should be > fixed/have a translation layer added for this item? I'd prefer having it be there also. Warner > Thanks, > -Garrett > > _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
