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

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

Hi,

> It's probably a historical accident that so much is installed.

That's a positive opinion, regarded from the viewpoint of my goals.


> In a lot of headers, there is "#ifdef _KERNEL" to keep kernel-private
> bits from being accessed by userland.

That's semi-bad news.
My main candidate for incompatible changes is cd9660_extern.h.
It does have such an #ifdef, and the struct iso_mnt which i want
to change is outside of it.

So somehow it was intended to have it exposed. But why ?

It is kindof a cookie, which VFS initially gets from cd9660 and
maybe derived from VFS objects whenever this ISO filesystem as
a whole needs to be referenced:
  int
  cd9660_blkatoff(struct vnode *vp, ...
  {
        struct iso_node *ip;
        struct iso_mnt *imp;
        ...
        ip = VTOI(vp);
        imp = ip->i_mnt;


> Likely all of this could be improved.

I am willing to do the necessary work if i get some instructions
and decisions about interfacing with userland and community.

My plans for now are:

A mount_cd9660 option -s like with the other BSDs.
This will need an API/ABI change which i seem to achieve in a very
compatible and transparent way. I am meanwhile testing userland and
kernel. Old and new in all combinations seem to cooperate neatly.
But the public cd9660_extern.h causes extra pain.

Support for data files of 4 GiB or larger.
This will have to change some assumptions of cd9660 about how
ISO 9660 allows file content to be arranged.
Assessment of relations still underway. One bug caught already
(kern/48799).
It has to be feared that i have to touch several .h files.
So a decision about their API/ABI-ness will be needed there too.


Have a nice day :)

Thomas