On 22/01/15 16:20, Martin Lucina wrote: >> Notably, though, the environment will be global for all rump kernel >> processes running in the same domain (i.e. rump_pub_lwproc_rfork() will >> not change it). Now, the issue is: should the environment setting usage >> have something which will later allow us to fix get/setenv() to be >> process-wide and specify the env for certain processes. something like >> -e 'mysql::env=value' -e 'php::anotherenv=value' (for example). > > There's no reason we couldn't do that. However, I still don't fully > understand the use case for running multiple processes atop a Rump Kernel > on Xen/KVM. There would be no isolation between them, so either process > could stomp over all other processes, so your example of mysql and php > seems particularly dangerous.
Let's not get hung on the php/mysql example. If putting two processes in the same guest is a bad idea per the use case, you of course wouldn't do it. php and mysql just happened to be the first two names that came to my mind ;) > Are you thinking of porting applications which rely on multiple processes > by design, such as Postfix? I can see that it would make sense there. I'm thinking of every scenario where it's necessary/useful. For example, if we want to configure a cryptographic disk into a guest, we'd need cgdconfig in there, and so forth. (ok, maybe I should have said that we want RAID, because currently I don't know how we'd protect an application vulnerability from leaking out the encryption key. leaking the raid config should be less critical ;) >> Hmm, was it so that rumprun-posix seeds the guest env with the host env >> and that there was some reason for it? Would be nice to have it work >> the same way as on xen with rumprun (and hopefully on baremetal with >> rumprun as well). > > You mean passing the full host environment as seen by rumprun to the > xen/KVM guest? > > I agree that it would be good to have a common mechanism. However I don't > know (haven't looked yet though) if eg. KVM has some equivalent of Xenstore > to communicate between the host and guests. Also, for pure bare > metal/embedded use cases the interface would likely be the bootloader or > other ad-hoc mechanism. No, not mechanism, semantics. I think it would be cool to be able to sport the same configuration for -posix, -xen and -baremetal and have things work in sort of a similar way. Yes, for some embedded IoT-like scenario rumprun would most likely produce an image you can flash or whatever, and which has the parameters baked into e.g. the bootloader as you suggest. I still think that we really should shoot for the "develop with rumprun-posix, then deploy as you like" model. Unfortunately, -posix is quite complicated and different. ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
