Thor Lancelot Simon wrote:
> Another option might be, by default at least, to do something like we
> do for ptys: allocate pids for native processes from the > 16-bit part
> of the space first, saving pids for iBCS2 binaries in the low part of
> the space.  If we believe that iBCS2 binaries are unlikely to need to
> refer to native processes by pid (possible, though handling getppid()
> might be a bit iffy) this might work.

I was thinking along this (some iBCS2-specific PID space), too.
I can see one problem with this particular proposal, tho.  PID is
allocated at fork() time. If you execute iBCS2 from native shell,
iBCS2 process could _still_ end up with 'high' PID.

Obviously, something completely iBCS2-specific (without any hooks
in generic code), would be less fragile and preferable.

I thought about completely iBCS2-specific PID space 'view' a bit.

According to my quick scan through sys/compat/ibcs2, it seems that:

1. iBCS2 process uses PIDs in IBCS2_F_GETLK, IBCS2_F_SETLK fcntl,
   kill(2), IBCS2_TIOCSPGRP ioctl, IPC syscalls, waitsys(2),
   pgrpsys(2)
2. iBCS2 process gets knowledge of PIDs via fork() return value[1],
   getpid() (both pid and ppid), pgrp/pgid via iBCS-specific system call.
   no other way (we don't support iBCS2 kernel kmem growellers AFAIK)

Since we have tight control of what PID space do iBCS2 processes
see, it would be very easy to make a hash with mapping of 'native',
actual NetBSD PIDs into iBCS PID range up to SHRT_MAX, and translate
for any relevant iBCS2 syscall. iBCS2 processes won't be allowed
to fork if there would be SHRT_MAX iBCS2 processes already, so the
PID space 'view' wouldn't overflow SHRT_MAX range.

Each mapping entry would be added when iBCS2 process would fork or
exec, removed on exit(2).  iBCS2 processes would only be able to
use PIDs of iBCS2 processes; kill(2) for a PID number without
mapping in the hash would return ESRCH.[2] Similarily F_SETLK fcntl.
There is slight problem with F_GETLK since the holder of the the
lock might be non-iBCS2 process; in that case, I think it's safe
to fill the ibcs2_flock structure with any iBCS2 pid not allocated
for any iBCS2 process (and it need not be consistent between calls).
Similar as for GETLK is true for IPC syscalls.

I hope I described what I mean well ;)

Does this sound as if it could work? Can anyone see any
obvious gotchas?

Jaromir

 [1] child process returns specially via child_return(), but
     fork() returns 0 for child and we can control parent fork()
     return value by supplanting a iBCS2-specific fork syscall
     instead of using sys_fork() directly. So, no changes
     to generic code are required to hook anything iBCS2-specific there.

 [2] Including, but not limited to potential 'native' (NetBSD) parent, whose
     PID iBCS2 process can get via getppid(2).
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-