Locking a file backed mdconfig into memory
freebsd at jdc.parodius.com
Fri May 28 23:28:07 UTC 2010
On Sat, May 29, 2010 at 01:34:24AM +0300, Andriy Gapon wrote:
> on 29/05/2010 00:58 Jeremy Chadwick said the following:
> > On Fri, May 28, 2010 at 12:26:12PM -0700, Dave Hayes wrote:
> >> Jeremy Chadwick <freebsd at jdc.parodius.com> writes:
> >>> And I think you meant this for variable names, in addition to what
> >>> vfs.root.mountfrom should be (specific to RELENG_8):
> >>> mfsroot_load="YES"
> >>> mfsroot_type="mfs_root"
> >>> mfsroot_name="/some/path/mfsroot"
> >> I'm using RELENG_7, but it seems rootfs_* works just like mfsroot_* ...
> >> is the former deprecated?
> > I spent a small bit of time looking through both RELENG_7 and RELENG_8
> > source (/usr/src) as well as /boot (for the Forth portion) and I was
> > unable to find any reference to "rootfs" aside from actual variable
> > names (not loader variables) in C code or include files. None were
> > strings. There's a strong possibility I'm not looking the right way
> > (grep -ri ...).
> > I can assure you that mfsroot_xxx works on both platforms because I
> > wrote the below documentation:
> Guys, you could have used "donotboot_" prefix there and it would still work :-)
> _type, _name and _load suffixes are what is important in this particular case.
> See description of these suffixes in loader.conf(5).
Andriy, I'm still having a bit of trouble understanding how all of this
works. No, not the loader part -- thanks for pointing that out, yeah, I
get that piece (mostly).
This is all I've managed to figure out, and it's probably wrong, but I'm
It appears the key piece is the xxx_type="mfs_root" declaration; the
string passed there (the value "mfs_root") is important. One could also
use "md_image". I'm basing that statement off of code in
src/sys/dev/md/md.c which appears to look for + permit either string.
However, what I'm having trouble understanding is what exactly
preload_search_info() looks for and how all this actually connects
and works. It appears to me that there are specific drivers located in
src/sys/dev that are KLD-supported and others which are expected to be
included in the kernel statically.
The ones which appear to be required static are md, loop, ether, and
pty; they have no *_MODULE macros in use. random and firmware, however,
are built as KLDs and do call DEV_MODULE() and DECLARE_MODULE() macros
All that said, I'm still not sure xxx_type="mfs_root" "tickles" the use
of the md code. I thought maybe the "metadata" was just a symbol lookup
(and maybe it is), but objdump on /boot/kernel/kernel and
/boot/kernel/kernel.symbols doesn't return anything. strings on
/boot/kernel/kernel does return "mfs_root", but I'm almost certain
that's because of the strncmp() in src/sys/dev/md/md.c.
Actually, as I dig through it more, it looks like the md stuff is loaded
by GEOM? I see DECLARE_GEOM_CLASS() in use which refers to g_md_class
that provides a series of addresses to initialisation and startup
routines, amongst other stuff.
...except there's /boot/kernel/geom_md.ko, so now I'm even more
confused. Aaugh! :-)
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-stable