tech-kern archive

[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

"Thomas Schmitt" <> writes:

>> I think Greg is right - historic accident.
> They are quite up to date.

Sure.  It's accidental that so much is exposed, but part of the build
system that they are copied.

> 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 ?

See src/sys/fs/cd9660/Makefile.  It's specified quite straightforwardly.

> Any other proposals for look-up ?

grep on the source tree :-)

> 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

New types should probably be uint64_t, rather than long.

> 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.

You can certainly drop them in the Makeefile in your source tree and do
a build and see what happens.  If it doesn't hurt the (full) base system
build, it seems reasonable to propose stopping installing them.

Attachment: pgp_fMe73Edc_.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index