Re: Reinventing the Hurd server bootstrap
Hello, This seems very nice to me. I've always thought that the obscure lines we have to put in grub to be able to boot a hurd system were hurting us: they make it difficult to boot into a hurd system by hand when in boot-hosed mode, making the Hurd look complex, and not really helping with hacking about it. Ideally, we could give gnumach a kernel command line option to automatically add the standard options to the modules (with convention that task0 is bootshell, task1 is bootscript, task2 is / FS). That way we'd have an easy way to boot a hurd system from grub, which I think can only help over time, and make the system look simpler (make the usual case simple). Also, loading ld.so for the exec task looked to me both hackish and indeed has posed problems for booting the installation CD and such. Now, it seems that the .scm scripts could be made even more simple: it'd be good to factorize the usual case, so that it is simple to read and hack on. Samuel
Re: Reinventing the Hurd server bootstrap
Hello,
Justus Winter, le Sat 27 Dec 2014 12:32:21 +0100, a écrit :
> Quoting Richard Braun (2014-12-27 12:20:17)
> > On Fri, Dec 26, 2014 at 06:32:33PM +0100, Justus Winter wrote:
> > > Quoting Richard Braun (2014-12-26 17:10:19)
> > > > What kind of non-elf files ?
> > >
> > > Any file. I created this patch in an attempt to use a dead task
> > > (i.e. a task w/o a thread) as a ramdisk. Now I'm (ab)using this patch
> > > to load the script that my interpreter runs:
> >
> > But how does Mach handle the loading of a non-elf file ?
>
> This isn't ready for inclusion, but for now it's mainly:
>
> @@ -746,9 +756,20 @@ static void user_bootstrap(void)
> exec_info_t boot_exec_info;
> int err;
> char **av;
> + boolean_t executable = TRUE;
>
> /* Load this task up from the executable file in the module. */
> err = exec_load(boot_read, read_exec, info->mod, &boot_exec_info);
> + if (err == EX_NOT_EXECUTABLE)
> +{
> + struct multiboot_module *mod = info->mod;
> + printf("reading %d bytes into map %p\n", mod->mod_end -
> mod->mod_start, current_task()->map);
I'd rather avoid such kind of autodetection: if the payload happens
to be an ELF file, gnumach will do things with it that we didn't
necessarily wanted. Some time ago (5 Sep 2011), while working on the
initrd part for the Debian installer, I thought about introducing a
data-task-create command, which would tell gnumach to just load the file
into a task at vaddr 0, without doing anything else about it. That way,
userland would be able to just kill the task when it does not need the
data any more. AIUI this is the same kind of usage that you'd have,
what do you think?
Samuel
Re: Reinventing the Hurd server bootstrap
Justus Winter, le Fri 30 Jan 2015 10:23:24 +0100, a écrit : > * Boots an unmodified Debian (debootstrap --variant=minbase) from a > readonly filesystem that does not support passive translators > (iso9660fs). Yay! :) > * Starts the Hurd console early on, How will this interact with being able to restart the console with /etc/init.d/hurd-console? Samuel
Re: Reinventing the Hurd server bootstrap
BTW, it may be also useful in the crosshurd case, which has always been quite fragile so far. Samuel
Re: Reinventing the Hurd server bootstrap
On Mon, Feb 02, 2015 at 10:03:16AM +0100, Samuel Thibault wrote: > I'd rather avoid such kind of autodetection: if the payload happens > to be an ELF file, gnumach will do things with it that we didn't > necessarily wanted. Some time ago (5 Sep 2011), while working on the > initrd part for the Debian installer, I thought about introducing a > data-task-create command, which would tell gnumach to just load the file > into a task at vaddr 0, without doing anything else about it. That way, > userland would be able to just kill the task when it does not need the > data any more. AIUI this is the same kind of usage that you'd have, > what do you think? Personally, I like this better. -- Richard Braun
Re: Investigation of the failing build of gnat-4.9 using fakeroot-hurd
On Sat, 2014-12-20 at 15:29 +0100, Svante Signell wrote: > Hi, > > Building gnat-4.9 fails currently with EACCES errors when building some > of the .debs, specifically libgnatvsn4.9-dev, libgnatprj4.9-dev. The > failing commands are dh_movefiles and dh_md5sums, ... > Invoking .../fakeroot-hurd sh -c 'command' results in different code > paths. How to track the code paths properly? It seems to be very > non-deterministic. Maybe not, but I have problems to find out which > functions are expected to be called. > > Here command = 1) direct, 2) using a shell script, 3) with make issuing > the script, 4) using make issuing dh_md5sums command, and 5) finally > debian/rules binary. ... > The fakeroot-hurd script is using the built binaries with printout > code > added, via /usr/bin/env LD_LIBRARY_PATH=... see below: > > exec /my_chroot/DEBs/test_fakeroot-hurd/settrans --chroot \ > /usr/bin/env > LD_LIBRARY_PATH=/my_chroot/DEBs/test_fakeroot-hurd/libs \ > /my_chroot/DEBs/test_fakeroot-hurd/fakeauth \ > /bin/sh -c 'cd "$1" || exit ; shift ; exec "$@"' \ > "$1" "$PWD" "$@" \ > -- / /usr/bin/env > LD_LIBRARY_PATH=/my_chroot/DEBs/test_fakeroot-hurd/libs\ > /my_chroot/DEBs/test_fakeroot-hurd/fakeroot > > The built ext2fs.static is used to mount a directory located in a > file: > settrans -ca ./test_ext2fs ./ext2fs.static test.fs > ... > 5) Case 4 above and > libnetfs/file-set-translator.c:netfs_S_file_set_translator > libnetfs/dir-mkfile.c:netfs_S_dir_mkfile > libnetfs/dir-link.c:netfs_S_dir_link > libdiskfs/dir-lookup:diskfs_S_dir_lookup. Here we get the failures with > EACCES: Permission denied Confusing thing is: Printouts in libnetfs/dir-lookup.c:netfs_S_dir_lookup() are not triggered, but libdiskfs/dir-lookup.c:diskfs_S_dir_lookup are. libnetfs is built into fakeroot itself, but not libdiskfs, which is built into ext2fs.static. libdiskfs functions does not seem to be faked. How to investigate the call tree for a translator, in this case fakeroot?
Re: Reinventing the Hurd server bootstrap
Quoting Samuel Thibault (2015-02-02 10:03:16) > I'd rather avoid such kind of autodetection Yes, I understand. > Some time ago (5 Sep 2011), while working on the initrd part for the > Debian installer, I thought about introducing a data-task-create > command, which would tell gnumach to just load the file into a task > at vaddr 0, without doing anything else about it. That way, userland > would be able to just kill the task when it does not need the data > any more. AIUI this is the same kind of usage that you'd have, what > do you think? Precisely. In fact, I did this for exactly the same reason (use the task store to build a ramdisk). The task store isn't usable in it's current form (i.e. it wants a PID, but when we need the ramdisk the proc server isn't around). Unfortunately I didn't get the task store to work, even with quite some patching. So back to the kernel part. We need to create a task, and then copy the data to it. There is `copyoutmap', but it doesn't actually implement the functionality we need. What the elf loader does is to create a thread inside the task, and to the copying from within that thread. My current patch is simply the least intrusive way of implementing what I needed b/c I wasn't sure how to do this properly. I'll send the patch as follow-up for the sake of completeness. Justus
[PATCH gnumach] XXX
---
kern/bootstrap.c | 36 ++--
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/kern/bootstrap.c b/kern/bootstrap.c
index 4edae7b..9c2eb87 100644
--- a/kern/bootstrap.c
+++ b/kern/bootstrap.c
@@ -35,6 +35,7 @@
#include
#include
+#include
#include
#include
#include
@@ -422,23 +423,19 @@ boot_read(void *handle, vm_offset_t file_ofs, void *buf,
vm_size_t size,
}
static int
-read_exec(void *handle, vm_offset_t file_ofs, vm_size_t file_size,
+read_in(void *handle, vm_offset_t file_ofs, vm_size_t file_size,
vm_offset_t mem_addr, vm_size_t mem_size,
-exec_sectype_t sec_type)
+vm_prot_t mem_prot)
{
struct multiboot_module *mod = handle;
vm_map_t user_map = current_task()->map;
vm_offset_t start_page, end_page;
- vm_prot_t mem_prot = sec_type & EXEC_SECTYPE_PROT_MASK;
int err;
if (mod->mod_start + file_ofs + file_size > mod->mod_end)
return -1;
- if (!(sec_type & EXEC_SECTYPE_ALLOC))
- return 0;
-
assert(mem_size > 0);
assert(mem_size >= file_size);
@@ -470,6 +467,19 @@ read_exec(void *handle, vm_offset_t file_ofs, vm_size_t
file_size,
return 0;
}
+static int
+read_exec(void *handle, vm_offset_t file_ofs, vm_size_t file_size,
+vm_offset_t mem_addr, vm_size_t mem_size,
+exec_sectype_t sec_type)
+{
+ if (!(sec_type & EXEC_SECTYPE_ALLOC))
+ return 0;
+
+ return read_in (handle, file_ofs, file_size,
+ mem_addr, mem_size,
+ sec_type & EXEC_SECTYPE_PROT_MASK);
+}
+
static void copy_bootstrap(void *e, exec_info_t *boot_exec_info)
{
//register vm_map_t user_map = current_task()->map;
@@ -746,9 +756,20 @@ static void user_bootstrap(void)
exec_info_t boot_exec_info;
int err;
char **av;
+ boolean_t executable = TRUE;
/* Load this task up from the executable file in the module. */
err = exec_load(boot_read, read_exec, info->mod, &boot_exec_info);
+ if (err == EX_NOT_EXECUTABLE)
+{
+ struct multiboot_module *mod = info->mod;
+ printf("reading %d bytes into map %p\n", mod->mod_end - mod->mod_start,
current_task()->map);
+ err = read_in (mod,
+0, mod->mod_end - mod->mod_start,
+0, mod->mod_end - mod->mod_start,
+VM_PROT_READ);
+ executable = FALSE;
+}
if (err)
panic ("Cannot load user executable module (error code %d): %s",
err, info->argv[0]);
@@ -770,6 +791,9 @@ static void user_bootstrap(void)
info->done = 1;
thread_wakeup ((event_t) info);
+ if (! executable)
+thread_terminate (current_thread ());
+
/*
* Exit to user thread.
*/
--
2.1.4
Re: Reinventing the Hurd server bootstrap
Quoting Samuel Thibault (2015-02-02 10:08:54) > > * Starts the Hurd console early on, > > How will this interact with being able to restart the console with > /etc/init.d/hurd-console? Badly :D. You cannot kill it easily with the init script b/c we cannot write the pid file that early on, and if you start two console frontends the keyboard input will go crazy. Then again, I always felt like starting the console in an init script was a kludge. Justus
