From: Tim Jansen <tim@tjansen.de>
To: Dan Kegel <dank@kegel.com>
Cc: linux-kernel@vger.kernel.org
Subject: /proc format (was Device Registry (DevReg) Patch 0.2.0)
Date: Wed, 25 Apr 2001 20:55:56 +0200 [thread overview]
Message-ID: <01042520555600.00849@cookie> (raw)
In-Reply-To: <3AE704FA.DCF1BEC6@kegel.com>
In-Reply-To: <3AE704FA.DCF1BEC6@kegel.com>
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.
> Better to factor the XML part out to a userspace library...
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);
Extending the devreg output with driver-specific data means registering a
callback function that prints the driver's data. The driver should use its
own XML namespace, so whatever the driver adds will not break any
(well-written) user-space applications. The data is created on-demand, so the
values can be dynamic and do not waste any space when devreg is not used.
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.
bye...
next prev parent reply other threads:[~2001-04-25 18:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-25 17:10 Device Registry (DevReg) Patch 0.2.0 Dan Kegel
2001-04-25 18:09 ` H. Peter Anvin
2001-04-25 18:55 ` Tim Jansen [this message]
2001-04-25 19:19 ` /proc format (was Device Registry (DevReg) Patch 0.2.0) Dan Kegel
2001-04-25 23:09 ` Tim Jansen
2001-04-25 19:37 ` Jesse Pollard
2001-04-25 20:08 ` Dan Kegel
2001-04-25 20:40 ` Tim Jansen
2001-04-25 21:16 ` Jesse Pollard
2001-04-25 21:50 ` J . A . Magallon
2001-04-25 21:58 ` Doug McNaught
2001-04-25 22:03 ` J . A . Magallon
2001-04-25 22:24 ` Marko Kreen
2001-04-25 22:42 ` Alexander Viro
2001-04-25 22:24 ` Mark Hahn
2001-04-26 14:06 ` Tim Jansen
2001-04-25 22:46 ` Tim Jansen
[not found] <200104252056.PAA44995@tomcat.admin.navo.hpc.mil>
2001-04-25 21:10 ` Dan Kegel
-- strict thread matches above, loose matches on Subject: below --
2001-04-26 1:09 Dan Kegel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01042520555600.00849@cookie \
--to=tim@tjansen.de \
--cc=dank@kegel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.