[9fans] fs layout and libc questions

[9fans] fs layout and libc questions

[Quinn Dunkan]

What's the difference between /lib and /sys/lib ? Supposing I have
(machine- independent) language libraries... where do they go? The
natural approach for me would be to do

disk/kfscmd 'create /lib/foo sys sys d'
bind -cb $home/lib/foo /lib/foo

for the language "foo", but this requires that I have write to /lib on
the file server (to create the directory to union). Of course, I do for kfs,
but in a "real" plan9 setup, I possibly wouldn't. I guess in that instance, I
could bind my whole $home/lib, but that seems a bit messy. Anyway, is this the
"correct" approach?



Somewhat silly question:

getenv() doesn't do any checking on the name it is passed. So by passing
a string with '..' one can read (or write to, with putenv) any file on
the system, or by passing a string greater than 194 characters, get
a buffer overrun. The question is, is this a design decision? I.e.
"only the client knows if an env var name can be trusted, so let's not
complicate the libc with checks, but let the client do them".

I notice rc goes straight to #e, and uses snprint(), so this doesn't
affect it (should it go directly to #e?  is there any reason to mount another
environment?).

My inclination would be to have the libc getenv() and putenv() check
their args. It costs almost nothing, and the less potentially dangerous
things the client has to think about checking the better.

Re: [9fans] fs layout and libc questions

[rob pike]

The original ideas for /lib and /sys/lib were that /lib would be a
"library" of general stuff, while /sys/lib would be things that
directly supported a particular application.  Dictionaries are in
/lib, troff macros in /sys/lib.  The distinction is hard to draw
sometimes and wasn't followed a lot of the time, but it is still
useful.

-rob

Re: [9fans] fs layout and libc questions

[presotto]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

We've been way to sloppy with /lib and /sys/lib to the point of the
distinction being almost meaningless.

In the case of libraries that are architecture dependent, the general
idea is to link them under their architecture's tree.  In  the manner
of $home/bin/{386, mips, ...} you can have a $home/lib/{386, mips, ...}
and in your lib/profile:

	for(i in 386 mips ...)
		bind -b $home/lib/$i /$i/lib

That way they'll be in the right place for {8, v, ...}l to find them.
Of course, if you put pragma's in the .h's for the libraries that point
to the libraries, you don't have to link them anywhere in particular.
However, the above might make life easier for you in the long run since
you can override just by binding.

If the libraries are also language dependent and the linking convetions
are different than those of C (or the names clash), you can have a
second level just as we do in /386/lib/alef, e.g.:

	for(i in 386 mips ...)
		bind -b $home/lib/$i/alef /$i/lib/alef

In the end, the only important thing is that the pragma's in the
include files point to the right place:

	#pragma	lib	"alef/libxyzzy.a"

The path is relative to /$objtype/lib.

[-- Attachment #2: Type: message/rfc822, Size: 2661 bytes --]

From: Quinn Dunkan <quinn@envy.ugcs.caltech.edu>
To: 9fans@cse.psu.edu
Subject: [9fans] fs layout and libc questions
Date: Mon, 19 Mar 2001 00:51:32 -0800
Message-ID: <200103190851.AAA00358@tammananny.tiger>

What's the difference between /lib and /sys/lib ? Supposing I have
(machine- independent) language libraries... where do they go? The
natural approach for me would be to do

disk/kfscmd 'create /lib/foo sys sys d'
bind -cb $home/lib/foo /lib/foo

for the language "foo", but this requires that I have write to /lib on
the file server (to create the directory to union). Of course, I do for kfs,
but in a "real" plan9 setup, I possibly wouldn't. I guess in that instance, I
could bind my whole $home/lib, but that seems a bit messy. Anyway, is this the
"correct" approach?



Somewhat silly question:

getenv() doesn't do any checking on the name it is passed. So by passing
a string with '..' one can read (or write to, with putenv) any file on
the system, or by passing a string greater than 194 characters, get
a buffer overrun. The question is, is this a design decision? I.e.
"only the client knows if an env var name can be trusted, so let's not
complicate the libc with checks, but let the client do them".

I notice rc goes straight to #e, and uses snprint(), so this doesn't
affect it (should it go directly to #e?  is there any reason to mount another
environment?).

My inclination would be to have the libc getenv() and putenv() check
their args. It costs almost nothing, and the less potentially dangerous
things the client has to think about checking the better.