[Haiku-commits] r27685 - haiku/trunk/src/system/boot/loader
ingo_weinhold at gmx.de
Tue Sep 23 00:55:54 CEST 2008
On 2008-09-22 at 14:56:41 [+0200], Axel Dörfler <axeld at pinc-software.de>
> 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
> - 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
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.
More information about the Haiku-commits