[Bug 192413] libdhcp : IPv6 and IPv4 DHCP client and network configuration library API

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: libdhcp : IPv6 and IPv4 DHCP client and network configuration library API


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192413





------- Additional Comments From dcantrel at redhat.com  2006-05-30 13:46 EST -------
(In reply to comment #28)
> RE:
> > Looking at /usr/include/dhcp4client/isc-dhcp/dhcp4client.h and then the one
> > for IPv6, I only see one function prototype and it looks like an entry point
> > for execing the client daemon to me.
> 
> Each libdhcp{4,6}client library provides only one entry point, which is the
> client main() function renamed to dhcpv{4,6}_client . The main functions 
> have been modifed not to go into daemon mode, fork any processes etc., or
> to create any files at all, if running under libdhcp, and also to clean up
> after themselves - before returning, they free all memory used by the
> client and reintialize all the global variables used by the client.
> I've tested running  both the clients 100 times in succession in the same
> process under valgrind and valgrind reports no leaked files, memory or 
> memory access errors from client code.

OK, then this is probably why I thought it was execing the client.  It's not
doing that, but rather it is the client code (minus some daemon housekeeping).

I'm all for code reuse, but the libdhcp{4,6}client + libdhcp solution is simply
too big for loader2.  Loader2 is static and needs to fit in tight spaces.

I also have questions about these new client libraries for DHCP.  It's just
duplicating the client code in the form of the library, right?  Having two
copies of large programs, one as a client and one as a library, opens the door
to more maintenance issues...at least down the road.  Are these libraries
something you want to send upstream to ISC and then patch the clients to use
them?  This really has no bearing on its use in anaconda, but it's a concern I have.

A drop-in replacement for pump now helps, but it pulls in libdhcp{4,6}client and
libdhcp, which doesn't help loader2.

Pump doesn't need to be a client, we just need the library.  I think this is the
way to go for loader2 in anaconda.  We need a minimal IPv4 and IPv6 library that
can link in to loader2.  It only needs to be there for bringing up the network
interface so we can grab stage2 and make it go.  It's hard to define minimal,
but there are certainly things in dhclient (and the one for IPv6) that just
don't matter for the installer.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.