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