Re: Suggested dual human/binary interface for proc/devfs

From: Ed Carp (erc@pobox.com)
Date: Fri Apr 07 2000 - 22:09:15 EST


Linus Torvalds (torvalds@transmeta.com) writes:

> Guys, remember what made UNIX successful, and Plan-9 seductive? The
> "everything is a file" notion is a powerful notion, and should NOT be
> dismissed because of some petty issues with people being too lazy to parse
> a full name.
>
> The same is true of ASCII contents. Binary files for configuration data
> are BAD. This is true for kernel interfaces the same way it is true of
> interfaces outside the kernel.

And yet there are files in user space that have been a part of UNIX forever that are binary in nature - /etc/utmp and friends immediately comes to mind.

> I tell you, you don't want the mess of having things like the Windows
> registry - we want to have dot-files that are ASCII, and readable with a
> regular editor, that you can do grep's on, and that can be manipulated
> easily with perl.

Yes, that's all true, but I think a standardized format would go a long way towards making this stuff more easily parsed and at the same time readable by humans.

> Think of /etc/password. And think of the STUPIDITIES that a lot of UNIX
> vendors made with their user managment databases - it happened not once,
> but multiple times. All in the name of unified tools (never mind the fact
> that none of the standard tools worked any more), and in the name of
> efficiency (the "parsing ASCII wastes CPU cycles").
>
> Do people think that .bashrc would be better in a binary format that uses
> special tools to edit it? I don't think so. Don't make the kernel
> interface files fall into that classic _stupid_ black hole.

The only problem with ASCII data in flat files is that it doesn't scale well. People are already screaming about "how Linux doesn't scale". On the one hand, that's marketing obfuscation put out by people who have a ve$ted intere$t in maintaining the Window$ status quo, and /proc/devfs certainly isn't large enough to worry about performance problems. On the other hand, having 100,000 entries in /etc/passwd takes a while to search, and those sorts of things are what people point to when they talk about lack of scalability.

I don't know what the answer is - perhaps a replacement library for things like getpwent and friends that would simultaneously update a database and also flat files would satisfy both camps ... or maybe no one. Or maybe arranging the data so that one could easily parse it and at the same time be easily readable by humans. I think both sides have valid points, but I can't see at the moment a solution that would make Alan and Linux both happy.

-
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:11 EST