>>>>> "Mike" == Mike Long <mike.long@analog.com> writes:

>> I really hate to see such static behaviour, the old maxpartitions
>> problem springs to mind.  Perhaps it would be possible to have a
>> sysctl (or maybe there already is) to report what syscalls,
>> emulations, filesystems, cdevs, bdevs, etc are enabled in a given
>> kernel.  Anybody wanting me to look into it?

Mike> That seems like far more work than is really necessary.

Perhaps, but after done a fast implementation for only the "netbsd"
emulation, I'd say it's not much work.  However I've learned something
about the design of emulations in the kernel which I don't like.

There is no central place where pointers to all enabled "struct emul"s
reside.  However there is the execsw, which is close enough, *but*, as
implemented today, cannot be used for this purpose.  In order to let
kdump know about LKM exec packages (which would be necessary the day
someone really writes such a beast, as ktracing is quite some tool for
hunting down emulation bugs) we need a way to get at the "struct
emul"s.

A simple way to go on about this is to add a register function
pointer to the execsw, but then we lose backward compatibility with
LKMs (does any such really exist yet?).  This functions would
maintain (register/deregister) an emulation pool which could be looked
at by kdump through a sysctl.

Another way would be to assume an exec package will only contain *one*
emulation.  If so the makecmds function called with a NULL proc
pointer could return a dummy exec_package with the ep_emul field set.
This would be uglier but retain backward compatibility.

A third way would be to separate emulations from exec packages and to
provide an emulsw, but that seems like overkill to me.

Maybe this is an issue not at all important as of today, but does it
hurt to solve the problem before someone hits it?  Actually, I've
started to write on a new emulation for the m68k (mostly just to widen
my experience) and I would much like this to be able to compile as an
LKM and still use ktrace/kdump and get correct syscall names.  I don't
call for others to implement this, I just want to discuss the issues,
I can well implement it myself, if something gets decided.  Maybe I'll
do it anyway, but it's nice to not waste time implementing the wrong
idea, of course :-)

Niklas

Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG	WWW:   Here
Sweden