Re: [RFC] Rewriting sade(8)

(( 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:
> 
> > On Thursday 08 April 2010 5:05:34 am Dag-Erling Smørgrav wrote:
> >> Alexander Leidinger <Alexander_at_Leidinger.net> writes:
> >>> Please consider using SVN instead. A lot more users will be able to
> >>> check out from there.
> >> 
> >> We don't grant non-committers access to the Subversion repo.
> >> 
> >>> 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 intent
> >>> 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.
> >> 
> >> 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 the
> >> installation procedure.  Anythig that sade can do, we want sysinstall to
> >> do as well, and we don't want to implement everything twice.
> >> 
> >> 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 instead
> >> of duplicating the code.
> > 
> > Actually, I would rather have sysinstall just invoke sade to do the disk 
> > related stuff.  Also, I think sysinstall should allow for a "back-door" mode 
> > where a user can setup partitions however they like and mount them at /mnt and 
> > then let sysinstall use the setup the user created.  This will allow users to 
> > setup more complex setups that sysinstall/sade do not currently support and 
> > allow sade to focus on simpler, common usage cases w/o having to handle 
> > painful edge cases.  It would also allow for new modules to be added to sade 
> > over time w/o requiring it to support every possible disk layout from the 
> > beginning.
> 
> I couldn't agree more.
> 
> Regards,
> --
> Rui Paulo
> 
-- 
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_at_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 <-