Re: [PATCH] 2.5 PROPOSAL: Replacement for current /proc of shit.

Martin Dalecki (dalecki@evision-ventures.com)
Thu, 01 Nov 2001 17:49:52 +0100


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/