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. > > 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. 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? > 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. > Thanks, > sin Ciao, Markus