> * Make minimal changes to the current code. > * Bring NetworkManager in and use it starting in stage 1. > * Do not make changes to the NetworkManager related packages as they are > in Fedora, just use them as is and pull in whatever we need. > * Be able to perform IPv4 installs over HTTP and NFS. These sound like reasonable goals. Hopefully we can also add some goals like: * Improved wireless support. * Fixing long-standing bugs like our inability to renew a lease. * Reducing our number of network configuration UIs. > 1) Lots of changes to upd-instroot and mk-images. NetworkManager means > we > also bring in dbus, hal, PolicyKit, functions, network-functions, and > other support programs called by those programs or scripts. dhclient > is in there, along with dhclient-script (which uses bash), and > dhcp6c. > It's a truckload of stuff. How much do you estimate we are growing the initrd (and I guess the stage2) images by? I see we're having to start more programs now from init. I assume this increases our memory requirements somewhat. Any idea how much it's grown? > 3) A new function called writeDisabledNetInfo() which writes out ifcfg > files for every found interface so we disable them by default. So, writeDisabledNetInfo() disables all discovered network interfaces by default, then we go back and enable the ones that the user asks for, or that we can successfully bring up via DHCP, or other means? > 4) The new iface.c stuff in isys. This code starts NetworkManager and > introduces a new type called iface_t. This is meant to replace all > uses of networkDeviceConfig and pumpNetIntf and all of the other > various structs that hold net info. Yes, there are a lot of flags > and copies of data right now, but cleanup is later. The rest of the > iface code is to provide a single API inside anaconda to get > information > about an interface (or set information). I expect the iface_t struct > to get smaller, as well as flags in loaderData to disappear. > > 5) No more pump or libdhcp. Both sound fine to me. > * Network configuration information is not carried over to stage 2 yet. > When you are at the post-config step for the network interfaces, it > won't reflect the current state. This would be the biggest concern I have for fixing before committing everything. > * Any wireless installs. The get_connection() function in loader2/net.c > provides a loop to attach this kind of stuff. When NM wants more > info, > we can prompt here and continue to wait for it to bring up the link. No big loss for now - we put up the "allowwireless" hurdle for people who want to install via wireless, so they know it's not really an officially supported mechanism. Would definitely be nice to have it done by release time. I don't really have any other specific comments. It's a lot of code, but the scariest part to me is really the UI flow components. That to me has always been our biggest problem in loader, not actually configuring interfaces. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
