[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200802052058.50663.lenb@kernel.org>
Date: Tue, 5 Feb 2008 20:58:50 -0500
From: Len Brown <lenb@...nel.org>
To: Greg KH <gregkh@...e.de>
Cc: linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH for review] ACPI: Create /sys/firmware/acpi/interrupts/ counters
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists