eeh@netbsd.org wrote:
> You want to be able to add emulations in LKMs more sanely.  What
> method do you plan to use to do that?

First of all, centralize the exec info and make struct emul
contain only emulation-specific stuff. This is what the patch does.

Then, the exec switch array would probably become an array of
(execsw[], nexecs, next) triples, so that it would be easy
to chain additional execsw structures. And couple of functions
would be added to manipulate the structs, which would also care
about locking and updating exec_maxhdrsz.
I think it's not necessary to lock individual execsw[] entries,
one lock while using/manipulating the execsw structues would probably be
okay - the time period is very brief and loading/unloading an
executable format is not likely to happen too frequently. sys_execve() would
use readonly/shared lock, LKM write/exclusive lock.

After that, find out how to get rid of the COMPAT_FOO conditionals
in MD syscall() or similar functions. This would probably need
to make trap()/syscall() emulation-specific. This thing may get
postponed until after LM_EMUL LKM changes, since playing with entirely new
emulation is not something I need ATM.

Then a method would be added to kern_lkm.c to load emulations.
When an emulation would be loaded, all supported exec format
hooks for it would be loaded as well, LM_EXEC would probably
get obsolete. I'm not sure about this bit. Though having
an ability to load executable format support separately from
emulation would be cool, I do not need it and I don't think
(my) work in that area is worth (my) efford - it's not likely NetBSD
itself would start to use other format than ELF. If you need
to play with new exec format, it would still be possible
to load the stuff via dummy emulation. Actually, making the new LM_EMUL
LKM interface flexible enough to support adding execsw[] entry only
would be probably not too difficult. But it should be able
to add both emulation and appropriate execsw[] entries, as this
would be common case.

> How do you deal with cases like COMPAT_NETBSD32 where what is a
> native binary on some machines needs to be run under an emulation
> on others, or with future COMPAT_SVR4_32 which has the same problem.
> Currently this is handled by *very careful* ordering of the execsw[]
> table where exec_netbsd32_makecmds needs to come before 
> exec_elf32_makecmds.

I haven't thought about this yet.
This could probably be handled by adding a priority field to execsw entries,
and evaluating the entries by priority. I don't think there are too many
needed priorities, two or three should do.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
@@@@  Wanna a real operating system ? Go and get NetBSD, damn!  @@@@