[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Path to kmods
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
> >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
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.
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |