On Sat, Jul 27, 2013 at 11:59:02AM +0200, Markus Wichmann wrote: > On Fri, Jul 26, 2013 at 10:54:43PM +0300, sin wrote: > > On Fri, Jul 26, 2013 at 12:14:08PM +0100, Nick wrote: > > > On Fri, Jul 26, 2013 at 01:51:01PM +0300, sin wrote: > > > > Incorporated Steve's changes as well to make it compile/work > > > > on OpenBSD. I realize #ifdef's are terrible but for now it should > > > > do the trick until we come up with a proper solution to this. > > > > > > Is there really no sensible way to get the required information for > > > most POSIXish systems? How does coreutils do it (I expect tons of > > > way more awful ifdefs than you've done here, but it's worth > > > checking)? > > > > No idea, I have not looked at the coreutils code. Will check it out. > > > > I just did. At least in the current version in Debian Squeeze it > contains a whole lot of algorithms for different system interfaces, > including listmntent(), getmntent() (for Linux, 4.3BSD, SunOS, HP-UX, > Dynix and Irix), getmntinfo() (in two different versions, one for > 4.4BSD, one for NetBSD 3.0), getmnt() (for Ultrix) and > next_dev()/fs_stat_dev() (for BeOS). All of these are checked for > availability, then executed and abstracted into GNU's own > datastructures. Which, in this case, is a linked list. > > Apparently this stuff can't be done portably.
We should probably make a decision on how portable we want to be. > > > I wonder what the right approach for utilities that can't be made > > > portable should be? Are there any others that are likely to have > > > these problems? > > > > If the build system can switch between between say Linux ops and > > OpenBSD ops then we could have something like os/openbsd.c and > > os/linux.c (for things that are not portable between them). > > > > Then the df.c code can just call a function that will be implemented > > by both OSes (with the same signature etc.). > > > > That would be a good choice, but I see problems on the horizon. Like, > what happens if stuff is actually portable between Linux and OpenBSD, > but some third option, say, Solaris, behaves differently? File > descriptor readiness notification comes to mind. Not that I think we'd > ever need that. If not all three behave the same then we should still abstract it. > What if some stuff is portable between operating systems, but unportable > between architectures? What if the combination of both matters? Will we > have a sysdeps tree like glibc? I would not worry much about that at the moment. I can't think of anything. Although if that really matters then we extend the above solution to include something like an arch/ folder. > > The number of tools that might require this glue code is less than > > 2% of the overall number of tools. So maybe leaving the #ifdef's for now > > is enough until we encounter other situations as well? > > > > I think that would be preferable. Unless we get a leaning tower of > hostnames at some point, I would go with ifdefs in those tools as well. David, what do you think? Thanks, sin
