Date: Thu, 08 Apr 2010 07:24:27 -0700 From: Devin Teske <dteske@vicor.com> To: Rui Paulo <rpaulo@freebsd.org> Cc: Bruce Cran <bruce@cran.org.uk>, John Baldwin <jhb@freebsd.org>, freebsd-current@freebsd.org, freebsd-geom@freebsd.org, Randi Harper <randi@freebsd.org>, "Andrey V. Elsukov" <bu7cher@yandex.ru>, Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= <des@des.no>, Alexander Leidinger <Alexander@leidinger.net> Subject: Re: [RFC] Rewriting sade(8) Message-ID: <1270736667.29753.14.camel@localhost.localdomain> In-Reply-To: <2FEF9866-2B2E-4AAC-B504-02CF1537AEC0@freebsd.org> References: <55861270658151@web135.yandex.ru> <20100408103809.13496s9i6ny03ocg@webmail.leidinger.net> <867hoi8gbl.fsf@ds4.des.no> <201004080849.12151.jhb@freebsd.org> <2FEF9866-2B2E-4AAC-B504-02CF1537AEC0@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
(( wishing that I hadn't un-CC'd the group on earlier e-mails )) Some concerns that I have with separating the code into a back-end versus front-end... 1. Is it currently the idea that -- when it comes down to the crunchgen stuff -- we are going to re-work the code that generates the non-shared binaries for mfsroot? or move away from the crunchgen/mfsroot paradigm? 2. If moving away from crunchgen/mfsroot, ... are we effectively making the statement that we no longer "support" installing FreeBSD on your floppy-enabled kitchen toaster? I'm not saying that there's an overwhelming need to retain the ability to install FreeBSD via floppy, ... but it uber-legacy support is something to be proud-of (just as lack-thereof could perhaps be something to be ashamed of -- I can fall into either camp channeling visions of Steve-Jobs-style mac-like shunning of the floppy drive or even Bill Gates almost sickening legacy- support of DOS). 3. We could abandon chrunchgen/mfsroot and simply load up all the back- end bits with the front-end bits for sysinstall to function in the installer environment ... but my quarrel is ... will it still fit on a floppy? if not, are we prepared to deprecate that? otherwise, does anyone care that the installer environment will be changing from a collection of staticallly-linked binaries to a "mess" ? I actually have a really nifty idea for deprecating mfsroot... and that's to start using syslinux as the boot-loader (which as of version 3.84 supports booting *.iso files). We're doing that in our company now... we have a CD-ROM that boots SYSLINUX and displays a menu with many options (among them "FreeBSD"). Selecting "FreeBSD" from the menu uses SYSLINUX's "memdisk" module to then boot `mdroot.iso' which essentially an `mfsroot'. The benefit here is that the `mdroot.iso' can be built cross-platform (matters not if you download our CVS tree to a Linux box or FreeBSD box... as long as you have `mkisofs' you can "compile" the disc and all incumbent file systems). The further beauty of this method is that the resultant mdroot.iso can be large (currently 14MB in our company ... but that's only because it contains two monolithic custom kernels which -- because we have a custom boot loader that allows us to cycle through any number of kernels at boot time to select the proper one for the hardware in question). -- Devin On Thu, 2010-04-08 at 15:08 +0100, Rui Paulo wrote: > On 8 Apr 2010, at 13:49, John Baldwin wrote: >=20 > > On Thursday 08 April 2010 5:05:34 am Dag-Erling Sm=C3=B8rgrav wrote: > >> Alexander Leidinger <Alexander@Leidinger.net> writes: > >>> Please consider using SVN instead. A lot more users will be able to > >>> check out from there. > >>=20 > >> We don't grant non-committers access to the Subversion repo. > >>=20 > >>> It looks like other people had a look at sysinstall, not at sade. As > >>> sysinstall is supposed to be used at installation time, and the inten= t > >>> for sade was to offer the functionality (or more) of the part of > >>> sysinstall which is useful after installation (and to prevent admins > >>> from using sysinstall after the installation to prevent some unwanted > >>> foot-shooting), I do not think that we need to think about a strong > >>> lock between sysinstall and sade. > >>=20 > >> Yes we do. Otherwise we'll just end up back where we are today, where > >> if you want anything more complicated than a single-disk install you > >> have to drop into the fixit shell and do it manually before running th= e > >> installation procedure. Anythig that sade can do, we want sysinstall = to > >> do as well, and we don't want to implement everything twice. > >>=20 > >> My suggestion is to add a "sysinstall mode" to sade where it operates > >> under certain (minor) constraints and reports what it did in a format > >> that sysinstall can parse, so sysinstall can just fork-exec sade inste= ad > >> of duplicating the code. > >=20 > > Actually, I would rather have sysinstall just invoke sade to do the dis= k=20 > > related stuff. Also, I think sysinstall should allow for a "back-door"= mode=20 > > where a user can setup partitions however they like and mount them at /= mnt and=20 > > then let sysinstall use the setup the user created. This will allow us= ers to=20 > > setup more complex setups that sysinstall/sade do not currently support= and=20 > > allow sade to focus on simpler, common usage cases w/o having to handle= =20 > > painful edge cases. It would also allow for new modules to be added to= sade=20 > > over time w/o requiring it to support every possible disk layout from t= he=20 > > beginning. >=20 > I couldn't agree more. >=20 > Regards, > -- > Rui Paulo >=20 --=20 Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <-
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1270736667.29753.14.camel>