On Wednesday 20 April 2005 12:06, Rob Landley wrote:
> http://www.landley.net/code/firmware/notes.html
>
> It's a ~80 meg tarball (half of which is the gcc, binutils, and
> linux-2.6.11 source tarballs) on a friend's machine, so don't hit the poor
> server too hard. I intend to move it to a faster connection after I get
> back from Penguicon...
>
> Yeah, I know the versions of most things are out of date, but the build
> worked when I ran it, and as a proof of concept it shows you what I did.
>
> By the way, I've toyed with the idea of running this sucker in an otherwise
> empty chroot environment (/proc/self/fd is likely to exist and have fairly
> uninteresting contents. As a chroot environment, it just has symlinks that
> point to nothing), but to chroot the UML kernel process from inside the
> initramfs, I need to come up with a new syscall.
Ok, I now understand... chrooting it on the host!
> Can't do it before
> running the UML kernel because A) it needs to make its memory file, 2) it
> needs to access /proc/self/exe, III) it needs to loopback mount its
> executable file to pull the trick I just did.
Not sure about this... you'll need to be root anyway to chroot, so you can
also (bind)mount what you need inside the chroot and unmount it later. You
still need to ask UML to do this, yes, but it's different (also you could
even provide a simple module to load to do this, if the other ideas are
rejected at any level).
> Does a new "chroot UML" syscall sound like a worthwhile idea?
A "chroot UML" thing would not be bad, but doing it as a syscall is not very
Ok for me*... Better, do it with a /proc entry. Not exactly
like /proc/sysemu, however - that was (initially) for testing only and it
pollutes the namespace. However, I don't know a better place where to put it
(no sysfs please, we don't want to learn kobjects for this :-) ).
Also, you can't read the value ("echo a > /proc/chroot; echo a > /proc/chroot"
will be equivalent to "echo a/a > /proc/chroot", since you can't chroot
*outside*; if you want that "echo a > /proc/chroot; echo > /proc/chroot" does
not mean "chroot inside and then go back outside", that's the only possible
interpretation).
A sysctl is not ok because it's supposed that the value it's "saved" in the
entry, while this is not true.
Also, we already have /proc/umid and /proc/exitcode which act on the outside,
so it would probably be ok.
* A syscall is not ok because the syscall table must match the i386 (and
whatever arch) one; we can't add "local" entries as we may need to move their
number to give place for new i386 syscalls. And asking all other archs to
reserve a slot for a syscall on which at least somebody will seriously object
won't work.
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
