> We want to avoid these problems:
> 1) It is hard to parse (some) /proc files from userspace
> 2) As /proc files change, parsers must be changed in userspace
>
> Still, we want to keep on offering
> 3) Human readable /proc files with some amount of pretty-printing
> 4) A /proc fs that can be changed as the kernel needs those changes
I've read the whole thread, but i still don't get it. Your solution doesn't
improve (1) for parsers in scripting languages, where it is frequently far
easier to parse ASCII stuff than messing with binary things, when not almost
impossible. So we don't make any progress here. And for languages like C,
where this will have most use, there actually is solution and it is working.
So, please, can you enlighten me, what's so wrong on sysctl? It actually
provides exactly what do you want, and you even don't need to bother yourself
with open() etc ;). So it would be maybe better improving sysctl interface,
especially mirroring of all /proc stuff there, instead of arguing about scanf()
:-).
So can you please explain me merits of your approach against sysctl?
--Petr "Pasky" Baudis
UN*X programmer, UN*X administrator, hobbies = IPv6, IRC Real Users hate Real Programmers. Public PGP key, geekcode and stuff: http://pasky.ji.cz/~pasky/ - 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/