Re: [RFC] Rewriting sade(8)

I too love the idea of "generalizing" (abstracting) the dirty-work to a
set of libraries and leaving the user interface up to the userland
applications. Thusly, an app in /usr/X11R6/bin can use said libraries in
plugging in functionality to an X11 GUI application, meanwhile an app
in /bin or /sbin (presumably, since we're talking about low-level system
utilities) could use the same libraries for plugging the same
functionality into a command-line interface (beit command-driven or
ncurses/libdialog driven).

However, I'm still wondering what that change would mean to our beloved
sysinstall when it comes time to place sysinstall into the mfsroot for
the CD-ROM installer.

Currently, the mfsroot contains very little in the ways of ELF binaries:

-sh, [ (test), arp, boot_crunch, camcontrol, cpio, dhclient, find,
fsck_4.2bsd, fsck_ffs, fsck_ufs, gunzip, gzip, hostname, ifconfig,
minigzip, mount_nfs, newfs, ppp, pwd, rm, route, rtsol, sed, sh,
sysinstall, test, tunefs, usbconfig, and zcat

Every last one of those is (a) statically linked and (b) hard-linked to
one-another (really, they are all hard-links to boot_crunch which is a
by-product of crunchgen(1)).

What might the landscape look like if we move down the road toward
separating the back-end from the front-end?

Presumably though, we could simply put the bits back together, no?
Currently, the following libraries are slurped into the crunchgen
configuration:

-ll, -ledit, -lutil, -lmd, -lcrypt, -lftpio, -lz, -lnetgraph, -ldialog,
-lncurses, -ldisk, -lcam, -lsbuf, -lufs, -ldevinfo, -lbsdxml, -larchive,
-lbz2, -lusb, and -ljail

Which I show to be these files in RELENG_8:

/usr/lib/libl.a
/usr/lib/libedit.a
/usr/lib/libutil.a
/usr/lib/libmd.a
/usr/lib/libcrypt.a
/usr/lib/libftpio.a
/usr/lib/libz.a
/usr/lib/libnetgraph.a
/usr/lib/libdialog.a
/usr/lib/libncurses.a
/usr/lib/libdisk.a
/usr/lib/libcam.a
/usr/lib/libsbuf.a
/usr/lib/libufs.a
/usr/lib/libdevinfo.a
/usr/lib/libbsdxml.a
/usr/lib/libarchive.a
/usr/lib/libbz2.a
/usr/lib/libusb.a
/usr/lib/libjail.a

I think I just answered my own question...

We should have no problem re-incorporating any heretofore developed
libraries (for the back-end functionality) *back into* the crunchgen
(1)'ed binaries.

In fact, if we, say for example, developed /usr/lib/libsysinstall.a
and /usr/lib/libsade.a , we could then simply just patch
`/usr/src/release/i386/boot_crunch.conf' in the following manner:

[dteske_at_push800 /usr/src/release/i386]$ diff -u boot_crunch.conf{.bak,}
--- boot_crunch.conf.bak        2010-04-08 07:10:49.000000000 -0700
+++ boot_crunch.conf    2010-04-08 07:10:27.000000000 -0700
_at__at_ -46,3 +46,4 _at__at_
 libs -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph
 libs -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo
 libs -lbsdxml -larchive -lbz2 -lusb -ljail
+libs -lsysinstall -lsade

Assuming of course that `release' (and intrinsically `buildworld') is
made to generate the libraries
at /R/stage/trees/base/usr/lib/libsysinstall.a
and /R/stage/trees/base/usr/lib/libsade.a (and respectively for
`buildworld', /usr/obj/usr/src/tmp/usr/lib/libsysinstall.a
and /usr/obj/usr/src/tmp/usr/lib/libsade.a).

So, I guess my fears of "mucking up" the install environment are
unfounded.

All-in-all, I'm right there with y'all on the idea of separating the
front-end from the back-end. It needs to be done (and will open up a
flurry of new installer interfaces and utilities that require low-end
stuff usually own made-available by sysinstall internals).
--
Devin

On Thu, 2010-04-08 at 16:19 +0200, Dag-Erling Smørgrav wrote:
> John Baldwin <jhb_at_freebsd.org> writes:
> > Dag-Erling Smørgrav <des_at_des.no> writes:
> > > 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.
> 
> ...which is exactly what I said - but in the sysinstall case, you may
> want to ask some additional questions ("are you sure you want to proceed
> without a swap partition?") or place some additional constraints (such
> as "don't allow the user to mount something on top of /mnt or /rescue"),
> and sysinstall needs to know the outcome.
> 
> DES
-- 
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 <-