Kostik Belousov wrote: > On Mon, Apr 25, 2011 at 03:26:02PM +0300, Alexander Motin wrote: >> Andrey V. Elsukov wrote: >>> On 25.04.2011 14:23, Alexander Motin wrote: >>>> What will not work: >>>> - old device names won't be seen inside GEOM, so users who hardcoded >>>> provider names in gmirror/gstripe/... metadata (not the default >>>> behavior) are still in trouble. >>>> - patch mimics ATA_STATIC_ID behavior, if user had custom kernel >>>> without it, he should update device names manually. >>>> - it won't work for users with hot-unplugging ATA controllers (not >>>> devices), but I believe it is really rare case. >>>> - low-level tools, such as smartmontools, won't be able to work with >>>> alias devices, as background ada driver doesn't implements legacy >>>> ioctls. May be I could partially fix this. >>>> >>>> Except those, I think this patch should work for the most of users. >>>> >>>> Any more objections/ideas? Is this an acceptable solution? >>> what about new GEOM class? You can create new class instance after >>> disk_alloc(), attach it to the new disk and create provider with old-style >>> name. It seems this class will be very simple. >> It sounds like less dirty option. I'll try it. Thank you. Won't >> re-providing exactly the same device into GEOM create some problems? >> glabel and co will connect to each of them (original and legacy) and >> report two equal sets of labels.
I have implemented it by adding one more specialized glabel submodule: http://people.freebsd.org/~mav/legacy_aliases_geom.patch But when I already done it, I understood where will be the problem: if somebody open any partition on the device with the new name, all legacy names will become inaccessible (busy), and vice versa. It could be not a big problem if it would only be user's choice -- we could say just: "use one or another, not both". But provider could be chosen blindly by some GEOM class, such as glabel, and then it turns into pure lottery. So while from the code side and for point of supporting hardcoded provider names it looks much better, it probably won't work so. > Can you limit the real functionality of this new class to the calls > to make_dev_alias(9) ? Ideally, I would think about some extension of > the core GEOM, which would take some parameter, lets call it alias > name, and will acompany the existing make_dev() calls with parallel > make_dev_alias(). Adding one more alias name field to the struct g_geom probably is not a problem. And the result probably would not have downsides of two previous approaches. And from the code side it would probably looked better then textual parsing in a first patch. But supporting alias in every place where names used in GEOM (that is required to make it usable) will probably require quite a massive set of changes though GEOM core and many classes. I am not sure I want to go there. -- Alexander Motin _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
