Hi, I finished playing around a bit with Ian's rumpxen/app-tools and, to pick some arbitrary application, thttpd. I could download thttpd, configure and make it with app-tools and run the resulting binary as a Xen guest. No source editing or ad-hoc build stunts were required. That's a truly awesome result!
Here are some thoughts on what probably should happen next. They're more in a braindump format than an actual proposal; I probably don't have time to work on this stuff at least this week. Others probably have something similar on their in-core (in-brain) roadmaps, so this mail also invites discussion. What currently isn't addressed is that applications like thttpd need some base configuration, like a network configuration and maybe the mounting of file system images. I hacked these configuration steps into callmain.c. However, the configuration problem shouldn't be very difficult to address properly. Currently, the "extra" parameter of the domain_config takes the command line arguments, e.g. for thttpd: extra = "-u thereisnoroot -D -d /etc" (/etc is the only directory that contains some files ... I was lazy ;) I'm thinking that instead we'd want it to contain some sort of an attempt at an rc script. If we do specification-by-example, the following could work for thttpd (starts two instances of thttpd for demonstration purposes): extra = "builtin_ifconfig xenif0 create builtin_ifconfig xenif0 <address> builtin_mkdir /etc builtin_mount ffs /blk1 /etc builtin_mkdir /anotherdir buildin_mount ffs /blk2 /anotherdir thttpd -u thereisnoroot -D -d /etc & thttpd -u thereisnoroot -D -p 8080 -d /anotherdir" Making the above work requires doing a few things: 1) support for some crunchgen/busybox-like build for bundling many binaries into the guest image 2) deciding if we want very simple "builtin" versions of some common configuration utilities, or if we'll always include the full NetBSD binaries 3) deciding if we want applications themselves to handle backgrounding e.g. via daemon(), or limit backgrounding to rc scripts using &, and dealing with whatever problems arise as a result 4) writing a few lines of code to parse said rc scripts, create rump kernel processes and call utility entry points. also, disband rump kernels processes when utilities exit to e.g. close file descriptors (note: since memory allocation does not go via the rump kernel, maybe add similar autofree support to malloc and friends) 5) dealing with things that could arise from lack of vm space per process, e.g. getopt() in libc uses globals If we go the "builtin" route for config utils, we don't immediately have to support a busybox-style build, the simple config utils can just be hardcoded into every image. Of course, this whole mail isn't really specific to Xen, and I'd eventually like to see things work the same way on all platforms. But we need at least one working platform as the first step ;) - antti ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
