RE: ARMS WAVING!!! Proposal to fix /proc dainbrammage.

Jon Burchmore (burch@offline.org)
Mon, 26 Oct 1998 11:40:51 -0800

> I think I shall spend next weekend coding up a insmod'able module that you
> can call using ioctl() calls to retrieve kernel information (i.e
> NR_PROCESSORS, TYPE_PROCESSORS et. al), perhaps have the ability to write
> kernel parameters, and publish the code here. Any takers?
>
> I know that making sysctl() calls is better but my Linux bible (Linux
> Device Drivers) doesn't mention anything about it, and so I don't know if
> it's possible to make sysctl() calls to a module, unfortunately. If I
> could, then I'd use sysctl() instead of ioctl().
>
> Then hopefully this will put an end to this debate - as then some of you
> can use /proc and some of us can use ioctl() (or sysctl() if possible)
> via this module.

I'm going to go out on a limb here and try not to make too much of
a fool of myself.

It seems to me that the best way to handle the /proc mess is to move all
of the driver-specific information into sysctl() calls, and then
re-implement
/proc in the kernel, using sysctl(). This has the following advantages:

1. The /proc code would be more centralized.
2. The driver-specific /proc code could perhaps be made more generic, which
would make it easier to maintain.
3. The script writers and cat users of the world are happy, because they
still have the human-readable /proc files.
4. The C programmers are happy, because they can call sysctl() instead of
having to parse a moving target.

-Jon Burchmore
Director of Software Development, Miva Corporation
Phone: (619) 490-2573 Fax: (619) 490-0548
PGP Key ID: 0xC5DA3E69 Finger: burch@miva.com
35D3 78F4 34D5 FE12 D249 F87C F958 7D25 C5DA 3E69

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/