Hi, On Thu, Mar 14, 2013 at 06:16:30PM +0100, Rafael J. Wysocki wrote: > Sorry for the sluggish response, I've been travelling recently. -> [...] > > > > So, I'd suggest the following changes. > > > > - Remove the "uevents" attribute. KOBJ_ONLINE/OFFLINE are not used for > > > > ACPI device objects. > > > > - Make the !autoeject case as an exception for now, and emit > > > > KOBJ_OFFLINE as a way to request off-lining to user. This uevent is > > > > tied with the !autoeject case. We can then revisit if this use-case > > > > needs to be supported going forward. If so, we may want to consider a > > > > different event type. > > > > > > Well, what about avoiding to expose uevents and autoeject for now and > > > exposing enabled only? Drivers would still be able to set the other flags on > > > init on init to enforce the backwards-compatible behavior. > > > > Now that we don't define uevents and autoeject in v2 of this series, could you > > explain how we get safe ejection from userspace e.g. for memory hot-remove? What > > are the other flags drivers can use (on init?) to avoid autoeject and only issue > > KOBJ_OFFLINE? > > > > > > > > I agree that it would be sufficient to use one additional flag then, to start > > > with, but its meaning would be something like "keep backwards compatibility > > > with the old container driver", so perhaps "autoeject" is not a good name. > > > > > > What about "user_eject" (that won't be exposed to user space) instead? Where, > > > if set, it would meand "do not autoeject and emit KOBJ_OFFLINE/ONLINE uevents > > > like the old container driver did"? > > > > I don't see user_eject in v2. Is it unnecessary for userspace ejection control > > or planned for later? Also why shouldn't it be exposed to userpace? > > -> At this point we are not sure if it is necessary to have an attribute for > direct ejection control. Since the plan is to have a separate offline/online > attribute anyway (and a check preventing us from ejecting things that haven't > been put offline), it is not clear how useful it is going to be to control > ejection directly from user space. ok. Regarding the offline/online attribute and ejection prevention checking, do you mean the offline/online framework from Toshi: http://thread.gmane.org/gmane.linux.kernel/1420262 or something else? I assume this is the long-term plan. Is there any other short-term solution planned? If i understand correctly, until this framework is accepted, memory hot-remove is broken (=unsafe). thanks, - Vasilis -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
