[ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interface support

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).

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

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.

thanks,
Anil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

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

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

Alex,

While I think that your patch is very important and should be included (maybe
if not as is if somebody has some objections but in some other form) I see it
more like developer's tool. I imagined status, HID, eject etc. attributes to
be sanitized interface to kernel's data, not necessarily causing re-evaluation.

So it could be like this:

/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/status
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/removable
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/lockable
..
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/eject

And your raw access to the ACPI methods could reside under raw:

/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_STA
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_RNV
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_LCK
..
/sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_EJ0

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

I got this one and as I have said I will come up with the path soon:)

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  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

Hmm, I do not quite agree. Except for "eject" being writeable to initiate
eject action the rest of the attributes would reflect kernel's view of the
device state and not re-evaluated when userspace references them. Monitoring
(or rather reacting to various events, like DEVICE_CHECK and BUS_CHECK) and
updating devices' statuses and other data is responsibility of the core ACPI
system. If system administrator is forced to manually (via libacpi or sysfs)
query device status to "kick" the device into working state I'd consider it
a bug, would'nt you agree? 

I see that in your other mail you mention _CRS parsing and chipset discovery.
I think that if you had an ability to just retrieve raw ACPI data from the
system that would suffice. In other words during normal operations there
is no need for "active" ACPI methods (such as _WAK, _S4, etc) to be available
from userspace. And just exporting raw data solves problem of bloating kernel
with parsing of vendor-specific data. I wonder if any of these methods need
arguments to run - if not then we would not need any adjustments to sysfs
opeen/close methods.

I am not saying that we should chose one method or another. I think they both
can co-exist, as they can be used for diffectent purposes - the raw ACPI access 
can affect state of the box while the sanitized attributes present kernel's
view and can be used to verify results of some action from kernel's POV.

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

I actually think that on the highest level we should treat controlled and
surprise ejects differently. With controlled ejects the system (kernel +
userspace) can abort the sequence if something goes wrong while with surprise
eject the device is physically gone. Even if driver refuses to detach or we
have partition still mounted or something else if physical device is gone we
don't have any choice except for t{*filter*} the tree and doing whatever we need
to do.


It could depend on parent's status. If parent is gone (surprise removal) we will
trim. If it is controlled removal and driver does not let device go we could
abort eject. 

Or we could always trim and offload the responsibility of having the system in
ready-to-eject state to the userspace. I.e. it should not write into "eject"
unless everything is unmounted/shut down/disconnected.

I am a bit light on implementation details though ;)

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

I agree, but when dealing with devices like CPU and Memory, not sure how the
rest of the Operating System handles surprise removal. For now I will go ahead and
add a PRINTK saying that BUS_CHECK(surprise removal request) was received in the 
ACPI Processor and in the container driver, and when we hit that printk on a 
real hardware, I believe it would be the right time then to see how the OS behaves 
and do the right code then. For Now I will just go ahead and add a PRINTK.

Let me know if this step by step approach is okay to you.

thanks,
Anil

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

Heh, I really don't expect the kernel to survive if somebody just yanks out a
CPU without a warning, especially if the CPU is the last one :) I hand in mind
devices like my port replicator that only has an additional network card and
could survive surprise removal.


It sure is, we can always adjust the process down the road.

Thank you for your work!

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

> In acpi_eject_store(), eject_operation() is called regardless of the
Hi Kei-san,
Your idea and the patch both looks good to me. 
Thanks for eye balling the code and detecting the corner cases like this.

I will merge this with my non-recursion version of the patch and post it ASAP.

thanks,
Anil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

Hi Anil,

It looks very nice except for the part above. I am really confused what the
purpose of this code is... It looks like it just complicates things?

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

Hi Dmitry,
	I just wanted to have a single function i.e setup_sys_fs_device_files() for both
creating and removing sysfs files. So I have #defined create_sysfs_device_files() and 
remove_sysfs_device_files() and one of the arguments to the setup_sys_fs_device_files()
is a function pointer, i.e for one it takes sysfs_create_file and for other it takes
sysfs_remove_file.

Having single function for creating and removing sysfs files make it easy 
from the maintaince perspective, as oppose to remember to code for remove 
as well when one adds the new file.


thanks,
Anil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/ 

Ah, I see... Makes sense, especially when there is additional logic involved
in creating some of the attributes, which is the case with ACPI.

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/