Messages in this thread | | | Date | Fri, 4 Jan 2002 07:19:40 -0500 | From | "Eric S. Raymond" <> | Subject | Re: LSB1.1: /proc/cpuinfo |
| |
Erik Andersen <andersen@codepoet.org>: > I once wrote up /dev/ps and /dev/mounts drivers to eliminate proc > for embedded systems (pointer available if you care). It was not > warmly received, but I did form some opinions in the process.
Sure, I'd like to see this work.
> The main things to think about are > 1) machine readability > Generally speaking the kernel gods have decided that > ASCII is good, binary structures and such are bad (think > endiannes, nfs exports, and similar oddness).
I agree with this decision. Binary structures would be false economy, trading away readability and flexibility for a marginal speed gain.
> 2) typing > Right now, if some /proc file prints a number, user space > has to go digging about in the kernel sources to find > what type that thing is -- int, uint, long, long long, etc. > Cant tell without digging in the source. And what if > someone then changes the type next week -- userspace > then overflows.
I'm not very worried about this. On modern machines int == long and the only case that's a potential headache is long long. If longer than int-size data is labeled, we'll be OK.
> 3) field length > When coping a string from /proc (say /proc/mounts), > userspace has to go digging in the kernel source to > find the field length. So if I copy things into a > static buffer, I may be fine.
I think the right answer to this is usually "don't use a language that has static buffers". :-)
> So what is needed is a kernelfs virtual filesystem that provides > kernel info to user space.
I don't care what it's called. I've seen `sys', 'system', and 'archfs' thrown around.
> It needs a format that provides information as an organized > directory hierarchy, which each directory and filename > identifying the nature of the provided information. Files should > provide information in ASCII with one value per file (to avoid > all the tedious parsing), but also provides along with that bit > of information type and or/length information. > > In some cases I guess we may also need more complex classes on > information. (lists of key-value stuff for example).
One value per *file*? That seems excessively fine-grained. Sometimes you want multiple values per file because the information is a functional unit for reporting to humans. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Americans have the will to resist because you have weapons. If you don't have a gun, freedom of speech has no power. -- Yoshimi Ishikawa, Japanese author, in the LA Times 15 Oct 1992 - 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/
| |