[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] some thoughts on appstacks and app-tools
On 15/07/14 15:26, Ian Jackson wrote: 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):I think that it would be better to deal with this by providing the script in the base fs image. That's a more suitable format for conveying something extended like one of these scripts. It also preserves the distinction between "out of band" environmental information like the filesystem etc., and the executable and its command line arguments. A rump kernel does not use a base fs image, at least unless I misunderstood what you meant by base fs image. For some applications it might be convenient to supply some sort of fs image, e.g. the libc calls that thttpd makes requires /etc/services, /etc/master.passwd and so forth. However, let's imagine a router/firewall. There is no true need to have any file system support in a rump kernel in that configuration (as in open() will return ENOSYS). Yet, the router needs to be configured somehow. That's why I'd rather supply the configuration information out-of-band. If I correctly understood what you mean by the xenstore stuff later, you are saying that the steps could be embedded, while the data needed by those steps could come dynamically from xenstore. Looking at it this way also enables us to do away with several of these steps:extra = "builtin_ifconfig xenif0 create builtin_ifconfig xenif0 <address>I think this information is already available via xenstore. Ok, but we still need to execute the actual configuration commands somehow. builtin_mkdir /etcThere is no need for the script to be able to mkdir. Why? Where will the mountpoint come from? builtin_mount ffs /blk1 /etcWe could perhaps provide a mount point in xenstore along with the rest of the pv block device control plane info. I have no idea what that means.Can you elaborate on how that will solve the practical problem of "thttpd needs some files in /etc"? thttpd -u thereisnoroot -D -d /etc & thttpd -u thereisnoroot -D -p 8080 -d /anotherdir"This notion of having multiple processes is quite alarming. There obviously won't be any memory protection between them, but also: how will their symbol namespaces be separated ? Is it intended that they would be able to communicate via some kind of IPC (eg pipes or AF_UNIX sockets) ? Symbol separation is what I referred to with crunchgen/busybox. I don't know about busybox, but at least crunchen does symbol renaming/hiding. Without going into a lot of detail, a rump kernel has an internal notion of a "process", sans a virtual memory space. I think the original use case was debugging the AF_UNIX file descriptor passing code (though there are other uses now). Multiple "processes" can communicate e.g. with pipes just like on a regular system. It's alarming only if you don't know what you're doing. Obviously if you want to lump a ton of processes into a single guest, you should be running a full OS. However, there might be cases where being able to run a few just makes things a lot easier to set up. It's of course a different story if we should support it before having any actual use cases ... 2) deciding if we want very simple "builtin" versions of some common configuration utilities, or if we'll always include the full NetBSD binariesPerhaps we can keep the set utilities small enough that we don't need to replicate busybox. ... yes, that's one option. 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 resultClearly applications can't background themselves (whatever that means) because they can't call fork(). My definition of backgrounding here = "rc script" doesn't wait for the current process to finish before running the next one. That works quite easily, we just create a thread before we call the application main and either join that thread or not. It might be possible to reach the same effect by "guessing" what fork() means for an application, but then again it might be better to not guess. Of course I appreciate that some of the xenstore-based answers I give above are perhaps less useful to other platforms, but perhaps they have something equivalent ? They don't exist, so I don't know yet ;)What I do know is that I'd like things to be general enough so that whatever infra you build on top of this doesn't have to be changed in 3 weeks (or forked) when we discover a platform where there is no equivalent. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |