In <Pine.LNX.3.96.1000409003418.5273O-100000@calvin.shorelink.com> George Bonser (grep@shorelink.com) wrote:
> On Sun, 9 Apr 2000, Anthony Barbachan wrote:
>> > Disagree. Too many bytes to describe something that should be really
>> simple, and you have to write your own parser, etc. Please don't try to use
>> the latest technological whizz-bang as a solution for a problem that doesn't
>> exist.
>> >
>>
>> I would suggest the .ini file type file format, like what Samba uses. Its
>> relatively easy to parse and also quite understandable to most people.
> ANY kind of common format would be fine. Just looking at the differences
> between /proc/cpuinfo and /proc/devices shows how difficult it could be to
> have one single parser for all /proc files. Something like this world
> work.
> /proc/cpuinfo
> processor 0 {
> vendor_id:GenuineIntel
> cpu family:6
> model:6
> ...
> }
> processor 1 {
> same stuff
> }
> Things are grouped with braces, leading white space ignored till first
> char. After first non-whitespace char everything is significant up to
> attribute:value deliminator ":" in this case. Note even the inconsistancy
> inside cpuinfo ... vendor_id vs. "cpu family" instead of cpu_family.
> Things are not even consistant within the same files.
> If the data were presented by the kernel is a format such as the above, it
> would be a simple matter to build a generic user space parser with final
> output in XML or human readable form or whatever. Simply tell the standard
> parser what you format you want. The basic problem is that there is no
> consistancy to the stuff in /proc.
Basic proble is that there are introduced problem where should not be one.
Look: you all trying to express tree-like structure of simple values
(numbers like cpu_family or strings like vendor_id). There are ALREADY
exist quite good way to do this: VFS. It handles trees quite well, you do
not need any parsers at all and you can not mess with whitespaces or
anything. Why to introduce "standard format", "standard parser" and so
on where NO SUCH NEED EXIST ? Yes, it'll lead to deep directory trees but
99.9% (if not 99.999%) information do NOT need superfast access. And for 0.1%
(or rather 0.001%) of stuff which must be accessed REALLY fast you can use
some other [UGLY BUT FAST] interface.
> Heck, you could even collapse some existing subdirs into a single file ...
> /proc/sys/net/ipv4/... might be an example. Seems we are using the
> filesystem as a sort of pre-parser.
This is EXACTLY how it should be used. Any file with more then ONE number
or more then ONE string entry under /proc is DESIGN PROBLEM. And in most
cases this "optimisation" will lead to broken tools, complex parsers in both
userspace and kernelspace and generally produce much more problem then
solves (how many times psutils was broken due "optimized" blob-like files
/proc ?). Cases where few values in one file can significally speed up
something are rare and far between, cases where it causes problems are
numerous and VERY common.
> Have a look at /proc/net/dev for a completely different format. It's gotta
> suck but I imagine a lot of programs rely on these weird formats.
> then again ..." Backwards compatability is not a priority with us Yanks"
Exactly. Then only way to solve procfs problem is to leave procfs in place for
now and develop new sysfs with clear design. If we want to clean up procfs we
NEED to broke LOTS of applications and we'll do this anyway better to do
everything from scratch.
-
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/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:12 EST