On Thu, 2007-12-06 at 12:18 -0500, Bill Nottingham wrote: > 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 This is because we're spastic about how we want to deal with the network, not because of HAL vs not. If we'd actually settle on one way of doing network configuration, then this would be a non-issue > - has to run under a global lock so that it doesn't trigger the media > automounter This doesn't really change that -- we're still going to want to avoid triggering the automounter because the automounter has no concept of mounting a system into a chroot. > - requires setting deprecated kernel options Which ones? > This is... good? Really? I'm not saying it's good... I'm just saying that I don't think that we magically fix anything with the live install case purely by switching > > 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. Huh? We haven't changed parted bindings that we use since we started using parted 6.5 years ago. pyparted is what msw had imported into parted and then I split it out into a separate source to be more maintainable 3.5 years ago. > 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. I guess that realistically, I'd be less inclined to want an abstraction over a real python binding. But directly talking to dbus ends up making things looking very much not like python and more difficult to read. Not to mention that you end up needing to wrap essentially _any_ dbus call in a try/except for a DBusException because otherwise you can and do get them in unexpected places. That's the unfortunate lesson that the CD support in pirut has taught me :( > > > - 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... Luckily, wacky controllers seem to be becoming less common. Well, except for on ppc :-) > > 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.) 50MB is more if we were to not have a split stage1/stage2 anymore, not just udev+hal in the first stage. But I guess that's probably inevitable and I'm likely the main one who'd be cranky about it... would be good to get some other opinions on which way is better. I just have been burned a few too many times by udev (and to a lesser degree hal, just because less is "dependent" on it) to be really happy with depending on them Jeremy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
