Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/lib/librumpuser



Antti Kantee wrote:
> 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.

The code is in the tree already. I don't need anything else for
sljit. The sljit library doesn't support W^X protection. Rumpuser
has a way to create an executable page via rumpuser_anonmap(...
exec=true). I understand it's not perfect but it's not my area to
change memory management in rumpuser.

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

Please teach me how to create a private component.

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

It's not a drama, it's a technical issue.

> ...

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

My problem is "syncing icache", therefore, "the approach is correct".

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

rumpuser(3):

DESCRIPTION
     The rumpuser hypercall interfaces allow a rump kernel to access host
     resources.  A hypervisor implementation must implement the routines
     described in this document to allow a rump kernel to run on the host.
     The implementation included in NetBSD is for POSIX hosts.
                                                  ^^^^^
                                                  ^^^^^

and it indeed broke buildrump.sh builds on Linux because sysarch
stuff isn't available.

There is no way I can make this interface POSIX-compatible because
POSIX doesn't specify icache sync as far as I know.

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

Ok, I'll leave it to you to think about it. All I need now is a private
component for my change.

> ...

> 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?

In my case, I could easily build icache in rumpkern conditionally
with MKSLJIT if librumpuser didn't break on non NetBSD hosts.

Alex


Home | Main Index | Thread Index | Old Index