"The fact that we continue to expose internal data structures via sysfs is a gaping open pit [and] is far more likely to cause any kind of problems than changing an error return," Theodore Ts'o noted, responding to a thread discussing a patch to fix an error return code. Andrew Morton agreed, "I was staring in astonishment at the pending sysfs patch pile last night. Forty syfs patches and twenty-odd patches against driver core and the kobject layer." He continued, "that's a huge amount of churn for a core piece of kernel infrastructure which has been there for four or five years. Not a good sign." Andrew then added a humorous quip, "I mean, it's not as if, say, the CPU scheduler guys keep on rewriting all their junk. oh, wait.."

Sysfs maintainer Greg KH replied, "I'm sorry, have I missed a breakage lately? I don't know of one in over a year that has not been fixed. Do you?" He noted that when sysfs is used properly from user space no breakage occurs, "if you want to propose some other kind of alternative to exporting this kind of _needed_ information to userspace, in a simple and easy-to-use manner, please do so. Until then, stop complaining unnecessarily." He went on to explain that most sysfs changes are to support things like containers, requiring per-user/per-container views, something sysfs wasn't originally designed for. "These aren't being done just because we like to break things, we are trying to make things better, and fix real bugs here."