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

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

Hi,

David Holland:
> at least in the case of ufs (dunno about cd9660) the
> definitions are all mixed together.

In cd9660 it is the full spectrum:

---------------- What i deem legit userland API

cd9660_mount.h : struct iso_args and its flags for mount(2).

---------------- Somewhat exotic userland API supplements

iso.h          : Constants and structs describing the byte layout of
                 ISO 9660 storage entities. Educational and re-usable
                 because supposed to stay absolutely stable.

cd9660_rrip.h  : About the same for ISO 9660 add-on SUSP/RRIP (Rock Ridge).

---------------- API for binaries intimately related to the kernel

cd9660_node.h  : In the non _KERNEL part it exposes the filesystem specific
                 struct iso_node which serves as vnode.v_data:
                 - struct iso_node points to the ISO 9660 directory record
                   on disk.
                   I did not yet decide whether i will propose to break
                   this API aspect. Currently i tend to not breaking it.
                 - type ISO_RRIP_INODE representing RRIP POSIX attributes.
                 - Macro to retrieve iso_node from vnode.
                 - Macro to retrieve vnode from iso_node.
                 - a riddling flag bit IN_ACCESS which gets set but
                   not inquired in cd9660
                 - two riddling macros i_forw, i_back which are unused
                   in cd9660.
                 - To come (in order to keep that API fully usable after
                   my changes to cd9660 and especially iso_node):
                   - Macros to tell presence of multi-extent code in
                     cd9660 and to tell its limitations.
                   - A description of address and section count encoding
                     in ino_t.
                   - Macros to retrieve address and section count.
                   - Macro which defines a C function which can tell
                     the overall byte count of the data file represented
                     by an iso_node.
                     To be implanted and called in programs which cannot
                     keep themselves from groping through VFS.

cd9660_extern.h: In non _KERNEL area there are a few entrails of the
                 filesystem driver, and the struct iso_mnt which serves
                 underneath struct mount as .mnt_data.
                 Programs which peek into iso_node might be interested
                 in hopping further to iso_mnt.

---------------- Internal headers

iso_rrip.h     : Internal definitions for the RRIP interpreter.
                 No _KERNEL area.
                 This interpreter is unreachable from userland, afaics.

--------------------------------------------------------------------------

The cleanup effect of removing only iso_rrip.h would be tiny.

A more radical approach would be to demand that the intimately kernel
related binaries include headers from /usr/src/sys/fs/cd9660 rather
than from /usr/include/isofs/cd9660.
This would make clear that they are depending on inofficial kernel
entrails.


Have a nice day :)

Thomas