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

From: sin <sin_AT_2f30.org>
Date: Sat, 27 Jul 2013 14:25:04 +0300

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
Received on Sat Jul 27 2013 - 13:25:04 CEST