Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754007Ab3COKrl (ORCPT ); Fri, 15 Mar 2013 06:47:41 -0400 Received: from mail-bk0-f47.google.com ([209.85.214.47]:65218 "EHLO mail-bk0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753880Ab3COKri (ORCPT ); Fri, 15 Mar 2013 06:47:38 -0400 Date: Fri, 15 Mar 2013 11:47:33 +0100 From: Vasilis Liaskovitis To: "Rafael J. Wysocki" Cc: Toshi Kani , ACPI Devel Maling List , Bjorn Helgaas , LKML , Yinghai Lu , Yasuaki Ishimatsu , Jiang Liu Subject: Re: [Update 4][PATCH 2/7] ACPI / scan: Introduce common code for ACPI-based device hotplug Message-ID: <20130315104732.GA4401@dhcp-192-168-178-175.profitbricks.localdomain> References: <3260206.bhaAobGhpZ@vostro.rjw.lan> <18666371.hyHAvqrdQ6@vostro.rjw.lan> <20130304131023.GA4561@dhcp-192-168-178-175.profitbricks.localdomain> <3390139.KZuRkSrE4e@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3390139.KZuRkSrE4e@vostro.rjw.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2791 Lines: 58 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/