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.
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).
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.
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. Till someone changes
the kernel to print out a bit more stuff. Then I've
either got a buffer overflow (if I can't code) or a
truncated string. Either way, its a problem.
So what is needed is a kernelfs virtual filesystem that provides
kernel info to user space.
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).
-Erik
-- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- - 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/