On 11/03/15 10:02, Martin Lucina wrote:
In the second instance, I will need to tackle rumprun-xen issue #15
(implement support for "xl shutdown"), however that is a separate
discussion. All I know right now is that I'm going to have to implement
some kind of SIGTERM emulation.

Right, but signals is something that should be attacked critically, not just bend over and emulating the existing concept. This whole work is pointless if the end result is what is known as an OS ;)

First, _lwp_foo() should probably not be used outside of places
where they are necessary.  It's more of an internal interface, and
let's keep uses of it to a minimum.  That said, I can appreciate
that we don't have an official way to suspend the execution of a
thread indefinitely. Maybe it warrants an issue report?  Something
like "if (timeout) nanosleep else for (;;) sleep(100)" might be a
better stepping stone, but no strong feelings about that.

The _lwp_foo() interfaces are common to all platforms (baremetal, xen and
posix), right? They are internal to the NetBSD libc, so at the same layer
conceptually as the calling code I'm implementing?

Can you elaborate on why you want to minimise their use by callers at the
same layer?

You make the mistake of assuming that we control when/how NetBSD revisions their internal interfaces and that we only support running against one specific version of NetBSD. They won't change the API (*) of nanosleep(), but they might change the API of _lwp_park() (and they have).

*) very specifically: API, not ABI

It's usually better to play these scenarios out in your head (or on paper) and think what happens if x changes or y changes or both change or neither change.

Second, in general, should call the normal interface (_lwp_park) and
not a versioned interface (___lwp_park60) unless there's a strong
reason to do the latter.

Will do. OOI, is there a document somewhere that describes how the
interface versioning works?

Not to my knowledge, but see here. __RENAME() in the headers is use to control what symbol referencing "x" actually refers to. When the ABI (*) for "x" changes, a new symbol is introduced, usually "__xVER" and the __RENAME() bit adjusted.

*) which may or may not mean an API change

Reply via email to