Re: [RFC PATCH] De-kudzuification of anaconda, stage 1

[Jeremy Katz <katzj redhat com>]

High-level thoughts

On Wed, 2007-12-05 at 18:22 -0500, Bill Nottingham wrote:
> These patches:
> 
> - replace the use of kudzu for probing in stage2 with HAL usage
> 
>   This seems to me to be the obvious choice - it matches the rest
>   of the system, and allows anaconda to be used as a 'normal' app
>   better. Furthermore, going down this road allows us to fix various
>   warts (network devices, CD locking, etc.) in the live install case
>   better.

I don't think it really makes things any different for the live case.
And with the upcoming HAL rewrite that davidz keeps alluding to, I'm not
entirely sure how comfortable I am having tendrils of something else
spread all over the place that we're then going to have to rip out
later.   But I guess that we can hide the details of HAL behind some of
our own abstraction

> - switch to using udev to create device nodes (not load modules) in
>   stage1 and stage2
>   
>   HAL uses udev for some device information, and getting anaconda out
>   of the business of creating device nodes seems to me to be an obvious
>   win.

... maybe not the best day to try to convince me that udev is a good
idea as I wrestle with the fact that livecds have stopped booting
because udev apparently doesn't want to create device nodes anymore ;)

> That leaves the question of what to replace kudzu with in stage1. That
> is not solved in this patch. Frankly, I think that using udev + hal
> makes the most sense from a standpoint of not having to duplicate and
> maintain code in anaconda proper going forward. However, that entails
> switching to a dynamic stage1 to accomplish that, and the surgery
> required to upd-instroot and mk-imageds to accomplish that may kill the
> patient. If we *do* do that, it's a good time to revisit the
> stage1/stage2 split, especially if we're changing how we download
> images. If we *don't* do HAL in stage1, then we just want a small shim
> that pulls block/net devices out of sysfs, and switches the way we load
> modules.

>From a POV of debuggability, the smaller approach with less moving parts
feels like it's going to fit in better and be less of a hassle.  Also,
including udev+hal in stage1 is going to lead to a substantial increase
in the size.  Even though we're changing some of how we download images,
the split is still pretty important because a 50 meg initramfs is kind
of painful.  

Jeremy