Re: Initial draft of musl documentation/manual

[Rich Felker <dalias@aerifal.cx>]

On Sun, Sep 01, 2013 at 05:45:48PM +0400, Vasily Kulikov wrote:
> On Sun, Sep 01, 2013 at 00:41 -0400, Rich Felker wrote:
> > ### Filesystem Layout Dependencies
> > 
> > musl aims to avoid imposing filesystem policy; however, the following
> > minimal set of filesystems dependencies must be met in order for
> > programs using musl to function correctly:
> > 
> > * `/dev/null` - required by POSIX
> > 
> > * `/tmp` - required by POSIX to exist as a directory, and used by
> > various temporary file creation functions.
> > 
> > * `/dev/shm` - must be a directory, and should have permissions 01777.
> > If absent, POSIX shared memory and named semaphore interfaces will
> > fail; programs not using these features will be unaffected.
> 
> If you name such files which are important in case of specific API usage
> and are not needed if this API is not used, why not enumerate other
> files like:
> 
> /dev/ptmx
> /dev/pts/*
> /dev/tty

Indeed, these are unintentional omissions. I will add them.

> Or, even better, compile two lists.  The first is a list of files which
> are needed for sure to be able just to start executable compiled against
> musl,

That list would be empty except for the dynamic linker in the case of
dynamic-linked programs.

> and a list of should-have files which are needed for several
> non-critical APIs like POSIX shared memory stuff.

The problem is that basically all of the files/devices are only needed
for certain particular features, and different people will have
different ideas of what's important. For non-networked use,
DNS/resolv.conf is unimportant. For many programs, /proc is not
important, but I'd rather not document exactly what it's needed for,
since it may be needed for more things in the future.

Perhaps the best structure is:

Group A: These are considered "required" in the sense that they're
used internally and it's intentionally undocumented where they're
used, as they might be used increasingly in the future.

Group B: These are considered "optional" in the sense that they're
used by specific interfaces and we document which interfaces need
them, so you can omit them if you won't be using the associated
features.

Rich