On Tuesday 05 February 2008 18:18, Greg KH wrote: > On Tue, Feb 05, 2008 at 06:12:09PM -0500, Len Brown wrote: > > On Tuesday 05 February 2008 17:18, Greg KH wrote: > > > On Tue, Feb 05, 2008 at 02:30:10AM -0500, Len Brown wrote: > > > > # cat /sys/firmware/acpi/interrupts/summary > > > > pm_timer 0 > > > > glbl_lock 0 > > > > power_btn 0 > > > > sleep_btn 0 > > > > rtc 0 > > > > gpe00 0 > > ... > > > > gpe1F 0 > > > > gpe_hi 0 > > > > gpe_total 63 > > > > acpi_irq 63 > > > > > > Eeek! Why? What's wrong with individual files here? > > > > My expectation is that this is a shell interface for debugging, > > not an API for programs. ala /proc/interrupts. > > Great, then use debugfs for it. Please, don't put debug stuff like this > in sysfs, that's not what it is there for. You can do whatever you want > in debugfs :) Can you point to a model of good behaviour that I can copy? note that I want this information to be available on every system, just like /proc/interrupts is. /proc/ has seqfile support, is there a reason I shouldn't use it? I'd banned additional files from /proc/acpi for a long time since the directory layout was ill-conceived. But maybe I should re-consider the headlong rush to use sysfs? thanks, -Len - 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