This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001177] Redboot DHCP client race condition, XID, and retryproblems.
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Sat, 26 Mar 2011 04:20:54 +0000
- Subject: [Bug 1001177] Redboot DHCP client race condition, XID, and retryproblems.
- Auto-submitted: auto-generated
- References: <bug-1001177-13@http.bugs.ecos.sourceware.org/>
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001177
--- Comment #8 from Grant Edwards <grant.b.edwards@gmail.com> 2011-03-26 04:20:52 GMT ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #2)
> >
> > > - It would be nice (although admittedly arguably an enhancement)
> > > for all of bootp/dhcp support to be removable by config
> > > option. There are many instances where redboot is only ever
> > > given a static IP, so this code is just taking up space.
> >
> > I've create a new CYGPKG_REDBOOT_NETWORKING_BOOTP which now contains
> > CYGSEM_REDBOOT_NETWORKING_DHCP and CYGSEM_REDBOOT_NETWORKING_VERBOSE_BOOTP.
> >
> > I'm wondering about the latter names. Are names supposed to
> > reflect package heirachy like more like this?
> >
> > CYGPKG_REDBOOT_NETWORKING
> > CYGPKG_REDBOOT_NETWORKING_BOOTP
> > CYGPKG_REDBOOT_NETWORKING_BOOTP_DHCP
> > CYGPKG_REDBOOT_NETWORKING_BOOTP_VERBOSE
>
> While I think that would be the ideal, changing option names (in
> general invalidates people's existing configurations, so shouldn't
> be done lightly.
Agreed. It had slipped my mind that two of the names were for options
that already existed -- and enhancing the consistency of the names a
bit doesn't justify breaking somebody's previously working
configuration.
> I'd suggest just leaving it. The more important thing is that the
> actual hierarchy of options is correct. But if you want to change
> it, I'm ok with that too.
The two existing names are going to stay the same.
>[...]
> > I don't have a strong opinion one way or the other, but if I were to
> > pick, I'd move CYGSEM_REDBOOT_DEFAULT_NO_BOOTP into
> > CYGPKG_REDBOOT_NETWORKING_BOOTP and make it independent of whether
> > CYGDAT_REDBOOT_DEFAULT_IP_ADDR is set or not. Who are we to say that
> > no default IP address and bootp built but disabled by default isn't
> > useful to somebody?
>
> Yes, there seems no reason to prohibit that, so if you didn't mind,
> I think it would be good if you could do that.
Done.
--
Grant
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.