On 27 Oct 2022 11:40, Tsukasa OI wrote:
> On 2022/10/23 23:56, Mike Frysinger wrote:
> > On 20 Oct 2022 09:32, Tsukasa OI wrote:
> >> 2.  syslog function must be called as a syscall rather than POSIX syslog
> >>     because we are emulating Linux system calls on the Linux host.
> > 
> > i don't think that is accurate.  if that were true, every other call in here
> > would be using syscall() instead of calling the C library functions.
> 
> Note that this part is a Linux to Linux syscall translator (though I
> consider this whole idea unsafe).  Yes, it uses many C library functions
> but I consider this is because they are (almost/completely) compatible
> with underlying syscalls.

this is incorrect.  let's take a step back.  the point of the sim runtime
environments is to emulate the specified userland regardless of the host
OS.  it is not a linux-to-linux translator.  the runtime decodes syscalls,
then attempts to emulate the requested behavior.  ideally that would only
ever involve going through the standard C library APIs.

the m32r linux runtime environment layer has a bunch of linuxisms in there
(because it can be hard to emulate linux behavior on non-linux systems).
but that doesn't mean it's a linux-to-linux layer, and we shouldn't be
making it worse.

> However, this isn't the case for syslog.  POSIX syslog (C library
> function on <syslog.h>) and Linux syslog (syscall) have very different
> semantics and Linux syslog should be used here.

you are correct here.

the arch backends for diff runtime environments are inconsistent whether
they pass through to the real host env, or they provide stub/fake data so
the program doesn't get real access to the host (basically constructing a
sandbox).  i see the value in both modes (especially since a sandbox is
easier to run cross-OS), but haven't fleshed out how to support these.

> Probably using glibc wrapper klogctl (<sys/klog.h>) might be a solution
> (see man page syslog.2).  I would like to hear your thoughts.

klogctl would be OK
-mike