Subject: Re: emul LKM hooks (was Re: Linux emulation for SPARC?)
To: Todd Vierling <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 11/05/1997 14:16:40
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.