This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001177] Redboot DHCP client race condition, XID, and retryproblems.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]