on 20/09/2012 19:53 Andriy Gapon said the following: > > Alexander, > > I think that g_retaste_event may have a problem along the lines that we > discussed > on IRC but in a little bit different context. > Namely, if we find a connected non-orphaned consumer belonging to a geom of a > target class, then we mark the consumer as orphaned and call g_wither_geom on > its > geom. Then we call taste method of the target class on the provider in > question. > But since g_wither_geom initiates an asynchronous operation the withered geom > will > still exist and we may create a new "duplicate" geom beside it. That could > result > in resource conflict or in confusion in the upper layers. > E.g. if the class would be geom_dev, then the newly attached geom won't be > able to > create a devfs entry, because the withering geom still has it. > I hope that miss something in this scenario... ^- this should have been 'I missed'
And indeed, what I missed is that retaste mechanism is not an infrastructural thing in GEOM, but rather it is used by code related to specific GEOM classes to trigger re-tasting by those classes. So that code should already know what it is going and when it is doing that. > P.S. > Also, the code seems to wither/orphan only the first of qualified > geoms/consumers. > I am not sure if it's safe to assume that only one geom of a given class > could be > attached to a provider. Hypothetically different instances/geoms of the same > class could be using some provider for different reasons and purposes. > Ditto here. -- Andriy Gapon _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "[email protected]"
