Date: Fri, 28 May 2010 16:28:05 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-stable@freebsd.org, Clifton Royston <cliftonr@lava.net> Subject: Re: Locking a file backed mdconfig into memory Message-ID: <20100528232805.GA88333@icarus.home.lan> In-Reply-To: <4C0044F0.5060807@icyb.net.ua> References: <201005272348.o4RNmgWh014243@hugeraid.jetcafe.org> <20100528043006.GA18560@lava.net> <201005281757.o4SHvTwq020905@hugeraid.jetcafe.org> <20100528191828.GA83371@icarus.home.lan> <201005281926.o4SJQCW3041849@hugeraid.jetcafe.org> <20100528215837.GA86689@icarus.home.lan> <4C0044F0.5060807@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 trying. :-) 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 respectively. 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@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100528232805.GA88333>