LWN: Comments on "debugfs: rules not welcome"

Developers versus administrators

robbe — Tue, 08 Mar 2011 09:40:51 +0000

If there wasn't an implicit backwards-compatibility guarantee for stuff in debugfs, people could simply move the "production-ready" parts like perf to a final place in sysfs without any hitch. Yes, they would be gone in debugfs, but you're not supposed to depend on anything there.

Actually, I don't see the big problem. If you deem /debugfs/foo/{bar,baz} such production interfaces, why not move them to /sysfs/.../foo/{bar,baz} and provide the compatibility via a symlink? Is that really a maintenance burden?

I'd really like a mirror policy for phasing out ABI. I.e. if an interface has been in the kernel for X releases and Y years when it goes on the deprecation list, it can be removed after another X releases or Y years (whichever is greater).

debugfs: rules not welcome

foom — Sat, 05 Mar 2011 01:35:18 +0000

Hah, I missed that sentence the first time I read the article. But that's indeed quite hilarious that "breaking tools" is a reason given to not want to move the files from a location that's supposedly "anything goes" with no ABI compatibility rules. :)

debugfs: rules not welcome

mikachu — Thu, 03 Mar 2011 15:53:32 +0000

"Moving interfaces requires possibly cleaning them up, making a stronger commitment to ABI compatibility going forward and, importantly, breaking tools which depend on the current location of those interfaces."

There is something incredibly oxymoronic about not wanting to move an interface for fear of breaking ABI compatibility for fear of not being able to break ABI compatilibity.

Developers versus administrators

epa — Mon, 28 Feb 2011 17:04:59 +0000

but if those things become useful to others, they should be "productized".

But that's not the same thing as 'maintained with an unchanging interface for ever after'.

It might be a useful thing to see how many times the frobfs code calls frob_inode(). Essential, even, for performance tuning on large systems. But the frobfs developers want to have freedom to change their code to get rid of the frob_inode() call without breaking backwards compatibility. So there must be a way to label this stuff as usable in production, but not guaranteed to be there in future kernel versions.

In general any kind of instrumentation that works based on the kernel's internal data structures or control flow is useful to see but not a part of its API.

Developers versus administrators

foom — Sat, 26 Feb 2011 03:01:46 +0000

Yeah, but....if something is useful and enabled on production systems, people will start depending on it. And then tools will start depending on it. And then you can't break it, and so diagfs becomes *yet another* place to look for the knob you want to check/tweak, just like you already have to look for it in both sysfs and procfs...

debugfs: rules not welcome

dmk — Fri, 25 Feb 2011 19:30:22 +0000

what about selecting at runtime (perhaps needing to remount) what entries are actually populating the debugfs..

something like
# echo "enable" > /sys/kernel/debugfs/entries/perf
# echo "disable" > /sys/kernel/debugfs/entries/buggy_subsys
# mount -o remount /debugfs

Developers versus administrators

misiu_mp — Fri, 25 Feb 2011 09:44:05 +0000

Isn't it a good idea to make the really useful stuff part of the kernel api and maintain it for backwards compatibility? This could only strengthen the system.
I understand if features in debugfs are made by the kernel hackers themselves for their own benefit, but if those things become useful to others, they should be "productized".
After all if debugfs is used today with no warranties of compatibility, then whatever uses is will be a burden to maintain and will make the useful stuff
just a niche. Making the useful stuff a solid part of the kernel could open for new possibilities.

I would like to see some examples of
"things which are useful and safe to enable on production systems to fix whatever problems come up today, but need not become supported interfaces to preserve forever".

Developers versus administrators

epa — Fri, 25 Feb 2011 07:56:39 +0000

The trouble is that once you put something into sysfs or procfs, it becomes part of the kernel interface and you must commit to backwards compatibility. For that reason a lot of useful stuff goes into debugfs instead. But there are many things which are useful and safe to enable on production systems to fix whatever problems come up today, but need not become supported interfaces to preserve forever. Hence the need for an intermediate category between 'supported kernel feature' and 'no rules at all, never use on production systems'.

Developers versus administrators

giraffedata — Fri, 25 Feb 2011 00:49:38 +0000

It needs to split into a pure 'debugfs' (which contains stuff of interest to kernel developers only, has no rules, and should never be mounted on production systems) and a new 'diagfs' for things which might be of interest to system administrators.

Isn't the latter what sysfs and procfs are for?

debugfs: rules not welcome

keybuk — Fri, 25 Feb 2011 00:01:29 +0000

Note that kees has patched Ubuntu to make debugfs root-only anyway:

https://launchpad.net/ubuntu/+source/mountall/2.22

Developers versus administrators

epa — Thu, 24 Feb 2011 16:39:55 +0000

It needs to split into a pure 'debugfs' (which contains stuff of interest to kernel developers only, has no rules, and should never be mounted on production systems) and a new 'diagfs' for things which might be of interest to system administrators.

debugfs: rules not welcome

johill — Thu, 24 Feb 2011 08:50:12 +0000

Doesn't debugfs still cause crashes if there are ever files that can disappear from it, because it doesn't have proper lifetime management? Or did that get fixed eventually and I just missed it?

The case I'm thinking of is basically

fd = open(debugfs/file)
<wait, while doing something that causes that file to disappear, like unplugging HW>
read(fd) / write(fd) [depending on your access]

debugfs: rules not welcome

ajb — Thu, 24 Feb 2011 08:10:48 +0000

Perhaps the production-ready status needs to be pushed down to the granularity of individual debugfs files. Eg, add a flag to the API calls which create debugfs files, and a 'production mode' in debugfs, under which files without the flag set do not get made available (except perhaps to root).