[this is a prototype, needs review and feedback before committing] FreeBSD formerly used a scheme of preallocating a fixed size region of memory for an embedded MFS filesystem image which was subsequently patched after kernel build with a utility program (write_mfs_in_kernel). This scheme is no longer used by sysinstall since md(4) and /boot/loader provides the ability to load an md(4) filesystem like a module. Some applications such as picoBSD and etherboot still need a linked-in filesystem. This patch allows one to specify an object file created with mdconfig(8) and objcopy(1) to be linked into the kernel image. This has the added benefit of allowing a flexible size for the filesystem. The patch deprecates 'options MD_ROOT_SIZE' replacing it with 'makeoptions MD_ROOT_IMAGE="mdimage.o"' where mdimage.o is a file created something like this: dd if=/dev/zero of=mdimage -bs=1024 count=4096 mdconfig -a -t vnode -f mdimage -s 4096k -u 4 disklabel -r -w md4 auto newfs /dev/md4c mount /dev/md4c /mnt . . put stuff on it . umount /mnt mdconfig -d -u 4 objcopy -I binary -O elf32-i386 -B i386 \ --redefine-symbol _binary_mdimage_start=md_root_image \ --redefine-symbol _binary_mdimage_size=md_root_image_size \ mdimage /tmp/mdimage.o Add the image to the kernel config: makeoption MD_ROOT_IMAGE="/tmp/mdimage.o" # needs option MD_ROOT Configure and build a kernel as usual; the contents of mdimage.o will provide the linked-in md(4) root file system. How-To-Repeat: Apply the patch :-)
In message <200206292331.g5TNVRRu000860@gehicks.dyndns.org>, W Gerald Hicks wri tes: > Some applications such as picoBSD and etherboot still need a > linked-in filesystem. This patch allows one to specify an object > file created with mdconfig(8) and objcopy(1) to be linked into the > kernel image. This has the added benefit of allowing a flexible > size for the filesystem. Looks useful. > The patch deprecates 'options MD_ROOT_SIZE' replacing it with > 'makeoptions MD_ROOT_IMAGE="mdimage.o"' where mdimage.o > is a file created something like this: The patch seems to remove rather than deprecate the MD_ROOT_SIZE code. Is there a good reason not just leave it there and add the new option? The new approach requires that you have the image available at the time that the kernel is compiled, so for some applications it is less flexible (for example, we use built-in root filesystems in a lot of diskless terminals, and it is useful that updating the root filesystem does not require re-linking the kernel). It would also be preferable if the makefile could do the objcopy step, so you can specify the actual image file in MD_ROOT_IMAGE. Ian
Adding to audit trail the text of kern/40026: : : Date: Sun, 30 Jun 2002 02:48:12 +0000 : From: W Gerald Hicks <gehicks@gehicks.dyndns.org> : Sender: gehicks@gehicks.dyndns.org : To: FreeBSD-gnats-submit@FreeBSD.org : Cc: Ian Dowse <iedowse@maths.tcd.ie>, freebsd-small@FreeBSD.org : Subject: pending/40026: [patch] use ld(1) to build kernel with linked-in md(4) filesys : : > The patch seems to remove rather than deprecate the MD_ROOT_SIZE code. : : Oops, wrong choice of words. Yes, it's intended to replace the : MD_ROOT_SIZE feature and any need for a write_mfs_in_kernel program. : : I wasn't clear about what this patch is for right now. I don't want : to ask to have it committed right away. It is one of a few : prerequisite patches I am preparing to do some work on PicoBSD and : needed to post this so others will be able to get the subsequent : patches to build. : : > Is there a good reason not just leave it there and add the new option. : : I suppose I could have set a -DMD_ROOT_IMAGE when : makeoption MD_ROOT_IMAGE= : is specified but otherwise it seems hard to relate 'options' with : 'makeoptions'. : : > The new approach requires that you have the image available at the : > time that the kernel is compiled, so for some applications it is : > less flexible (...) : : Well, not exactly. This patch is only the first piece of a scheme : :-) : : kern/40017 is related to this effort. It allows us to use modified : kernel build metadata (sys/conf) for specialized applications. : Using this facility I am going to provide further patches which : allow incremental linking. : : These changes are pretty far-reaching and I was afraid of taking : them straight to src/sys/conf directly. kern/40017 allows us to use : something like /usr/local/src/picobsd/conf to implement extra build : steps from private specialized versions of the kern.pre.mk and : kern.post.mk files. : : The picobsd/conf example will implement another couple of : makeoptions: : : makeoptions RLINK_KERNEL="/mykernels/kernel-foo-v1.rel" : makeoptions RLINK_KERNEL_OBJS="/tmp/foo.o" : : There are two new kernel build targets used for these options: : : make prelim # build a partially linked-kernel : make final # produce a bootable kernel : : This has all been tested successfully in a src/conf patch. : I hesitated submitting them there in favor of an "outboard" approach : using kern/40017 : : I'd really rather avoid bringing the objcopy step into the kernel : build process. : : Being able to build a kernel with a two-step process allows us to : trivially wrap everything into a little shell script or other : makefile fragment. The 'make final' step can be run as often as one : requires while changing filesystem images.
State Changed From-To: open->suspended Mark as 'suspended' since no one seems to have done any work on this new-feature idea in some time.
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"
Something like this was committed in r286727. See also https://reviews.freebsd.org/D2903