Date: Sun, 24 Jan 2016 22:59:25 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Bits deduplication: current situation I'm about to try starting the bits deduplication, but before getting started, I took a quick survey of the current bits headers we have: endian.h: We could have generic ones for little and big, but each arch that has subarchs with both endians needs its own custom version that tests the psABI-defined macro. errno.h: Almost all archs can share a generic errno.h. Those that don't might be able to share sub subset (thus benefiting from a more elaborate bits-header-gen system) but only a couple ugly archs are affected anyway. fcntl.h: Not sure how much these differ or how much they could share. Almost all archs' versions are unique now, but some may only have cosmetic differences. fenv.h: We can have a generic softfloat/no-fenv version, but each arch with hard float basically needs its own version. float.h: Only 3 generic versions should need to exist: ld64, ld80, and ld128(ieeequad). io.h: Most archs can use a generic empty file. ioctl.h: Varies highly but it may be possible to have generic versions (perhaps one 32-bit and one 64-bit) for the clean archs to share. ipc.h: Lots of trivial variations to account for kernel bugs in type/padding/etc. Not sure if they can be unified. limits.h: Varies by page size and 32/64-bit. Not sure if it makes sense to have generic versions; the logic to pick which one would be as large as the file. It would be nice to get the #ifdefs out of it though. mman.h: Seems to vary but differences may be mostly cosmetic; not sure. msg.h: Same deal as ipc.h. poll.h: Empty except for mips; generic definitions are in top-level poll.h now. With bits dedup we could move them to a generic bits file so that top-level doesn't have a nasty #ifndef. posix.h: Only 2 versions: ILP32 and LP64. They can be generic. reg.h: Completely arch-specific except in the case of multiple logical archs for the same ISA (x32). resource.h: Same deal as poll.h. sem.h: Same deal as ipc.h. setjmp.h: Arch-specific, same as reg.h. shm.h: Same deal as ipc.h. signal.h: Arch-specific, and currently omits siginfo_t which is gratuitously different on mips (and thus broken). Moving siginfo_t into it would add A LOT of duplication and maintenance burden unless we have an elaborate bits generation system that can piece these headers together from multiple parts so the siginfo_t part can be shared by all but mips. socket.h: The main difference is that workarounds for bogus kernel definitions of msghdr and cmsghdr are needed on 64-bit archs. A few archs also have their own definitions of some constants which override the top-level file's. stat.h: It varies a lot on current archs, but in principle there's a generic stat/stat64 that should be used for all new archs on the kernel side, so perhaps we could have a generic one for that. statfs.h: Mostly generic, but mips and x32 have quirks. stdarg.h: Not even used except with ancient/broken compilers. Same on all archs but i386 where the invalid legacy defs are provided. Probably should be dropped entirely. stdint.h: Purely a matter of 32 vs 64 bit, otherwise totally generic. syscall.h: Arch-specific except new kernel archs should use the generic one, which we can do as a generic. termios.h: Generic except for wacky archs (mips and powerpc). user.h: Highly arch-specific. The good news is that there are not a lot of places where there's value in doing anything elaborate with the deduplication. Just having a fixed ordered list of include dirs to search while building, and installation rules to pick the first matching one and install it in $(includedir)/bits, would probably work. It's possible that we could eliminate some bits headers entirely by having features.h (via a new bits/features.h) expose some parameters like endianness, ILP32-vs-LP64, etc. which the top-level headers could then use to define things in a non-arch-specific way. I'm not sure whether I like doing that though. It simplifies porting and header maintenance work, but at the cost of some explicitness whereby you can just open the header file (or the bits header file) and see how something is defined right away. A possible compromise is to highly abstract these things at the musl source level, but generate flat bits files to install, or even flatten the headers completely to remove bits so that all definitions are inline and explicit in the top-level headers. Ideas/requests/preferences/etc.? 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.