Review of pwlconfig 0.90

Ralph Stickley [email protected]
Mon, 3 Apr 2000 13:55:54 -0700 (PDT)


Dennis,

--- "Dennis W. Tokarski" <[email protected]> wrote:
> Hi Ralph,
> 
> Sorry it took me so long to get back to you with a review of pwlconfig
> 0.90. I got sidetracked for a bit in the "educational" experience of
> seeing what a minimal boot disk really requires if constructed manually.
> It was really rather interesting, and I at least wound up with something
> useable for my initial target/development system.
> 
> I hope you find this feedback helpful.
> 
>   --Dennis
> 
No problem, thanks for the feed back. I don't know what my schedule holds for
the next week or so, but I do hope to get back on this soon...

I'll see if I can explain away these problems (or at least find something to
blame them on :)...

Thanks again,
Ralph

>  ====================================
> 
> As a general observation, the way pwlconfig drops into a text mode
> screen between menus creats a disconcerting flash. Even doing so for
> the sake of printing progress dots is kind of annoying. Painting one
> menu directly after another would be preferable. Progress indicators
> for long operations would be nicer if shown on the menu display as
> a spinning arrow, or a %done display, or even the more typical
> %done "thermometer" style progress bar.
> 
I know, I hate it when that happens...menuconfig doesn't seem to do that, not
sure why...I also thought I saw an indicator available in lxdialog, but haven't
persued that one any further...

> Here are some other rough spots I ran into, pretty much in the order
> they'd pop up when creating a new project.
> 
> * When pwlconfig is started for the very first time (i.e., its
>   .* files don't exist yet and there is no "projects" directory),
>   it asks for a project to create but not a target device.
> 
Yep...went back and forth on this one...current default is the device I'm
currently working on :)

> * After the first run, creating a new project does prompt for a
>   default device, (DOC/FLOPPY/etc) which MUST be entered in upper
>   case. This should probably be made lower case, case insensitive,
>   or selected from a menu of fixed choices.
> 
That should be a select list anyhow -> New feature <-

>   Currently, a mistake on entry gives a warning, but no reprompt.
>   Setting the device must then be done by manually selecting
>   Manage Projects/Project defaults/Device Type, then editing the
>   field.
> 
Should have thought someone would type it in wrong...fixed with above new
feature...oops.

> * When a target device is correctly entered for a newly created
>   project, it appears nothing is done with that information. A
>   look at project defaults shows they're all set to assume Flash.
> 
Oops...that sounds like the pick any one as long as it flash feature...

> * Modifying the device type in the Reset Project Defaults menu
>   doesn't cause coordinated changes to other fields, like Boot Location,
>   Device Name, Device Partition, and Device Type Node. Reasonable
> defaults
>   could be supplied keyed to the selection of Device Type.
> 
I thought the reset changed most fields here...of course, I only tested lately
with FLASH...

> * If a project is removed, the pwlconfig is pretty good about
>   insisting that the user select another project. However, it
>   is possible to exit the whole program suite without doing so.
>   Upon restart, pwlconfig reinserts the removed project name into
>   the projects list under Manage Projects, but it has new
>   default configuration information.
> 
BUG -- Ouch...hadn't thought of that...(ummm...don't do that?)...should force
you to select a new project when you restart...

>   Essentially, pwlconfig implicitly creates a new project using the  
>   same name as the project the user just removed. This is potentially
>   confusing. Probably the right thing to do is not have a current
> project
>   and go back to insisting the user select one.
> 
Yep...

> * When configuring the file system the base-filesys-2 package
>   has a *lot* of possibly extraneous stuff in the dev directory.
>   So does base-filesys-minimal-1, for that matter. When pruning this
>   collection by manually deselecting individual items, each deselect
>   causes a drop to text mode while pwlconfig prints out about three
>   and a half lines of progress dots, which takes a looooooong time.
> 
This is a killer...the way I'm using lxdialog and the script language just kill
the system with long lists...I need to look at some optimizations, mabe pageing
(list 50 at a time or something)...as is, your manual prune is best bet.

>   This one *really* had me climbing the wall. I finally took to just
>   accepting the whole smash, generating the file system, then using
>   'rm' to clean out the directlry after stopping pwlconfig.
> 
>   It would be much much much ***much*** nicer to simply note the
>   selections/deselections and defer whatever processing is neccessary
>   until after the menu is exited. Or maybe an "Apply" button would be
>   appropriate here?
> 
> * Here's a problem which showed up while trying to use one of the
>   "minimal" packages, busybox-0.36. Suppose you really want to
>   use busybox along with some other package which contains a
>   conflicting file. You can't install the other package second
>   because it might replace some of busybox's links with real files,
>   and thus take up more space than you want. But installing busybox
>   second doesn't work either, because the "ln" command to make the
>   links is issued without the -f option.
> 
Yep...we've seen this - it has to do with the order in which the files are
extracted (alphabetical now)...don't know how to fix it...

