Magic filesystems are too clever

Posted Oct 29, 2009 23:09 UTC (Thu) by quotemstr (subscriber, #45331)
Parent article: /proc and directory permissions

Kernighan wrote:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Made in classic ha-ha only serious fashion, the statement is as true as ever. Magic filesystems like procfs and sysfs are too clever, and create many problems, ranging from security (in the procfs case) to fundamental correctness, in the sysfs case. And for what? Being able to read a process' FD table with ls, or to change a system's current sleep state with cat?

Nobody does that. People really use tools like udev, and lsof, and ps to manipulate entries in the magic filesystem, and these tools could be better implemented using sysctl(2) and new system calls.

Magic filesystem introduce needless complexity and obscure correctness and security problems while at the same time providing nothing over other approaches. Magic filesystems are a bad idea, and ought to be slowly deprecated in favor of sysctl (for generic key-value manipulation) and special system calls (for everything else).

Magic filesystems are too clever

Posted Oct 30, 2009 10:15 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

Ew. No thanks. I find the /proc/$PID directories utterly crucial for all sorts of things. The problem with needing tools and sysctls to get at things is that they're not shell-compatible: you *must* write a tool to access it, and in extremis you can't do this because there isn't time; but you *can* cd into a directory and use ordinary shell tools. It's also crucial for non-emergency but adhoc stuff, which is a huge proportion of the stuff people actually do (as the non-adhoc stuff can be automated).

And for systems-administration stuff, well, am I the only person who's ever done a grep -R of /proc/sys/? Surely not.

Being shell-transparent is a huge huge huge feature. Don't break it.

Bringing up ps(1) as a counterargument is ridiculous: the reason ps(1) exists is both compatibility with Unix and that it can provide heaps of features that would be really annoying to implement by bashing on /proc yourself. But having /proc made ps(1) a hell of a lot easier to implement than it would have been otherwise (how else would you do it? grovelling through /dev/kmem, like traditional Unix? files in /proc with heaps of magic ioctl()s, like Solaris? Oh, please. We're moving *away* from that sort of opaque nightmare.)

(I'd actually quite like rm -r /proc/$PID to be made equivalent to kill -9, but I haven't implemented that or even tried to.)

Magic filesystems are too clever

Posted Oct 30, 2009 21:33 UTC (Fri) by foom (subscriber, #14868) [Link]

While I certainly agree that /proc/$PID is a useful feature...

> sysctls [...] not shell-compatible

Say what? "sysctl -w variable=value" is quite shell-friendly. For kernel *configuration*, I think the
sysctl interface made (and still makes!) a lot more sense than the 20 different mechanisms added
since then.

"sysctl -a | grep Whatever" is just as good -- perhaps even better -- than recursive grep against
/proc/sys, /sys/, and whatever the new-userspace-interface-of-the-month this month is...