On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote: > No patch attached because it's quite large. I apologize for the > length, but considering this replaces a library and introduces a new > struct it meant a new file and changing calls everywhere. I know it's large and I know that splitting up patches is a pain, but it really does increase the ability to review them which then ends up having a positive impact on the end result. And there's a fair bit of just renaming variables, etc in there. Which could be looked at on their own, easily validated and then overall shrinking the real meat of the patch. The biggest concrete thing I was able to see trying to churn through the patch is that /sbin/dhclient-script depends on bash which we don't have in the first stage at this point. > This patch removes anaconda's use of libdhcp, which also means > removing libdhcp4client and libdhcp6client. For static network > configuration, I am using libnl. To gather current network interface > information, I am using libnl. To control IPv6 autoconf, I read/ > write /proc since that's all we can do right now. For DHCP and > DHCPv6, I run dhclient and dhcp6c, respectively. > > I'd like everyone to have a look at iface.h and the patch file. It's > not complete yet, so I probably know about the obvious things (the > FIXMEs and the useless debugging printfs and the incomplete isys.py > code and so on). The goal with iface.patch is to get us closer to > using NetworkManager in stage 1 and stage 2. I envision the NM > changeover to be just as large, but hopefully by then we will have > decided to nuke certain parts of loader entirely. Completely > eliminating libdhcp and friends will be a nice step. So, I'm going to ask the obvious question which ends up staring us in the face at this point. Why not use NetworkManager like the rest of the OS *now* instead of making another wheel for ourselves that in all likelihood, will end up having to be maintained for on the order of years. The biggest reason I can come up with after thinking about it all night is that we'd end up pulling in more junk to the initrd (hal and dbus at the very least) and I wasn't entirely thrilled about doing that just for hardware detection. But maybe it really is the right thing to do now. The other downside is that we'd probably still need to have our own control code to prompt for information and then send that to NetworkManager. And yeah, substantial change. But meh, so was the udev/hal stuff The positive benefit would be that we'd largely be out of this business and could reassign the bugs ;) Plus, it'd make it easier for us to decide to start supporting things like installs over wireless using WPA. > There are some other things that need discussion as well. mkinitrd > currently uses libdhcp, for example. This had me thinking we could > generate libisys in an anaconda-devel package for things like > mkinitrd, but I'm just brainstorming. Maybe I should put the iface > code elsewhere? I dunno. At any rate, mkinitrd needs to be not left > out. A libisys seems like a bad idea as isys is best summed up as a set of bodges around things the OS doesn't sanely provide for us ;) And I don't even want to think about trying to maintain any sort of API or ABI compatibility for it. The right fix for mkinitrd given the direction we continue to move in there is probably to switch away from nash builtins and just suck in the appropriate utilities into the initrd. But that's not an easy move either. Jeremy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
