Re: CVS commit: src/lib/librumpuser

[Antti Kantee <pooka%NetBSD.org@localhost>]

On 17/06/14 09:46, Alexander Nasonov wrote:
> Antti Kantee wrote:
> > To be clear: the objection was to modifying a stable interface
> > without coordination.  The hypercall interface is implemented in
> > multiple places outside of the NetBSD tree, including by 3rd parties.
>
> Stable interface in -current? How are you supposed to make any
> significant changes then?
>
> As I stated in the private email to Antti, we need to support two
> versions: stable for users and current for developers. Otherwise,
> it will block a development of NetBSD if every time you need to
> make a change in NetBSD-current, you have to wait for a rumpuser
> bump for stable users even though many of them are outside of
> NetBSD.
>
> In other words, don't rely on NetBSD-current being 100% stable,
> especially for users outside of NetBSD.
>
> I don't know enough details about rump to be certain but would
> splitting only rumpuser into two versions work? If there were two
> versions of rumpuser I could tweak the makefile to build cpufunc.c
> only if MKSLJIT=yes and it would solve the problem because MKSLJIT
> is "no" by default on arm.

I think that will be overengineering it, but if you want to come up with 
a concrete proposal patch, please.  I'd simply use discussion and not 
rushing commits to avoid issues here.

If you don't have time to wait for discussion or coordination, do 
everything in the privacy of the sljit component.

In either case, there's no need for the "blocking development" drama card.

> Another reason for splitting rumpuser is because some hypercalls can't
> be implemented with POSIX API. I don't think we need to support Linux or
> Solaris in NetBSD tree, especailly if it depends on OS-specific code.

I don't think we need to support Linux or Solaris in the NetBSD tree. 
Similarly, I don't think we need to make changes which _unnecessarily_ 
makes supporting them hard.

> > Think of it like changing the libc ABI: no matter the merits of
> > the change itself (which they too remain to be discussed), it will
> > be objected to.
>
> I got an impression from your private email yesterday that the
> approach is correct (you didn't say that librumpuser code must be
> POSIX while the code I sent to you wasn't as it used NetBSD specific
> sysarch syscall).

For reference, here's what I wrote:

=== snip ===
If the problem is syncing icache, the approach is correct.

However, I'd argue that the problem is dynamically loading code into a 
rump kernel, and with that the interface falls somewhat short.  What if 
someone wants W^X?
=== snip ===

If you understood that as "go ahead", sorry for not being clear, "falls 
short" was the comment that I was trying to ease in.

I'm not saying that librumpuser must be POSIX.  I'm not sure where 
you're getting that from.

What I _am_ saying is that there must be some critical thought going in 
to the interfaces and their implications.  We're several years past the 
"oh I'll just add this because I need it today" stage of discovery.

> And because it was a pure addition of a new function and it didn't break
> NetBSD build, I assumed that it's safe to add it. The only thing I
> didn't do was rumpuser ABI version bump.

It's a pure addition in the same sense as if you made a pure addition to 
NetBSD's Xen hypercall interface and made guests unconditionally use it. 
 It would not break the NetBSD build.  Would you assume that's a safe 
change to make?