lkml.org 
[lkml]   [2001]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: /proc format (was Device Registry (DevReg) Patch 0.2.0)
    Tim Jansen wrote:
    >
    > On Wednesday 25 April 2001 19:10, you wrote:
    > > The command
    > > more foo/* foo/*/*
    > > will display the values in the foo subtree nicely, I think.
    >
    > Unfortunately it displays only the values. Dumping numbers and strings
    > without knowing their meaning (and probably not even the order) is not very
    > useful.

    The meanings should be implied by the filenames, which are displayed (try it).
    The order is alphabetical by filename.

    > But the one-value per file approach is MORE work. It would be less work to
    > create XML and factor out the directory structure in user-space :)
    > Devreg collects its data from the drivers, each driver should contribute the
    > information that it can provide about the device.
    > Printing a few values in XML format using the functions from xmlprocfs is as
    > easy as writing
    > proc_printf(fragment, "<usb:topology port=\"%d\" portnum=\"%d\"/>\n",
    > get_portnum(usbdev), usbdev->maxchild);

    The corresponding one-value-per-file approach can probably be made to
    be a single call per value. IMHO that's more useful; it means that
    (once we agree on definitions) programs don't need to parse XML to
    access this data; they can go straight to the node in the document object
    model tree ( = /proc ). Think of /proc as a preparsed XML tree
    that hasn't been standardized yet.

    > The code is easy to read and not larger than a solution that creates static
    > /proc entries, and holding the data completely static would take much more
    > memory. And it takes less code than a solution that would create the values
    > in /proc dynamically because this would mean one callback per file or a
    > complicated way to specify several values with a single callback.

    ... but XML parsing is something we don't want to force on people
    when we can provide the same data in a pre-parsed, much easier to access
    form, IMHO.

    Have you bothered to go back and read the old discussions on this topic?

    > The driver should use its
    > own XML namespace, so whatever the driver adds will not break any
    > (well-written) user-space applications.

    Are you trying to avoid writing a DTD? IMHO it would be better to
    have a single DTD for the entire tree, rather than a separate
    anything-goes namespace for each driver. Yes, this is more work,
    but all the Linux drivers are tightly integrated into the kernel
    source tree, we may as well have a tightly-integrated DTD documenting
    what each block, serial, synch, etc. driver must provide.

    I think we both agree that there needs to be an easy, standardized way
    to access this data. IMHO there's a lot of standardizing that needs
    to happen before you can start writing code -- otherwise your new code
    won't help, and we'll be in the same mess we're in now.

    The DTD can apply to both the existing /proc form and any proposed XML form
    of config info exported by the kernel; there should be an easy transformation
    between them. And it has to come first!

    - Dan
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 12:52    [W:0.024 / U:0.468 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site