lkml.org 
[lkml]   [1997]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: procfs problems
    Todd Graham Lewis wrote:
    >
    > On Wed, 16 Apr 1997, James Hughes wrote:
    >
    > > How about using ASN to define a MIB for the values in the procfs and get
    > > an enterprise number registered for Linux with the INA? The values can
    > > be read by humans as now in human friendly strings or in OID format
    > > depending on the method of retrieval.
    >
    > I don't like this idea because I've been mulling it for a few days. 8^)
    >

    Yeah, I've seen this same thread in various forms for a year or so now.
    I've mentioned this every time and then the list gets purged, so beware
    :)


    > I do like this idea because it's a really good one. Also, n.b. that /proc
    > has tons of overlap with MIB-II variables already, and MIB-II could offer
    > some suggestions as to which information might be useful in /proc.
    >
    > "Me too."
    >

    One advantage of such a scheme is that it would be well documented. It
    would be easy for driver/subsystem developers to impliment the reporting
    and control functionality in their code and be consistant with the rest
    of the system. The experimental tree can be used for "under-development"
    items. When they're officially integrated into the kernel, they could be
    moved under the Linux enterprise tree.

    I've seen references to the "sysctl" system. I think this would be the
    place to hook all this in. It could report values, update counters,
    schedule SetOID jobs (which could be used to adjust driver/subsystem
    parameters, etc.).

    The Linux version of the CMU-SNMP agent could drive the procfs via
    "sysctl". The procfs could be made to also respond to 'echo value >
    /proc/item' and 'cat /proc/item', as it is now.

    The interface would be there for all kinds of local 'system control' or
    'configuration' utilities to use. So it would help those who don't use
    networking as well.

    > Incidentally, I offered the snmpd developers to register a Linux MIB, but
    > they were of the opinion that it'd be too much of a political football. I
    > think that Linux International might make a decent custodian, but I really
    > don't see too many Linux-specific variables that we'd need. There's
    > already a Linux-specific tree off of utwente's EOID, so that could be used
    > as well. (Hell, we could delegate a tree off of Mindspring's EOID;
    > namespace under snmp isn't that hard to come by.)
    >

    Even though the mgmt OID is pretty comprehensive, I think we should have
    our own EOID. It just makes a statement about Linux. Besides, it would
    give us a place to generate those "lp1 on fire' messages ;)

    I think Linux International would be a good candidate to officiate the
    Linux tree. Whoever does would need to delve out the proper OID's when
    each driver/subsystem comes out of development. So, they would probably
    need volunteers to help with that.


    > The ASN.1 part is a really great idea, though. I could help write the MIB
    > if anyone thinks it's any good.
    >

    What if each driver/subsystem comes with the fields in the header files.
    When we 'make config' we select the drivers we want included in the
    build. When we 'make dep' the MIB for our configuration is made
    automatically from the information in the selected drivers/subsystem
    headers. Could we do that? I saw a "Linux Drivers Developers Kit" once.
    Could somthing like that make it easy for the developer to coordinate
    the OID/sysctl/MIB with their code?

    That way the MIB, therefore the procfs and sysctl interface, is updated
    with current information automaticaly each time a new kernel is built
    instead of one person having to keep up with all new or obsolete
    components in the system. The load of maintaining the procfs would be
    distributed among the developers. And they would be able to use the
    power of the system to enhance the functionality of their code.


    -James

    --

    This 'telephone' has too many shortcomings to be seriously considered
    as a means of communication. The device is inherently of no value to
    us.
    -- Western Union internal memo, 1876.

    \
     
     \ /
      Last update: 2005-03-22 13:39    [W:0.023 / U:29.964 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site