Date: Fri, 7 Sep 2018 23:27:36 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: internal header proposal On Fri, Sep 07, 2018 at 01:23:12PM -0400, Rich Felker wrote: > Option 1: The big fancy header wrapping > > Add a new tree of "wrapper headers" for public headers (let's call it > $(srcdir)/src/include), and -I it before the real public ones > ($(srcdir)/include). These new headers include their corresponding > public header (../../include/[self].h) then add anything else that's > supposed to be "public within musl". For example sys/mman.h would have > stuff like: > > hidden void __vm_wait(void); > hidden void __vm_lock(void); > hidden void __vm_unlock(void); > > hidden void *__mmap(void *, size_t, int, int, int, off_t); > hidden int __munmap(void *, size_t); > hidden void *__mremap(void *, size_t, size_t, int, ...); > hidden int __madvise(void *, size_t, int); > hidden int __mprotect(void *, size_t, int); > > hidden const unsigned char *__map_file(const char *, size_t *); > > Now, every file that needs to use mman.h functions without violating > namespace can just #include <sys/mman.h> and use the above. If we > wanted, at some point we could even #define the unprefixed names to > remap to the prefixed ones, and only #undef them in the files that > define them, so that everything automatically gets the namespace-safe, > low-call-overhead names. This idea is a lot like how > syscall()/__syscall() work now -- the musl source files get programmed > with familiar interfaces, and a small amount of header magic makes > them do the right thing rather than depending on a public namespace > violation. > > If this all seems too radical, or like it has potential pitfalls we > need to think about before committing to it, I have a less invasive > proposal too: I have this option implemented and it's working out really well, with just the following headers: src/include/arpa/inet.h src/include/langinfo.h src/include/pthread.h src/include/resolv.h src/include/signal.h src/include/stdlib.h src/include/string.h src/include/sys/mman.h src/include/time.h src/include/unistd.h This list tells a lot about what parts (how little) of libc are useful/necessary for implementing other parts. So far I've dropped the number of inline-in-source declarations down from over 160 to 41, and most of the ones left are either ABI/linking glue stuff, or internal interfaces with a single consumer. Nothing left is purely a namespace-protected version of a public function. I'll wrap up the rest soon and get all this ready to push. Already found and fixed a few small bugs in the process. :) 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.