Re: Testing Emulation Syscalls

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Tue, Aug 01, 2023 at 08:16:50 +0200, Martin Husemann wrote:

> On Mon, Jul 31, 2023 at 05:03:48PM -0400, Theodore Preduta wrote:
> > One idea (mentioned in the original thread) would be to introduce a
> > syscall along the lines of
> > 
> > 	int emul_syscall(const char *emul_name, int number, ...)
> > 
> > which executes a single syscall.  The flaw with this idea is that state
> > may need to be stored across syscalls in struct linux_emuldata, but I
> > don't know how this interface could accommodate this.
> > 
> > Another idea would be to introduce a syscall along the lines of
> > 
> > 	int setemul(const char *emul_name)
> > 
> > which would switch the syscall table dynamically so that the test case
> > could be run under emulation (preserving emuldata state) and then switch
> > back to report the result.  (And then individual syscalls would be
> > called via __syscall(2).)
> 
> I think this would be quite tricky for the test code in userland.
> 
> But what about a variant of the initial suggestion:
> 
> // returns an integer descriptor
> int open_emul(const char *emulname);
> 
> // invokes a syscall under an open emulation
> int emul_syscall(int emul, int number, ...);
> 
> // frees all state for the emulation, returns 0 or -1
> int close_emul(int emul);
> 
> IMO this still is far better than exposing native syscalls that we do
> not really need/want.

I'd rather we don't expose epoll(2) as a native syscall at least not
just yet, given what pkgsrc folks are telling us.  It's not like we
have pressing need to use it in our own code in base.  And for third
party software it creates confusion as was pointed out.

As for testing emulated syscalls - can we solve this problem with a
bit of elf branding to convince the kernel to start the binary under
emulation directly?  Inventing a whole new backdoor API for that seems
kinda an overkill.

-uwe