Re: problems about ACPI sysfs convert work

[Thomas Renninger <trenn@suse.de>]

On Mon, 2006-11-20 at 18:10 +0800, Zhang, Rui wrote:
> Hello, lists
> I’m doing the ACPI sysfs convert work now. And I have some problems when duplicating some procfs interfaces to sysfs.
> Under driver model (this will be available soon), files under /proc/acpi/xxx(driver)/yyy(device)/ will be duplicated under /sys/device/ as they are properties of individual devices.
> But I still have some trouble on dealing with the files under /prco/acpi, including “alarm”, “sleep”, “wakeup”, “debug_layer”, “debug_level”, “dsdt”, “fadt”, “event” and “info”.
> Following is a proposal as well as some problem and I’m not quite sure about the places all these attributes should be located at. I wish to get some advice from you, and any comment is welcome☺.
> 
> 1. Where should “alarm” be located? Another problem is whether we should put a duration into this file instead of a future time.
Don't know, never used...
> 2. “sleep” is already marked as deprecated because /sys/power/state has the same function. I won’t do the repeated work again.
Yep.
> 3. “wakeup” should not exist, but be an attribute of individual devices kobjects.
Maybe the devices can be linked
like /sys/.../wakeup/${links_to_wakeup_devices}
So that userspace does not need to search over the whole device tree to
find them?

> 4. “debug_layer” and “debug_level” are not decided yet. I think making them into two directories and locating them under /sys/bus/acpi is one choice.
> 5. Is “dsdt” and “fadt” still needed in sysfs? This is not necessary because the acpidump tools are quite handy.
> If “Yes”, are other tables also needed, e.g. multiple SSDTs and dynamically loaded op-regions? This is much more difficult, as they can’t be distinguished sometimes.
> And where should these tables locate?
IMO they can vanish (at least temporarily).
If really needed (AFAIK explicitly loaded tables via "Load(addr,)"
statement that are not listed in RSDT/XSDT can't be found by acpidump),
a /sys/../tables/* can still be implemented at later time? We are also
not able to grab them atm...
> If the answer is “No”, that’s good news for me. ☺.
> 6. “info” shows the ACPICA version. Is it ok to register “info” as an attribute of ACPI bus kobject?

   Thomas


-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html