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