[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190329102436.GA7286@kroah.com>
Date: Fri, 29 Mar 2019 11:24:36 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Marek Behun <marek.behun@....cz>
Cc: Pavel Machek <pavel@....cz>, Tejun Heo <tj@...nel.org>,
linux-kernel@...r.kernel.org,
Jacek Anaszewski <jacek.anaszewski@...il.com>
Subject: Re: kernfs: can read/write method grow buffer size?
On Fri, Mar 29, 2019 at 09:48:23AM +0100, Marek Behun wrote:
> > pavel@amd:~/cip$ cat /sys/power/state
> > freeze mem disk
> > pavel@amd:~/cip$ cat /sys/class/leds/phy0-led/trigger
> > none bluetooth-power rfkill-any rfkill-none kbd-scrolllock kbd-numlock
> > kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock
> > kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock
> > AC-online BAT0-charging-or-full BAT0-charging BAT0-full
> > BAT0-charging-blink-full-solid rfkill0 phy0rx phy0tx phy0assoc
> > phy0radio [phy0tpt] mmc0 timer heartbeat audio-mute audio-micmute
> > rfkill1 hci0-power rfkill8
> > pavel@amd:~/cip$
> >
>
> Yes, and cpufreq governors too list available governosrs as space
> separated list.
> Maybe the "one value per file" rule was thought-of only after these
> were merged?
For small numbers of things, like /sys/power/state, which was the first
file to use this style, it was fine as we "knew" this was going to be a
small, well-bounded list of states that the file could be in.
As you have seen, 'trigger' is not that, and I am pretty sure I have
complained about this in the past.
I suggest you use a different way of "discovering" what types of
triggers are available. I don't know what would work best for you, but
any time you are ever worried about the size of a sysfs file's buffer,
you know you are doing something wrong.
thanks,
greg k-h
Powered by blists - more mailing lists