Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sun, 25 Apr 2010 17:23:06 -0700 | From | Randy Dunlap <> | Subject | Re: [PATCH 5/9] PM: suspend_block: Add debugfs file |
| |
On 04/25/10 17:00, tytso@mit.edu wrote: > On Sun, Apr 25, 2010 at 12:53:01PM -0700, Randy Dunlap wrote: >>> It's debug-like information, and has more than one value per file, so >>> debugfs seems like the proper place for it. I have no objection to it >>> going there. >> >> I have no objection if it really is debug info, but I'm not convinced >> of that yet. > > Well, I'll note right now we have a somewhat annoying gap. If you > need to export multiple values such that they are consistent with each > other, what's the choice? /proc, where some (but not all) kernel > developers will say, "eeeeeeviilllll". /sys is explicitly for single > value per files only. And then we have /debugfs, where some pendants > are kvetching about whether something is "really" debug information.
First of all, I am not a pendant.
> One of the things that we sometimes have to tell people who are trying > to navigate the maze of upstream submission is that sometimes you need > to know who to ignore, and that sometimes rules are guidelines > (despite pendants who will NACK based on rules like, "/proc, > eeeeewwww", or "/debugfs must only strictly be for debug information". > > Telling embedded developers who only want to submit their driver that > they must create a whole new pseudo-filesystem just to export a single > file that in older, simpler times, would have just been thrown into > /proc is really not fair, and is precisely the sort of thing that may > cause them to say, "f*ck it, these is one too many flaming hoops to > jump through". If we throw up too many barriers, in the long run it's > not actually doing Linux a service.
Yeah, I think that it should be in procfs. It's not strictly closed to new files. (IOW, I'm sure that we can find a bunch of recent files added to procfs.)
> Sure, we need to make sure is code doesn't become a future burden, but > does a new file in /proc or something that might not _really_ be debug > information showing up in /debugfs really such a terrible thing in > terms of making the kernel less maintainable in the future?
I don't think that we want to make debugfs required to get decent tuning info/stats from the kernel. That's all.
-- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
| ![\](/images/icornerr.gif) |