Jeremy Katz (katzj@xxxxxxxxxx) 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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
