lkml.org 
[lkml]   [2004]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support
On Mon, Sep 20, 2004 at 06:12:45PM -0500, Dmitry Torokhov wrote:
> On Monday 20 September 2004 02:24 pm, Keshavamurthy Anil S wrote:
> > On Mon, Sep 20, 2004 at 01:33:42PM -0500, Dmitry Torokhov wrote:
> > > On Monday 20 September 2004 11:35 am, Keshavamurthy Anil S wrote:
> > > > This patch support /sys/firmware/acpi/eject interface where in
> > > > the ACPI device say "LSB0" can be ejected by echoing "\_SB.LSB0" >
> > > > /sys/firmware/acpi/eject
> > > >
> > >
> > > I wonder if eject should be an attribute of an individual device and visible
> > > only when device can be ejected. Reading from it could show eject level
> > > (_EJ0/_EJ3 etc).
> > Hi Dmitry,
> > Today there is really no sysfs representation of acpi devices apart from
> > the acpi namespace representation. Evaluating acpi namespaces's _EJ0 method won't help,
> > as we need acpi device and all its child devices to be removed as part of the eject.
> >
> > Also for there is no 1:1 maping of acpi devices to pci devices to consider eject to be
> > part of the pci devices.
> >
> > Hence the best solution for now is to echo ACPI full path name of the device to be
> > ejected onto the eject file and the code will make sure that the device supports _EJx method before actuall removing the device.
> >
>
> Hi Anil,
>
> I obviously failed to deliver my idea :) I meant that I would like add eject
> attribute (along with maybe status, hid and some others) to kobjects in
> /sys/firmware/acpi tree.
I got this one and as I have said I will come up with the path soon:)
>
> I also wonder if userspace should traverse tree and emit eject requests for
> children. While it is OK for user[space]-initiated removal what about surprise
> removal. My concern that scripts will not be ready for all devices to be
> suddently gone... Would not it be beter if generic handler for BUS_CHECK was
> implemented in acpi/bus.c that would add/remove acpi devices and notify
> userspace via hotplug?

Can you please clarify my concern here.

Currently I am handling both the surprise removal and the eject request in the same
way, i,e send the notification to the userland and the usermode agent scripts
is responsible for offlining of all the devices and then echoing onto eject file.

My worry is if we implement a generic handler for BUS_CHECK, then what would you
do if the device fails to remove, i.e what action to take if the device remove fails?

Thanks,
Anil

-
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/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.114 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site