public inbox for ecos-bugs@sourceware.org help / color / mirror / Atom feed
From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1001177] Redboot DHCP client race condition, XID, and retry problems. Date: Thu, 24 Mar 2011 17:37:00 -0000 [thread overview] Message-ID: <20110324173653.B77252F7800A@mail.ecoscentric.com> (raw) In-Reply-To: <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 Jonathan Larmour <jifl@ecoscentric.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |jifl@ecoscentric.com --- Comment #2 from Jonathan Larmour <jifl@ecoscentric.com> 2011-03-24 17:36:49 GMT --- Some comments: - in changelog "fixrace" -> "fix race". Also reference this issue number. - 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. If that happens, obviously a few existing CDL config options would then live under that CDL component. I notice (in existing code, not your patch) that CYGSEM_REDBOOT_NETWORKING_USE_GATEWAY depends on CYGSEM_REDBOOT_NETWORKING_DHCP, which seems spurious to me. - In various places in the patch, constants like 4 or 6 are used. While entirely accurate, and they'll never change, from the principle of self-documenting code it would be nicer if they were things like e.g. sizeof(b->bp_chaddr) or sizeof(__local_enet_addr) etc. I admit I'm being a bit idealistic. - It's not clear to me in bootp_handler that this supports BOOTP even when CYGSEM_REDBOOT_NETWORKING_DHCP is enabled. Can you confirm it does? Just because CYGSEM_REDBOOT_NETWORKING_DHCP is enabled, shouldn't mean that we can't work with BOOTP any more. This may have been a problem in the previous code too. - You now depend on the CRC code for xid generation. That's quite a chunky dependency to introduce, and slightly pointless given there's very little randomness from every byte of the MAC address. I think it would be good enough to just take the lower 4 bytes of the MAC (or if you prefer, take the bottom four, and then XOR in the top 2). You could maybe XOR in MS_TICKS() for a little more entropy, although not much I agree. Or for a bit more, XOR in &xid and &__bootp_find_local_ip thus making it more specific to the specific build of the executable. I know that CYGPKG_CRC comes from the template, but that doesn't mean the code is included - only if it's used. Admittedly we should also add on explicit CDL dependencies where it's already been used - it's rather lax that that hasn't been done for CYGBLD_BUILD_REDBOOT_WITH_CKSUM and CYGSEM_REDBOOT_FIS_CRC_CHECK. Formally, I'll mark this patch as not having passed review, even though the changes are minor. Also please don't set the assignment flag until we hear from the FSF. I still haven't had a reply from them. I have no doubt you filled in the assignment, but we've had things before when a company has made changes to the assignment text, or changes to the copyright disclaimer, or has omitted the disclaimer entirely in what they sent. So I want to allow for the possibility that something goes wrong. The copyright is only actually assigned once the FSF executes the assignment on their side too, so until then, the copyright still rests with you, even if you've signed. Jifl -- 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.
next prev parent reply other threads:[~2011-03-24 17:37 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-03-21 14:50 [Bug 1001177] New: " bugzilla-daemon 2011-03-24 14:35 ` [Bug 1001177] " bugzilla-daemon 2011-03-24 17:37 ` bugzilla-daemon [this message] 2011-03-24 17:37 ` bugzilla-daemon 2011-03-24 17:37 ` bugzilla-daemon 2011-03-24 18:12 ` bugzilla-daemon 2011-03-24 19:33 ` bugzilla-daemon 2011-03-24 19:36 ` bugzilla-daemon 2011-03-25 16:20 ` bugzilla-daemon 2011-03-26 2:17 ` bugzilla-daemon 2011-03-26 4:21 ` bugzilla-daemon 2011-03-26 18:01 ` bugzilla-daemon 2011-06-08 16:13 ` bugzilla-daemon 2012-03-02 21:10 ` bugzilla-daemon 2012-03-03 3:44 ` bugzilla-daemon 2012-03-03 3:44 ` bugzilla-daemon 2012-03-06 16:47 ` bugzilla-daemon 2011-03-21 14:50 [Bug 1001177] New: " bugzilla-daemon 2011-03-24 14:36 ` [Bug 1001177] " bugzilla-daemon 2011-03-24 17:37 ` bugzilla-daemon 2011-03-24 17:37 ` bugzilla-daemon 2011-03-24 17:37 ` bugzilla-daemon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20110324173653.B77252F7800A@mail.ecoscentric.com \ --to=bugzilla-daemon@bugs.ecos.sourceware.org \ --cc=ecos-bugs@ecos.sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).