On May 21, 2008, at 3:35 AM, Jeremy Katz wrote:
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.
I can use splitdiff and create three patches or so.
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.
The patch should include a line to patch mk-images that brings bash in.
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.
The driving goal for me has been "get rid of libdhcp fast". So I put
this patch together hoping I could merge it in to rawhide sooner
rather than later and then have some time to work up a move-to-NM
patch. If people want to skip that interim step entirely, I'm cool
with that and can go ahead and start moving it to NM entirely. Not
knowing how long that would take, I just focused on removing libdhcp
for now and leaving our current functionality in place.
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.
Agreed, was just throwing out an idea for mkinitrd since something
will need to happen with it once libdhcp goes away.
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.
That's an entire project by itself, I think.
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
