Re: Path to kmods

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, Nov 12, 2008 at 11:37:42PM +0100, Hubert Feyrer wrote:
> >but there is a senario where this doesn't work: if the kernel is loaded
> >from a path which is not accessible from the kernel itself (this is not
> >so uncommon, I think several of our port don't have a bootloader at
> >this time), then the kernel doesn't have an accessible path (or eventually 
> >no
> >path at all, depending on how the kernel is loaded) from where to find
> >the modules.
> >
> >Maybe is this case a sysctl'able path would do the trick ...
> 
> I guess you're thinking about Xen, where a DomU kernel gets loaded from 
> Dom0,

or PXE boot, or an embeeded system where the kernel is in a flash readable
only by firmware.

> and where that kernel then needs to get its modules from. The 
> situation there is about the same: you need to place the modules 
> somewhere, and /netbsd/modules/* could still be used - the usual Xen dance 
> on how to get the kernel from Dom0 in the first place is the real problem, 
> but that's not the question here - I guess passing this as kernel 
> parameter could be done. Or try to fiddle it from the booted kernel name, 
> somehow, e.g. use /`sysctl machdep.booted_kernel`/modules/*.

machdep.booted_kernel is machine-dependant (as its name suggest) and
is not available everywhere. Does multiboot make this information available
for kernel ? For the kernel loaded as a module, as in the xen dom0 case ?

> 
> Out of curiosity, what is the machdep.booted_kernel sysctl set to on a Xen 
> Dom0 system? (Assuming that's the scenario you have in mind)

it's not present at all.

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--