From: Rob L. <ro...@la...> - 2005-11-10 03:55:39
|
On Wednesday 09 November 2005 22:07, Jeff Dike wrote: > On Tue, Nov 08, 2005 at 06:35:47PM -0600, Rob Landley wrote: > > Jeff was going to split out the scheduler and filesystem into shared > > libraries or some such. He mentions it in his intermittent diary, among > > other places. > > This has nothing to do with that. Ok. > One of my other future projects is embedding UML into other things, as in > a library, to give those other processes access to functionality like > clustering. You've mentioned this before. I've never quite been able to visualize what it is you want to do. (Embed UML to give processes access to functionality like clustering... Nope, I still don't get it. Can you give a more concrete example?) > In this case, you may not want UML booting to userspace - you > just want the kernel initialized enough that you can call into it. My normal use case for UML involves an init that's either a command shell or a shell script, so I'm used to there often only being one process on the system. (I even made a dumb little "oneit.c", attached, that runs one process and then shuts down when that process exits, and sets up everything so ctrl-c works in that process.) I.E. ./linux rootfstype=hostfs rw init=/path/to/oneit /bin/sh And then once you've got your command shell in UML, you can insmod a module that calls or prints out whatever you need, while the init process can block indefinitely and there are no other tasks running. So I've never had too much trouble accessing the sucker's internals when I wanted to do so, in an otherwise quiescent system. (Usually I just stick printfs into the sucker, though. It's just so easy...) Rob |