re: Time to merge the pgoyette-compat branch

[Paul Goyette <paul%whooppee.com@localhost>]

Please note that I'm not really very good at explaining things; never
have been, and likely never will be.  :)  I'm trying.  I hope that
the following helps;  more importantly I hope that I don't introduce
any additional confusion.  :)


On Fri, 7 Sep 2018, matthew green wrote:

> congrats getting this fixed up.  i don't like the monolithic module
> we have currently ;-)

Thanks.

> > * Introduction of module "aliases".  In addition to its own name, a
> >    module can now provide alias names.  This is useful for the
> >    monolithic compat module, which now contains the functionality of
> >    the many version-specific modules.  If you load the monolithic module,
> >    its aliases will prevent you from also loading individual-version
> >    compat modules.
>
> i'm not sure i understand the point of this.  how does the normal
> duplicate symbol detection not cause a failure?  why do we care
> about names, vs what is actually imported or exported?  ie, what
> happens differently if this change is excluded?

This issue arises in a situation where you have none of the compat
code built in.  First you load (for example) the compat_70 module,
and then you try to load the monolithic compat module.  You will
of course get duplicate symbols, and the load will fail with EEXEC.
But if you try to otherwise load a duplicate module, the load will
fail with EEXIST.  The alias mechanism allows the monolithic compat
module to have multiple names, including compat_70, so the load can
fail with the (IMHO) more informative EEXIST - module already exists.

Note also that this change includes modification to the modctl(2)
MODCTL_STAT command.  As a result, modctl(2) itself now has a
compat_80-controlled MODCTL_OSTAT command as well as a new version
of MODCTL_STAT, and modstat(8) was modified to undertand the new
format of returned data.  The versioning was also done in for the
compat_netbsd32 version of modctl.  :)


> > * Removed linking of the .o kernel compat library into all kernels.
> >    This caused problems, since the library included lots of compat
> >    symbols, but did not include module linkage; attempts to subsequently
> >    load some modules would fail due to multiply-defined symbols.
>
> can you expand upon this more?  what exactly has changed how?

When maxv did (one of) his rototill a while ago, he replaced the .a
compat library with a .o library.  As I recall, the reason was that
there were some shared routines that weren't strictly compat (I don't
have the original discussion handy).  By using a .o library, we end up
with much of the compat code included in the kernel even without the
COMPAT_xx options.  (And the routines that caused maxv to do this have
now been included in a module of their own, and are required by their
callers.)

On the branch, we return to a .a library, only including in the
kernel those things that are actually needed to resolve symbols in
the kernel.

If I remember correctly, you could build a kernel without all the
COMPAT_xx defined, and then try to load compat_sysv and watch for
the duplicate-symbol messages.  The compat_sysv module could not be
loaded in this case.  Yet, even though all the code for compat_sysv
was present, the compat_sysv module initialization code would never
have been called, so none of its syscalls would ever have been
syscall_establish()ed.

(FWIW, this was the other straw that broke my poor camel's back and
made me undertake this effort!)

Please note that if you build a default GENERIC kernel, with all of
the modules built-in, nothing changes other than that you'll see a
lot more module names when you run modstat(8).  The changes being
made are only meaningful when you actually use load{ed,able} modules.



+------------------+--------------------------+----------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+------------------+--------------------------+----------------------------+