On Jun 5,  7:30, Chris G. Demetriou wrote:
> > 	To implement sysfs() one needs to establish a mapping
> > 	between filesystem-type name and number.  I noticed that
> > 	the FreeBSD emulation already has such a mapping, so I
> > 	extended that emulation a bit and made it common instead
> > 	of making another version.  The mapping should in theory
> > 	be dynamic, but in practice it suffices to add new
> > 	filesystem types as (or preferrably a bit before) they
> > 	are implemented for Net/FreeBSD.
>
> This patch, and the understanding behind it, is incorrect.
>
> That table is necessarily OS-dependent.  It maps from file system type
> to the file system type number that _the target OS_ would use for that
> file system type.
>
> Those numbers do not necessarily have any similarity in different
> OSes, so the translation table sill have to be different.
> Additionally, the supported file systems in each OS are going to be
> slightly different.  Only file systems which are supported by the
> target OS should be listed in the table.  Others use some undefined or
> reserved (or otherwise 'weird') value.
>
> So, it's incorrect to attempt to use the FreeBSD table for iBCS2, or
> to generalize it to any other system, for that matter.
>
> Also, the mapping should _not_ be dynamic, for the reasons cited
> above.
>
> If the needs of sysfs() are different than what that table was
> intended to do, well, then it should probably use a different
> mechanism.  8-)

I agree that the table for FreeBSD was intended to solve a different
problem.  However, for the purpose of sysfs() we just need a table - any
table will do - which maps between filesystem type-number and type-name.
I didn't want to create another table to grow outdated (the FreeBSD one
was slightly out of date already).

Any IBCS2 application that needs to treat a specific filesystem type
would (one hopes) use sysfs() to map name-to-number.  I guess the most
common use of sysfs would be to map a filesystem type (as returned by
statfs) to a string, probably for display purposes.  The numbers
and names are dynamic, I think (at least on SCO).

It might be that some application might want to recognize the strings
returned by sysfs().  In that case, we would have to lie to the
application in some way, I guess.  The most 'equivalent' filesystem
type is probably NFS, which you might have noticed I already
did a translation of.  If we wanted to do a better translation we would
need another (type of) table, but I don't know which other translation
we should then make; we don't have EAFS or S5 filesystem types, AFAIK.

I hope this reasoning makes sense  :-)

  -  Arne H. J.