On Tue, 4 Nov 1997, Todd Vierling wrote:

> [pulled from port-sparc]
> 
> On Tue, 4 Nov 1997, Jim Wise wrote:
> 
> Well, we can't quite make emulation LKM's, yet, but that can be fixed.  I'd
> like a concensus opinion for something.  The big problem with LKM'ifying
> emulations is that emulations often require a little bit of code in locore,
> which can't quite be brought in by LKM.

That should be easy to deal w/.

> So, what about emulation hooks that are linked in from libcompat.a when an
> emulation is not compiled in by default?  These hooks can be intercepted by
> an emulation LKM, and would be no-ops or error-ops if the LKM is not loaded. 
> The LKM could also be unloaded if the refcnt for that emulation is 0, and
> the hooks would then be released.   The hooks could be completely eliminated
> (or actually, the locore code would be eliminated, removing references to
> the code in libcompat) if an option were not specified in kernel config,
> say, "EMUL_SVR4_HOOKS".  The locore code could be included whether the hooks
> or full-blown emulation were compiled in.

Why mess w/ libcompat?

Why not just add generalized lkm hooks in the exec code. If an exec was
not recognized by a compiled-in emulation, each loaded lkm gets called in
turn to have a crack at the program.

Then you don't have an svr4 emulation lkm, you just have an emulation lkm
which does svr4.

Take care,

Bill