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