Re: [dev] [sbase] [patch v4] Add df(1)

From: Markus Wichmann <nullplan_AT_gmx.net>
Date: Sat, 27 Jul 2013 11:59:02 +0200

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
Received on Sat Jul 27 2013 - 11:59:02 CEST