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/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:24 EST