Subject: Re: Per-process personalities in emulations
To: None <frank@fwi.uva.nl>
From: Niklas Hallqvist <niklas@appli.se>
List: tech-kern
Date: 11/10/1995 14:18:34
>>>>> "Frank" == Frank van der Linden <frank@fwi.uva.nl> writes:

Frank> Quoting Niklas Hallqvist,
Frank> The solution you suggest might be the only workable one, with
Frank> some changes perhaps. The wrapper might be extended to a more
Frank> general purpose program, say emul(1), which would look
Frank> something like:

Frank> 	emul [-e emultype] [-f emulflags] executable args ...

Frank> emultype is the emulation type, i.e. 'svr4', 'sunos', 'linux'
Frank> emulflags are the flags to use, like 'dellsvr4', 'ncrsvr4'

Well, I don't like the generic emul(1) because it encourages doing
wrappers in scripts instead of generating native ones.  This may hurt
performance.  On the other hand there's no real controversy between
the two ways of doing wrappers so it doesn't matter that much.

Frank> The best (least ugly?) way to implement this would be to create
Frank> an exec() call which accept the additional flags, either as 2
Frank> additional parameters, or as a pointer to a structure
Frank> containing the emulation type and flags.

Coincidentally, CGD told me the same, and I agree that I like it a bit
more than my initial proposal.  It definitely makes the SVR4-linux/ELF
controversy a bit more maintainable.  So as you may have seen by now I
started to work in that direction.

Frank> The information needed at load time needs to be decoupled
Frank> from the information needed at runtime.

Agreed strongly.  We also need central repositories of available exec
packages and emulations where we can get at the structures keyed by
the names. I've already needed things like this when doing my ktrace
work.  But it was much simpler there, the following structure sufficed
for me:

struct emulsw {
	char *em_name;
	int  em_maxsyscall;
	char **em_syscallnames;
};

I guess we have to redesign this area and it has to be quite carefully
done.  I will continue this work and keep you all updated.  I invite
everyone who chooses to help out.

After some more thought I guess the execvee(2) call need not only to
specify the exec package but *also* the emulation.

	int execvee(const char  *path,
		    char *const argv[],
		    char *const envp[],
		    const char  *exec_package,
		    caddr_t     exec_package_data,
		    size_t	exec_package_datalen);
		    const char  *emulation,
		    caddr_t     emulation_data,
		    size_t	emulation_datalen);

But this is getting icky, IMO.  Perhaps the optv approach I talked
about in a previous message is better...

Niklas

Niklas Hallqvist       Phone: +46-(0)31-40 75 00  Home: +46-(0)31-41 93 95
Applitron Datasystem   Fax:   +46-(0)31-83 39 50  Home: +46-(0)31-41 93 96
Molndalsvagen 95       Email: niklas@appli.se     GSM:  +46-(0)70-714 10 35
S-412 63  GOTEBORG     WWW:   Here
Sweden		       IRC:   niklas (#NetBSD)    ICB:  niklas (netbsd)