Messages in this thread |  | | Date | Thu, 01 Nov 2001 17:49:52 +0100 | From | Martin Dalecki <> | Subject | Re: [PATCH] 2.5 PROPOSAL: Replacement for current /proc of shit. |
| |
Jeff Garzik wrote: > > > No kernel-formatted tables: use a directory. (eg. kernel symbols > > become a directory of symbol names, each containing the symbol value). > > > > For cases when you don't want to take the overhead of creating a new > > proc entry (eg. tcp socket creation), you can create directories on > > demand when a user reads them using: > > > > proc_dir("net", "subdir", dirfunc, NULL); > > unproc_dir("net", "subdir"); > > > > Note that with kbuild 2.5, you can do something like: > > > > proc(KBUILD_OBJECT, "foo", my_foo, int, 0644); > > > > And with my previous parameter patch: > > PARAM(foo, int, 0444); > > Is this designed to replace sysctl? > > In general we want to support using sysctl and similar features WITHOUT > procfs support at all (of any type). Nice for embedded systems > especially. > > sysctl may be ugly but it provides for a standard way of manipulating > kernel variables... sysctl(2) or via procfs or via /etc/sysctl.conf. > > AFAICS your proposal, while nice and clean :), doesn't offer all the > features that sysctl presently does. > > Jeff
sysctl IS NOT UGLY. Not the sysctl I know from Solaris or BSD. Both are far more pleasant solutions then the proliferation of ad-hoc, undocumented ever changing, redunand, slow, overcomplex in implementation, (insert a list of random invectives here) interfaces shown under /proc. And yes I don't give a shit about "cool features" like:
echo "bull shit" > /proc/this/is/some/random/peace/of/crappy/interface/design
BTW.> /proc/sys is indeed silly, since it's a "second order" interface to something you can gat your gip on far easier already. And redundant system intrefaces are not a nice design. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |