Date: Mon, 17 Sep 2012 16:01:09 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: Importing NetBSD's mtree (and install) Message-ID: <CAJ-Vmo=6wXZGxzJtwpzWO%2B-Q-2Pv-DLxSbvaZmjFYVzOZRDEmw@mail.gmail.com> In-Reply-To: <F952C1AF-BE7A-4422-9997-11B3D41795F7@bsdimp.com> References: <20120917201919.GA43626@lor.one-eyed-alien.net> <F952C1AF-BE7A-4422-9997-11B3D41795F7@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It surely would be nice to be able to compile/run geom modules in userland. Just saying. :) Adrian On 17 September 2012 14:33, Warner Losh <imp@bsdimp.com> wrote: > > On Sep 17, 2012, at 2:19 PM, Brooks Davis wrote: > >> As part of an effort to improve our ability to create full system images >> without root access I would like to import NetBSD's version of mtree. >> By doing so we would gain the -C option which produces mtree files >> compatible with libarchive and makefs (one line per file with full >> path) and the -N option which allows a stand alone set of passwd and >> group files. >> >> When mated with the -U and -M options to NetBSD's install we will have >> most[0] of the pieces require to allow installworld to run as a user and >> then build images containing proper permissions. The rest of this post >> will focus on my plans for mtree since it is the logical next step. >> >> NetBSD's mtree is missing a few features present in our mtree. Most of >> them looks simple to implement and I plan to do so before any import. >> The only exception is -i which implements indenting of old-style mtree >> files to match the format of the files in /etc/mtree/. It will either >> need another name or to be dropped. I honestly don't see the point in >> it so I'm not sure if it's worth keeping if people will need to alter >> their scripts regardless, but I'm willing to be convinced otherwise. >> >> Importing mtree requires importing or implementing some enhancements to >> libc. First, the strsvis() function is required which is most >> easily handled by importing NetBSD's vis/unvis implementations with the >> addition of the VIS_GLOB set of characters. Compatibly wrappers will >> be required for existing vis(3) functions and for unvis() due to ABI >> changes, but they will be minimal. >> >> Second, pwcache_userdb(), uid_from_user(), pwcache_groupdb(), and >> gid_from_group() provide useful enhancements to the uid_from_user() >> and group_from_gid(). They appear to be entirely compatible with our >> current implementation so simply importing the enhanced version seems >> like the best course. >> >> Finally, FreeBSD and Mac OS have the functions fflagstostr() and >> strtofflags() in libc. NetBSD has flags_to_string() and >> string_to_flags() in libutil. The latter could be a very thin wrapper >> around fflagstostr() and the former is exactly strtofflags(). I think >> the best course is probably to provide compatible wrappers for mtree's >> internal use, but I could be convinced to make them more globally >> available. >> >> Does anything about this plan seem seriously objectionable? > > Looks good to me. I started doing this a while ago an ran into lots of p= roblems, many of which you've outlined here. They weren't hard problems, ju= st numerous enough for me to lose interest in the project before I complete= d it. Glad to see somebody has pushed through. > >> I've written some of this up along with a list of missing features in >> the wiki. I'll keep progress up to date there: >> >> http://wiki.freebsd.org/NetBSDMtree >> >> -- Brooks >> >> [0] We also lack a tool to build disk images including partition tables, >> but Marcel is looking into this. > > makefs will build the disk image w/o the MBR/GPT tables. For most flash = devices, this is sufficient. For more complex situations, like where the b= oot loader groks FAT but not UFS, that needs some help... Once upon a time,= you could use dd + fdisk to create an MBR image, but nothing apart from th= e kernel understands using it. gpart is so darn easy to use, it is a shame= that you have to make a privileged trip to the kernel to use it. > > Warner_______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=6wXZGxzJtwpzWO%2B-Q-2Pv-DLxSbvaZmjFYVzOZRDEmw>