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. 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. > 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). 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. Alex
