Date: Sun, 1 Sep 2013 12:54:22 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Initial draft of musl documentation/manual 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.