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

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

Hi,

> I think Greg is right - historic accident.

They are quite up to date.

Is the mechanism known by which /usr/src/sys/fs/cd9660/*.h
gets forwarded to /usr/include/isofs/cd9660 ?
Has some script or makefile to be changed ?


> I would check with nxr.netbsd.org

93 milliseconds later:
No "iso_mnt" in project(s) "src" outside of /src/sys/fs/cd9660/.
  http://nxr.netbsd.org/search?q=iso_mnt&project=src&defs=&refs=&path=&hist=

Cross-check: "iso_args" is public.
nxr.netbsd.org finds /src/sbin/mount_cd9660 and others.

Any other proposals for look-up ?


> Otherwise let common sense decide wether any third-party software would have
> good reasons to use anything in those headers.

I'd really say no.

mount(2) and /usr/include/isofs/cd9660/mount_cd9660.h is as dirty
as you can get in userland. Even VFS is supposed to be encapsulated
by libc, isn't it ?
Those entrails are opaque to VFS. I am certain (and can be wrong).

I will possibly refrain from changing inappropriate (int) to
(uint32_t) in struct iso_mnt, and only attach a new member
(unsigned long int) to its end.
This will not fix potential 4 TiB rollovers, but will be more
compatible and still allow this:

  netbsd# ./mount_cd9660 -s 8768 /dev/cd0d /mnt/iso
  netbsd# ./mount_cd9660 -o getargs /dev/cd0d /mnt/iso
  0x40<ssector>
  -s 8768

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

Nevertheless, for clarity and to remove lures for shooting
the own foot, i'd still like to get a decision about the removal
of at least four, better five of the files from /usr/include.
Only then will undue includers break and have a reason to enter
this discussion.

I am sure that one could provoke clear compiler error messages
by installing placeholders for some time of testing.

Encapsulation is a fine design pattern. One should try to enable it.

So if anybody can shed light on the mechanism that publishes
the cd9660/*.h files, then please consider to narrow it to only
 mount_cd9660.h . (iso.h makes few sense either, although
it is not really deliberate kernel entrails.)


Have a nice day :)

Thomas