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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html