[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: API/ABI rank of headers in /usr/include/isofs/cd9660
> 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/.
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
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
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 :)
Main Index |
Thread Index |