don't think there is a good way to allow the user to set priority on which
files actually get installed, that leaves:

1. make the duplicated file you really want as custom (custom files get copied
last and overwrite any existing files)

2. manually go in an disable the duplicated files from busybox (haven't tested
that to see if that would work..do links get enabled/disabled properly
..hmmmm...)


> pwlconfig appears to assume that the target device will be mounted
> as / in the running system. There is no provision for use of initrd
> or compressed ram disk. These features really are needed if the goal
> is to make some sort of minimal special purpose rescue/diagnostic
> disk. At the very least, separate boot and root floppies need to
> be supported.
> 
Yep...pwlconfig is "partition" centric...that is one project matches one
partition.  My plan (not done) was to:

1. make a project for the ramdisk file system
- extract files just as currently done
- add a flag in the "defaults" that tells pwlconfig to compress this into some
image filename
- "Load"  files operation would then build a compressed image file somewhere in
the system ./Embedded_Build/misc/myimage or whatever)

2. make a project that is the file system for the boot files
- Include the custom file ./Embedded_Build/misc/myimage 
- Load files includes the image file - poof, instant ramdisk


> As a result, pwlconfig can't presently make a bootable floppy at
> all. There are several obstacles:
>
Yep, one of those features that I've never needed, never got implemented...
 
>  * For one, the libraries are too darn big, and there's nothing
>    we can reasonably do about it. They either *must* go on a
>    compressed ram disk or there has to be a separate root floppy.
> 
ummmm...Adi could answer to this better :-)

>  * There are too many entries in /dev taking up too many inodes.
>    When pwlconfig copies the project filesystem to the floppy,
>    it quickly gets a "no space on device" error even if
>    there's plenty of space. What's really happening is it's
>    out of inodes. You need to make the file system with something
>    like
>          mke2fs -N `wc -l ./projects/PROJECTNAME/mnt` /dev/fd0
> 
neat trick!

>    Presently, just the base filesystem package is too much for
>    a floppy made with just "mke2fs /dev/fd0".
> 
>  * Making the floppy boot able with LILO has a couple of hitches--  
>    pwlconfig insists that lilo be in ./bin, rather than just using
>    /sbin/lilo as installed, and (cosmetic only) the prompt for using
>    the existing lilo.conf.FLOPPY is done in text mode.
> 
Yep...I had to do this for the DOC which uses its own Lilo program...just left
the default lilo program there too..didn't have to...could change it...that
would make sense too...

>  * The generated lilo.conf.FLOPPY file expects a kernel image name
>    of vmlinuz, but the kernel packages use bzImage.
> 
yep..one of those pesky defaults...

> Just to see if a floppy produced by pwlconfig would boot, I made one up
> without any libraries. After resolving the above problems, lilo seemed
> to run successfully. However, trying to boot the floppy resulted in the
> first stage loader stopping after printing "L", then it loops printing
> an error code: "04". Removing the "disk=" line from lilo.conf.FLOPPY
> solved this problem. 
> 
Hmmmm...I guess that makes sense...disk= is for hdd table...Ok, yet another bug
- good catch :)

> 
> 
>       *** Some suggestions for initrd/ramdisk/root disk support ***
> 
> It seems that a natural way to extend pwlconfig would be to split
> the Configure Project File System menu into three sections: Configure
> Boot File System, Configure Initrd, and Configure Root File System.
> In the latter case there should be options to specify if the Root
> File System will be a ramdisk, and if it should be compressed. You
> would also need to specify the ramword parameters. Ramdisk size could
> be determined automatically using du.
> 
> Each of these three options would build file systems under separate
> trees: ./projects/PROJECTNAME/{boot,initrd,root} using the current
> package installation procedures. The mere existence of the initrd
> and/or root file trees at the end of the procedure would be enough
> information for you to figure out how to generate the composite
> boot disk, or boot/root set.

See my coment about the partition thing.  We've had some discussions on this
but I'm not at a point where I can add this in yet - although everyone who
looks at this system seems to think that ramdisk is useful...

Wow, Great testing! I'll have to print this out and use it for the next rev (or
if you have any patches that would help too :-)
Thanks!

> ---------------------------------------------------
> See the list archives at http://adis.on.ca/archives/
> See the PWL homepage at  http://embedded.adis.on.ca
> ---------------------------------------------------
> 

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
---------------------------------------------------
See the list archives at http://adis.on.ca/archives/
See the PWL homepage at  http://embedded.adis.on.ca
---------------------------------------------------