FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 05-21-2008, 04:40 AM
David Cantrell
 
Default removal of libdhcp

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.


http://dcantrel.fedorapeople.org/anaconda/iface/

iface.h - Header file explaining the iface API. iface_t structure
replacing pumpNetIntf and networkDeviceConfig, and all of the functions.

iface.patch - The changes, it's about 90% complete at this point.
*.txt - Explanations and notes.

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.


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.


Work in progress, comments welcome.

--
David Cantrell <dcantrell@redhat.com>
Red Hat / Honolulu, HI

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-21-2008, 12:01 PM
John Summerfield
 
Default removal of libdhcp

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.


http://dcantrel.fedorapeople.org/anaconda/iface/

iface.h - Header file explaining the iface API. iface_t structure
replacing pumpNetIntf and networkDeviceConfig, and all of the functions.

iface.patch - The changes, it's about 90% complete at this point.
*.txt - Explanations and notes.

This patch removes anaconda's use of libdhcp,


Why?
How will your patch improve Anaconda?[1]
How is/will Network Manager be better?
Does the result use less RAM?

I'm sure there are more questions.


[1] I accept that reducing duplicated code is good.


--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-21-2008, 01:35 PM
Jeremy Katz
 
Default removal of libdhcp

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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-21-2008, 03:50 PM
Elliot Peele
 
Default removal of libdhcp

On Wed, May 21, 2008 at 09:35:30AM -0400, Jeremy Katz wrote:
> On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
> > 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.

What about distros that don't use NetworkManager? Will there be a fall
back? If we are using NetworkManager with Anaconda will it still able
able to generate "classic" network configuration?

Elliot

--
Elliot Peele
rPath, Inc.
elliot@rpath.com

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-21-2008, 05:31 PM
David Cantrell
 
Default removal of libdhcp

On May 21, 2008, at 2:01 AM, John Summerfield wrote:


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.

http://dcantrel.fedorapeople.org/anaconda/iface/
iface.h - Header file explaining the iface API. iface_t structure
replacing pumpNetIntf and networkDeviceConfig, and all of the
functions.

iface.patch - The changes, it's about 90% complete at this point.
*.txt - Explanations and notes.
This patch removes anaconda's use of libdhcp,


Why?
How will your patch improve Anaconda?[1]


libdhcp replaced libpump around F-5 or so. It's been nothing but
trouble since then as it just wraps the client daemons and provides a
sloppy control system around talking to them. And the dhcp clients
don't even get executed correctly via this library anyway. It's been
a real pain to keep working and it just needs to go.


So, the patch has us directly configuring interfaces using libnl
(which is used by NM), and running the actual client daemons for dhcp
and dhcpv6 when the user requests configuration that way. The same
way it run on the target system.



How is/will Network Manager be better?


It's what the final system uses by default now and it's what we [the
installer team/distribution] would like to ultimately use for network
interface configuration during installation. If it's good enough for
the final system, it should be good enough for the installer. So,
it's more about using the same code for the same tasks.



Does the result use less RAM?



Not necessarily. But maybe.

--
David Cantrell <dcantrell@redhat.com>
Red Hat / Honolulu, HI

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-21-2008, 05:43 PM
David Cantrell
 
Default removal of libdhcp

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@redhat.com>
Red Hat / Honolulu, HI

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-21-2008, 05:48 PM
David Cantrell
 
Default removal of libdhcp

On May 21, 2008, at 5:50 AM, Elliot Peele wrote:


On Wed, May 21, 2008 at 09:35:30AM -0400, Jeremy Katz wrote:

On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:

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.


What about distros that don't use NetworkManager? Will there be a fall
back? If we are using NetworkManager with Anaconda will it still able
able to generate "classic" network configuration?



Personally, I'd rather not allow users the option to create a classic
set of ifcfg-* files if we are doing NM by default. As long as it's
an option, people will still use it, which means we'll still have to
support multiple ways of configuring network devices on the target
system. If we're going NM for everything, it should be NM for
everything.


--
David Cantrell <dcantrell@redhat.com>
Red Hat / Honolulu, HI

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-21-2008, 06:08 PM
Jeremy Katz
 
Default removal of libdhcp

On Wed, 2008-05-21 at 07:48 -1000, David Cantrell wrote:
> On May 21, 2008, at 5:50 AM, Elliot Peele wrote:
> > What about distros that don't use NetworkManager? Will there be a fall
> > back? If we are using NetworkManager with Anaconda will it still able
> > able to generate "classic" network configuration?
>
>
> Personally, I'd rather not allow users the option to create a classic
> set of ifcfg-* files if we are doing NM by default. As long as it's
> an option, people will still use it, which means we'll still have to
> support multiple ways of configuring network devices on the target
> system. If we're going NM for everything, it should be NM for
> everything.

Generating ifcfg-* files is still sane with NetworkManager, though. It
uses them for the system-settings backend

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-21-2008, 06:10 PM
Jeremy Katz
 
Default removal of libdhcp

On Wed, 2008-05-21 at 07:43 -1000, David Cantrell wrote:
> 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.

Fair enough... I just think that we might as well get the real end goal
in place, even if it takes a little bit longer. It will end up saving
effort overall as we won't have to fix things in the interim step.

[snip]
> > 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.

Yep. Hence, I wouldn't try and tie it at all to this set of changes.
Which might mean that libdhcp sticks around for a minor case for a
little bit longer, but hopefully not that much longer.

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-21-2008, 06:11 PM
Jeremy Katz
 
Default removal of libdhcp

On Wed, 2008-05-21 at 11:50 -0400, Elliot Peele wrote:
> On Wed, May 21, 2008 at 09:35:30AM -0400, Jeremy Katz wrote:
> > On Tue, 2008-05-20 at 18:40 -1000, David Cantrell wrote:
> > > 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.
>
> What about distros that don't use NetworkManager? Will there be a fall
> back? If we are using NetworkManager with Anaconda will it still able
> able to generate "classic" network configuration?

Honestly, I think that's getting more to the point of "what about
distros that don't use udev/hal" or something along those lines. A more
constructive thing would be to figure out how NetworkManager doesn't fit
your use cases and try to get those resolved.

But writing out ifcfg-* files is probably still something that will
remain in some form or fashion, but from a UI perspective, interactive
installs may not want to expose a lot of it.

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 10:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org