Re: API/ABI rank of headers in /usr/include/isofs/cd9660

["Thomas Schmitt" <scdbackup%gmx.net@localhost>]

Hi,

David Holland wrote:
> In an ideal world, each filesystem would install two headers:
>  - one with the structures, constants, etc. needed to work with the
> on-disk format; this would be used by fsck, newfs, makefs, etc.

Sounds dangerous for my cause.

Obviously my grepping was not good enough on the first try.
  grep -R 'isofs/cd9660/.*\.h' /usr/src
now finds
  /usr/src/distrib/utils/sysinst/util.c:#include <isofs/cd9660/iso.h>
  /usr/src/usr.bin/fstat/isofs.c:#include <isofs/cd9660/iso.h>
  /usr/src/usr.bin/fstat/isofs.c:#include <isofs/cd9660/cd9660_extern.h>
  /usr/src/usr.bin/fstat/isofs.c:#include <isofs/cd9660/cd9660_node.h>
  /usr/src/usr.bin/pmap/pmap.h:#include <isofs/cd9660/iso.h>
  /usr/src/usr.bin/pmap/pmap.h:#include <isofs/cd9660/cd9660_node.h>
  /usr/src/usr.sbin/mscdlabel/iso9660.c:#include <isofs/cd9660/iso.h>

So making these headers private seems to be impossible,
although  cd9660_extern.h and  cd9660_node.h  do not contain
on-disk format info, but rather VFS implementation entrails.

iso.h and iso_rrip.h are indeed representations of the specs.


I would love to justify my changes in
  cd9660_extern.h 
  cd9660_node.h
by Martin Husemanns comment to kern/48808:
  "Forward binary compat like this is not needed - a new mount_cd9660 binary
   can expect a new kernel always."
May i expand this expectation to above includers ?
Will they be recompiled if changed headers become public ?
I.e. may i break ABI compatibility ?

The changes necessary to enhance cd9660 for large data files in
  cd9660_node.h : struct iso_node
will probably affect its includers even on API level.

Less problematic are the planned changes in
  cd9660_extern.h : struct iso_mnt


A main suspect was makefs(8), which i now checked again.
Two includes are suspicious, although i do not understand how
the include path would point to /usr/include/isofs/cd9660/:
  ./cd9660.h:#include "iso.h"
  ./cd9660.h:#include "iso_rrip.h"
These names are not to find underneath
  /usr/src/usr.sbin/makefs
but exist in
  /usr/src/sys/fs/cd9660

Regrettably i cannot yet experiment with it:

  netbsd# cd /usr/src/usr.sbin/makefs
  netbsd# make USETOOLS=never
  ...
  In file included from /usr/src/usr.sbin/makefs/ffs/buf.h:48:0,
                   from ffs/ffs_extern.h:35,
                   from ffs.c:107:
  /usr/include/stddef.h:41:25: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'ptrdiff_t'


> All the other stuff (in-memory structures, function prototypes, etc.)
> should be in other headers that aren't installed for userland.

This content description applies to all <isofs/cd9660/*.h>
except the header for mount(2) type MOUNT_CD9660: cd9660_mount.h
and except the headers with ISO 9660 format structs and constants:
iso.h and iso_rrip.h

But obviously some tools found reasons to include others
nevertheless.

kern/48808 proposes to only keep <isofs/cd9660/cd9660_mount.h>.
This will need to be changed now.

In the next days i will try to find out how much the found
tools depend on cd9660 entrails and what consequences my
change proposals would have.


Have a nice day :)

Thomas