| |||||||||||||
Developers versus administratorsDevelopers versus administratorsPosted Feb 25, 2011 0:49 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: Developers versus administrators by epa Parent article: debugfs: rules not welcome
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?
(Log in to post comments)
Developers versus administrators Posted Feb 25, 2011 7:56 UTC (Fri) by epa (subscriber, #39769) [Link]
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 Posted Feb 25, 2011 9:44 UTC (Fri) by misiu_mp (guest, #41936) [Link]
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
Developers versus administrators Posted Feb 28, 2011 17:04 UTC (Mon) by epa (subscriber, #39769) [Link] 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 Posted Feb 26, 2011 3:01 UTC (Sat) by foom (subscriber, #14868) [Link]
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...
Developers versus administrators Posted Mar 8, 2011 9:40 UTC (Tue) by robbe (guest, #16131) [Link]
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).
|
|||||||||||||