Re: Tagged files in /proc
Albert Cahalan (albert@ccs.neu.edu)
Mon, 26 Feb 1996 09:59:56 -0500 (EST)
> Kjetil Torgrim Homme writes:
> > | extension: hello
> > | +world
> >
> > Is the + really necessary? That lines beginning with whitespace is a
> > continuation of the previous line is a convention from RFC-822, it
> > would be nice to use it here. It would invalidate this example,
> > though, due to the lead-in SPACE:
> >
> > | tag1: value
> > | yet-another-tag This is a sample entry :3.141592
>
> This is up to discussion, but I personally prefer my approach, as it
> will ease outputting legal file contents.
>
> Assume this case: The kernel wants to output a line with the contents
> "Hello world". In order to make reading the file easier, when being
> cat'ed, the kernel decides to do some line-wrapping after 72
> characters. If we decide to stick with my solution, then the kernel
> can split the line at any arbitrary character position and all three
> space characters would be preserved. If OTOH, we decided to trim
> lead-in space characters, the kernel would have to pay extra attention
> as to never split the line before a space character.
Why make this so hard for the kernel and apps?
Always quote filenames like this: /my filename has a space/
Numbers are always 0-padded hex: 00000B62
Memory sizes are given in allocation units, often 4k or 8k pages.
Space pad all strings - thus filenames are always padded to about 255.
It would not be pretty, but it is still human readable.
It is much faster, and you can just use proper tools to read proc
information. I would say that /bin/cat is not a proper tool,
unless you are trying to debug a better tool.