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

[Bill Nottingham <notting redhat com>]

Jeremy Katz (katzj redhat com) said: 
> >   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.

So, right now, we have a live CD that:

- writes network configs that have no bearing on what the system is
  actually using at the time
- has to run under a global lock so that it doesn't trigger the media
  automounter
- requires setting deprecated kernel options

This is... good? Really?

> 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


Frankly, I'm confused by the fact that we don't want to use the system
hardware library because of a possible rewrite at some point in the
future, and yet we're perfectly happy to redo the installer to talk to
the parted bindings of the month twice a year.

Abstractions for our abstractions? Brilliant!

More seriously, there is a python-ish binding for HAL, but using the
straight dbus interface seems simpler from a dependency standpoint, and
it's shorter code.

> > - 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 ;)

*shrug*. Not sure why you'd *want* to maintain a giant stack of NIH, and
special cases for the wacky controllers of the future, and... 

> 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.  

Somehow I suspect 50MB isn't quite what it would end up being. And udev's
already there (see above.)

Bill