[Haiku-commits] r27685 - haiku/trunk/src/system/boot/loader

[Ingo Weinhold]

On 2008-09-22 at 14:56:41 [+0200], Axel Dörfler <axeld at pinc-software.de> 
wrote:
> Ingo Weinhold <ingo_weinhold at gmx.de> wrote:
> > On 2008-09-22 at 10:58:08 [+0200], axeld at BerliOS <
> > axeld at mail.berlios.de>
> > wrote:
> > > Log:
> > > * The boot loader now replaces the first path component of all path
> > > names
> > >   passed to the kernel with "boot" instead of the volume name; the
> > > kernel
> > >   mounts the boot volume always as "/boot".
> > > * This should fix #2757.
> > As of r27688 the full paths aren't needed anymore by the debugging
> > support,
> > so I consider reverting all recent boot loader changes. Opinions?
> 
> Enlarging the heap definitely wasn't a bad idea, though ;-)
> I'm a bit torn on this one:
> + the module code needs correct image paths for maintaining the
> sModuleImagesHash correctly; the problem obviously happens while
> collecting new modules (when iterating over the file system via the
> module list functions). While building the path completely manually
> seems to work now, it's not really future proof if we ever want to
> support boot kernel modules in /boot/common/.

I haven't found a serious problem in the module code with respect to 
differing image paths. In fact I even think it has advantages when the 
preloaded images have different paths. The only thing that is a problem is 
module::file. It only seems to be an optimization for get_module(), but it 
will screw dealing with live changes when multiple module directories are 
involved (i.e. "/boot/common") or actually already with a single directory, 
when the module is moved along its path name (e.g. when moving module 
"foo/bar/v1" living in file "foo" to file "foo/bar").

With the VFS entry cache it is probably not that expensive anymore to 
actually search for the module files in the module directories in 
get_module() (though simply resetting the module's image there as done now 
is a no-go). Alternatively a kind of module file name cache could be 
maintained, which would be kept in sync via node monitoring.

Anyway, I would revert the path stuff in the boot loader. If the pre-loaded 
images have been loaded from the boot volume, 
module_init_post_boot_device() should adjust their module image names 
accordingly. When booting via network or floppy, the pre-loaded images are 
not the same ones as on the boot volume, so they should not get the same 
name. When getting rid of module::file, this should be no problem at all.

> + I actually liked loading the symbols in userland better than having a
> dedicated syscall for this. Especially because loading the kernel
> symbols will be turned off by kernel setting (and this might even get
> the default if we're stable one day :-)).

The syscall is inevitable for network/floppy boot, since the original files 
won't be available anymore. Even if the symbol table hasn't been loaded, 
the kernel does at least know the dynamic symbol table. I would simply 
change the procedure in the SymbolLookup code to first try loading the 
symbols from the image file (if there is an actual path) and fall back to 
the syscall.

> - it needs more memory.
>
> The first item could be relieved a bit by giving precendence for
> existing module names - right now, there is no code to handle
> duplicates, as those cannot happen when the add-ons are in the same
> namespace.

I suppose you're referring to several images containing modules with the 
same name. This is not really hard to handle: module::file must go and 
get_module() on a referenced module must not reset its image. Then 
everything should work fine already.

CU, Ingo