On Wed, 2006-11-22 at 15:53 +0800, Zhang Rui wrote:
> On Wed, 2006-11-22 at 09:28 +0800, Shaohua Li wrote:
> > On Mon, 2006-11-20 at 12:18 +0100, Thomas Renninger wrote:
> > > 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?
> Sounds great. I'll have a try.
> > Sounds like a good idea. But this should be done in driver core. Other
> > devices like pci might support wakeup too. device declaims to support
> > wakeup, and driver core create a link to /sys/.../wakeup/xxx. I'd
> > suggest don't do this in acpi part.
> >
> Yes. That makes sense. But I don't want too many files to be involved,
> especially at the beginning. :). This should be done in another patch in
> the future if everything goes well.
Yep, enabling the core ACPI sysfs stuff first sounds like a good idea?
(I am especially looking for ACPI module autoloading..., probing blindly
all ACPI modules on all x86 machines is really ugly atm...) Getting
every detail duplicated or not from /proc/acpi can later be integrated
as needed. Small on top patches later are easier to review and less
error prone, once the basic stuff runs fine?
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
