Re: some more JOBS

[Steinar Hamre <steinarh+hurd@stud.fim.ntnu.no>]

On Sat, Aug 11, 2001 at 09:49:05AM -0700, Marcus Brinkmann wrote:
> On Fri, Aug 10, 2001 at 04:56:12PM +0200, Steinar Hamre wrote:
> > This #ifdef OS used in this way is hell to maintain as soon as more
> > than two operating system is to be supported.  In addition different
> > versions of the same OS would support different sets of filesystems!
> > A much better approach in cases like this, would be:
> 
> Indeed.  However, it is questionable if the small set of common filesystems
> warrants a unification of this code.

My experience is that the number of common filesystems is very large.
Actually, Linux and *BSD support most filesystems used by any widespread unix
implementation. Single-OS filesystems (like ext2 originally was), is not very
common anymore.  (Today, somewhere around a dozen operating systems
understand ext2.)

> I like your approach, but it only shines if you also map the different type
> ids on the systems to the same symbol, like this:
> 
> #ifdef UFS_SUPER_MAGIC
> #define FSTYPE_UFS UFS_SUPER_MAGIC
> #endif
>
> etc.

I agree this can be a problem in some situations.  But this is the f_type
member of struct statfs.  If some operating system at some point in the 
future, should decide to use the same f_type for two filesystems,
that are speparate f_type's in another operating system, that
should be dealt with then.  I really have a problem with creating
workarounds for problems that does not exist, and hopefully never will.
However I like the idea of making code portable to sensible interfaces
on operating systems that _do_ exist.


In situations where this is an actual problem, I have used things like:

switch (c) {
#ifdef A
    case A:
	...
	break;
#endif
#if defined(B) && (B != A)
    case B:	
	...
	break;
#endif


> If you truly want to fix this code, you should get the POSIX standard
> extended so that it defines interfaces to check if a certain fstype
> number is a supported filesystem type and what string (name) it maps to.

The main problem here is that there is not (to my knowlegde) any POSIX
standard describing statfs/statvfs at all.  (See, not even the name is
standardized!)

However, a interface similar to the one you describe, do already exist.
NetBSD, FreeBSD and OpenBSD all have the f_fstypename member of
struct statfs.  In fact, OpenBSD do not anymore have the f_type!
(NetBSD and FreeBSD keeps both members for compability, a more
sensible solution.)

f_fstypename could be added to glibc without any changes to
Linux or Hurd, I think.

	Steinar