Per a suggestion from CGD I'm investigating another way to solve my
emulation personalities problems.  Instead of having a setpersonality
mechanism at user-level I'm looking at doing a new exec syscall.
This syscall should be much like execve but also should accept a
specified emulation and some per-process data for the emulation code
to use.  This data should be hooked of struct proc and could contain
anything an emulation would want, e.g. my personality flags.  My first
stab at this will use a traditional interface, but I'm also
contemplating an alternative interface which are extensible.  I will
mention more about this later.

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

This syscall will work exactly like execve if "emulation" is NULL (the
extra emulation_data args will then be ignored).  This makes it
possible to scrap execve sometime and make it a libc wrapper of
excvee, if we'd like to.

If emulation is non-NULL a search of the specified emulation will be
made, if it fails the syscall will fail.  When the emulation is found,
the binary is checked to see if it looks like a binary executable by
the specific emulation.  If not, the syscall will fail, i.e. the
traditional automatic emulationprobing is *not* used in this case.

If "emulation_data" is non-NULL and "emulation_datalen" is positive,
the emulation data area will be copied in to a per-process buffer and
hooked on struct proc via a void *p_emuldata pointer.  Of course this
buffer will be deallocated at process termination.  The size of the
emulation_data area will be limited by some fixed limit.  What happens
to this p_emuldata field at fork?  The buffer will be cloned.  Not
that I know why this would be useful, sharing could well suffice for
the intents I have, but cloning is more general and inline with the
fact that this is really a per-process area.  A new exec however, will
deallocate the buffer and reset p_emuldata.  Why?  Because we can
never know what will be execed.  In the case where we exec a binary of
the same emulation it might well be meaningful to retain the info or
even "some" info from the buffer, but I have a hard time to foresee
the need now.  I do think of adding a per-emulation hook function
that might get called at times when we exec binaries of the same type,
and gets to decide how p_emuldata gets treated.  What do you think?
I'd really like to make this design general enough to accomodate at
least the foreseeable wishes.

The alternative interface would take just four arguments but require
a new datastructure inspired by sys/auxv.h in OSF/1.

	struct exec_opt {
		int	eo_type;
		union eo_data {
			long	eo_val;
			void	*eo_ptr;
			void	(*eo_fcn)();
		} eo_un;
	};

	/* Ends the optional argument list */
	#define EO_NULL			0

	/* Like emulation in the traditional-style interface. */
	#define EO_EMULATION		1

	/* Like emulation_data in the traditional-style interface. */
	#define EO_EMULATION_DATA	2

	/* Like emulation_datalen in the traditional-style interface. */
	#define EO_EMULATION_DATALEN	3
			
	int execvee(const char        *path,
		    char *const       argv[],
		    struct exec_opt   *optv[]);

The positive side is that we don't need to change the interface if we
come up with more exec arguments.  Of course we need to fail if
unknown types are seen.  Comments?  I'd say this might actually be
overkill, but maybe someone else can come up with other contrived
examples where this would be good?

I still haven't scrapped the former idea (p_personality), although I
agree with CGD that at first sight this seem more general and safer
compared to that one.  Please comment on both and compare them.  Are
there other ideas?

Maybe this could be a way to deal with, however a bit rough, the SVR4
vs Linux/ELF ambiguity (Hi Dan!).  Just always wrap these binaries
with an execvee to choose the right emulation.  It needs extra work to
setup, but after that it's failsafe.

SPEAK UP!

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)