From ss at comp.lancs.ac.uk Thu Sep 1 02:50:56 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Thu, 01 Sep 2011 10:50:56 +0100 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E5E50DE.80802@candelatech.com> References: <4E5CFAA3.6000603@comp.lancs.ac.uk> <1314791703-23416-1-git-send-email-ss@comp.lancs.ac.uk> <4E5E50DE.80802@candelatech.com> Message-ID: <4E5F5580.5080401@comp.lancs.ac.uk> On 31/08/11 16:18, Ben Greear wrote: > On 08/31/2011 04:55 AM, ss at comp.lancs.ac.uk wrote: >> diff --git a/xorp/libxipc/SConscript b/xorp/libxipc/SConscript >> index 104bc8e..e7cf973 100644 >> --- a/xorp/libxipc/SConscript >> +++ b/xorp/libxipc/SConscript >> @@ -87,6 +87,7 @@ libxipc_sources = [ >> 'xrl_std_router.cc', >> 'xrl_tokens.cc', >> 'xuid.cc', # only for udp (and fea tcpudp mgr) >> + 'fp64serial.c', >> ] > > It should be a .cc file I think. It was intentional. It appeared to be the easiest way to access certain C99 features portably - they don't all appear automatically in C++ (so I discovered). I don't think finding a strictly C++ solution buys you very much for the effort - it's just two ordinary functions that don't use any C++ features. Is it vital to be C++ for other reasons? I'll put the effort in if so. >> +// $XORP: xorp/libxipc/xrl_atom.hh,v 1.23 2008/10/30 20:49:07 pavlin >> Exp $ > > Please just remove the previous line. Ew - will do. > In general, I'm amazed at how much code this took, but from skimming > through > it quickly, I didn't notice any issues. I guess floating-point > serialization > is just a pain in the arse to do right! It's a matter of recognizing that double has many implementation-defined characteristics, so it can't just be shifted and masked like an integer. frexp, ldexp, etc allow it to be expressed more portably, and shouldn't be too costly on most systems. In practice, you could probably just alias a double as uint64_t on most systems, but I don't think there's a robust, portable, general way to detect this at compile time. Of course, you could still detect specific environments, and conditionally compile in a trivially cheap implementation, but at least you have the portable code as a back-up for everything else. Cheers! From greearb at candelatech.com Thu Sep 1 08:31:35 2011 From: greearb at candelatech.com (Ben Greear) Date: Thu, 01 Sep 2011 08:31:35 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E5F5580.5080401@comp.lancs.ac.uk> References: <4E5CFAA3.6000603@comp.lancs.ac.uk> <1314791703-23416-1-git-send-email-ss@comp.lancs.ac.uk> <4E5E50DE.80802@candelatech.com> <4E5F5580.5080401@comp.lancs.ac.uk> Message-ID: <4E5FA557.7000103@candelatech.com> On 09/01/2011 02:50 AM, Steven Simpson wrote: > On 31/08/11 16:18, Ben Greear wrote: >> On 08/31/2011 04:55 AM, ss at comp.lancs.ac.uk wrote: >>> diff --git a/xorp/libxipc/SConscript b/xorp/libxipc/SConscript >>> index 104bc8e..e7cf973 100644 >>> --- a/xorp/libxipc/SConscript >>> +++ b/xorp/libxipc/SConscript >>> @@ -87,6 +87,7 @@ libxipc_sources = [ >>> 'xrl_std_router.cc', >>> 'xrl_tokens.cc', >>> 'xuid.cc', # only for udp (and fea tcpudp mgr) >>> + 'fp64serial.c', >>> ] >> >> It should be a .cc file I think. > > It was intentional. It appeared to be the easiest way to access certain > C99 features portably - they don't all appear automatically in C++ (so I > discovered). I don't think finding a strictly C++ solution buys you > very much for the effort - it's just two ordinary functions that don't > use any C++ features. Is it vital to be C++ for other reasons? I'll > put the effort in if so. It's not vital..if there's a big reason for it to be C instead of C++, that's OK by me. Have you tried compiling this on older systems..say perhaps Fedora Core 5? Some folks use old compilers and such for embedded systems and cannot easily upgrade to later code... >> In general, I'm amazed at how much code this took, but from skimming >> through >> it quickly, I didn't notice any issues. I guess floating-point >> serialization >> is just a pain in the arse to do right! > > It's a matter of recognizing that double has many implementation-defined > characteristics, so it can't just be shifted and masked like an > integer. frexp, ldexp, etc allow it to be expressed more portably, and > shouldn't be too costly on most systems. Could you just convert it to a string and pass it that way? But, as long as your stuff compiles and works on stuff at least as old as Fedora 5, then that's good enough for me. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Fri Sep 2 10:57:36 2011 From: noreply at github.com (noreply at github.com) Date: Fri, 2 Sep 2011 10:57:36 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] e1467f: fea: Add some debugging for windows adapters. Message-ID: <20110902175736.F0852426C5@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: e1467fd6edcef34bf18fa68a78a908b5ee4831f9 https://github.com/greearb/xorp.ct/commit/e1467fd6edcef34bf18fa68a78a908b5ee4831f9 Author: Ben Greear Date: 2011-09-02 (Fri, 02 Sep 2011) Changed paths: M xorp/fea/data_plane/ifconfig/ifconfig_get_iphelper.cc Log Message: ----------- fea: Add some debugging for windows adapters. From noreply at github.com Fri Sep 2 16:28:10 2011 From: noreply at github.com (noreply at github.com) Date: Fri, 2 Sep 2011 16:28:10 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] facf72: xrl/fea: Add some debugging logic. Message-ID: <20110902232810.D136942629@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: facf723badbce8866dff9d44ee89b75f4387f944 https://github.com/greearb/xorp.ct/commit/facf723badbce8866dff9d44ee89b75f4387f944 Author: Ben Greear Date: 2011-09-02 (Fri, 02 Sep 2011) Changed paths: M README M xorp/fea/data_plane/ifconfig/ifconfig_get_iphelper.cc M xorp/libxipc/finder_tcp.cc M xorp/libxipc/sockutil.cc M xorp/libxipc/xrl.hh M xorp/libxipc/xrl_dispatcher.cc M xorp/libxipc/xrl_pf_stcp.cc M xorp/libxipc/xrl_pf_stcp.hh M xorp/libxorp/asyncio.cc M xorp/libxorp/buffered_asyncio.cc M xorp/libxorp/eventloop.cc M xorp/libxorp/eventloop.hh M xorp/libxorp/selector.cc M xorp/libxorp/selector.hh M xorp/libxorp/win_dispatcher.cc M xorp/libxorp/xorp_osdep_begin.h M xorp/libxorp/xorpfd.hh M xorp/ospf/ospf.hh M xorp/ospf/peer.cc M xorp/ospf/xrl_io.cc Log Message: ----------- xrl/fea: Add some debugging logic. Made an initial start at letting windows use selector logic, but not sure that will ever actually work. It stays with the win_dispatcher logic for now. Signed-off-by: Ben Greear From noreply at github.com Tue Sep 6 17:09:34 2011 From: noreply at github.com (noreply at github.com) Date: Tue, 6 Sep 2011 17:09:34 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] a8a674: xrl: Read up to 100 at a time instead of two. Message-ID: <20110907000934.3B65F42695@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: a8a67454e20116462e246d9fca3c35475d5ca746 https://github.com/greearb/xorp.ct/commit/a8a67454e20116462e246d9fca3c35475d5ca746 Author: Ben Greear Date: 2011-09-06 (Tue, 06 Sep 2011) Changed paths: M xorp/libcomm/comm_api.h M xorp/libxipc/xrl_args.cc M xorp/libxipc/xrl_args.hh M xorp/libxipc/xrl_pf_stcp.cc M xorp/libxipc/xrl_router.cc Log Message: ----------- xrl: Read up to 100 at a time instead of two. Clean up some white-space & comments. Listen queue set to 50 instead of 5. Might still be a problem with xrl processing...not sure if code is smart enough to immediately start processing backlog if there were more than 100, but 100 should be better than 2, at least. Signed-off-by: Ben Greear Commit: 886bacb32343e15965d0a9998514637e0c79b78f https://github.com/greearb/xorp.ct/commit/886bacb32343e15965d0a9998514637e0c79b78f Author: Ben Greear Date: 2011-09-06 (Tue, 06 Sep 2011) Changed paths: M xorp/libxipc/xrl_pf_stcp.cc M xorp/libxipc/xrl_pf_stcp.hh M xorp/libxorp/asyncio.cc M xorp/libxorp/asyncio.hh Log Message: ----------- xrl: Remove dead code, some windows xmit, xrl batching. This code was #if 0 and/or unused in other ways. Signed-off-by: Ben Greear Commit: 5337a2c915a5b74e6d4266f78322bd2862d721b9 https://github.com/greearb/xorp.ct/commit/5337a2c915a5b74e6d4266f78322bd2862d721b9 Author: Ben Greear Date: 2011-09-06 (Tue, 06 Sep 2011) Changed paths: M xorp/libxorp/asyncio.cc Log Message: ----------- xrl: Remove more dead code. Signed-off-by: Ben Greear Commit: 8a5068be1a4e06bcc5a373c0eeccf860301bd1d4 https://github.com/greearb/xorp.ct/commit/8a5068be1a4e06bcc5a373c0eeccf860301bd1d4 Author: Ben Greear Date: 2011-09-06 (Tue, 06 Sep 2011) Changed paths: M xorp/libxipc/xrl_pf_stcp.cc Log Message: ----------- xrl: Propagate socket write failures on windows. Signed-off-by: Ben Greear Commit: bcd90c855949d4cb70181b0178dbc97f7f0a9314 https://github.com/greearb/xorp.ct/commit/bcd90c855949d4cb70181b0178dbc97f7f0a9314 Author: Ben Greear Date: 2011-09-06 (Tue, 06 Sep 2011) Changed paths: M xorp/libxorp/asyncio.cc Log Message: ----------- asyncio: Add some debugging logic for asyncio. Signed-off-by: Ben Greear Commit: 87358e2e437ffaf3908f08e5c8464fbfe21678d7 https://github.com/greearb/xorp.ct/commit/87358e2e437ffaf3908f08e5c8464fbfe21678d7 Author: Ben Greear Date: 2011-09-06 (Tue, 06 Sep 2011) Changed paths: M xorp/SConstruct M xorp/bgp/SConscript M xorp/bgp/harness/SConscript M xorp/bgp/tools/SConscript M xorp/cli/SConscript M xorp/cli/tools/SConscript M xorp/contrib/olsr/SConscript M xorp/contrib/olsr/tools/SConscript M xorp/fea/SConscript M xorp/fea/tools/SConscript M xorp/fib2mrib/SConscript M xorp/libxipc/SConscript M xorp/libxorp/clock.cc M xorp/libxorp/clock.hh M xorp/libxorp/timer.cc M xorp/mld6igmp/SConscript M xorp/ospf/SConscript M xorp/ospf/tools/SConscript M xorp/pim/SConscript M xorp/policy/SConscript M xorp/rib/SConscript M xorp/rib/tools/SConscript M xorp/rip/SConscript M xorp/rip/tools/SConscript M xorp/rtrmgr/SConscript M xorp/static_routes/SConscript M xorp/vrrp/SConscript Log Message: ----------- time: Support higher-resolution time-stamps on windows. By using the timePeriodBegin and timePeriodEnd logic. Makes logs more useful in nothing else. Signed-off-by: Ben Greear Commit: c258fd4b127af71448e567b143b0e6fe0c54e1b4 https://github.com/greearb/xorp.ct/commit/c258fd4b127af71448e567b143b0e6fe0c54e1b4 Author: Ben Greear Date: 2011-09-06 (Tue, 06 Sep 2011) Changed paths: M xorp/libxorp/eventloop.cc M xorp/libxorp/win_dispatcher.cc Log Message: ----------- eventloop: Clean up event loop slightly, cap wait on MS. Was seeing hangs on windows..seems to work better if I cap it to max of 100ms of sleeps. Looks like waitForMultipleObjects can signal more than one is ready (thank goodness), so need to change code to use that information...that might be root cause of the slowness. Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/facf723...c258fd4 From greearb at candelatech.com Tue Sep 6 22:05:03 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 06 Sep 2011 22:05:03 -0700 Subject: [Xorp-hackers] question on some windows programming API Message-ID: <4E66FB7F.3070200@candelatech.com> Just in case someone has some better experience with this... In the win_dispatcher.cc, it is calling WaitForMultipleObjects. The existing code that works OK just uses the retval - WAIT_OBJECT_0 object. But, if I read the MS help pages right, that is really just the first entry that may have events pending, and one should probably check the rest to make sure we are not starving higher objects. I tried changing the processing as below, but now xorp_fea stops with no useful errors. If anyone has any insight on how to properly use WaitForMultipleObjects, I'm interested! Thanks, Ben void WinDispatcher::wait_and_dispatch(int ms) { DWORD retval; // // Wait or sleep. Do not enter a state where APCs may be called; // they are not compatible with the XORP event loop. // If we need to fix the sleep quantum to deal with polled objects, do so. // if ((!_polled_pipes.empty()) && (ms > POLLED_INTERVAL_MS || ms < 0)) ms = POLLED_INTERVAL_MS; //XLOG_WARNING("win-dispatcher, ms: %i handles-size: %i", // ms, (int)(_handles.size())); // Seeing weird slownesses on windows..going to cap the timeout and see // if that helps. if (ms > 100) ms = 100; else if (ms < 0) ms = 0; if (_handles.empty()) { // We probably don't want to sleep forever with no pending waits, // as Win32 doesn't have the same concept of signals as UNIX does. XLOG_ASSERT(ms != -1); Sleep(ms); retval = WAIT_TIMEOUT; } else { retval = WaitForMultipleObjects(_handles.size(), &_handles[0], FALSE, ms); } //XLOG_WARNING("Done waiting, retval: %i", retval); _clock->advance_time(); // Reads need to be handled first because they may come from // dying processes picked up by the handle poll. if (!_polled_pipes.empty()) dispatch_pipe_reads(); // The order of the if clauses here is important. if (retval == WAIT_FAILED) { DWORD lasterr = GetLastError(); if (lasterr == ERROR_INVALID_HANDLE && !_handles.empty()) { callback_bad_handle(); } else { // Programming error. XLOG_FATAL("WaitForMultipleObjects(%d,%p,%d,%d) failed " "with the error code %lu (%s). " "Please report this error to the XORP core team.", _handles.empty() ? 0 : _handles.size(), _handles.empty() ? NULL : &_handles[0], FALSE, ms, lasterr, win_strerror(lasterr)); } } else if (retval == WAIT_TIMEOUT) { // The timeout period elapsed. This is normal. Fall through. } else if (retval <= (WAIT_OBJECT_0 + _handles.size() - 1)) { // // An object in _handles was signalled. Dispatch its callback. // Check if it's an event associated with a socket first. // This is really just the first one, so try all the rest as well. // for (int i = retval - WAIT_OBJECT_0; i<(_handles.size() - WAIT_OBJECT_0); i++) { HANDLE eh = _handles[i]; XLOG_INFO("retval: %i handle: %i i: %i _handles.size(): %i\n", (int)(retval), (int)(eh), i, _handles.size()); EventSocketMap::iterator qq = _event_socket_map.find(eh); if (qq != _event_socket_map.end()) { dispatch_sockevent(qq->first, qq->second); } else { // It's not an Event, so it must be something else. // Figure out what it is, and deal with it. XorpFd efd(eh); XLOG_ASSERT(efd.type() != XorpFd::FDTYPE_SOCKET); XLOG_ASSERT(efd.type() != XorpFd::FDTYPE_PIPE); IoEventType evtype = (efd.type() == XorpFd::FDTYPE_CONSOLE) ? IOT_READ : IOT_EXCEPTION; IoEventMap::iterator jj = _callback_map.find(IoEventTuple(efd, evtype)); if (jj != _callback_map.end()) { XLOG_INFO("event: evtype: %i efd: %s\n", (int)(evtype), cstring(efd)); jj->second->dispatch(efd, evtype); XLOG_INFO("Done with event dispatch..\n"); } else { XLOG_ERROR("no callback for object %s", efd.str().c_str()); } } }// for all possible events. XLOG_INFO("Done handling events...\n"); } else { // Programming error. XLOG_FATAL("WaitForMultipleObjects(%d,%p,%d,%d) returned an " "unhandled return value %lu. " "Please report this error to the XORP core team.", _handles.empty() ? 0 : _handles.size(), _handles.empty() ? NULL : &_handles[0], FALSE, ms, retval); } } -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ss at comp.lancs.ac.uk Wed Sep 7 03:11:57 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Wed, 07 Sep 2011 11:11:57 +0100 Subject: [Xorp-hackers] question on some windows programming API In-Reply-To: <4E66FB7F.3070200@candelatech.com> References: <4E66FB7F.3070200@candelatech.com> Message-ID: <4E67436D.6080702@comp.lancs.ac.uk> On 07/09/11 06:05, Ben Greear wrote: > In the win_dispatcher.cc, it is calling WaitForMultipleObjects. The > existing code that works OK just uses the retval - WAIT_OBJECT_0 object. > But, if I read the MS help pages right, that is really just the first > entry that may have events pending, and one should probably check the > rest to make sure we are not starving higher objects. I have a portable event reactor which I last looked at some time ago, so this is all IIRC. For Windows, I used WaitFor* functions, and I think I managed to get some successful behaviour out of it, for a moderate task (a TCP proxy). However, I probably relied on wine, or simply passing the tests over to someone routinely using Windows, so it can't have been as rigorous as the testing and practical use it's had on Linux. Looking at the code now, it seems I've called WaitForMultipleObjects several times, with almost the same array. The return code evidently identifies one of the entries that has fired (the first one), but I needed to ensure that all the other ones were queued before actually executing any of them, so they could be executed according to user-defined priorities. So, I believe the code removes the identified event from the array, and re-calls WaitFor* to pick out the next one. Re-calls always use a zero timeout, since an event has already fired. IOW, having detected one event, WaitFor* is used repeatedly to enumerate all the others, so you get the same effect as a single select() with scan over the fd_sets. If you'll excuse the self-signed cert, you should be able to see the code here: Cheers, Steven From greearb at candelatech.com Wed Sep 7 09:08:48 2011 From: greearb at candelatech.com (Ben Greear) Date: Wed, 07 Sep 2011 09:08:48 -0700 Subject: [Xorp-hackers] question on some windows programming API In-Reply-To: <4E67436D.6080702@comp.lancs.ac.uk> References: <4E66FB7F.3070200@candelatech.com> <4E67436D.6080702@comp.lancs.ac.uk> Message-ID: <4E679710.8090303@candelatech.com> On 09/07/2011 03:11 AM, Steven Simpson wrote: > On 07/09/11 06:05, Ben Greear wrote: >> In the win_dispatcher.cc, it is calling WaitForMultipleObjects. The >> existing code that works OK just uses the retval - WAIT_OBJECT_0 object. >> But, if I read the MS help pages right, that is really just the first >> entry that may have events pending, and one should probably check the >> rest to make sure we are not starving higher objects. > > I have a portable event reactor which I last looked at some time ago, so > this is all IIRC. For Windows, I used WaitFor* functions, and I think I > managed to get some successful behaviour out of it, for a moderate task > (a TCP proxy). However, I probably relied on wine, or simply passing > the tests over to someone routinely using Windows, so it can't have been > as rigorous as the testing and practical use it's had on Linux. > > Looking at the code now, it seems I've called WaitForMultipleObjects > several times, with almost the same array. The return code evidently > identifies one of the entries that has fired (the first one), but I > needed to ensure that all the other ones were queued before actually > executing any of them, so they could be executed according to > user-defined priorities. So, I believe the code removes the identified > event from the array, and re-calls WaitFor* to pick out the next one. > Re-calls always use a zero timeout, since an event has already fired. That seems like a neat hack, but it's hard to believe the windows API is so inefficient as to require all of those system calls! Still, that's better than missing events or whatever is crashing with my current attempt. I'll give that a try... It's also possible to use select in windows, but it only works on sockets I think...so not sure I could add console (stdin?) to make xorpsh work properly, so I haven't tried to enable that yet... Thanks for the suggestions. > IOW, having detected one event, WaitFor* is used repeatedly to enumerate > all the others, so you get the same effect as a single select() with > scan over the fd_sets. > > If you'll excuse the self-signed cert, you should be able to see the > code here: > > Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Wed Sep 7 14:49:59 2011 From: noreply at github.com (noreply at github.com) Date: Wed, 7 Sep 2011 14:49:59 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 794ab6: event-loop: Remove dead code, make sure win-dispa... Message-ID: <20110907214959.D7288426F4@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 794ab62774ae03baa93d1914dadc9bd313d5bb90 https://github.com/greearb/xorp.ct/commit/794ab62774ae03baa93d1914dadc9bd313d5bb90 Author: Ben Greear Date: 2011-09-07 (Wed, 07 Sep 2011) Changed paths: M xorp/libxorp/eventloop.cc M xorp/libxorp/eventloop.hh M xorp/libxorp/timeval.cc M xorp/libxorp/timeval.hh M xorp/libxorp/win_dispatcher.cc M xorp/libxorp/win_dispatcher.hh Log Message: ----------- event-loop: Remove dead code, make sure win-dispatcher handles all events. Remove aggressiveness and some #if 0 priority code from event loop. Neither is a good idea in my mind...the aggressiveness was playing dangerous tricks just to save a gettimeofday call, and the prioritization could cause priority inversion locks as implemented. Update win-dispatcher to make sure to process all descriptors that have events on them each time we do a wait-and-dispatch. This should increase fairness on heavily loaded systems. Add debug logic to eventloop to print out cases where things take longer than expected. Need more debugging in this area to find out exactly what is causing the slowdowns... Signed-off-by: Ben Greear Commit: b167b0d1e600f9ad440b2b5cdf2818a7a65bc4fc https://github.com/greearb/xorp.ct/commit/b167b0d1e600f9ad440b2b5cdf2818a7a65bc4fc Author: Ben Greear Date: 2011-09-07 (Wed, 07 Sep 2011) Changed paths: M xorp/libxorp/debug.h M xorp/libxorp/eventloop.cc M xorp/libxorp/eventloop.hh M xorp/libxorp/win_dispatcher.cc Log Message: ----------- event-loop: Make environ-trace object generic, warn of slow win-dispatcher callbacks. Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/c258fd4...b167b0d From ss at comp.lancs.ac.uk Thu Sep 8 02:55:57 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Thu, 08 Sep 2011 10:55:57 +0100 Subject: [Xorp-hackers] question on some windows programming API In-Reply-To: <4E679710.8090303@candelatech.com> References: <4E66FB7F.3070200@candelatech.com> <4E67436D.6080702@comp.lancs.ac.uk> <4E679710.8090303@candelatech.com> Message-ID: <4E68912D.2080700@comp.lancs.ac.uk> On 07/09/11 17:08, Ben Greear wrote: > On 09/07/2011 03:11 AM, Steven Simpson wrote: >> So, I believe the code removes the identified >> event from the array, and re-calls WaitFor* to pick out the next one. >> Re-calls always use a zero timeout, since an event has already fired. > > That seems like a neat hack, but it's hard to believe the windows API > is so inefficient as to require all of those system calls! Yeah, though it might be as few as: * one call (with non-zero timeout) that identifies one event, * the second one (with zero timeout) that reports no more events. ...regardless of the number of handles submitted. > It's also possible to use select in windows, but it only works on > sockets I think... That was my understanding too, hence I went looking into WaitFor*. > so not sure I could add console (stdin?) to make > xorpsh work properly, so I haven't tried to enable that yet... It ought to be possible to get the HANDLE for stdin. This looks promising: Cheers, Steven -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110908/f2ff05c7/attachment.html From ss at comp.lancs.ac.uk Thu Sep 8 07:35:11 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Thu, 08 Sep 2011 15:35:11 +0100 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E5FA557.7000103@candelatech.com> References: <4E5CFAA3.6000603@comp.lancs.ac.uk> <1314791703-23416-1-git-send-email-ss@comp.lancs.ac.uk> <4E5E50DE.80802@candelatech.com> <4E5F5580.5080401@comp.lancs.ac.uk> <4E5FA557.7000103@candelatech.com> Message-ID: <4E68D29F.9090107@comp.lancs.ac.uk> On 01/09/11 16:31, Ben Greear wrote: > On 09/01/2011 02:50 AM, Steven Simpson wrote: >> On 31/08/11 16:18, Ben Greear wrote: > >>> In general, I'm amazed at how much code this took, but from skimming >>> through >>> it quickly, I didn't notice any issues. I guess floating-point >>> serialization >>> is just a pain in the arse to do right! >> >> It's a matter of recognizing that double has many implementation-defined >> characteristics, so it can't just be shifted and masked like an >> integer. frexp, ldexp, etc allow it to be expressed more portably, and >> shouldn't be too costly on most systems. > > Could you just convert it to a string and pass it that way? It has been suggested, but advice around the web often seems to point to frexp etc, and you get a fixed-size representation out of it. > But, as long as your stuff compiles and works on stuff at least as > old as Fedora 5, then that's good enough for me. I seem to be hitting one brick wall after another, just trying to set up a fresh FC5 system that XORP can run on. However, I did try just compiling fp64serial.c (with fp64serial.h and fp64.h), with gcc -std=c99, and produced no errors. It's not so surprising - the features I'm after are basically a few macros that ought to have been in place for some time when FC5 came out. Cheers! From greearb at candelatech.com Thu Sep 8 09:09:36 2011 From: greearb at candelatech.com (Ben Greear) Date: Thu, 08 Sep 2011 09:09:36 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E68D29F.9090107@comp.lancs.ac.uk> References: <4E5CFAA3.6000603@comp.lancs.ac.uk> <1314791703-23416-1-git-send-email-ss@comp.lancs.ac.uk> <4E5E50DE.80802@candelatech.com> <4E5F5580.5080401@comp.lancs.ac.uk> <4E5FA557.7000103@candelatech.com> <4E68D29F.9090107@comp.lancs.ac.uk> Message-ID: <4E68E8C0.9070000@candelatech.com> On 09/08/2011 07:35 AM, Steven Simpson wrote: > On 01/09/11 16:31, Ben Greear wrote: >> On 09/01/2011 02:50 AM, Steven Simpson wrote: >>> On 31/08/11 16:18, Ben Greear wrote: >> >>>> In general, I'm amazed at how much code this took, but from skimming >>>> through >>>> it quickly, I didn't notice any issues. I guess floating-point >>>> serialization >>>> is just a pain in the arse to do right! >>> >>> It's a matter of recognizing that double has many implementation-defined >>> characteristics, so it can't just be shifted and masked like an >>> integer. frexp, ldexp, etc allow it to be expressed more portably, and >>> shouldn't be too costly on most systems. >> >> Could you just convert it to a string and pass it that way? > > It has been suggested, but advice around the web often seems to point to > frexp etc, and you get a fixed-size representation out of it. > >> But, as long as your stuff compiles and works on stuff at least as >> old as Fedora 5, then that's good enough for me. > > I seem to be hitting one brick wall after another, just trying to set up > a fresh FC5 system that XORP can run on. > > However, I did try just compiling fp64serial.c (with fp64serial.h and > fp64.h), with gcc -std=c99, and produced no errors. It's not so > surprising - the features I'm after are basically a few macros that > ought to have been in place for some time when FC5 came out. Ok, I have a build machine on FC5 running the automated regression builds and tests, so if it's broken, it will show up quickly. It is a pain to get FC5 working..had to manually upgrade python and/or scons it seems. Please repost your patch when you're happy and I'll apply it. Also, be sure to re-sync against upstream..I've been pushing a bunch of changes lately, some of which touches the xrl code lightly. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Thu Sep 8 10:04:11 2011 From: greearb at candelatech.com (Ben Greear) Date: Thu, 08 Sep 2011 10:04:11 -0700 Subject: [Xorp-hackers] question on some windows programming API In-Reply-To: <4E68912D.2080700@comp.lancs.ac.uk> References: <4E66FB7F.3070200@candelatech.com> <4E67436D.6080702@comp.lancs.ac.uk> <4E679710.8090303@candelatech.com> <4E68912D.2080700@comp.lancs.ac.uk> Message-ID: <4E68F58B.90107@candelatech.com> On 09/08/2011 02:55 AM, Steven Simpson wrote: > On 07/09/11 17:08, Ben Greear wrote: >> On 09/07/2011 03:11 AM, Steven Simpson wrote: >>> So, I believe the code removes the identified >>> event from the array, and re-calls WaitFor* to pick out the next one. >>> Re-calls always use a zero timeout, since an event has already fired. >> >> That seems like a neat hack, but it's hard to believe the windows API >> is so inefficient as to require all of those system calls! > > Yeah, though it might be as few as: > > * one call (with non-zero timeout) that identifies one event, > * the second one (with zero timeout) that reports no more events. > > ...regardless of the number of handles submitted. > >> It's also possible to use select in windows, but it only works on >> sockets I think... > > That was my understanding too, hence I went looking into WaitFor*. > >> so not sure I could add console (stdin?) to make >> xorpsh work properly, so I haven't tried to enable that yet... > > It ought to be possible to get the HANDLE for stdin. This looks promising: > > Every time I look at the event loop and the auto-generated templated callback logic in general I want to re-write everything, so I think I'll stay clear of it for now. Looks like OSPF is a bigger issue anyway...it's taking 4+ seconds to process a single packet (on windows, connecting to a large OSPF network). So, will be digging into that if I can convince a customer to pay for it :) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Thu Sep 8 10:22:43 2011 From: noreply at github.com (noreply at github.com) Date: Thu, 8 Sep 2011 10:22:43 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 7c1306: ospf: Add/update debug tracing. Message-ID: <20110908172243.13BE24275F@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 7c1306ef1d25c1596c18148a156367530ea5a6a1 https://github.com/greearb/xorp.ct/commit/7c1306ef1d25c1596c18148a156367530ea5a6a1 Author: Ben Greear Date: 2011-09-08 (Thu, 08 Sep 2011) Changed paths: M xorp/libxipc/xrl_dispatcher.cc M xorp/ospf/ospf.cc M xorp/ospf/peer.cc M xorp/ospf/peer_manager.cc M xorp/ospf/xrl_io.cc Log Message: ----------- ospf: Add/update debug tracing. Remove some debug_msg logic, add XORP_TRACE instead (run-time enable/disable logging is way more useful). Based on this, it appears ospf takes 4+ seconds to process LSA packets when running on Windows in a large OSPF network. Not sure exactly why yet, but problem appears to be in this method or something it calls: void Neighbour::link_state_update_received(LinkStateUpdatePacket *lsup) Signed-off-by: Ben Greear From noreply at github.com Thu Sep 8 10:45:41 2011 From: noreply at github.com (noreply at github.com) Date: Thu, 8 Sep 2011 10:45:41 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] d75b55: Fix build on 64-bit systems. Message-ID: <20110908174541.0DDC142795@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: d75b55d8d1e4574b5a3539f414b716e0d9bbc069 https://github.com/greearb/xorp.ct/commit/d75b55d8d1e4574b5a3539f414b716e0d9bbc069 Author: Ben Greear Date: 2011-09-08 (Thu, 08 Sep 2011) Changed paths: M xorp/libxipc/xrl_pf_stcp.cc M xorp/libxorp/asyncio.cc M xorp/ospf/peer.cc Log Message: ----------- Fix build on 64-bit systems. Needed to cast some things to integers for logging code. Signed-off-by: Ben Greear From ss at comp.lancs.ac.uk Fri Sep 9 03:30:35 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Fri, 09 Sep 2011 11:30:35 +0100 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E68E8C0.9070000@candelatech.com> References: <4E5CFAA3.6000603@comp.lancs.ac.uk> <1314791703-23416-1-git-send-email-ss@comp.lancs.ac.uk> <4E5E50DE.80802@candelatech.com> <4E5F5580.5080401@comp.lancs.ac.uk> <4E5FA557.7000103@candelatech.com> <4E68D29F.9090107@comp.lancs.ac.uk> <4E68E8C0.9070000@candelatech.com> Message-ID: <4E69EACB.9000802@comp.lancs.ac.uk> Hi Ben, On 08/09/11 17:09, Ben Greear wrote: > Also, be sure > to re-sync against upstream..I've been pushing a bunch of changes > lately, some > of which touches the xrl code lightly. Having just pulled, enable_tests=True isn't working, as xorp/libxipc/tests/test_stcp.cc is using the old XrlPFSTCPSender constructor, i.e. without the leading 'string name' argument. Cheers, Steven From greearb at candelatech.com Fri Sep 9 09:04:42 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 09 Sep 2011 09:04:42 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E69EACB.9000802@comp.lancs.ac.uk> References: <4E5CFAA3.6000603@comp.lancs.ac.uk> <1314791703-23416-1-git-send-email-ss@comp.lancs.ac.uk> <4E5E50DE.80802@candelatech.com> <4E5F5580.5080401@comp.lancs.ac.uk> <4E5FA557.7000103@candelatech.com> <4E68D29F.9090107@comp.lancs.ac.uk> <4E68E8C0.9070000@candelatech.com> <4E69EACB.9000802@comp.lancs.ac.uk> Message-ID: <4E6A391A.6060609@candelatech.com> On 09/09/2011 03:30 AM, Steven Simpson wrote: > Hi Ben, > > On 08/09/11 17:09, Ben Greear wrote: >> Also, be sure >> to re-sync against upstream..I've been pushing a bunch of changes >> lately, some >> of which touches the xrl code lightly. > > Having just pulled, enable_tests=True isn't working, as > xorp/libxipc/tests/test_stcp.cc is using the old XrlPFSTCPSender > constructor, i.e. without the leading 'string name' argument. I'll try to get that fixed today if someone doesn't beat me to it. Thanks, Ben > > Cheers, > > Steven > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Fri Sep 9 15:28:29 2011 From: noreply at github.com (noreply at github.com) Date: Fri, 9 Sep 2011 15:28:29 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 02ee14: Fix enable_tests=True build. Message-ID: <20110909222829.9DDF042743@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 02ee1423ebde457d27093d5fc3adbb7b19ca1de4 https://github.com/greearb/xorp.ct/commit/02ee1423ebde457d27093d5fc3adbb7b19ca1de4 Author: Ben Greear Date: 2011-09-09 (Fri, 09 Sep 2011) Changed paths: M xorp/libxipc/tests/test_stcp.cc M xorp/libxorp/tests/test_ipv4net.cc M xorp/libxorp/tests/test_ipvxnet.cc Log Message: ----------- Fix enable_tests=True build. A few regressions I added recently, and some un-used variables that cause complaints on Fedora 15. Signed-off-by: Ben Greear From greearb at candelatech.com Fri Sep 9 15:29:51 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 09 Sep 2011 15:29:51 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E69EACB.9000802@comp.lancs.ac.uk> References: <4E5CFAA3.6000603@comp.lancs.ac.uk> <1314791703-23416-1-git-send-email-ss@comp.lancs.ac.uk> <4E5E50DE.80802@candelatech.com> <4E5F5580.5080401@comp.lancs.ac.uk> <4E5FA557.7000103@candelatech.com> <4E68D29F.9090107@comp.lancs.ac.uk> <4E68E8C0.9070000@candelatech.com> <4E69EACB.9000802@comp.lancs.ac.uk> Message-ID: <4E6A935F.2000407@candelatech.com> On 09/09/2011 03:30 AM, Steven Simpson wrote: > Hi Ben, > > On 08/09/11 17:09, Ben Greear wrote: >> Also, be sure >> to re-sync against upstream..I've been pushing a bunch of changes >> lately, some >> of which touches the xrl code lightly. > > Having just pulled, enable_tests=True isn't working, as > xorp/libxipc/tests/test_stcp.cc is using the old XrlPFSTCPSender > constructor, i.e. without the leading 'string name' argument. Should be fixed now. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ss at comp.lancs.ac.uk Mon Sep 12 05:10:10 2011 From: ss at comp.lancs.ac.uk (ss at comp.lancs.ac.uk) Date: Mon, 12 Sep 2011 13:10:10 +0100 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E68E8C0.9070000@candelatech.com> References: <4E68E8C0.9070000@candelatech.com> Message-ID: <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> From: Steven Simpson * New atom type fp64 * selects alias fp64_t for most compatible native C type. Native type's characteristics are echoed with corresponding macros (analogous to DBL_MIN, etc). * (de)serializes fp64_t into uint_fast64_t. * New methods for fp64_t added on XrlAtom and XrlArgs. * Added fp64 to xif types, mapping to fp64_t in C++ and double for Thrift. * Extended atom and args tests to include fp64_t. * Added fp64_t serialization test. (It always succeeds for now, but might be useful for diagnostics.) * Added method to test XIF to demonstrate fp64 type. Signed-off-by: Steven Simpson --- xorp/libxipc/SConscript | 1 + xorp/libxipc/fp64.h | 196 ++++++++++++++++++++++++++++++ xorp/libxipc/fp64serial.c | 184 ++++++++++++++++++++++++++++ xorp/libxipc/fp64serial.h | 38 ++++++ xorp/libxipc/tests/SConscript | 1 + xorp/libxipc/tests/test_fp64.cc | 224 +++++++++++++++++++++++++++++++++++ xorp/libxipc/tests/test_xrl_args.cc | 5 +- xorp/libxipc/tests/test_xrl_atom.cc | 4 + xorp/libxipc/xrl_args.cc | 28 +++++ xorp/libxipc/xrl_args.hh | 24 ++++ xorp/libxipc/xrl_atom.cc | 55 +++++++++- xorp/libxipc/xrl_atom.hh | 19 +++- xorp/rtrmgr/xorp_client.cc | 1 + xorp/xrl/interfaces/test.xif | 5 + xorp/xrl/scripts/Xif/xiftypes.py | 3 +- 15 files changed, 784 insertions(+), 4 deletions(-) create mode 100644 xorp/libxipc/fp64.h create mode 100644 xorp/libxipc/fp64serial.c create mode 100644 xorp/libxipc/fp64serial.h create mode 100644 xorp/libxipc/tests/test_fp64.cc diff --git a/xorp/libxipc/SConscript b/xorp/libxipc/SConscript index ec0619b..95d7f4b 100644 --- a/xorp/libxipc/SConscript +++ b/xorp/libxipc/SConscript @@ -87,6 +87,7 @@ libxipc_sources = [ 'xrl_std_router.cc', 'xrl_tokens.cc', 'xuid.cc', # only for udp (and fea tcpudp mgr) + 'fp64serial.c', ] # deal with shared objects diff --git a/xorp/libxipc/fp64.h b/xorp/libxipc/fp64.h new file mode 100644 index 0000000..9ce74a9 --- /dev/null +++ b/xorp/libxipc/fp64.h @@ -0,0 +1,196 @@ +// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- +// vim:set sts=4 ts=8: + +// Copyright (c) 2001-2011 XORP, Inc and Others +// +// This program is free software; you can redistribute it and/or modify +// it under the terms of the GNU Lesser General Public License, Version +// 2.1, June 1999 as published by the Free Software Foundation. +// Redistribution and/or modification of this program under the terms of +// any other version of the GNU Lesser General Public License is not +// permitted. +// +// This program is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, +// see the GNU Lesser General Public License, Version 2.1, a copy of +// which can be found in the XORP LICENSE.lgpl file. +// +// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; +// http://xorp.net + +#ifndef __LIBXIPC_FP64_H__ +#define __LIBXIPC_FP64_H__ + +#include +#include + +/* This header chooses a native real type (float, double, long double) + which best matches the IEEE754 binary64 capabilities. */ + + + +/* These are the target characteristics of various IEEE754 types, + expressed in terms that make them comparable to the native real + types. */ + +/* TODO: We only need the 64-bit details; the others could be in their + own header. */ + +#define XORP_IEEE754_BIN16_MANT_DIG 11 +#define XORP_IEEE754_BIN16_MAX_EXP 16 +#define XORP_IEEE754_BIN16_MIN_EXP -13 + +#define XORP_IEEE754_BIN32_MANT_DIG 24 +#define XORP_IEEE754_BIN32_MAX_EXP 128 +#define XORP_IEEE754_BIN32_MIN_EXP -125 + +#define XORP_IEEE754_BIN64_MANT_DIG 53 +#define XORP_IEEE754_BIN64_MAX_EXP 1024 +#define XORP_IEEE754_BIN64_MIN_EXP -1021 + +#define XORP_IEEE754_BIN128_MANT_DIG 113 +#define XORP_IEEE754_BIN128_MAX_EXP 16384 +#define XORP_IEEE754_BIN128_MIN_EXP -16381 + + +/* TODO: These ratios and test macros are not binary64-specific. If + other types were to be supported, these macros should be factored + out. */ + +/* These are 100000*log2(FLT_RADIX) for various possible FLT_RADIX + values. In comparing the capabilities of float, double and long + double with binary64, we need to account for the slim possibility + that our native base is not 2, while binary64's base is 2. */ + +#define XORP_IEEE754_RADIX_RATIO_2 1000000 +#define XORP_IEEE754_RADIX_RATIO_3 1584963 +#define XORP_IEEE754_RADIX_RATIO_4 2000000 +#define XORP_IEEE754_RADIX_RATIO_5 2321928 +#define XORP_IEEE754_RADIX_RATIO_6 2584963 +#define XORP_IEEE754_RADIX_RATIO_7 2807354 +#define XORP_IEEE754_RADIX_RATIO_8 3000000 +#define XORP_IEEE754_RADIX_RATIO_9 3169925 +#define XORP_IEEE754_RADIX_RATIO_10 3321928 + +#define XORP_IEEE754_RADIX_RATIO_N(B) (XORP_IEEE754_RADIX_RATIO_ ## B) +#define XORP_IEEE754_RADIX_RATIO(B) (XORP_IEEE754_RADIX_RATIO_N(B)) + + +/* These preprocessor-safe macros test various native types' + characteristics against IEEE754 types'. */ + +#define XORP_IEEE754_TEST_MANT_DIG(T,W) \ + ( T ## _MANT_DIG * XORP_IEEE754_RADIX_RATIO(FLT_RADIX) >= \ + XORP_IEEE754_BIN ## W ## _MANT_DIG * XORP_IEEE754_RADIX_RATIO_2 ) + +#define XORP_IEEE754_TEST_MAX_EXP(T,W) \ + ( T ## _MAX_EXP * XORP_IEEE754_RADIX_RATIO(FLT_RADIX) >= \ + XORP_IEEE754_BIN ## W ## _MAX_EXP * XORP_IEEE754_RADIX_RATIO_2 ) + +#define XORP_IEEE754_TEST_MIN_EXP(T,W) \ + ( T ## _MIN_EXP * XORP_IEEE754_RADIX_RATIO(FLT_RADIX) <= \ + XORP_IEEE754_BIN ## W ## _MIN_EXP * XORP_IEEE754_RADIX_RATIO_2) + +#define XORP_IEEE754_TEST(T,W) \ + ( XORP_IEEE754_TEST_MANT_DIG(T,W) && \ + XORP_IEEE754_TEST_MAX_EXP(T,W) && \ + XORP_IEEE754_TEST_MIN_EXP(T,W) ) + +/* Now we choose a native type to fulfil binary64. */ + +#if XORP_IEEE754_TEST(DBL,64) +/* double is sufficient, and is probably the optimal FP type used by + this system. */ +#define XORP_IEEE754_BIN64_DBL 1 +#else +/* We'll have to use long double, and hope that it is adequate. What + other choice do we have? */ +#define XORP_IEEE754_BIN64_LDBL 1 +#endif + + +/* Declare a type alias according to what we've chosen. Also define + some macros (like those in ) to print and scan the + type. */ + +#if XORP_IEEE754_BIN64_FLT +typedef float fp64_t; +#define XORP_PRIaFP64 "a" +#define XORP_PRIeFP64 "e" +#define XORP_PRIfFP64 "f" +#define XORP_PRIgFP64 "g" +#define XORP_PRIAFP64 "A" +#define XORP_PRIEFP64 "E" +#define XORP_PRIFFP64 "F" +#define XORP_PRIGFP64 "G" +#define XORP_SCNaFP64 "a" +#define XORP_SCNeFP64 "e" +#define XORP_SCNfFP64 "f" +#define XORP_SCNgFP64 "g" +#define XORP_FP64(F) F ## f +#define XORP_FP64_DIG FLT_FP64_DIG +#define XORP_FP64_EPSILON FLT_FP64_EPSILON +#define XORP_FP64_MANT_DIG FLT_FP64_MANT_DIG +#define XORP_FP64_MAX FLT_FP64_MAX +#define XORP_FP64_MAX_10_EXP FLT_FP64_MAX_10_EXP +#define XORP_FP64_MAX_EXP FLT_FP64_MAX_EXP +#define XORP_FP64_MIN FLT_FP64_MIN +#define XORP_FP64_MIN_10_EXP FLT_FP64_MIN_10_EXP +#define XORP_FP64_MIN_EXP FLT_FP64_MIN_EXP +#endif + +#if XORP_IEEE754_BIN64_DBL +typedef double fp64_t; +#define XORP_PRIaFP64 "a" +#define XORP_PRIeFP64 "e" +#define XORP_PRIfFP64 "f" +#define XORP_PRIgFP64 "g" +#define XORP_PRIAFP64 "A" +#define XORP_PRIEFP64 "E" +#define XORP_PRIFFP64 "F" +#define XORP_PRIGFP64 "G" +#define XORP_SCNaFP64 "la" +#define XORP_SCNeFP64 "le" +#define XORP_SCNfFP64 "lf" +#define XORP_SCNgFP64 "lg" +#define XORP_FP64(F) F +#define XORP_FP64_DIG DBL_FP64_DIG +#define XORP_FP64_EPSILON DBL_FP64_EPSILON +#define XORP_FP64_MANT_DIG DBL_FP64_MANT_DIG +#define XORP_FP64_MAX DBL_FP64_MAX +#define XORP_FP64_MAX_10_EXP DBL_FP64_MAX_10_EXP +#define XORP_FP64_MAX_EXP DBL_FP64_MAX_EXP +#define XORP_FP64_MIN DBL_FP64_MIN +#define XORP_FP64_MIN_10_EXP DBL_FP64_MIN_10_EXP +#define XORP_FP64_MIN_EXP DBL_FP64_MIN_EXP +#endif + +#if XORP_IEEE754_BIN64_LDBL +typedef long double fp64_t; +#define XORP_PRIaFP64 "La" +#define XORP_PRIeFP64 "Le" +#define XORP_PRIfFP64 "Lf" +#define XORP_PRIgFP64 "Lg" +#define XORP_PRIAFP64 "LA" +#define XORP_PRIEFP64 "LE" +#define XORP_PRIFFP64 "LF" +#define XORP_PRIGFP64 "LG" +#define XORP_SCNaFP64 "La" +#define XORP_SCNeFP64 "Le" +#define XORP_SCNfFP64 "Lf" +#define XORP_SCNgFP64 "Lg" +#define XORP_FP64(F) F ## l +#define XORP_FP64_DIG LDBL_FP64_DIG +#define XORP_FP64_EPSILON LDBL_FP64_EPSILON +#define XORP_FP64_MANT_DIG LDBL_FP64_MANT_DIG +#define XORP_FP64_MAX LDBL_FP64_MAX +#define XORP_FP64_MAX_10_EXP LDBL_FP64_MAX_10_EXP +#define XORP_FP64_MAX_EXP LDBL_FP64_MAX_EXP +#define XORP_FP64_MIN LDBL_FP64_MIN +#define XORP_FP64_MIN_10_EXP LDBL_FP64_MIN_10_EXP +#define XORP_FP64_MIN_EXP LDBL_FP64_MIN_EXP +#endif + + +#endif diff --git a/xorp/libxipc/fp64serial.c b/xorp/libxipc/fp64serial.c new file mode 100644 index 0000000..e61329f --- /dev/null +++ b/xorp/libxipc/fp64serial.c @@ -0,0 +1,184 @@ +// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- +// vim:set sts=4 ts=8: + +// Copyright (c) 2001-2011 XORP, Inc and Others +// +// This program is free software; you can redistribute it and/or modify +// it under the terms of the GNU Lesser General Public License, Version +// 2.1, June 1999 as published by the Free Software Foundation. +// Redistribution and/or modification of this program under the terms of +// any other version of the GNU Lesser General Public License is not +// permitted. +// +// This program is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, +// see the GNU Lesser General Public License, Version 2.1, a copy of +// which can be found in the XORP LICENSE.lgpl file. +// +// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; +// http://xorp.net + +#include +#include +#include +#include + +#include "fp64serial.h" + +/* How big are the fields of IEEE754 binary64? */ +#define MANTISSA_BIT 52 +#define EXPONENT_BIT 11 +#define SIGN_BIT 1 + +/* What's the offset for each field? */ +#define MANTISSA_SHIFT 0 +#define EXPONENT_SHIFT (MANTISSA_SHIFT + MANTISSA_BIT) +#define SIGN_SHIFT (EXPONENT_SHIFT + EXPONENT_BIT) + +/* Compute masks for each field. */ +#define MANTISSA_MASK ((UINTMAX_C(1) << MANTISSA_BIT) - 1u) +#define EXPONENT_MASK ((UINTMAX_C(1) << EXPONENT_BIT) - 1u) +#define SIGN_MASK ((UINTMAX_C(1) << SIGN_BIT) - 1u) + +/* How much is the exponent biased? */ +#define EXPONENT_BIAS ((EXPONENT_MASK >> 1u) - 1u) + + +uint_fast64_t fp64enc(fp64_t input) +{ + fp64_t d_mant; + unsigned int u_exp; + uint_fast64_t u_mant; + bool neg; + int s_exp; + uint_fast64_t bytes; + + switch (fpclassify(input)) { + default: + abort(); + break; + + case FP_ZERO: + neg = signbit(input); + u_mant = 0; + u_exp = 0; + break; + + case FP_INFINITE: + neg = signbit(input); + u_mant = 0; + u_exp = EXPONENT_MASK; + break; + + case FP_NAN: + neg = false; + u_mant = 1; + u_exp = EXPONENT_MASK; + break; + + case FP_SUBNORMAL: + case FP_NORMAL: + /* Handle normal and subnormal together. The number might be + one class for double, but another for binary64. */ + + /* Decompose the input into a significand (mantissa + 1) and + an exponent. */ + d_mant = XORP_FP64(frexp)(input, &s_exp); + + /* Extract the sign bit from the mantissa. */ + neg = signbit(input); + d_mant = XORP_FP64(fabs)(d_mant); + + /* Offset the exponent so it can be represented as an unsigned + value. */ + s_exp += EXPONENT_BIAS; + + /* Now we find out whether the number we represent is normal, + subnormal, or overflows binary64. */ + if (s_exp >= (long) EXPONENT_MASK) { + /* The number is too big for binary64, so use the maximum + value. */ + u_mant = MANTISSA_MASK; + u_exp = EXPONENT_MASK - 1u; + } else if (s_exp <= 0) { + /* The number is subnormal in binary64. */ + + /* Shift the mantissa so that it's exponent would be 0. */ + u_mant = XORP_FP64(ldexp)(d_mant, MANTISSA_BIT); + + u_mant >>= -s_exp; + u_exp = 0; + } else { + /* The number is normal in binary64. */ + + /* Use the suggested exponent. */ + u_exp = s_exp; + + /* Make the mantissa value into a positive integer. */ + u_mant = XORP_FP64(ldexp)(d_mant, MANTISSA_BIT + 1); + } + + break; + } + + /* Transmit the bottom MANTISSA_BITs of u_mant. The extra top bit + will always be one when normalized. */ + + bytes = ((uint_fast64_t) u_mant & MANTISSA_MASK) << MANTISSA_SHIFT; + bytes |= ((uint_fast64_t) u_exp & EXPONENT_MASK) << EXPONENT_SHIFT; + bytes |= ((uint_fast64_t) neg & SIGN_MASK) << SIGN_SHIFT; + + return bytes; +} + +fp64_t fp64dec(uint_fast64_t bytes) +{ + int s_exp; + unsigned int u_exp; + uint_fast64_t u_mant; + bool neg; + fp64_t output; + + /* Extract the bit fields. */ + u_exp = (bytes >> EXPONENT_SHIFT) & EXPONENT_MASK; + u_mant = (bytes >> MANTISSA_SHIFT) & MANTISSA_MASK; + neg = (bytes >> SIGN_SHIFT) & SIGN_MASK; + + if (u_exp == EXPONENT_MASK) { + if (u_mant == 0) + return neg ? -INFINITY : +INFINITY; + return NAN; + } + + + do { + if (u_exp == 0) { + /* Positive or negative zero */ + if (u_mant == 0) + return XORP_FP64(copysign)(0.0, neg ? -1.0 : +1.0); + + /* Subnormal value */ + + /* Multiply the mantissa by a power of two. */ + output = XORP_FP64(ldexp) + (u_mant, -(MANTISSA_BIT + (int) EXPONENT_BIAS)); + break; + } + + /* Recover the top bit of the mantissa. */ + u_mant |= MANTISSA_MASK + 1; + + /* Convert offset exponent back into a native signed value. */ + s_exp = (int) u_exp - EXPONENT_BIAS; + + /* Multiply the mantissa by a power of two. */ + output = XORP_FP64(ldexp) + (u_mant, s_exp - (MANTISSA_BIT + 1)); + } while (false); + + if (neg) + output = -output; + + return output; +} diff --git a/xorp/libxipc/fp64serial.h b/xorp/libxipc/fp64serial.h new file mode 100644 index 0000000..4430f77 --- /dev/null +++ b/xorp/libxipc/fp64serial.h @@ -0,0 +1,38 @@ +// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- +// vim:set sts=4 ts=8: + +// Copyright (c) 2001-2011 XORP, Inc and Others +// +// This program is free software; you can redistribute it and/or modify +// it under the terms of the GNU Lesser General Public License, Version +// 2.1, June 1999 as published by the Free Software Foundation. +// Redistribution and/or modification of this program under the terms of +// any other version of the GNU Lesser General Public License is not +// permitted. +// +// This program is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, +// see the GNU Lesser General Public License, Version 2.1, a copy of +// which can be found in the XORP LICENSE.lgpl file. +// +// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; +// http://xorp.net + +#ifndef __LIBXIPC_FP64SERIAL_H__ +#define __LIBXIPC_FP64SERIAL_H__ + +#include "fp64.h" + +#ifdef __cplusplus +extern "C" { +#endif + + extern uint_fast64_t fp64enc(fp64_t); + extern fp64_t fp64dec(uint_fast64_t); + +#ifdef __cplusplus +} +#endif + +#endif diff --git a/xorp/libxipc/tests/SConscript b/xorp/libxipc/tests/SConscript index d6d9b8b..4b1d611 100644 --- a/xorp/libxipc/tests/SConscript +++ b/xorp/libxipc/tests/SConscript @@ -70,6 +70,7 @@ simple_cpp_tests = [ 'xrl_error', 'xrl_parser', 'xrl_router', + 'fp64', ] xrlrcvr_sources = [ diff --git a/xorp/libxipc/tests/test_fp64.cc b/xorp/libxipc/tests/test_fp64.cc new file mode 100644 index 0000000..9d7788c --- /dev/null +++ b/xorp/libxipc/tests/test_fp64.cc @@ -0,0 +1,224 @@ +// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- +// vim:set sts=4 ts=8: + +// Copyright (c) 2001-2009 XORP, Inc. +// +// This program is free software; you can redistribute it and/or modify +// it under the terms of the GNU Lesser General Public License, Version +// 2.1, June 1999 as published by the Free Software Foundation. +// Redistribution and/or modification of this program under the terms of +// any other version of the GNU Lesser General Public License is not +// permitted. +// +// This program is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, +// see the GNU Lesser General Public License, Version 2.1, a copy of +// which can be found in the XORP LICENSE.lgpl file. +// +// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; +// http://xorp.net + + + +// Needed for PRIXFAST64 +#define __STDC_FORMAT_MACROS 1 + +#include +#include + +#include "xrl_module.h" + +#include "libxorp/xorp.h" +#include "libxorp/xlog.h" + +#ifdef HAVE_GETOPT_H +#include +#endif + +#include "xrl_args.hh" +#include "fp64serial.h" + + +/////////////////////////////////////////////////////////////////////////////// +// +// Constants +// + +static const char *program_name = "test_fp64"; +static const char *program_description = "Test IEEE754-fp64_t conversion"; +static const char *program_version_id = "0.1"; +static const char *program_date = "August, 2011"; +static const char *program_copyright = "See file LICENSE"; +static const char *program_return_value = "0 on success, 1 if test error, " + "2 if internal error"; + +/////////////////////////////////////////////////////////////////////////////// +// +// Verbosity level control +// + +static bool s_verbose = false; +bool verbose() { return s_verbose; } +void set_verbose(bool v) { s_verbose = v; } + +#define verbose_log(x...) _verbose_log(__FILE__,__LINE__, x) + +#define _verbose_log(file, line, x...) \ +do { \ + if (verbose()) { \ + printf("From %s:%d: ", file, line); \ + printf(x); \ + } \ +} while(0) + +/** + * Print program info to output stream. + * + * @param stream the output stream the print the program info to. + */ +static void +print_program_info(FILE *stream) +{ + fprintf(stream, "Name: %s\n", program_name); + fprintf(stream, "Description: %s\n", program_description); + fprintf(stream, "Version: %s\n", program_version_id); + fprintf(stream, "Date: %s\n", program_date); + fprintf(stream, "Copyright: %s\n", program_copyright); + fprintf(stream, "Return: %s\n", program_return_value); +} + +/** + * Print program usage information to the stderr. + * + * @param progname the name of the program. + */ +static void +usage(const char* progname) +{ + print_program_info(stderr); + fprintf(stderr, "usage: %s [-v] [-h]\n", progname); + fprintf(stderr, " -h : usage (this message)\n"); + fprintf(stderr, " -v : verbose output\n"); +} + +static double error_threshold; + +static int test_conversion(fp64_t input) +{ + uint_fast64_t encoded = fp64enc(input); + fp64_t output = fp64dec(encoded); + + fp64_t diff = output - input; + if (verbose()) + fprintf(stderr, "%15" XORP_PRIgFP64 " %016" PRIXFAST64 + " %15" XORP_PRIgFP64 " %15" XORP_PRIgFP64 "\n", + input, encoded, output, diff); + if (diff > error_threshold) { + verbose_log("THRESHOLD EXCEEDED\n"); + return 1; + } + return 0; +} + +static int +run_test() +{ + error_threshold = ldexp(1.0, 3 - DBL_MANT_DIG); + + + verbose_log("\n***** Expanding from DBL_MIN\n"); + for (double input = DBL_MIN; fpclassify(input) == FP_NORMAL; + input *= rand() * 50.0 / RAND_MAX) { + test_conversion(input); + } + + verbose_log("\n***** Expanding from -DBL_MIN\n"); + for (double input = -DBL_MIN; fpclassify(input) == FP_NORMAL; + input *= rand() * 50.0 / RAND_MAX) { + test_conversion(input); + } + + verbose_log("\n***** Reducinging from largest +ve subnormal\n"); + for (double input = nextafter(DBL_MIN, 0.0); fpclassify(input) != FP_ZERO; + input /= rand() * 50.0 / RAND_MAX) { + test_conversion(input); + } + + verbose_log("\n***** Reducinging from largest -ve subnormal\n"); + for (double input = -nextafter(DBL_MIN, 0.0); fpclassify(input) != FP_ZERO; + input /= rand() * 50.0 / RAND_MAX) { + test_conversion(input); + } + + + verbose_log("\n***** Infinities\n"); + test_conversion(+INFINITY); + test_conversion(-INFINITY); + + + verbose_log("\n***** Zeroes\n"); + test_conversion(+0.0); + test_conversion(-0.0); + +#ifdef NAN + verbose_log("\n***** NANs\n"); + test_conversion(NAN); +#endif + + return 0; +} + +int +main(int argc, char * const argv[]) +{ + srand(time(NULL)); + + int ret_value; + const char* const argv0 = argv[0]; + + int ch; + while ((ch = getopt(argc, argv, "hv")) != -1) { + switch (ch) { + case 'v': + set_verbose(true); + break; + case 'h': + case '?': + default: + usage(argv[0]); + if (ch == 'h') + return 0; + else + return 1; + } + } + argc -= optind; + argv += optind; + + // + // Initialize and start xlog + // + xlog_init(argv0, NULL); + xlog_set_verbose(XLOG_VERBOSE_LOW); // Least verbose messages + // XXX: verbosity of the error messages temporary increased + xlog_level_set_verbose(XLOG_LEVEL_ERROR, XLOG_VERBOSE_HIGH); + xlog_add_default_output(); + xlog_start(); + + XorpUnexpectedHandler x(xorp_unexpected_handler); + try { + ret_value = run_test(); + } + catch (...) { + xorp_catch_standard_exceptions(); + ret_value = 2; + } + // + // Gracefully stop and exit xlog + // + xlog_stop(); + xlog_exit(); + + return ret_value; +} diff --git a/xorp/libxipc/tests/test_xrl_args.cc b/xorp/libxipc/tests/test_xrl_args.cc index a4afcb4..f929957 100644 --- a/xorp/libxipc/tests/test_xrl_args.cc +++ b/xorp/libxipc/tests/test_xrl_args.cc @@ -168,7 +168,8 @@ run_serialization_test() XrlAtom("binary_data", test_binary), XrlAtom("a_list", test_list), XrlAtom("integer64", int64_t(-1234567890123456789LL)), - XrlAtom("uinteger64", uint64_t(0xabadc0ffee123456ULL)) + XrlAtom("uinteger64", uint64_t(0xabadc0ffee123456ULL)), + XrlAtom("fp64", fp64_t(0.087613017887164087613407)) }; uint32_t n_test_args = sizeof(test_args) / sizeof(test_args[0]); @@ -211,6 +212,7 @@ run_test() al.add_string("bad_karma", ""); al.add_int64("a_named_int64", int64_t(-98765432101234LL)); al.add_uint64("a_named_uint64", uint64_t(123456789012345ULL)); + al.add_fp64("a_named_fp64", fp64_t(0.087613017887164087613407)); XrlAtomList xal; xal.append(XrlAtom("first", string("fooo"))); @@ -260,6 +262,7 @@ run_test() al.get_string("bad_karma"); al.get_int64("a_named_int64"); al.get_uint64("a_named_uint64"); + al.get_fp64("a_named_fp64"); } catch (XrlArgs::BadArgs& e) { verbose_log("Error decoding the argument: %s\n", e.str().c_str()); return 1; diff --git a/xorp/libxipc/tests/test_xrl_atom.cc b/xorp/libxipc/tests/test_xrl_atom.cc index 280bc6b..dd3beed 100644 --- a/xorp/libxipc/tests/test_xrl_atom.cc +++ b/xorp/libxipc/tests/test_xrl_atom.cc @@ -242,6 +242,10 @@ test() test_atom(XrlAtom("test_uint64_value", uint64_t(0xabadc0ffee123456ULL))); break; + case xrlatom_fp64: + test_atom(XrlAtom("test_fp64_value", + fp64_t(0.087613017887164087613407))); + break; } } } diff --git a/xorp/libxipc/xrl_args.cc b/xorp/libxipc/xrl_args.cc index e22e03a..0a3ef81 100644 --- a/xorp/libxipc/xrl_args.cc +++ b/xorp/libxipc/xrl_args.cc @@ -533,6 +533,34 @@ XrlArgs::remove_uint64(const char* name) throw (XrlAtomNotFound) // ---------------------------------------------------------------------------- +// XrlArgs add/get/remove fp64 + +XrlArgs& +XrlArgs::add_fp64(const char* name, fp64_t val) throw (XrlAtomFound) +{ + return add(XrlAtom(name, val)); +} + +const fp64_t& +XrlArgs::get_fp64(const char* name) const throw (BadArgs) +{ + try { + return get(XrlAtom(name, xrlatom_fp64)).fp64(); + } catch (const XrlAtom::NoData& e) { + xorp_throw(BadArgs, e.why()); + } catch (const XrlAtom::WrongType& e) { + xorp_throw(BadArgs, e.why()); + } +} + +void +XrlArgs::remove_fp64(const char* name) throw (XrlAtomNotFound) +{ + remove(XrlAtom(name, xrlatom_fp64)); +} + + +// ---------------------------------------------------------------------------- // Append an existing XrlArgs XrlArgs& diff --git a/xorp/libxipc/xrl_args.hh b/xorp/libxipc/xrl_args.hh index 8121884..2975cdf 100644 --- a/xorp/libxipc/xrl_args.hh +++ b/xorp/libxipc/xrl_args.hh @@ -251,6 +251,18 @@ public: void get(const char* n, uint64_t& t) const throw (BadArgs); + /* --- fp64 accessors --- */ + + XrlArgs& add_fp64(const char* name, fp64_t v) throw (XrlAtomFound); + + const fp64_t& get_fp64(const char* name) const throw (BadArgs); + + void remove_fp64(const char* name) throw (XrlAtomNotFound); + + XrlArgs& add(const char* n, fp64_t v) throw (XrlAtomFound); + + void get(const char* n, fp64_t& t) const throw (BadArgs); + // ... Add your type's add, get, remove functions here ... @@ -515,6 +527,18 @@ XrlArgs::get(const char* n, uint64_t& t) const throw (BadArgs) t = get_uint64(n); } +inline XrlArgs& +XrlArgs::add(const char* n, fp64_t v) throw (XrlAtomFound) +{ + return add_fp64(n, v); +} + +inline void +XrlArgs::get(const char* n, fp64_t& t) const throw (BadArgs) +{ + t = get_fp64(n); +} + inline const XrlAtom& XrlArgs::item(uint32_t index) const { diff --git a/xorp/libxipc/xrl_atom.cc b/xorp/libxipc/xrl_atom.cc index 2cdc6e1..5106e4a 100644 --- a/xorp/libxipc/xrl_atom.cc +++ b/xorp/libxipc/xrl_atom.cc @@ -31,7 +31,7 @@ #include "libproto/packet.hh" - +#include "fp64serial.h" #ifdef HAVE_SYS_TYPES_H #include @@ -62,6 +62,7 @@ static const char* xrlatom_list_name = "list"; static const char* xrlatom_binary_name = "binary"; static const char* xrlatom_int64_name = "i64"; static const char* xrlatom_uint64_name = "u64"; +static const char* xrlatom_fp64_name = "fp64"; static inline void do_pack_uint32(const uint32_t u32val, uint8_t* buffer) @@ -97,6 +98,7 @@ xrlatom_type_name(const XrlAtomType& t) NAME_CASE(xrlatom_binary); NAME_CASE(xrlatom_int64); NAME_CASE(xrlatom_uint64); + NAME_CASE(xrlatom_fp64); // ... Your type here ... } return xrlatom_no_type_name; @@ -125,6 +127,7 @@ resolve_xrlatom_name(const char* name) CHECK_NAME(xrlatom_binary); /* FALLTHRU */ CHECK_NAME(xrlatom_int64); /* FALLTHRU */ CHECK_NAME(xrlatom_uint64); /* FALLTHRU */ + CHECK_NAME(xrlatom_fp64); /* FALLTHRU */ // ... Your type here ... case xrlatom_no_type: break; @@ -220,6 +223,9 @@ XrlAtom::data_from_c_str(const char* c_str) _u64val = (uint64_t)strtoull(c_str, (char**)NULL, 10); #endif break; + case xrlatom_fp64: + sscanf(c_str, "%" XORP_SCNgFP64, &_fp64val); + break; // ... Your types instantiator here ... } @@ -356,6 +362,13 @@ XrlAtom::uint64() const throw (NoData, WrongType) return _u64val; } +const fp64_t& +XrlAtom::fp64() const throw (NoData, WrongType) +{ + type_and_data_okay(xrlatom_fp64); + return _fp64val; +} + // ---------------------------------------------------------------------------- // XrlAtom dynamic data management functions @@ -415,6 +428,9 @@ XrlAtom::copy(const XrlAtom& xa) case xrlatom_uint64: _u64val = xa._u64val; break; + case xrlatom_fp64: + _fp64val = xa._fp64val; + break; // ... Your type's copy operation here ... case xrlatom_no_type: @@ -461,6 +477,7 @@ XrlAtom::discard_dynamic() break; case xrlatom_int64: case xrlatom_uint64: + case xrlatom_fp64: break; // ... Your type should free allocated memory here ... @@ -608,6 +625,10 @@ XrlAtom::value() const static_cast(_u64val)); #endif return xrlatom_encode_value(tmp, strlen(tmp)); + case xrlatom_fp64: + snprintf(tmp, sizeof(tmp) / sizeof(tmp[0]), + "%" XORP_PRIAFP64, _fp64val); + return xrlatom_encode_value(tmp, strlen(tmp)); // ... Your type's c_str equivalent here ... } @@ -682,6 +703,9 @@ XrlAtom::operator==(const XrlAtom& other) const case xrlatom_uint64: mv = (_u64val == other._u64val); break; + case xrlatom_fp64: + mv = (_fp64val == other._fp64val); + break; // ... Your type's equality test here ... } @@ -765,6 +789,7 @@ XrlAtom::packed_bytes() const break; case xrlatom_int64: case xrlatom_uint64: + case xrlatom_fp64: bytes += 8; break; @@ -790,6 +815,7 @@ XrlAtom::packed_bytes_fixed() const case xrlatom_boolean: case xrlatom_int64: case xrlatom_uint64: + case xrlatom_fp64: return true; case xrlatom_mac: case xrlatom_text: @@ -1169,6 +1195,27 @@ XrlAtom::unpack_uint64(const uint8_t* buf) } size_t +XrlAtom::pack_fp64(uint8_t* buffer) const +{ + uint_fast64_t bytes = fp64enc(_fp64val); + + do_pack_uint32(bytes >> 32, buffer); + do_pack_uint32(bytes & 0xFFFFFFFF, &buffer[4]); + return sizeof(_fp64val); +} + +size_t +XrlAtom::unpack_fp64(const uint8_t* buf) +{ + uint_fast64_t bytes; + bytes = uint_fast64_t(do_unpack_uint32(buf)) << 32; + bytes |= do_unpack_uint32(&buf[4]); + + _fp64val = fp64dec(bytes); + return sizeof(_fp64val); +} + +size_t XrlAtom::pack(uint8_t* buffer, size_t buffer_bytes) const { size_t pb = packed_bytes(); @@ -1229,6 +1276,9 @@ XrlAtom::pack(uint8_t* buffer, size_t buffer_bytes) const case xrlatom_uint64: packed_size += pack_uint64(buffer + packed_size); break; + case xrlatom_fp64: + packed_size += pack_fp64(buffer + packed_size); + break; // ... Your type here ... } @@ -1330,6 +1380,9 @@ XrlAtom::unpack(const uint8_t* buffer, size_t buffer_bytes) case xrlatom_uint64: used = unpack_uint64(buffer + unpacked); break; + case xrlatom_fp64: + used = unpack_fp64(buffer + unpacked); + break; // ... Your type here ... } diff --git a/xorp/libxipc/xrl_atom.hh b/xorp/libxipc/xrl_atom.hh index d4be38f..50fb4f1 100644 --- a/xorp/libxipc/xrl_atom.hh +++ b/xorp/libxipc/xrl_atom.hh @@ -39,6 +39,7 @@ #include "xrl_atom_list.hh" +#include "fp64.h" enum XrlAtomType { @@ -56,13 +57,14 @@ enum XrlAtomType { xrlatom_binary, xrlatom_int64, xrlatom_uint64, + xrlatom_fp64, // ... Your type's unique enumerated name here ... // Changing order above will break binary compatibility // ...Don't forget to update xrlatom_start and xrlatom_end below... // Bounds for enumerations xrlatom_start = xrlatom_int32, // First valid enumerated value - xrlatom_end = xrlatom_uint64 // Last valid enumerated value + xrlatom_end = xrlatom_fp64 // Last valid enumerated value }; inline XrlAtomType& operator++(XrlAtomType& t) @@ -329,6 +331,16 @@ public: } + // fp64 constructors + explicit XrlAtom(const fp64_t& value) + : _type(xrlatom_fp64), _have_data(true), _own(true), _u64val(value) {} + + XrlAtom(const char* name, fp64_t value) throw (BadName) + : _type(xrlatom_fp64), _have_data(true), _own(true), _fp64val(value) { + set_name(name); + } + + // ... Your type's constructors here ... // Copy operations @@ -368,6 +380,7 @@ public: const vector& binary() const throw (NoData, WrongType); const int64_t& int64() const throw (NoData, WrongType); const uint64_t& uint64() const throw (NoData, WrongType); + const fp64_t& fp64() const throw (NoData, WrongType); // ... Your type's accessor method here ... @@ -392,6 +405,7 @@ public: SET(string, _text, &) SET(XrlAtomList, _list, &) SET(vector, _binary, &); + SET(fp64_t, _fp64val, ) #undef SET void set(const IPv4& v) { @@ -446,6 +460,7 @@ private: size_t pack_list(uint8_t* buffer, size_t buffer_bytes) const; size_t pack_binary(uint8_t* buffer) const; size_t pack_uint64(uint8_t* buffer) const; + size_t pack_fp64(uint8_t* buffer) const; size_t unpack_name(const uint8_t* buffer, size_t buffer_bytes) throw (BadName); @@ -460,6 +475,7 @@ private: size_t unpack_list(const uint8_t* buffer, size_t buffer_bytes); size_t unpack_binary(const uint8_t* buffer, size_t buffer_bytes); size_t unpack_uint64(const uint8_t* buffer); + size_t unpack_fp64(const uint8_t* buffer); private: XrlAtomType _type; @@ -479,6 +495,7 @@ private: vector* _binary; int64_t _i64val; uint64_t _u64val; + fp64_t _fp64val; // ... Your type here, if it's more than sizeof(uintptr_t) bytes, // use a pointer ... diff --git a/xorp/rtrmgr/xorp_client.cc b/xorp/rtrmgr/xorp_client.cc index e4e01a8..5119ff4 100644 --- a/xorp/rtrmgr/xorp_client.cc +++ b/xorp/rtrmgr/xorp_client.cc @@ -143,6 +143,7 @@ XorpClient::fake_return_args(const string& xrl_return_spec) case xrlatom_binary: case xrlatom_uint64: case xrlatom_int64: + case xrlatom_fp64: XLOG_UNFINISHED(); break; } diff --git a/xorp/xrl/interfaces/test.xif b/xorp/xrl/interfaces/test.xif index b6e3fe9..bd84ad8 100644 --- a/xorp/xrl/interfaces/test.xif +++ b/xorp/xrl/interfaces/test.xif @@ -36,4 +36,9 @@ interface test/1.0 { * Something that always fails. */ shoot_foot; + + /** + * Handle IEEE754 binary64 format. + */ + float_my_point ? input:fp64 -> output:fp64; } diff --git a/xorp/xrl/scripts/Xif/xiftypes.py b/xorp/xrl/scripts/Xif/xiftypes.py index d8d6180..85489f2 100644 --- a/xorp/xrl/scripts/Xif/xiftypes.py +++ b/xorp/xrl/scripts/Xif/xiftypes.py @@ -12,7 +12,8 @@ xrl_atom_type = { 'list' : ('XrlAtomList', 'list', 'list'), 'binary' : ('vector', 'binary', 'binary'), 'i64' : ('int64_t', 'int64', 'i64'), - 'u64' : ('uint64_t', 'uint64', 'i64') + 'u64' : ('uint64_t', 'uint64', 'i64'), + 'fp64' : ('fp64_t', 'fp64', 'double') } class XrlArg: -- 1.7.4.1 From noreply at github.com Mon Sep 12 15:11:48 2011 From: noreply at github.com (noreply at github.com) Date: Mon, 12 Sep 2011 15:11:48 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 287f71: Wiki backup on Sat, 10 Sep 2011 03:00:01 +0200... Message-ID: <20110912221148.2FF3F42526@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 287f717c5702a5b56fec779729fafcc7c4059644 https://github.com/greearb/xorp.ct/commit/287f717c5702a5b56fec779729fafcc7c4059644 Author: RUN Admin Team Date: 2011-09-09 (Fri, 09 Sep 2011) Changed paths: M docs/wiki/meta/latex2wiki/introduction_xorp_process.meta Log Message: ----------- Wiki backup on Sat, 10 Sep 2011 03:00:01 +0200... Commit: 299047a1748f5c01028345427dc6906993e5ad1b https://github.com/greearb/xorp.ct/commit/299047a1748f5c01028345427dc6906993e5ad1b Author: RUN Admin Team Date: 2011-09-09 (Fri, 09 Sep 2011) Changed paths: M xorp/libxipc/tests/test_stcp.cc M xorp/libxorp/tests/test_ipv4net.cc M xorp/libxorp/tests/test_ipvxnet.cc Log Message: ----------- Merge branch 'master' of https://github.com/greearb/xorp.ct Compare: https://github.com/greearb/xorp.ct/compare/02ee142...299047a From noreply at github.com Mon Sep 12 15:15:46 2011 From: noreply at github.com (noreply at github.com) Date: Mon, 12 Sep 2011 15:15:46 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 41cc1c: Support for IEEE754 binary64 format in XRLs Message-ID: <20110912221546.0AE64425DF@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 41cc1c9f57ea984319cc18d0d699708fcc170e5d https://github.com/greearb/xorp.ct/commit/41cc1c9f57ea984319cc18d0d699708fcc170e5d Author: Steven Simpson Date: 2011-09-12 (Mon, 12 Sep 2011) Changed paths: M xorp/libxipc/SConscript A xorp/libxipc/fp64.h A xorp/libxipc/fp64serial.c A xorp/libxipc/fp64serial.h M xorp/libxipc/tests/SConscript A xorp/libxipc/tests/test_fp64.cc M xorp/libxipc/tests/test_xrl_args.cc M xorp/libxipc/tests/test_xrl_atom.cc M xorp/libxipc/xrl_args.cc M xorp/libxipc/xrl_args.hh M xorp/libxipc/xrl_atom.cc M xorp/libxipc/xrl_atom.hh M xorp/rtrmgr/xorp_client.cc M xorp/xrl/interfaces/test.xif M xorp/xrl/scripts/Xif/xiftypes.py Log Message: ----------- Support for IEEE754 binary64 format in XRLs * New atom type fp64 * selects alias fp64_t for most compatible native C type. Native type's characteristics are echoed with corresponding macros (analogous to DBL_MIN, etc). * (de)serializes fp64_t into uint_fast64_t. * New methods for fp64_t added on XrlAtom and XrlArgs. * Added fp64 to xif types, mapping to fp64_t in C++ and double for Thrift. * Extended atom and args tests to include fp64_t. * Added fp64_t serialization test. (It always succeeds for now, but might be useful for diagnostics.) * Added method to test XIF to demonstrate fp64 type. Signed-off-by: Steven Simpson From noreply at github.com Mon Sep 12 17:42:42 2011 From: noreply at github.com (noreply at github.com) Date: Mon, 12 Sep 2011 17:42:42 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 557141: Update copyright for recently touched files. Message-ID: <20110913004242.D392E426E1@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 5571416c2557f69f55cd043b9c008e543ca987de https://github.com/greearb/xorp.ct/commit/5571416c2557f69f55cd043b9c008e543ca987de Author: Ben Greear Date: 2011-09-12 (Mon, 12 Sep 2011) Changed paths: M docs/man/xorpsh.1 M docs/man/xorpsh.sgml M xorp/bgp/route_table_decision.cc M xorp/bgp/route_table_ribin.cc M xorp/contrib/olsr/topology.cc M xorp/contrib/olsr/xrl_port.cc M xorp/libxipc/finder_messenger.cc M xorp/libxipc/tests/test_fp64.cc M xorp/libxipc/tests/test_xrl_args.cc M xorp/libxipc/xrl_cmd_map.cc M xorp/libxipc/xrl_dispatcher.cc M xorp/libxorp/clock.hh M xorp/ospf/ospf.hh M xorp/rib/rt_tab_origin.cc M xorp/rtrmgr/xorp_client.cc Log Message: ----------- Update copyright for recently touched files. With old date of 2009. Signed-off-by: Ben Greear Commit: 2c62e3d0fedac0e0ae9c03e29c712498b673b6c6 https://github.com/greearb/xorp.ct/commit/2c62e3d0fedac0e0ae9c03e29c712498b673b6c6 Author: Ben Greear Date: 2011-09-12 (Mon, 12 Sep 2011) Changed paths: M xorp/devnotes/update_changed_copyright.bash Log Message: ----------- Use new perl script to update copyright. Bash script was too hard to modify for me... Signed-off-by: Ben Greear Commit: 4f467929f2dc81f88cd6bb4f53531581843494ee https://github.com/greearb/xorp.ct/commit/4f467929f2dc81f88cd6bb4f53531581843494ee Author: Ben Greear Date: 2011-09-12 (Mon, 12 Sep 2011) Changed paths: M xorp/libcomm/comm_api.h M xorp/libxorp/timer.cc Log Message: ----------- Update a few non-standard copyrights. Signed-off-by: Ben Greear Commit: cd30f2dd575e8eec40e7b9984e629b50c1819725 https://github.com/greearb/xorp.ct/commit/cd30f2dd575e8eec40e7b9984e629b50c1819725 Author: Ben Greear Date: 2011-09-12 (Mon, 12 Sep 2011) Changed paths: A xorp/devnotes/update_copyright.pl Log Message: ----------- Add perl script to update copyrights. Signed-off-by: Ben Greear Commit: 74282ff12ec3f2c326d183e476db8feb8466f765 https://github.com/greearb/xorp.ct/commit/74282ff12ec3f2c326d183e476db8feb8466f765 Author: Ben Greear Date: 2011-09-12 (Mon, 12 Sep 2011) Changed paths: R xorp/devnotes/update_copyright.sh Log Message: ----------- Remove old update_copyright.sh script. Signed-off-by: Ben Greear Commit: 457d8c30866828690792812029aca5c4b37ed659 https://github.com/greearb/xorp.ct/commit/457d8c30866828690792812029aca5c4b37ed659 Author: Ben Greear Date: 2011-09-12 (Mon, 12 Sep 2011) Changed paths: M www/html_src/index.html M xorp/Makefile.deb M xorp/RELEASE_NOTES M xorp/VERSION M xorp/devnotes/pkg_xorp.bash M xorp/devnotes/release_process.txt M xorp/etc/templates/xorpsh.cmds M xorp/package_files/xorp.ct.spec M xorp/rtrmgr/master_conf_tree.cc Log Message: ----------- Update version to 1.8.4 Signed-off-by: Ben Greear Commit: 7be03741355c877b62944438905bfd2cdbff978e https://github.com/greearb/xorp.ct/commit/7be03741355c877b62944438905bfd2cdbff978e Author: Ben Greear Date: 2011-09-12 (Mon, 12 Sep 2011) Changed paths: M www/html_src/index.html M www/html_src/news.html M xorp/devnotes/release_process.txt M xorp/devnotes/update_changed_copyright.bash Log Message: ----------- Update html for 1.8.4. Signed-off-by: Ben Greear Commit: 1ea5e1c13b37edcdb4be36b3ccc6ca896b7cdd4a https://github.com/greearb/xorp.ct/commit/1ea5e1c13b37edcdb4be36b3ccc6ca896b7cdd4a Author: Ben Greear Date: 2011-09-12 (Mon, 12 Sep 2011) Changed paths: M xorp/RELEASE_NOTES M xorp/devnotes/release_process.txt Log Message: ----------- Update release notes with git shortlog. Signed-off-by: Ben Greear Commit: f9cb23138bea2b86870eae779dfeeb69628eb726 https://github.com/greearb/xorp.ct/commit/f9cb23138bea2b86870eae779dfeeb69628eb726 Author: Ben Greear Date: 2011-09-12 (Mon, 12 Sep 2011) Changed paths: M docs/kdoc/README.txt M xorp/devnotes/release_process.txt Log Message: ----------- Update release procedures docs, www pkg script. Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/41cc1c9...f9cb231 From greearb at candelatech.com Mon Sep 12 19:42:08 2011 From: greearb at candelatech.com (Ben Greear) Date: Mon, 12 Sep 2011 19:42:08 -0700 Subject: [Xorp-hackers] Xorp 1.8.4 release almost ready. Message-ID: <4E6EC300.6090803@candelatech.com> I've pushed the changes to the source tree to update xorp to release 1.8.4. I should have binary builds and the web page updated tomorrow. If anyone wants to give the latest code a spin, it would be good to get an extra bit of testing in.... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Tue Sep 13 09:04:56 2011 From: noreply at github.com (noreply at github.com) Date: Tue, 13 Sep 2011 09:04:56 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 905340: Fix test build failure on F15. Message-ID: <20110913160456.E700E425C7@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 90534044024c6874d65f9bb0d56202bd83459896 https://github.com/greearb/xorp.ct/commit/90534044024c6874d65f9bb0d56202bd83459896 Author: Ben Greear Date: 2011-09-13 (Tue, 13 Sep 2011) Changed paths: M xorp/ospf/tests/test_packet.cc Log Message: ----------- Fix test build failure on F15. Signed-off-by: Ben Greear From greearb at candelatech.com Tue Sep 13 09:14:20 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 13 Sep 2011 09:14:20 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> Message-ID: <4E6F815C.1010102@candelatech.com> On 09/12/2011 05:10 AM, ss at comp.lancs.ac.uk wrote: > From: Steven Simpson > > * New atom type fp64 This breaks the build on Fedora 8, 32-bit: scons: done reading SConscript files. scons: Building targets ... scons: Configure: creating obj/i686-pc-linux-gnu/xorp_config.h g++ -o obj/i686-pc-linux-gnu/cli/tools/cli_generic.o -c -O1 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. cli/tools/cli_generic.cc cc1plus: warnings being treated as errors ./libxipc/xrl_atom.hh: In constructor ???XrlAtom::XrlAtom(const fp64_t&)???: ./libxipc/xrl_atom.hh:336: warning: converting to ???uint64_t??? from ???const double??? scons: building terminated because of errors. scons: *** [obj/i686-pc-linux-gnu/cli/tools/cli_generic.o] Error 1 program finished with exit code 2 elapsedTime=15.113463 This from the build-bot: http://dmz2.candelatech.com:8010/waterfall Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ss at comp.lancs.ac.uk Tue Sep 13 09:21:43 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Tue, 13 Sep 2011 17:21:43 +0100 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E6F815C.1010102@candelatech.com> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> <4E6F815C.1010102@candelatech.com> Message-ID: <4E6F8317.1060008@comp.lancs.ac.uk> On 13/09/11 17:14, Ben Greear wrote: > ./libxipc/xrl_atom.hh: In constructor ???XrlAtom::XrlAtom(const > fp64_t&)???: > ./libxipc/xrl_atom.hh:336: warning: converting to ???uint64_t??? from > ???const double??? D'oh! // fp64 constructors explicit XrlAtom(const fp64_t& value) : _type(xrlatom_fp64), _have_data(true), _own(true), _u64val(value) {} That _u64val should, of course, be _fp64val! Sorry! From greearb at candelatech.com Tue Sep 13 09:29:07 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 13 Sep 2011 09:29:07 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E6F8317.1060008@comp.lancs.ac.uk> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> <4E6F815C.1010102@candelatech.com> <4E6F8317.1060008@comp.lancs.ac.uk> Message-ID: <4E6F84D3.4000305@candelatech.com> On 09/13/2011 09:21 AM, Steven Simpson wrote: > On 13/09/11 17:14, Ben Greear wrote: >> ./libxipc/xrl_atom.hh: In constructor ???XrlAtom::XrlAtom(const >> fp64_t&)???: >> ./libxipc/xrl_atom.hh:336: warning: converting to ???uint64_t??? from >> ???const double??? > > D'oh! > > // fp64 constructors > explicit XrlAtom(const fp64_t& value) > : _type(xrlatom_fp64), _have_data(true), _own(true), _u64val(value) {} > > That _u64val should, of course, be _fp64val! I figured that...but then it blows up again: Maybe something funky with how math.h works on this system... cc1: warnings being treated as errors libxipc/fp64serial.c: In function ?fp64enc?: libxipc/fp64serial.c:58: warning: implicit declaration of function ?fpclassify? libxipc/fp64serial.c:58: warning: nested extern declaration of ?fpclassify? libxipc/fp64serial.c:63: error: ?FP_ZERO? undeclared (first use in this function) libxipc/fp64serial.c:63: error: (Each undeclared identifier is reported only once libxipc/fp64serial.c:63: error: for each function it appears in.) libxipc/fp64serial.c:64: warning: implicit declaration of function ?signbit? libxipc/fp64serial.c:69: error: ?FP_INFINITE? undeclared (first use in this function) libxipc/fp64serial.c:75: error: ?FP_NAN? undeclared (first use in this function) libxipc/fp64serial.c:81: error: ?FP_SUBNORMAL? undeclared (first use in this function) libxipc/fp64serial.c:82: error: ?FP_NORMAL? undeclared (first use in this function) libxipc/fp64serial.c: In function ?fp64dec?: libxipc/fp64serial.c:151: error: ?INFINITY? undeclared (first use in this function) libxipc/fp64serial.c:152: error: ?NAN? undeclared (first use in this function) scons: *** [obj/i686-pc-linux-gnu/libxipc/fp64serial.os] Error 1 scons: building terminated because of errors. > > Sorry! > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From JoeCoco at mecnet.net Tue Sep 13 09:48:02 2011 From: JoeCoco at mecnet.net (Joe Coco) Date: Tue, 13 Sep 2011 16:48:02 +0000 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E6F84D3.4000305@candelatech.com> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> <4E6F815C.1010102@candelatech.com> <4E6F8317.1060008@comp.lancs.ac.uk> <4E6F84D3.4000305@candelatech.com> Message-ID: <9513B0D809E3024A85A611E9B3726CA99B9430@MECnetExchange.mecnet.net> Explodes on one of my systems as well. Errors are identical. 32bit, linux 2.6.32, glibc 2.3, Pentium4. -- Joe -----Original Message----- From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Ben Greear Sent: Tuesday, September 13, 2011 12:29 PM To: Steven Simpson Cc: xorp-hackers at icir.org Subject: Re: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs On 09/13/2011 09:21 AM, Steven Simpson wrote: > On 13/09/11 17:14, Ben Greear wrote: >> ./libxipc/xrl_atom.hh: In constructor ???XrlAtom::XrlAtom(const >> fp64_t&)???: >> ./libxipc/xrl_atom.hh:336: warning: converting to ???uint64_t??? from >> ???const double??? > > D'oh! > > // fp64 constructors > explicit XrlAtom(const fp64_t& value) > : _type(xrlatom_fp64), _have_data(true), _own(true), _u64val(value) > {} > > That _u64val should, of course, be _fp64val! I figured that...but then it blows up again: Maybe something funky with how math.h works on this system... cc1: warnings being treated as errors libxipc/fp64serial.c: In function ?fp64enc?: libxipc/fp64serial.c:58: warning: implicit declaration of function ?fpclassify? libxipc/fp64serial.c:58: warning: nested extern declaration of ?fpclassify? libxipc/fp64serial.c:63: error: ?FP_ZERO? undeclared (first use in this function) libxipc/fp64serial.c:63: error: (Each undeclared identifier is reported only once libxipc/fp64serial.c:63: error: for each function it appears in.) libxipc/fp64serial.c:64: warning: implicit declaration of function ?signbit? libxipc/fp64serial.c:69: error: ?FP_INFINITE? undeclared (first use in this function) libxipc/fp64serial.c:75: error: ?FP_NAN? undeclared (first use in this function) libxipc/fp64serial.c:81: error: ?FP_SUBNORMAL? undeclared (first use in this function) libxipc/fp64serial.c:82: error: ?FP_NORMAL? undeclared (first use in this function) libxipc/fp64serial.c: In function ?fp64dec?: libxipc/fp64serial.c:151: error: ?INFINITY? undeclared (first use in this function) libxipc/fp64serial.c:152: error: ?NAN? undeclared (first use in this function) scons: *** [obj/i686-pc-linux-gnu/libxipc/fp64serial.os] Error 1 scons: building terminated because of errors. > > Sorry! > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com _______________________________________________ Xorp-hackers mailing list Xorp-hackers at icir.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers From greearb at candelatech.com Tue Sep 13 10:50:55 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 13 Sep 2011 10:50:55 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <9513B0D809E3024A85A611E9B3726CA99B9430@MECnetExchange.mecnet.net> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> <4E6F815C.1010102@candelatech.com> <4E6F8317.1060008@comp.lancs.ac.uk> <4E6F84D3.4000305@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B9430@MECnetExchange.mecnet.net> Message-ID: <4E6F97FF.1050503@candelatech.com> On 09/13/2011 09:48 AM, Joe Coco wrote: > Explodes on one of my systems as well. Errors are identical. 32bit, linux 2.6.32, glibc 2.3, Pentium4. Mine will compile that file if I pass -std=c99 to the gcc options. I'll try adding that globally and see if that works elsewhere as well... Anyone see any problems with using that? Thanks, Ben > > -- Joe > > -----Original Message----- > From: xorp-hackers-bounces at icir.org [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Ben Greear > Sent: Tuesday, September 13, 2011 12:29 PM > To: Steven Simpson > Cc: xorp-hackers at icir.org > Subject: Re: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs > > On 09/13/2011 09:21 AM, Steven Simpson wrote: >> On 13/09/11 17:14, Ben Greear wrote: >>> ./libxipc/xrl_atom.hh: In constructor ???XrlAtom::XrlAtom(const >>> fp64_t&)???: >>> ./libxipc/xrl_atom.hh:336: warning: converting to ???uint64_t??? from >>> ???const double??? >> >> D'oh! >> >> // fp64 constructors >> explicit XrlAtom(const fp64_t& value) >> : _type(xrlatom_fp64), _have_data(true), _own(true), _u64val(value) >> {} >> >> That _u64val should, of course, be _fp64val! > > I figured that...but then it blows up again: > > Maybe something funky with how math.h works on this system... > > cc1: warnings being treated as errors > libxipc/fp64serial.c: In function ?fp64enc?: > libxipc/fp64serial.c:58: warning: implicit declaration of function ?fpclassify? > libxipc/fp64serial.c:58: warning: nested extern declaration of ?fpclassify? > libxipc/fp64serial.c:63: error: ?FP_ZERO? undeclared (first use in this function) > libxipc/fp64serial.c:63: error: (Each undeclared identifier is reported only once > libxipc/fp64serial.c:63: error: for each function it appears in.) > libxipc/fp64serial.c:64: warning: implicit declaration of function ?signbit? > libxipc/fp64serial.c:69: error: ?FP_INFINITE? undeclared (first use in this function) > libxipc/fp64serial.c:75: error: ?FP_NAN? undeclared (first use in this function) > libxipc/fp64serial.c:81: error: ?FP_SUBNORMAL? undeclared (first use in this function) > libxipc/fp64serial.c:82: error: ?FP_NORMAL? undeclared (first use in this function) > libxipc/fp64serial.c: In function ?fp64dec?: > libxipc/fp64serial.c:151: error: ?INFINITY? undeclared (first use in this function) > libxipc/fp64serial.c:152: error: ?NAN? undeclared (first use in this function) > scons: *** [obj/i686-pc-linux-gnu/libxipc/fp64serial.os] Error 1 > scons: building terminated because of errors. > >> >> Sorry! >> >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From JoeCoco at mecnet.net Tue Sep 13 11:14:03 2011 From: JoeCoco at mecnet.net (Joe Coco) Date: Tue, 13 Sep 2011 18:14:03 +0000 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E6F97FF.1050503@candelatech.com> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> <4E6F815C.1010102@candelatech.com> <4E6F8317.1060008@comp.lancs.ac.uk> <4E6F84D3.4000305@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B9430@MECnetExchange.mecnet.net> <4E6F97FF.1050503@candelatech.com> Message-ID: <9513B0D809E3024A85A611E9B3726CA99B94DA@MECnetExchange.mecnet.net> That got me as far as here: libcomm/comm_sock.c: In function 'comm_sock_bind4': libcomm/comm_sock.c:302:28: error: 'u_char' undeclared (first use in this function) libcomm/comm_sock.c:302:28: note: each undeclared identifier is reported only once for each function it appears in libcomm/comm_sock.c:302:35: error: expected ';' before 'family' libcomm/comm_sock.c: In function 'comm_sock_bind6': libcomm/comm_sock.c:342:30: error: 'u_char' undeclared (first use in this function) libcomm/comm_sock.c:342:37: error: expected ';' before 'family' libcomm/comm_sock.c: In function 'comm_sock_connect4': libcomm/comm_sock.c:584:28: error: 'u_char' undeclared (first use in this function) libcomm/comm_sock.c:584:35: error: expected ';' before 'family' libcomm/comm_sock.c: In function 'comm_sock_connect6': libcomm/comm_sock.c:640:30: error: 'u_char' undeclared (first use in this function) libcomm/comm_sock.c:640:37: error: expected ';' before 'family' libcomm/comm_sock.c: In function 'comm_set_loopback': libcomm/comm_sock.c:981:2: error: 'u_char' undeclared (first use in this function) libcomm/comm_sock.c:981:9: error: expected ';' before 'loop' libcomm/comm_sock.c:984:10: error: 'loop' undeclared (first use in this function) libcomm/comm_sock.c: In function 'comm_set_multicast_ttl': libcomm/comm_sock.c:1167:2: error: 'u_char' undeclared (first use in this function) libcomm/comm_sock.c:1167:9: error: expected ';' before 'ip_multicast_ttl' libcomm/comm_sock.c:1170:10: error: 'ip_multicast_ttl' undeclared (first use in this function) libcomm/comm_sock.c: In function 'comm_set_bindtodevice': libcomm/comm_sock.c:1298:21: error: 'IFNAMSIZ' undeclared (first use in this function) -----Original Message----- From: Ben Greear [mailto:greearb at candelatech.com] Sent: Tuesday, September 13, 2011 1:51 PM To: Joe Coco Cc: Steven Simpson; xorp-hackers at icir.org Subject: Re: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs On 09/13/2011 09:48 AM, Joe Coco wrote: > Explodes on one of my systems as well. Errors are identical. 32bit, linux 2.6.32, glibc 2.3, Pentium4. Mine will compile that file if I pass -std=c99 to the gcc options. I'll try adding that globally and see if that works elsewhere as well... Anyone see any problems with using that? Thanks, Ben > > -- Joe > > -----Original Message----- > From: xorp-hackers-bounces at icir.org > [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Ben Greear > Sent: Tuesday, September 13, 2011 12:29 PM > To: Steven Simpson > Cc: xorp-hackers at icir.org > Subject: Re: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 > format in XRLs > > On 09/13/2011 09:21 AM, Steven Simpson wrote: >> On 13/09/11 17:14, Ben Greear wrote: >>> ./libxipc/xrl_atom.hh: In constructor ???XrlAtom::XrlAtom(const >>> fp64_t&)???: >>> ./libxipc/xrl_atom.hh:336: warning: converting to ???uint64_t??? >>> from ???const double??? >> >> D'oh! >> >> // fp64 constructors >> explicit XrlAtom(const fp64_t& value) >> : _type(xrlatom_fp64), _have_data(true), _own(true), _u64val(value) >> {} >> >> That _u64val should, of course, be _fp64val! > > I figured that...but then it blows up again: > > Maybe something funky with how math.h works on this system... > > cc1: warnings being treated as errors > libxipc/fp64serial.c: In function ?fp64enc?: > libxipc/fp64serial.c:58: warning: implicit declaration of function ?fpclassify? > libxipc/fp64serial.c:58: warning: nested extern declaration of ?fpclassify? > libxipc/fp64serial.c:63: error: ?FP_ZERO? undeclared (first use in > this function) > libxipc/fp64serial.c:63: error: (Each undeclared identifier is > reported only once > libxipc/fp64serial.c:63: error: for each function it appears in.) > libxipc/fp64serial.c:64: warning: implicit declaration of function ?signbit? > libxipc/fp64serial.c:69: error: ?FP_INFINITE? undeclared (first use in > this function) > libxipc/fp64serial.c:75: error: ?FP_NAN? undeclared (first use in this > function) > libxipc/fp64serial.c:81: error: ?FP_SUBNORMAL? undeclared (first use > in this function) > libxipc/fp64serial.c:82: error: ?FP_NORMAL? undeclared (first use in > this function) > libxipc/fp64serial.c: In function ?fp64dec?: > libxipc/fp64serial.c:151: error: ?INFINITY? undeclared (first use in > this function) > libxipc/fp64serial.c:152: error: ?NAN? undeclared (first use in this > function) > scons: *** [obj/i686-pc-linux-gnu/libxipc/fp64serial.os] Error 1 > scons: building terminated because of errors. > >> >> Sorry! >> >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Tue Sep 13 11:19:49 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 13 Sep 2011 11:19:49 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <9513B0D809E3024A85A611E9B3726CA99B94DA@MECnetExchange.mecnet.net> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> <4E6F815C.1010102@candelatech.com> <4E6F8317.1060008@comp.lancs.ac.uk> <4E6F84D3.4000305@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B9430@MECnetExchange.mecnet.net> <4E6F97FF.1050503@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B94DA@MECnetExchange.mecnet.net> Message-ID: <4E6F9EC5.2020009@candelatech.com> On 09/13/2011 11:14 AM, Joe Coco wrote: > That got me as far as here: > > libcomm/comm_sock.c: In function 'comm_sock_bind4': > libcomm/comm_sock.c:302:28: error: 'u_char' undeclared (first use in this function) I'm trying to hack through these now... Ben > libcomm/comm_sock.c:302:28: note: each undeclared identifier is reported only once for each function it appears in > libcomm/comm_sock.c:302:35: error: expected ';' before 'family' > libcomm/comm_sock.c: In function 'comm_sock_bind6': > libcomm/comm_sock.c:342:30: error: 'u_char' undeclared (first use in this function) > libcomm/comm_sock.c:342:37: error: expected ';' before 'family' > libcomm/comm_sock.c: In function 'comm_sock_connect4': > libcomm/comm_sock.c:584:28: error: 'u_char' undeclared (first use in this function) > libcomm/comm_sock.c:584:35: error: expected ';' before 'family' > libcomm/comm_sock.c: In function 'comm_sock_connect6': > libcomm/comm_sock.c:640:30: error: 'u_char' undeclared (first use in this function) > libcomm/comm_sock.c:640:37: error: expected ';' before 'family' > libcomm/comm_sock.c: In function 'comm_set_loopback': > libcomm/comm_sock.c:981:2: error: 'u_char' undeclared (first use in this function) > libcomm/comm_sock.c:981:9: error: expected ';' before 'loop' > libcomm/comm_sock.c:984:10: error: 'loop' undeclared (first use in this function) > libcomm/comm_sock.c: In function 'comm_set_multicast_ttl': > libcomm/comm_sock.c:1167:2: error: 'u_char' undeclared (first use in this function) > libcomm/comm_sock.c:1167:9: error: expected ';' before 'ip_multicast_ttl' > libcomm/comm_sock.c:1170:10: error: 'ip_multicast_ttl' undeclared (first use in this function) > libcomm/comm_sock.c: In function 'comm_set_bindtodevice': > libcomm/comm_sock.c:1298:21: error: 'IFNAMSIZ' undeclared (first use in this function) > > -----Original Message----- > From: Ben Greear [mailto:greearb at candelatech.com] > Sent: Tuesday, September 13, 2011 1:51 PM > To: Joe Coco > Cc: Steven Simpson; xorp-hackers at icir.org > Subject: Re: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs > > On 09/13/2011 09:48 AM, Joe Coco wrote: >> Explodes on one of my systems as well. Errors are identical. 32bit, linux 2.6.32, glibc 2.3, Pentium4. > > Mine will compile that file if I pass -std=c99 to the gcc options. I'll try adding that globally and see if that works elsewhere as well... > > Anyone see any problems with using that? > > Thanks, > Ben > >> >> -- Joe >> >> -----Original Message----- >> From: xorp-hackers-bounces at icir.org >> [mailto:xorp-hackers-bounces at icir.org] On Behalf Of Ben Greear >> Sent: Tuesday, September 13, 2011 12:29 PM >> To: Steven Simpson >> Cc: xorp-hackers at icir.org >> Subject: Re: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 >> format in XRLs >> >> On 09/13/2011 09:21 AM, Steven Simpson wrote: >>> On 13/09/11 17:14, Ben Greear wrote: >>>> ./libxipc/xrl_atom.hh: In constructor ???XrlAtom::XrlAtom(const >>>> fp64_t&)???: >>>> ./libxipc/xrl_atom.hh:336: warning: converting to ???uint64_t??? >>>> from ???const double??? >>> >>> D'oh! >>> >>> // fp64 constructors >>> explicit XrlAtom(const fp64_t& value) >>> : _type(xrlatom_fp64), _have_data(true), _own(true), _u64val(value) >>> {} >>> >>> That _u64val should, of course, be _fp64val! >> >> I figured that...but then it blows up again: >> >> Maybe something funky with how math.h works on this system... >> >> cc1: warnings being treated as errors >> libxipc/fp64serial.c: In function ?fp64enc?: >> libxipc/fp64serial.c:58: warning: implicit declaration of function ?fpclassify? >> libxipc/fp64serial.c:58: warning: nested extern declaration of ?fpclassify? >> libxipc/fp64serial.c:63: error: ?FP_ZERO? undeclared (first use in >> this function) >> libxipc/fp64serial.c:63: error: (Each undeclared identifier is >> reported only once >> libxipc/fp64serial.c:63: error: for each function it appears in.) >> libxipc/fp64serial.c:64: warning: implicit declaration of function ?signbit? >> libxipc/fp64serial.c:69: error: ?FP_INFINITE? undeclared (first use in >> this function) >> libxipc/fp64serial.c:75: error: ?FP_NAN? undeclared (first use in this >> function) >> libxipc/fp64serial.c:81: error: ?FP_SUBNORMAL? undeclared (first use >> in this function) >> libxipc/fp64serial.c:82: error: ?FP_NORMAL? undeclared (first use in >> this function) >> libxipc/fp64serial.c: In function ?fp64dec?: >> libxipc/fp64serial.c:151: error: ?INFINITY? undeclared (first use in >> this function) >> libxipc/fp64serial.c:152: error: ?NAN? undeclared (first use in this >> function) >> scons: *** [obj/i686-pc-linux-gnu/libxipc/fp64serial.os] Error 1 >> scons: building terminated because of errors. >> >>> >>> Sorry! >>> >>> _______________________________________________ >>> Xorp-hackers mailing list >>> Xorp-hackers at icir.org >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> >> >> -- >> Ben Greear >> Candela Technologies Inc http://www.candelatech.com >> >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ss at comp.lancs.ac.uk Tue Sep 13 11:28:18 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Tue, 13 Sep 2011 19:28:18 +0100 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E6F9EC5.2020009@candelatech.com> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> <4E6F815C.1010102@candelatech.com> <4E6F8317.1060008@comp.lancs.ac.uk> <4E6F84D3.4000305@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B9430@MECnetExchange.mecnet.net> <4E6F97FF.1050503@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B94DA@MECnetExchange.mecnet.net> <4E6F9EC5.2020009@candelatech.com> Message-ID: <4E6FA0C2.3010804@comp.lancs.ac.uk> On 13/09/11 19:19, Ben Greear wrote: > On 09/13/2011 11:14 AM, Joe Coco wrote: >> That got me as far as here: >> >> libcomm/comm_sock.c: In function 'comm_sock_bind4': >> libcomm/comm_sock.c:302:28: error: 'u_char' undeclared (first use in >> this function) > > I'm trying to hack through these now... I have managed to make the fp64*.* files compile with -std=c89 as well as -std=c99. That might save you some hackery. Patch due. > >> libcomm/comm_sock.c:302:28: note: each undeclared identifier is >> reported only once for each function it appears in >> libcomm/comm_sock.c:302:35: error: expected ';' before 'family' >> libcomm/comm_sock.c: In function 'comm_sock_bind6': >> libcomm/comm_sock.c:342:30: error: 'u_char' undeclared (first use in >> this function) Tried with -std=gnu89? From greearb at candelatech.com Tue Sep 13 11:32:13 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 13 Sep 2011 11:32:13 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E6FA0C2.3010804@comp.lancs.ac.uk> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> <4E6F815C.1010102@candelatech.com> <4E6F8317.1060008@comp.lancs.ac.uk> <4E6F84D3.4000305@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B9430@MECnetExchange.mecnet.net> <4E6F97FF.1050503@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B94DA@MECnetExchange.mecnet.net> <4E6F9EC5.2020009@candelatech.com> <4E6FA0C2.3010804@comp.lancs.ac.uk> Message-ID: <4E6FA1AD.3020506@candelatech.com> On 09/13/2011 11:28 AM, Steven Simpson wrote: > On 13/09/11 19:19, Ben Greear wrote: >> On 09/13/2011 11:14 AM, Joe Coco wrote: >>> That got me as far as here: >>> >>> libcomm/comm_sock.c: In function 'comm_sock_bind4': >>> libcomm/comm_sock.c:302:28: error: 'u_char' undeclared (first use in >>> this function) >> >> I'm trying to hack through these now... > > I have managed to make the fp64*.* files compile with -std=c89 as well > as -std=c99. That might save you some hackery. Patch due. I'd like to not have to use things liek -std=foo, so looking forward to your patch... Thanks, Ben > >> >>> libcomm/comm_sock.c:302:28: note: each undeclared identifier is >>> reported only once for each function it appears in >>> libcomm/comm_sock.c:302:35: error: expected ';' before 'family' >>> libcomm/comm_sock.c: In function 'comm_sock_bind6': >>> libcomm/comm_sock.c:342:30: error: 'u_char' undeclared (first use in >>> this function) > > Tried with -std=gnu89? > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ss at comp.lancs.ac.uk Tue Sep 13 11:33:25 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Tue, 13 Sep 2011 19:33:25 +0100 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in In-Reply-To: <4E6FA0C2.3010804@comp.lancs.ac.uk> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> <4E6F815C.1010102@candelatech.com> <4E6F8317.1060008@comp.lancs.ac.uk> <4E6F84D3.4000305@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B9430@MECnetExchange.mecnet.net> <4E6F97FF.1050503@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B94DA@MECnetExchange.mecnet.net> <4E6F9EC5.2020009@candelatech.com> <4E6FA0C2.3010804@comp.lancs.ac.uk> Message-ID: <4E6FA1F5.9020705@comp.lancs.ac.uk> On 13/09/11 19:28, Steven Simpson wrote: >>> libcomm/comm_sock.c:302:28: note: each undeclared identifier is >>> reported only once for each function it appears in >>> libcomm/comm_sock.c:302:35: error: expected ';' before 'family' >>> libcomm/comm_sock.c: In function 'comm_sock_bind6': >>> libcomm/comm_sock.c:342:30: error: 'u_char' undeclared (first use in >>> this function) > Tried with -std=gnu89? Err, gnu99. From greearb at candelatech.com Tue Sep 13 11:59:10 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 13 Sep 2011 11:59:10 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in In-Reply-To: <4E6FA1F5.9020705@comp.lancs.ac.uk> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> <4E6F815C.1010102@candelatech.com> <4E6F8317.1060008@comp.lancs.ac.uk> <4E6F84D3.4000305@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B9430@MECnetExchange.mecnet.net> <4E6F97FF.1050503@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B94DA@MECnetExchange.mecnet.net> <4E6F9EC5.2020009@candelatech.com> <4E6FA0C2.3010804@comp.lancs.ac.uk> <4E6FA1F5.9020705@comp.lancs.ac.uk> Message-ID: <4E6FA7FE.9030404@candelatech.com> On 09/13/2011 11:33 AM, Steven Simpson wrote: > On 13/09/11 19:28, Steven Simpson wrote: >>>> libcomm/comm_sock.c:302:28: note: each undeclared identifier is >>>> reported only once for each function it appears in >>>> libcomm/comm_sock.c:302:35: error: expected ';' before 'family' >>>> libcomm/comm_sock.c: In function 'comm_sock_bind6': >>>> libcomm/comm_sock.c:342:30: error: 'u_char' undeclared (first use in >>>> this function) >> Tried with -std=gnu89? > > Err, gnu99. -std=gnu99 with the typo fix compiles. If we have to, we can conditionally enabled -std=gnu99 for systems that require it, with some sort of scons logic to figure out when it's needed. Still, if you have a fix that doesn't require any -std=foo options, I think that is probably preferable.. Thanks, Ben > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Tue Sep 13 13:07:52 2011 From: noreply at github.com (noreply at github.com) Date: Tue, 13 Sep 2011 13:07:52 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] dbee89: Fix compile breakage due to fpnotify. Message-ID: <20110913200752.ABAFB424B0@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: dbee89622c4f057fca3220dc3d41bc3cd3816cb7 https://github.com/greearb/xorp.ct/commit/dbee89622c4f057fca3220dc3d41bc3cd3816cb7 Author: Ben Greear Date: 2011-09-13 (Tue, 13 Sep 2011) Changed paths: M xorp/libxipc/xrl_atom.hh M xorp/site_scons/config/allconfig.py Log Message: ----------- Fix compile breakage due to fpnotify. On older systems (Fedora 8 in my case), we need -std=gnu99 for fpnotify to be found. Add scons logic to add this if we detect it is needed. Hopefully no one is using a compiler that needs something different! Also fix typo in the floating-point serialization logic. Signed-off-by: Ben Greear From noreply at github.com Tue Sep 13 14:05:48 2011 From: noreply at github.com (noreply at github.com) Date: Tue, 13 Sep 2011 14:05:48 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] cd05de: mcast: Add checks for inet6_option_space Message-ID: <20110913210548.011AA425B5@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: cd05de167c6a9f27c4a0bbfe5eb9791af25bb3c8 https://github.com/greearb/xorp.ct/commit/cd05de167c6a9f27c4a0bbfe5eb9791af25bb3c8 Author: Ben Greear Date: 2011-09-13 (Tue, 13 Sep 2011) Changed paths: M xorp/fea/data_plane/io/io_ip_socket.cc M xorp/fea/mfea_osdep.hh M xorp/site_scons/config/allconfig.py Log Message: ----------- mcast: Add checks for inet6_option_space This code is only used if RFC3542 is not available. Warn user if neither are available, and don't try to use inet6_option_* methods if they are not available. Reported-by: Joe Coco Signed-off-by: Ben Greear From greearb at candelatech.com Tue Sep 13 14:08:44 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 13 Sep 2011 14:08:44 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in In-Reply-To: <4E6FA7FE.9030404@candelatech.com> References: <4E68E8C0.9070000@candelatech.com> <1315829410-20153-1-git-send-email-ss@comp.lancs.ac.uk> <4E6F815C.1010102@candelatech.com> <4E6F8317.1060008@comp.lancs.ac.uk> <4E6F84D3.4000305@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B9430@MECnetExchange.mecnet.net> <4E6F97FF.1050503@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99B94DA@MECnetExchange.mecnet.net> <4E6F9EC5.2020009@candelatech.com> <4E6FA0C2.3010804@comp.lancs.ac.uk> <4E6FA1F5.9020705@comp.lancs.ac.uk> <4E6FA7FE.9030404@candelatech.com> Message-ID: <4E6FC65C.7090802@candelatech.com> On 09/13/2011 11:59 AM, Ben Greear wrote: > On 09/13/2011 11:33 AM, Steven Simpson wrote: >> On 13/09/11 19:28, Steven Simpson wrote: >>>>> libcomm/comm_sock.c:302:28: note: each undeclared identifier is >>>>> reported only once for each function it appears in >>>>> libcomm/comm_sock.c:302:35: error: expected ';' before 'family' >>>>> libcomm/comm_sock.c: In function 'comm_sock_bind6': >>>>> libcomm/comm_sock.c:342:30: error: 'u_char' undeclared (first use in >>>>> this function) >>> Tried with -std=gnu89? >> >> Err, gnu99. > > -std=gnu99 with the typo fix compiles. If we have to, we can conditionally > enabled -std=gnu99 for systems that require it, with some sort of scons > logic to figure out when it's needed. > > Still, if you have a fix that doesn't require any -std=foo options, I think that > is probably preferable.. I pushed a fix that conditionally uses -std=gnu99, looks good so far. But, wouldn't mind backing that out if you have a different cure that requires no compiler flags. Thanks, Ben > > Thanks, > Ben > >> >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ss at comp.lancs.ac.uk Tue Sep 13 14:50:18 2011 From: ss at comp.lancs.ac.uk (ss at comp.lancs.ac.uk) Date: Tue, 13 Sep 2011 22:50:18 +0100 Subject: [Xorp-hackers] [PATCH] Made fp64 serialization compatible with pre-C99. In-Reply-To: <4E6FC65C.7090802@candelatech.com> References: <4E6FC65C.7090802@candelatech.com> Message-ID: <1315950618-13953-1-git-send-email-ss@comp.lancs.ac.uk> From: Steven Simpson * Copyright blocks use /* */, not //. * Macros to build type-specific function names and macros don't add any suffix. * Feature macros tested for presence of fpclassify. Basic implementation used when not present. * Feature macros tested for presence of signbit. Basic implementation used when not present. * Optional INFINITY detected; HUGE_VAL used instead. * Lack of NAN detected; HUGE_VAL used instead. Signed-off-by: Steven Simpson --- xorp/libxipc/fp64.h | 55 ++++++++++++++++--------- xorp/libxipc/fp64serial.c | 95 +++++++++++++++++++++++++++++++++++---------- xorp/libxipc/fp64serial.h | 40 ++++++++++--------- 3 files changed, 130 insertions(+), 60 deletions(-) diff --git a/xorp/libxipc/fp64.h b/xorp/libxipc/fp64.h index 8d44239..335c73a 100644 --- a/xorp/libxipc/fp64.h +++ b/xorp/libxipc/fp64.h @@ -1,23 +1,25 @@ -// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- -// vim:set sts=4 ts=8: - -// Copyright (c) 2001-2011 XORP, Inc and Others -// -// This program is free software; you can redistribute it and/or modify -// it under the terms of the GNU Lesser General Public License, Version -// 2.1, June 1999 as published by the Free Software Foundation. -// Redistribution and/or modification of this program under the terms of -// any other version of the GNU Lesser General Public License is not -// permitted. -// -// This program is distributed in the hope that it will be useful, but -// WITHOUT ANY WARRANTY; without even the implied warranty of -// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, -// see the GNU Lesser General Public License, Version 2.1, a copy of -// which can be found in the XORP LICENSE.lgpl file. -// -// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; -// http://xorp.net +/* -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- + * vim:set sts=4 ts=8: */ + +/* + * Copyright (c) 2001-2011 XORP, Inc and Others + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License, Version + * 2.1, June 1999 as published by the Free Software Foundation. + * Redistribution and/or modification of this program under the terms of + * any other version of the GNU Lesser General Public License is not + * permitted. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, + * see the GNU Lesser General Public License, Version 2.1, a copy of + * which can be found in the XORP LICENSE.lgpl file. + * + * XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; + * http://xorp.net + */ #ifndef __LIBXIPC_FP64_H__ #define __LIBXIPC_FP64_H__ @@ -128,7 +130,13 @@ typedef float fp64_t; #define XORP_SCNeFP64 "e" #define XORP_SCNfFP64 "f" #define XORP_SCNgFP64 "g" +#if __STDC_VERSION__ >= 199901L #define XORP_FP64(F) F ## f +#define XORP_FP64UC(FN) FN ## F +#else +#define XORP_FP64(F) F +#define XORP_FP64UC(FN) FN +#endif #define XORP_FP64_DIG FLT_FP64_DIG #define XORP_FP64_EPSILON FLT_FP64_EPSILON #define XORP_FP64_MANT_DIG FLT_FP64_MANT_DIG @@ -155,6 +163,7 @@ typedef double fp64_t; #define XORP_SCNfFP64 "lf" #define XORP_SCNgFP64 "lg" #define XORP_FP64(F) F +#define XORP_FP64UC(F) F #define XORP_FP64_DIG DBL_FP64_DIG #define XORP_FP64_EPSILON DBL_FP64_EPSILON #define XORP_FP64_MANT_DIG DBL_FP64_MANT_DIG @@ -180,7 +189,13 @@ typedef long double fp64_t; #define XORP_SCNeFP64 "Le" #define XORP_SCNfFP64 "Lf" #define XORP_SCNgFP64 "Lg" +#if __STDC_VERSION__ >= 199901L #define XORP_FP64(F) F ## l +#define XORP_FP64UC(F) F ## L +#else +#define XORP_FP64(F) F +#define XORP_FP64UC(F) F +#endif #define XORP_FP64_DIG LDBL_FP64_DIG #define XORP_FP64_EPSILON LDBL_FP64_EPSILON #define XORP_FP64_MANT_DIG LDBL_FP64_MANT_DIG diff --git a/xorp/libxipc/fp64serial.c b/xorp/libxipc/fp64serial.c index c943ef3..fde5149 100644 --- a/xorp/libxipc/fp64serial.c +++ b/xorp/libxipc/fp64serial.c @@ -1,23 +1,25 @@ -// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- -// vim:set sts=4 ts=8: - -// Copyright (c) 2001-2011 XORP, Inc and Others -// -// This program is free software; you can redistribute it and/or modify -// it under the terms of the GNU Lesser General Public License, Version -// 2.1, June 1999 as published by the Free Software Foundation. -// Redistribution and/or modification of this program under the terms of -// any other version of the GNU Lesser General Public License is not -// permitted. -// -// This program is distributed in the hope that it will be useful, but -// WITHOUT ANY WARRANTY; without even the implied warranty of -// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, -// see the GNU Lesser General Public License, Version 2.1, a copy of -// which can be found in the XORP LICENSE.lgpl file. -// -// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; -// http://xorp.net +/* -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- + * vim:set sts=4 ts=8: */ + +/* + * Copyright (c) 2001-2011 XORP, Inc and Others + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License, Version + * 2.1, June 1999 as published by the Free Software Foundation. + * Redistribution and/or modification of this program under the terms of + * any other version of the GNU Lesser General Public License is not + * permitted. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, + * see the GNU Lesser General Public License, Version 2.1, a copy of + * which can be found in the XORP LICENSE.lgpl file. + * + * XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; + * http://xorp.net + */ #include #include @@ -44,6 +46,48 @@ /* How much is the exponent biased? */ #define EXPONENT_BIAS ((EXPONENT_MASK >> 1u) - 1u) +#if __STDC_VERSION__ >= 199901L || \ + _XOPEN_SOURCE >= 600 || \ + _ISOC99_SOURCE || \ + _POSIX_C_SOURCE >= 200112L + +/* fpclassify is available. */ +#else +/* We can't guarantee that fpclassify exists, so define a simple + implementation that at least picks out zero. */ +#undef FP_ZERO +#undef FP_INFINITE +#undef FP_NAN +#undef FP_NORMAL +#undef FP_SUBNORMAL +#undef fpclassify + +#define FP_ZERO 0 +#define FP_INFINITE 1 +#define FP_NAN 2 +#define FP_NORMAL 3 +#define FP_SUBNORMAL 4 + +#define fpclassify(X) \ + ((X) == 0.0 ? FP_ZERO : \ + (X) >= +XORP_FP64UC(HUGE_VAL) ? FP_INFINITE : \ + (X) <= -XORP_FP64UC(HUGE_VAL) ? FP_INFINITE : \ + (X) != (X) ? FP_NAN : \ + FP_NORMAL) +#endif + + +#if __STDC_VERSION__ >= 199901L || \ + _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE || _POSIX_C_SOURCE >= 200112L +/* signbit is available. */ +#else +/* We can't guarantee that signbit exists. Define a simple + implementation that probably won't do worse than fail to detect -ve + zero. */ +#undef signbit +#define signbit(X) ((X) < 0) + +#endif uint_fast64_t fp64enc(fp64_t input) { @@ -146,9 +190,18 @@ fp64_t fp64dec(uint_fast64_t bytes) neg = (bytes >> SIGN_SHIFT) & SIGN_MASK; if (u_exp == EXPONENT_MASK) { - if (u_mant == 0) + if (u_mant == 0) { +#ifdef INFINITY return neg ? -INFINITY : +INFINITY; +#else + return neg ? -XORP_FP64UC(HUGE_VAL) : +XORP_FP64UC(HUGE_VAL); +#endif + } +#ifdef NAN return NAN; +#else + return HUGE_VAL; +#endif } diff --git a/xorp/libxipc/fp64serial.h b/xorp/libxipc/fp64serial.h index 03d1daa..ccbd299 100644 --- a/xorp/libxipc/fp64serial.h +++ b/xorp/libxipc/fp64serial.h @@ -1,23 +1,25 @@ -// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- -// vim:set sts=4 ts=8: +/* -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- + * vim:set sts=4 ts=8: */ -// Copyright (c) 2001-2011 XORP, Inc and Others -// -// This program is free software; you can redistribute it and/or modify -// it under the terms of the GNU Lesser General Public License, Version -// 2.1, June 1999 as published by the Free Software Foundation. -// Redistribution and/or modification of this program under the terms of -// any other version of the GNU Lesser General Public License is not -// permitted. -// -// This program is distributed in the hope that it will be useful, but -// WITHOUT ANY WARRANTY; without even the implied warranty of -// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, -// see the GNU Lesser General Public License, Version 2.1, a copy of -// which can be found in the XORP LICENSE.lgpl file. -// -// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; -// http://xorp.net +/* + * Copyright (c) 2001-2011 XORP, Inc and Others + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License, Version + * 2.1, June 1999 as published by the Free Software Foundation. + * Redistribution and/or modification of this program under the terms of + * any other version of the GNU Lesser General Public License is not + * permitted. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, + * see the GNU Lesser General Public License, Version 2.1, a copy of + * which can be found in the XORP LICENSE.lgpl file. + * + * XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; + * http://xorp.net + */ #ifndef __LIBXIPC_FP64SERIAL_H__ #define __LIBXIPC_FP64SERIAL_H__ -- 1.7.4.1 From noreply at github.com Wed Sep 14 09:24:00 2011 From: noreply at github.com (noreply at github.com) Date: Wed, 14 Sep 2011 09:24:00 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 1e84c2: Made fp64 serialization compatible with pre-C99. Message-ID: <20110914162400.34750426AD@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 1e84c22dd64873f4ec2625b8ca789ff640bcf679 https://github.com/greearb/xorp.ct/commit/1e84c22dd64873f4ec2625b8ca789ff640bcf679 Author: Steven Simpson Date: 2011-09-14 (Wed, 14 Sep 2011) Changed paths: M xorp/libxipc/fp64.h M xorp/libxipc/fp64serial.c M xorp/libxipc/fp64serial.h Log Message: ----------- Made fp64 serialization compatible with pre-C99. * Copyright blocks use /* */, not //. * Macros to build type-specific function names and macros don't add any suffix. * Feature macros tested for presence of fpclassify. Basic implementation used when not present. * Feature macros tested for presence of signbit. Basic implementation used when not present. * Optional INFINITY detected; HUGE_VAL used instead. * Lack of NAN detected; HUGE_VAL used instead. Signed-off-by: Steven Simpson From noreply at github.com Fri Sep 16 16:53:37 2011 From: noreply at github.com (noreply at github.com) Date: Fri, 16 Sep 2011 16:53:37 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] e341d6: pim: Use pointers instead of references for membe... Message-ID: <20110916235337.AA4C6428BE@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: e341d699bb57e3e3d7d66f1bb9ff30461e733410 https://github.com/greearb/xorp.ct/commit/e341d699bb57e3e3d7d66f1bb9ff30461e733410 Author: Ben Greear Date: 2011-09-16 (Fri, 16 Sep 2011) Changed paths: M xorp/pim/pim_mfc.cc M xorp/pim/pim_mfc.hh M xorp/pim/pim_mre.cc M xorp/pim/pim_mre.hh M xorp/pim/pim_mre_assert.cc M xorp/pim/pim_mre_data.cc M xorp/pim/pim_mre_join_prune.cc M xorp/pim/pim_mre_register.cc M xorp/pim/pim_mre_rpf.cc M xorp/pim/pim_mre_task.cc M xorp/pim/pim_mre_task.hh M xorp/pim/pim_mre_track_state.cc M xorp/pim/pim_mre_track_state.hh M xorp/pim/pim_mrt.cc M xorp/pim/pim_mrt.hh M xorp/pim/pim_mrt_mfc.cc M xorp/pim/pim_mrt_task.cc M xorp/pim/pim_node.cc M xorp/pim/pim_node.hh Log Message: ----------- pim: Use pointers instead of references for members. pim has a nasty bug that causes pure virtual functions to be called during some destructors. This is probably due to the tangle of class references held in various structs. I believe the way to clean this up is to use pointers and then carefully null them out on teardown and add appropriate checks for null in the destruct sequences. This patch should make no functional change..just change to using pointers. Signed-off-by: Ben Greear Commit: aa3da4a90f3dc351760c8c9fb946e27570d759f5 https://github.com/greearb/xorp.ct/commit/aa3da4a90f3dc351760c8c9fb946e27570d759f5 Author: Ben Greear Date: 2011-09-16 (Fri, 16 Sep 2011) Changed paths: M xorp/pim/pim_node.cc M xorp/pim/pim_node.hh M xorp/pim/xorp_pimsm4.cc M xorp/pim/xorp_pimsm6.cc M xorp/pim/xrl_pim_node.cc M xorp/pim/xrl_pim_node.hh Log Message: ----------- pim: Attempt manual destruction of pim node. This might work around the pure-virtual call. Needs testing and running under valgrind, however. Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/1e84c22...aa3da4a From JoeCoco at mecnet.net Mon Sep 19 05:58:24 2011 From: JoeCoco at mecnet.net (Joe Coco) Date: Mon, 19 Sep 2011 12:58:24 +0000 Subject: [Xorp-hackers] 1.8.4 problems with xorpsh Message-ID: <9513B0D809E3024A85A611E9B3726CA99BC2BC@MECnetExchange.mecnet.net> Hello, So we're seeing this problem. Once you have the router configured, a number of hours or a day later when we run xorpsh from the command prompt we get the following error: Saturn:/Log_Drive# xorpsh Failed to register with router manager process 102 Command failed Failed to close temporary file: /tmp/rtrmgr-xorpsh-3990-Saturn The following files are in /tmp xrl.DfneQu xrl.Dm4fN3 xrl.HRzApF xrl.V3ucPO xrl.fI4sT3 xrl.he3lP3 xrl.l027P5 xrl.p9pZbl The following xorp processes are in the list: 2379 ? S 12:03 xorp_fea 2380 ? S 6:51 xorp_rib 2381 ? S 0:02 xorp_policy 2382 ? S 0:02 xorp_static_routes 2383 ? S 11:02 xorp_bgp 2384 ? Ss 0:48 /usr/local/xorp/sbin/xorp_rtrmgr -b /home/xorp/config.boot -l /var/log/xo Attached is a log file, not sure if it is telling us anything related to this issue. The only way to manage the router at this point is to kill and restart all processes. n Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110919/e3146c51/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: xorp.log Type: application/octet-stream Size: 238401 bytes Desc: xorp.log Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110919/e3146c51/attachment-0001.obj From greearb at candelatech.com Mon Sep 19 09:22:16 2011 From: greearb at candelatech.com (Ben Greear) Date: Mon, 19 Sep 2011 09:22:16 -0700 Subject: [Xorp-hackers] 1.8.4 problems with xorpsh In-Reply-To: <9513B0D809E3024A85A611E9B3726CA99BC2BC@MECnetExchange.mecnet.net> References: <9513B0D809E3024A85A611E9B3726CA99BC2BC@MECnetExchange.mecnet.net> Message-ID: <4E776C38.3060902@candelatech.com> On 09/19/2011 05:58 AM, Joe Coco wrote: > Hello, > > So we?re seeing this problem. Once you have the router configured, a number of hours or a day later when we run xorpsh from the command prompt we get the > following error: > > Saturn:/Log_Drive# xorpsh > > Failed to register with router manager process > > 102 Command failed Failed to close temporary file: /tmp/rtrmgr-xorpsh-3990-Saturn > > The following files are in /tmp > > xrl.DfneQu xrl.Dm4fN3 xrl.HRzApF xrl.V3ucPO xrl.fI4sT3 xrl.he3lP3 xrl.l027P5 xrl.p9pZbl > > The following xorp processes are in the list: > > 2379 ? S 12:03 xorp_fea > > 2380 ? S 6:51 xorp_rib > > 2381 ? S 0:02 xorp_policy > > 2382 ? S 0:02 xorp_static_routes > > 2383 ? S 11:02 xorp_bgp > > 2384 ? Ss 0:48 /usr/local/xorp/sbin/xorp_rtrmgr -b /home/xorp/config.boot -l /var/log/xo > > Attached is a log file, not sure if it is telling us anything related to this issue. I don't see any obvious errors in the logs...but maybe the problem happened before the time covered in these logs? One thing though: It seems we are deleting already-deleted routes very often..multiple per second. Any idea why this is? Are your links in constant heavy modification? Can you have it log to a file so that we have the complete logs available? Also, if that doesn't show an obvious problem, please run strace xorpsh to see what system calls it makes (and which ones fail, perhaps). Finally, you might try increasing the xrl related timeouts by setting the environ vars on this page before starting xorpsh: http://xorp.run.montefiore.ulg.ac.be/latex2wiki/user_manual/environment_variables If increasing timeouts somehow 'fixes' it, then things are still weird, but it gives us some additional information... Thanks, Ben > > The only way to manage the router at this point is to kill and restart all processes. > > nJoe > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From JoeCoco at mecnet.net Mon Sep 19 10:24:21 2011 From: JoeCoco at mecnet.net (Joe Coco) Date: Mon, 19 Sep 2011 17:24:21 +0000 Subject: [Xorp-hackers] 1.8.4 problems with xorpsh In-Reply-To: <4E776C38.3060902@candelatech.com> References: <9513B0D809E3024A85A611E9B3726CA99BC2BC@MECnetExchange.mecnet.net> <4E776C38.3060902@candelatech.com> Message-ID: <9513B0D809E3024A85A611E9B3726CA99BC638@MECnetExchange.mecnet.net> Hi Ben, > I don't see any obvious errors in the logs...but maybe the problem happened before the time covered in these logs? Yeah, I didn't realize that route flap was so bad and was filling up the log. > One thing though: It seems we are deleting already-deleted routes very often..multiple per second. Any idea why this is? Are your links in constant heavy modification? This is a BGP link, and apparently the route for this network (2610:1e0:1f00::/48) keeps flapping. I'm going to contact my peer and find out what is going on. Is there a way I can suppress that route from being logged? -- Joe From greearb at candelatech.com Mon Sep 19 10:54:34 2011 From: greearb at candelatech.com (Ben Greear) Date: Mon, 19 Sep 2011 10:54:34 -0700 Subject: [Xorp-hackers] 1.8.4 problems with xorpsh In-Reply-To: <9513B0D809E3024A85A611E9B3726CA99BC638@MECnetExchange.mecnet.net> References: <9513B0D809E3024A85A611E9B3726CA99BC2BC@MECnetExchange.mecnet.net> <4E776C38.3060902@candelatech.com> <9513B0D809E3024A85A611E9B3726CA99BC638@MECnetExchange.mecnet.net> Message-ID: <4E7781DA.7050302@candelatech.com> On 09/19/2011 10:24 AM, Joe Coco wrote: > Hi Ben, > >> I don't see any obvious errors in the logs...but maybe the problem happened before the time covered in these logs? > > Yeah, I didn't realize that route flap was so bad and was filling up the log. > >> One thing though: It seems we are deleting already-deleted routes very often..multiple per second. Any idea why this is? Are your links in constant heavy modification? > > This is a BGP link, and apparently the route for this network (2610:1e0:1f00::/48) keeps flapping. I'm going to contact my peer and find out what is going on. > Is there a way I can suppress that route from being logged? No, not w/out commenting out that particular bit of code. Thanks, Ben > > -- Joe -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon Sep 19 17:10:46 2011 From: greearb at candelatech.com (Ben Greear) Date: Mon, 19 Sep 2011 17:10:46 -0700 Subject: [Xorp-hackers] xorp callback code replacement? Message-ID: <4E77DA06.5010905@candelatech.com> Hello! While trying to debug some un-related issues, I notice that xorp rtrmgr crashes often under valgrind due to what appears to be callbacks happening on already-deleted objects. This makes me once again think about re-doing the callback logic entirely. My complaints with the current code: * callback code is generated by a python script, and results in templated c++ code that I simply cannot understand. This also makes it very hard to add debugging code as well (say, a string name; object so we can identify callbacks generically, or similar.) * The callbacks take pointers to objects, and there is virtually no way to cleanly remove the callbacks once added if we are deleting an object that might have a reference held by a callback. I am curious if anyone has any suggestions for improving this. My first instinct is to try to hand-write the callback objects, and give them enough smarts to introspect themselves (recursively, as needed) so we can remove callbacks that reference objects we want to free. That may be a huge amount of work, however...so any other ideas are welcome! Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Mon Sep 19 17:27:12 2011 From: noreply at github.com (noreply at github.com) Date: Mon, 19 Sep 2011 17:27:12 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 7801b0: pim: Add some memory debugging. Message-ID: <20110920002712.7EDB84264A@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 7801b00f7c2f4d068fc40a68e4c973b9d61c3b2a https://github.com/greearb/xorp.ct/commit/7801b00f7c2f4d068fc40a68e4c973b9d61c3b2a Author: Ben Greear Date: 2011-09-19 (Mon, 19 Sep 2011) Changed paths: M xorp/libxorp/service.hh M xorp/pim/pim_mre.cc M xorp/pim/pim_mre.hh M xorp/pim/pim_mrt.cc M xorp/pim/pim_mrt.hh M xorp/pim/pim_proto.h Log Message: ----------- pim: Add some memory debugging. I'm seeing crashes in PimMre when accessing _pim_mrt. Perhaps something I caused recently, but also possibly some old bugs that are now more visible... Add some memory debugging logic to help track it down. Signed-off-by: Ben Greear Commit: 7d29e8e05dc2625cc8f9cf6d1a14108b8cbb40ff https://github.com/greearb/xorp.ct/commit/7d29e8e05dc2625cc8f9cf6d1a14108b8cbb40ff Author: Ben Greear Date: 2011-09-19 (Mon, 19 Sep 2011) Changed paths: M xorp/ospf/packet.hh M xorp/ospf/peer.hh Log Message: ----------- ospf: Initialize some variables. This fixes some warnings found by valgrind. Probably not a serious problem, however. Signed-off-by: Ben Greear Commit: b7feb06bab16ec61680d7d568e5b9dfce83af610 https://github.com/greearb/xorp.ct/commit/b7feb06bab16ec61680d7d568e5b9dfce83af610 Author: Ben Greear Date: 2011-09-19 (Mon, 19 Sep 2011) Changed paths: M xorp/libxorp/eventloop.cc M xorp/libxorp/eventloop.hh M xorp/libxorp/run_command.hh M xorp/libxorp/timer.cc M xorp/libxorp/timer.hh Log Message: ----------- libxorp: Allow un-registering timers. This can help objects clean up their timers when they are being destructed. Signed-off-by: Ben Greear Commit: 2a15d7bddb7a0f2ddd8385ab5f6c814e85dcfdac https://github.com/greearb/xorp.ct/commit/2a15d7bddb7a0f2ddd8385ab5f6c814e85dcfdac Author: Ben Greear Date: 2011-09-19 (Mon, 19 Sep 2011) Changed paths: M xorp/mrt/mrt.hh Log Message: ----------- mrt: Initialize iterators to know values. Noticed this while looking for another bug. Signed-off-by: Ben Greear Commit: 0f1a000766845de8964cd2a9e06094628e7af41e https://github.com/greearb/xorp.ct/commit/0f1a000766845de8964cd2a9e06094628e7af41e Author: Ben Greear Date: 2011-09-19 (Mon, 19 Sep 2011) Changed paths: M xorp/rib/protocol.hh M xorp/rib/rib.cc M xorp/rib/rib.hh Log Message: ----------- rib: Fix memory leak in rib. This probably only happens on teardown..found with valgrind. Signed-off-by: Ben Greear Commit: 3405bb487a052c305fba84d7ea62afadc383c614 https://github.com/greearb/xorp.ct/commit/3405bb487a052c305fba84d7ea62afadc383c614 Author: Ben Greear Date: 2011-09-19 (Mon, 19 Sep 2011) Changed paths: M xorp/pim/pim_bsr.hh M xorp/pim/pim_mre.cc M xorp/pim/pim_mre.hh M xorp/pim/pim_node.cc Log Message: ----------- pim: Fix recently added bugs. There were two bugs in the code I recently added to pim. First, the order of variables in PimMre is vital: You have to initialize pim_mrt before you can init some of the others (which use _pim_mrt). The DELETE_BUFFER call needs a check for null. Also, re-ordered the class so that all the data members were private so that it is easier to see data v/s methods in the header file. Signed-off-by: Ben Greear Commit: 519c22cce6551bf298d6a67f0c210c9d81a467d0 https://github.com/greearb/xorp.ct/commit/519c22cce6551bf298d6a67f0c210c9d81a467d0 Author: Ben Greear Date: 2011-09-19 (Mon, 19 Sep 2011) Changed paths: M xorp/rtrmgr/module_manager.cc M xorp/rtrmgr/module_manager.hh M xorp/rtrmgr/task.cc M xorp/rtrmgr/task.hh M xorp/rtrmgr/xorp_client.cc M xorp/rtrmgr/xorp_client.hh Log Message: ----------- rtrmgr: Remove some timers in destructors. While running under valgrind, I found some errors that appeared to be timers firing after their objects were deleted. Explicitly clean up any timers in some of the destructors. Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/aa3da4a...519c22c From noreply at github.com Mon Sep 19 17:28:48 2011 From: noreply at github.com (noreply at github.com) Date: Mon, 19 Sep 2011 17:28:48 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 3bd347: Update copyrights for recently touched files. Message-ID: <20110920002848.E8C8642646@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 3bd3475a0260b8166ac5945021fdacfff92d4b4e https://github.com/greearb/xorp.ct/commit/3bd3475a0260b8166ac5945021fdacfff92d4b4e Author: Ben Greear Date: 2011-09-19 (Mon, 19 Sep 2011) Changed paths: M xorp/fea/mfea_osdep.hh M xorp/libxorp/service.hh M xorp/libxorp/timer.cc M xorp/ospf/packet.hh M xorp/pim/pim_mfc.cc M xorp/pim/pim_mfc.hh M xorp/pim/pim_mre.cc M xorp/pim/pim_mre.hh M xorp/pim/pim_mre_assert.cc M xorp/pim/pim_mre_data.cc M xorp/pim/pim_mre_register.cc M xorp/pim/pim_mre_task.cc M xorp/pim/pim_mrt.cc M xorp/pim/pim_mrt.hh M xorp/pim/pim_mrt_task.cc M xorp/rib/protocol.hh M xorp/rtrmgr/xorp_client.hh Log Message: ----------- Update copyrights for recently touched files. Signed-off-by: Ben Greear From ss at comp.lancs.ac.uk Tue Sep 20 07:02:53 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Tue, 20 Sep 2011 15:02:53 +0100 Subject: [Xorp-hackers] xorp callback code replacement? In-Reply-To: <4E77DA06.5010905@candelatech.com> References: <4E77DA06.5010905@candelatech.com> Message-ID: <4E789D0D.9080602@comp.lancs.ac.uk> Hi Ben, On 20/09/11 01:10, Ben Greear wrote: > * callback code is generated by a python script, and results in > templated c++ code that I simply cannot understand. > This also makes it very hard to add debugging code as well (say, > a string name; object so we can identify callbacks generically, > or similar.) Without native variadic templates (C++0X?), I doubt you can get away from that. However, I notice a little redundancy in libxorp/callback_nodebug.hh (starting at line 275): /** * @short Callback object for member methods with 0 dispatch time * arguments and 0 bound (stored) arguments. */ template struct XorpMemberCallback0B0 : public XorpCallback0 { typedef R (O::*M)() ; XorpMemberCallback0B0(O* o, M m) : XorpCallback0(), _o(o), _m(m) {} R dispatch() { R r = ((*_o).*_m)(); return r; } protected: O* _o; // Callback's target object M _m; // Callback's target method }; First, the dispatch call creates a local 'r' and then returns it. Perhaps it's necessary for some obscure cases, but it should be possible to return directly. Immediately after that, there's a specialised version for returning void: /** * @short Callback object for void member methods with 0 dispatch time * arguments and 0 bound (stored) arguments. */ template struct XorpMemberCallback0B0 : public XorpCallback0 { typedef void (O::*M)() ; XorpMemberCallback0B0(O* o, M m) : XorpCallback0(), _o(o), _m(m) {} void dispatch() { ((*_o).*_m)(); } protected: O* _o; // Callback's target object M _m; // Callback's target method }; I presume it exists because the (now void) dispatch method can't declare the local 'r' for immediate return. However, I noticed when doing the async stuff that you can return a void expression from a void function, so it should be safe[*] to use R=void with the more generic version. If the specialised version can be removed, it should cut down on the size of the generated code, and maybe cut down on required comprehension. [*] I'm extrapolating standard behaviour from the observed behaviour of a particular compiler, but it seems reasonable to be standard given its convenience when used with templates. Just tried this without error: $ cat voidret.cc void m() { } void n() { return m(); } $ g++ -std=c++98 -c voidret.cc > * The callbacks take pointers to objects, and there > is virtually no way to cleanly remove the callbacks once > added if we are deleting an object that might have a reference > held by a callback. It ought to be possible to have callbacks taking ref_ptrs, instead of, or in addition to raw pointers. I think you'll still have to keep the raw-pointer versions, as there will probably be static objects being used as receivers somewhere. Writing XorpMemberCallbackRP0B0 based on XorpMemberCallback0B0, you get: /** * @short Callback object for member methods with 0 dispatch time * arguments and 0 bound (stored) arguments. */ template struct XorpMemberCallbackRP0B0 : public XorpCallback0 { typedef R (O::*M)() ; XorpMemberCallback0B0(ref_ptr o, M m) : XorpCallback0(), _o(o), _m(m) {} R dispatch() { R r = (_o.get()->*_m)(); return r; } protected: ref_ptr _o; // Callback's target object M _m; // Callback's target method }; For ref_ptrs, you'll have to be careful not to allow the callback factory to implicitly make a ref_ptr from a raw one. IOW, you don't want this form: static MyObject obj; MyObject *ptr =&obj; later(callback(ptr,&MyObject::func)); ...to create a ref_ptr over obj, because of some unexpected implicit conversion. Not suggesting there is such a conversion, just to watch out for it. Cheers, Steven From greearb at candelatech.com Tue Sep 20 09:28:25 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 20 Sep 2011 09:28:25 -0700 Subject: [Xorp-hackers] xorp callback code replacement? In-Reply-To: <4E789D0D.9080602@comp.lancs.ac.uk> References: <4E77DA06.5010905@candelatech.com> <4E789D0D.9080602@comp.lancs.ac.uk> Message-ID: <4E78BF29.2060209@candelatech.com> On 09/20/2011 07:02 AM, Steven Simpson wrote: > Hi Ben, > > On 20/09/11 01:10, Ben Greear wrote: >> * callback code is generated by a python script, and results in >> templated c++ code that I simply cannot understand. >> This also makes it very hard to add debugging code as well (say, >> a string name; object so we can identify callbacks generically, >> or similar.) > > Without native variadic templates (C++0X?), I doubt you can get away > from that. However, I notice a little redundancy in > libxorp/callback_nodebug.hh (starting at line 275): I was thinking we'd have a generic Callback object, maybe something like: class Callback { Callback(CallbackArgs* a); /* rv can be NULL if you do not care about return code */ virtual void process(CallbackReturn* rv) = 0; bool hasReferenceTo(CallbackRef* obj); private: CallbackArgs a; }; class CallbackArgs { CallbackArgs(CallbackRef* r); virtual bool hasReferenceTo(CallbackRef* obj); private: CallbackRef* r; }; class CallbackRef { const string& getName() const { return name; } private: string name; }; class CallbackReturn { virtual void getMessageString(string* rv) { }; virtual int getReturnValue() { return 0; } // maybe return an enum instead? }; Code that actually uses callbacks would spend a lot of time implementing CallbackArgs and Callback child classes to do their specific work and hold the pertinent callback-args data. Anything that passes itself in as an object to be accessed by the callback would inherit from CallbackRef. This is primarily to allow easy debugging hooks so when we crash we can at least figure out what callback caused it. Instead of using raw pointers for callback ref, it could be a ref-counted object, but in my opinion, being lazy about memory use often just creates other problems (for instance, if the object is logically deleted from the system, and we reference it in a callback, that could cause all sorts of un-expected behaviour, even if the memory in question is perfectly valid as far as new/delete is concerned.) Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Tue Sep 20 12:04:42 2011 From: noreply at github.com (noreply at github.com) Date: Tue, 20 Sep 2011 12:04:42 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 4a00b6: Update release notes, rls procedure notes. Message-ID: <20110920190443.10D424258C@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 4a00b64008bdda852373208697f1b0bbb10ce5d9 https://github.com/greearb/xorp.ct/commit/4a00b64008bdda852373208697f1b0bbb10ce5d9 Author: Ben Greear Date: 2011-09-20 (Tue, 20 Sep 2011) Changed paths: M xorp/RELEASE_NOTES M xorp/devnotes/release_process.txt Log Message: ----------- Update release notes, rls procedure notes. Signed-off-by: Ben Greear From noreply at github.com Tue Sep 20 12:32:42 2011 From: noreply at github.com (noreply at github.com) Date: Tue, 20 Sep 2011 12:32:42 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 8f4462: Create script to package xorp release files. Message-ID: <20110920193242.248364253E@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 8f44623f0c8ef15a19411eb655471907c379caa5 https://github.com/greearb/xorp.ct/commit/8f44623f0c8ef15a19411eb655471907c379caa5 Author: Ben Greear Date: 2011-09-20 (Tue, 20 Sep 2011) Changed paths: A publish_html.bash Log Message: ----------- Create script to package xorp release files. Signed-off-by: Ben Greear From noreply at github.com Tue Sep 20 14:12:37 2011 From: noreply at github.com (noreply at github.com) Date: Tue, 20 Sep 2011 14:12:37 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 65814f: Update html, release-process notes. Message-ID: <20110920211237.D7A074250D@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 65814fc5278e124c3b9fb6cd87a78ba626fb0200 https://github.com/greearb/xorp.ct/commit/65814fc5278e124c3b9fb6cd87a78ba626fb0200 Author: Ben Greear Date: 2011-09-20 (Tue, 20 Sep 2011) Changed paths: M www/html_src/index.html M www/scripts/XorpOrgGenerator.py M xorp/devnotes/release_process.txt Log Message: ----------- Update html, release-process notes. Going to serve main downloads from the www.xorp.org now. If load ever becomes high, will change link back to source-forge. Sourceforge will still be kept up to date with at least source and windows-binary builds. Signed-off-by: Ben Greear From noreply at github.com Tue Sep 20 14:35:40 2011 From: noreply at github.com (noreply at github.com) Date: Tue, 20 Sep 2011 14:35:40 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 46636d: Add some notes in the rpm building script. Message-ID: <20110920213540.9C2C642444@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 46636d35caa38eb6ad3942a416a8536d85511999 https://github.com/greearb/xorp.ct/commit/46636d35caa38eb6ad3942a416a8536d85511999 Author: Ben Greear Date: 2011-09-20 (Tue, 20 Sep 2011) Changed paths: M xorp/build_rpms.bash Log Message: ----------- Add some notes in the rpm building script. From greearb at candelatech.com Wed Sep 21 10:31:00 2011 From: greearb at candelatech.com (Ben Greear) Date: Wed, 21 Sep 2011 10:31:00 -0700 Subject: [Xorp-hackers] Xorp 1.8.4 is released. Message-ID: <4E7A1F54.7090008@candelatech.com> I have uploaded binaries & source code to www.xorp.org. The downloads link points to xorp.org now instead of SourceForge, but I put the windows binary and source code snapshot on sourceforge and github as well, just in case someone prefers that. Generally, 1.8.4 is mostly a bug-fix release. Here's the release notes highlights: * Add async-XRL support, from Steven Simpson * Fix bug in deleting non-VLAN interface. Commit would fail because the code would attempt to remove the interface from the kernel and fail. * Fix BSD related crash when adding interface with same ifindex as a previous interface. OpenBSD has the nasty habit of re-using the ifindex when creating/deleting virtual interfaces. * Fix multicast bug that totally breaks XORP multicast on recent Linux kernels. The problem is that I chose the wrong default multicast routing table (254, instead of 253 as it should be). So, if users don't specify a routing table, it pokes routes into the wrong table. This wasn't caught in my testing because I always explicitly set the routing table ID. * Add some env variable controlled debugging to the libxorp and libxipc logic for better debugging of xrls and the event loop. Full release notes and change log are available here: http://www.xorp.org/releases/1.8.4/docs/RELEASE_NOTES Please post to the list if you have a chance to try this out, and let us know how it works for you. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Wed Sep 21 11:05:49 2011 From: greearb at candelatech.com (Ben Greear) Date: Wed, 21 Sep 2011 11:05:49 -0700 Subject: [Xorp-hackers] Who maintains the xorp freshmeat entry? Message-ID: <4E7A277D.9060601@candelatech.com> If you are on the list, please send me email. I'd like to make sure I send you email when I do releases so you can update the freshmeat page. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From igorm at etf.rs Fri Sep 23 06:19:09 2011 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Fri, 23 Sep 2011 15:19:09 +0200 Subject: [Xorp-hackers] MPLS + RSVP-TE Message-ID: Hi all, my name is Igor Maravic, and I'm the employee of Innovation Center of School of Electrical Engineering in Belgrade, Serbia. I'm writing to this list, because I started to write MPLS and after that RSVP-TE modules for XORP. MPLS part is going to be based on mpls-linux implementation Any help would be appreciated. Also if you know any MPLS(or RSVP-TE) implementation that was written for XORP, please write me. BR Igor Maravi? From igorm at etf.rs Fri Sep 23 06:43:26 2011 From: igorm at etf.rs (=?utf-8?B?Iklnb3IgTWFyYXZpxIci?=) Date: Fri, 23 Sep 2011 15:43:26 +0200 Subject: [Xorp-hackers] [PATCH] main SConstract bugs Message-ID: <16371486e4d45cc2e1021459345b54c8.squirrel@kondor.etf.bg.ac.rs> When I did "scons install" rtrmngr was looking for .xrls files in folder /xrl/targets not in folder /xorp/xrls, so I changed that. Also I removed ; from if statements. Also only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. BR Igor Maravi? Sigend-off-by: Igor Maravi? --- diff -upNr xorp.orig/SConstruct xorp/SConstruct --- xorp.orig/SConstruct 2011-09-12 20:23:12.000000000 +0200 +++ xorp/SConstruct 2011-09-23 15:28:34.429947091 +0200 @@ -379,30 +379,30 @@ env['xorp_moduledir'] = env['libdir'] env['xorp_sbindir'] = env['sbindir'] # End-user binaries env['xorp_templatedir'] = env['datadir'] + '/templates' env['xorp_tooldir'] = env['libdir'] + '/xorp/bin' # tools/* -env['xorp_xrlsdir'] = env['datadir'] + '/xorp/xrls' # *.xrls +env['xorp_xrlsdir'] = env['datadir'] + '/xrl/targets' # *.xrls env['xorp_sourcedir'] = sourcedir # rtrmgr/util.cc and xif need this tst = ARGUMENTS.get('enable_boost', False) if tst and not (tst == "no"): - env['enable_boost'] = True; + env['enable_boost'] = True else: env['enable_boost'] = False tst = ARGUMENTS.get('enable_ustl', False) if tst and not (tst == "no"): - env['enable_ustl'] = True; + env['enable_ustl'] = True else: env['enable_ustl'] = False tst = ARGUMENTS.get('enable_tests', False) if tst and not (tst == "no"): - env['enable_tests'] = True; + env['enable_tests'] = True else: env['enable_tests'] = False tst = ARGUMENTS.get('enable_click', False) if tst and not (tst == "no"): - env['enable_click'] = True; + env['enable_click'] = True else: env['enable_click'] = False @@ -464,67 +464,67 @@ else: tst = ARGUMENTS.get('disable_ipv6', False) if tst and not (tst == "no"): - env['disable_ipv6'] = True; + env['disable_ipv6'] = True else: env['disable_ipv6'] = False tst = ARGUMENTS.get('disable_fw', False) if tst and not (tst == "no"): - env['disable_fw'] = True; + env['disable_fw'] = True else: env['disable_fw'] = False tst = ARGUMENTS.get('disable_libtecla', False) if tst and not (tst == "no"): - env['disable_libtecla'] = True; + env['disable_libtecla'] = True else: env['disable_libtecla'] = False tst = ARGUMENTS.get('disable_profile', False) if tst and not (tst == "no"): - env['disable_profile'] = True; + env['disable_profile'] = True else: env['disable_profile'] = False tst = ARGUMENTS.get('disable_warninglogs', False) if tst and not (tst == "no"): - env['disable_warninglogs'] = True; + env['disable_warninglogs'] = True else: env['disable_warninglogs'] = False tst = ARGUMENTS.get('disable_errorlogs', False) if tst and not (tst == "no"): - env['disable_errorlogs'] = True; + env['disable_errorlogs'] = True else: env['disable_errorlogs'] = False tst = ARGUMENTS.get('disable_tracelogs', False) if tst and not (tst == "no"): - env['disable_tracelogs'] = True; + env['disable_tracelogs'] = True else: env['disable_tracelogs'] = False tst = ARGUMENTS.get('disable_fatallogs', False) if tst and not (tst == "no"): - env['disable_fatallogs'] = True; + env['disable_fatallogs'] = True else: env['disable_fatallogs'] = False tst = ARGUMENTS.get('disable_infologs', False) if tst and not (tst == "no"): - env['disable_infologs'] = True; + env['disable_infologs'] = True else: env['disable_infologs'] = False tst = ARGUMENTS.get('disable_assertlogs', False) if tst and not (tst == "no"): - env['disable_assertlogs'] = True; + env['disable_assertlogs'] = True else: env['disable_assertlogs'] = False tst = ARGUMENTS.get('disable_otherlogs', False) if tst and not (tst == "no"): - env['disable_otherlogs'] = True; + env['disable_otherlogs'] = True else: env['disable_otherlogs'] = False @@ -713,7 +713,7 @@ if not env['optimize'] == 'override': 'highest': '-O3', 'size': '-Os' } bigoflag = bigodict[env['optimize']] - if not env['optimize'] == 'no': + if not env['optimize'] == 'override': env.AppendUnique(CFLAGS = [ bigoflag ]) env.AppendUnique(CXXFLAGS = [ bigoflag ]) From igorm at etf.rs Fri Sep 23 06:48:00 2011 From: igorm at etf.rs (=?utf-8?B?Iklnb3IgTWFyYXZpxIci?=) Date: Fri, 23 Sep 2011 15:48:00 +0200 Subject: [Xorp-hackers] [PATCH] rtrmngr fixes Message-ID: <973d1d9e45952badf3153ac6c827c6b4.squirrel@kondor.etf.bg.ac.rs> cleaned_xrl should have reference to it. That reference should be argument of functions XRLDB::check_xrl_syntax and XRLDB::check_xrl_exists. Don't know why but it didn't wont to compile with out that fix. VALIDATE_XRLDB should be replaced with DEBUG_XRLDB BR Igor Maravi? Signed-off-by: Igor Maravi? --- diff -upNr xorp.old/rtrmgr/template_commands.cc xorp.mpls/rtrmgr/template_commands.cc --- xorp.old/rtrmgr/template_commands.cc 2011-03-22 22:08:58.000000000 +0100 +++ xorp.mpls/rtrmgr/template_commands.cc 2011-09-08 00:30:24.000000000 +0200 @@ -316,6 +316,7 @@ XrlAction::check_xrl_is_valid(const list // Then we can check it is a valid XRL as known by the XRLdb. // string cleaned_xrl; + const string& refToCleanedXRL = cleaned_xrl; // Trim quotes from around the XRL size_t start = 0; @@ -465,13 +466,14 @@ XrlAction::check_xrl_is_valid(const list } debug_msg("XrlAction after cleaning:\n%s\n", cleaned_xrl.c_str()); - if (xrldb->check_xrl_syntax(cleaned_xrl) == false) { + if (xrldb->check_xrl_syntax(refToCleanedXRL) == false) { error_msg = c_format("Syntax error in module %s XRL %s: " "invalid XRL syntax (check_xrl_syntax failed)", module_name.c_str(), cleaned_xrl.c_str()); return false; } - XRLMatchType match = xrldb->check_xrl_exists(cleaned_xrl); + + XRLMatchType match = xrldb->check_xrl_exists(refToCleanedXRL); switch (match) { case MATCH_FAIL: case MATCH_RSPEC: { diff -upNr xorp.old/rtrmgr/xrldb.cc xorp.mpls/rtrmgr/xrldb.cc --- xorp.old/rtrmgr/xrldb.cc 2011-03-22 22:08:58.000000000 +0100 +++ xorp.mpls/rtrmgr/xrldb.cc 2011-09-07 16:13:24.000000000 +0200 @@ -160,7 +160,7 @@ XRLtarget::str() const XRLdb::XRLdb(const string& xrldir, bool verbose) throw (InitError) : _verbose(verbose) { -#ifdef VALIDATE_XRLDB +#ifdef DEBUG_XRLDB string errmsg; list files; @@ -209,7 +209,7 @@ XRLdb::XRLdb(const string& xrldir, bool #endif } -#ifdef VALIDATE_XRLDB +#ifdef DEBUG_XRLDB bool XRLdb::check_xrl_syntax(const string& xrlstr) const { diff -upNr xorp.old/rtrmgr/xrldb.hh xorp.mpls/rtrmgr/xrldb.hh --- xorp.old/rtrmgr/xrldb.hh 2011-03-22 22:08:58.000000000 +0100 +++ xorp.mpls/rtrmgr/xrldb.hh 2011-09-07 16:05:26.000000000 +0200 @@ -65,7 +65,7 @@ private: class XRLdb { public: XRLdb(const string& xrldir, bool verbose) throw (InitError); -#ifdef VALIDATE_XRLDB +#ifdef DEBUG_XRLDB bool check_xrl_syntax(const string& xrl) const; XRLMatchType check_xrl_exists(const string& xrl) const; #endif From igorm at etf.rs Fri Sep 23 08:15:13 2011 From: igorm at etf.rs (=?utf-8?B?Iklnb3IgTWFyYXZpxIci?=) Date: Fri, 23 Sep 2011 17:15:13 +0200 Subject: [Xorp-hackers] [PATCH] xorp_install script Message-ID: <6452ab63ce541186f7cfa8a71743eac2.squirrel@kondor.etf.bg.ac.rs> When XORP user is initially created with xorp_install.sh script, I think that it is better to create user as system user without home dir. BR Igor Maravi? Signed-off-by: Igor Maravi? --- --- xorp/xorp_install.bash.orig 2011-09-23 17:08:41.405949155 +0200 +++ xorp/xorp_install.bash 2011-09-23 17:05:34.021949091 +0200 @@ -19,7 +19,7 @@ fi # Add xorp user and group echo "Creating xorp user and adding xorp to xorp and root groups..." -adduser xorp +adduser --system --no-create-home xorp usermod -a -G xorp xorp usermod -a -G xorp root usermod -a -G xorp lanforge From greearb at candelatech.com Fri Sep 23 09:05:43 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 23 Sep 2011 09:05:43 -0700 Subject: [Xorp-hackers] [PATCH] rtrmngr fixes In-Reply-To: <973d1d9e45952badf3153ac6c827c6b4.squirrel@kondor.etf.bg.ac.rs> References: <973d1d9e45952badf3153ac6c827c6b4.squirrel@kondor.etf.bg.ac.rs> Message-ID: <4E7CAE57.3070803@candelatech.com> On 09/23/2011 06:48 AM, "Igor Maravi?" wrote: > cleaned_xrl should have reference to it. That reference should be argument of functions XRLDB::check_xrl_syntax and XRLDB::check_xrl_exists. > Don't know why but it didn't wont to compile with out that fix. > > VALIDATE_XRLDB should be replaced with DEBUG_XRLDB > > BR > Igor Maravi? > > Signed-off-by: Igor Maravi? > --- > > diff -upNr xorp.old/rtrmgr/template_commands.cc xorp.mpls/rtrmgr/template_commands.cc > --- xorp.old/rtrmgr/template_commands.cc 2011-03-22 22:08:58.000000000 +0100 > +++ xorp.mpls/rtrmgr/template_commands.cc 2011-09-08 00:30:24.000000000 +0200 > @@ -316,6 +316,7 @@ XrlAction::check_xrl_is_valid(const list > // Then we can check it is a valid XRL as known by the XRLdb. > // > string cleaned_xrl; > + const string& refToCleanedXRL = cleaned_xrl; > > // Trim quotes from around the XRL > size_t start = 0; > @@ -465,13 +466,14 @@ XrlAction::check_xrl_is_valid(const list > } > debug_msg("XrlAction after cleaning:\n%s\n", cleaned_xrl.c_str()); > > - if (xrldb->check_xrl_syntax(cleaned_xrl) == false) { > + if (xrldb->check_xrl_syntax(refToCleanedXRL) == false) { > error_msg = c_format("Syntax error in module %s XRL %s: " > "invalid XRL syntax (check_xrl_syntax failed)", > module_name.c_str(), cleaned_xrl.c_str()); > return false; > } > - XRLMatchType match = xrldb->check_xrl_exists(cleaned_xrl); > + > + XRLMatchType match = xrldb->check_xrl_exists(refToCleanedXRL); > switch (match) { > case MATCH_FAIL: > case MATCH_RSPEC: { What system are you compiling on, and can you show the exact compiler command and errors? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Sep 23 09:10:12 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 23 Sep 2011 09:10:12 -0700 Subject: [Xorp-hackers] [PATCH] main SConstract bugs In-Reply-To: <16371486e4d45cc2e1021459345b54c8.squirrel@kondor.etf.bg.ac.rs> References: <16371486e4d45cc2e1021459345b54c8.squirrel@kondor.etf.bg.ac.rs> Message-ID: <4E7CAF64.6060607@candelatech.com> On 09/23/2011 06:43 AM, "Igor Maravi?" wrote: > When I did "scons install" rtrmngr was looking for .xrls files in folder /xrl/targets not in folder /xorp/xrls, so I changed that. > Also I removed ; from if statements. > Also only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. > When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. Please break this into 3 different patches for these 3 different things. For the .xrls part, what error did you see? I don't see any trouble with 'scons install' on my systems. What command are you using for the compile? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Fri Sep 23 09:34:12 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 23 Sep 2011 09:34:12 -0700 Subject: [Xorp-hackers] [PATCH] xorp_install script In-Reply-To: <6452ab63ce541186f7cfa8a71743eac2.squirrel@kondor.etf.bg.ac.rs> References: <6452ab63ce541186f7cfa8a71743eac2.squirrel@kondor.etf.bg.ac.rs> Message-ID: <4E7CB504.9010900@candelatech.com> On 09/23/2011 08:15 AM, "Igor Maravi?" wrote: > When XORP user is initially created with xorp_install.sh script, I think that it is better to create user as system user without home dir. > BR > Igor Maravi? > > Signed-off-by: Igor Maravi? > --- > --- xorp/xorp_install.bash.orig 2011-09-23 17:08:41.405949155 +0200 > +++ xorp/xorp_install.bash 2011-09-23 17:05:34.021949091 +0200 > @@ -19,7 +19,7 @@ fi > > # Add xorp user and group > echo "Creating xorp user and adding xorp to xorp and root groups..." > -adduser xorp > +adduser --system --no-create-home xorp > usermod -a -G xorp xorp > usermod -a -G xorp root > usermod -a -G xorp lanforge On Fedora Core 5, this does not work. The --no-create-home option is not supported. The -M option appears to be, and it means do not create a home dir. FC5 does not support the --system option either. I've no idea what Debian and similar systems support. If you'd like to make the script smart enough to detect which options are available (maybe try each until something succeeds?), then I'll apply the patch. Otherwise, I'll leave it as it is. Thanks, Ben > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Fri Sep 23 09:48:14 2011 From: noreply at github.com (noreply at github.com) Date: Fri, 23 Sep 2011 09:48:14 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] e9314e: Update version to 1.8.5-WIP Message-ID: <20110923164814.C9E8F42722@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: e9314ec9787f07cabf096a9cd3c164dc6d2157a8 https://github.com/greearb/xorp.ct/commit/e9314ec9787f07cabf096a9cd3c164dc6d2157a8 Author: Ben Greear Date: 2011-09-23 (Fri, 23 Sep 2011) Changed paths: M xorp/Makefile.deb M xorp/VERSION M xorp/devnotes/pkg_xorp.bash M xorp/etc/templates/xorpsh.cmds M xorp/package_files/xorp.ct.spec M xorp/rtrmgr/master_conf_tree.cc Log Message: ----------- Update version to 1.8.5-WIP Starting new dev cycle... Signed-off-by: Ben Greear From noreply at github.com Fri Sep 23 10:32:10 2011 From: noreply at github.com (noreply at github.com) Date: Fri, 23 Sep 2011 10:32:10 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] d82718: ospf: Log peer state changes. Message-ID: <20110923173210.75DF1426CA@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: d8271859d8a5038d5cf0fd2faf971632a16e47ec https://github.com/greearb/xorp.ct/commit/d8271859d8a5038d5cf0fd2faf971632a16e47ec Author: Ben Greear Date: 2011-09-23 (Fri, 23 Sep 2011) Changed paths: M xorp/ospf/peer.cc M xorp/ospf/peer.hh Log Message: ----------- ospf: Log peer state changes. Also, convert pp_state() to return const char* instead of needlessly converting the return value to a string object. Signed-off-by: Ben Greear From noreply at github.com Fri Sep 23 14:26:03 2011 From: noreply at github.com (noreply at github.com) Date: Fri, 23 Sep 2011 14:26:03 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] f1c7c8: fea: Re-arrange netlink parsing logic. Message-ID: <20110923212603.DC03342616@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: f1c7c8cfc27cc6168b5ad38528ae443507a771bd https://github.com/greearb/xorp.ct/commit/f1c7c8cfc27cc6168b5ad38528ae443507a771bd Author: Ben Greear Date: 2011-09-23 (Fri, 23 Sep 2011) Changed paths: M xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc M xorp/fea/data_plane/control_socket/netlink_socket_utilities.hh M xorp/fea/data_plane/ifconfig/SConscript M xorp/fea/data_plane/ifconfig/ifconfig_get_netlink_socket.cc R xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc Log Message: ----------- fea: Re-arrange netlink parsing logic. Move static methods into NlmUtils file, ifconfig_get_netlink_socket method from ifconfig_parse_nelink_socket to ifconfig_get_netlink_socket.cc Should make it easier to find the code in question. Signed-off-by: Ben Greear Commit: efeec217311c0327c594b4b1ce1a07d395c40618 https://github.com/greearb/xorp.ct/commit/efeec217311c0327c594b4b1ce1a07d395c40618 Author: Ben Greear Date: 2011-09-23 (Fri, 23 Sep 2011) Changed paths: M xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc Log Message: ----------- fea: Fix GRE tunnel IP addresses on Linux. The old code used the 'link-level' IP address, ie the IP that GRE is using underneath, as one of the GRE interface's IP addresses. I see no reason to do this, and it appears to mess up multicast over GRE tunnels. Since there were two addresses, it was a bit of a race as to which one won, which might be why sometimes multicast over GRE somewhat worked. Reported-by: J G Miller Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/d827185...efeec21 From noreply at github.com Fri Sep 23 15:11:26 2011 From: noreply at github.com (noreply at github.com) Date: Fri, 23 Sep 2011 15:11:26 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] ce0bda: multicast: Don't crash if interface configured fo... Message-ID: <20110923221126.AD364426FF@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: ce0bda5cc5bcfbc83c8fc328ce8b634d47c9a8d7 https://github.com/greearb/xorp.ct/commit/ce0bda5cc5bcfbc83c8fc328ce8b634d47c9a8d7 Author: Ben Greear Date: 2011-09-23 (Fri, 23 Sep 2011) Changed paths: M xorp/fea/mfea_node.cc M xorp/fea/mfea_vif.cc M xorp/mld6igmp/mld6igmp_vif.cc M xorp/pim/pim_node.cc M xorp/pim/pim_vif.cc Log Message: ----------- multicast: Don't crash if interface configured for mcast doesn't have MULTICAST flag. Old code would return errors, which caused the commit to failed, which killed fea (and mld6igmp and pim). Instead, flag interface as wanting to start and start it later if user figures out that they need to run the equivalent of: interface foo multicast Signed-off-by: Ben Greear From igorm at etf.rs Mon Sep 26 00:59:24 2011 From: igorm at etf.rs (=?utf-8?B?Iklnb3IgTWFyYXZpxIci?=) Date: Mon, 26 Sep 2011 09:59:24 +0200 Subject: [Xorp-hackers] [PATCH] xorp_install script Message-ID: <9498baa19ad76537b1da92a0b7093dd3.squirrel@kondor.etf.bg.ac.rs> > On 09/23/2011 08:15 AM, "Igor Maravi?" wrote: >> When XORP user is initially created with xorp_install.sh script, I think that it is better to create user as system user without home dir. >> BR >> Igor Maravi? >> >> Signed-off-by: Igor Maravi? >> --- >> --- xorp/xorp_install.bash.orig 2011-09-23 17:08:41.405949155 +0200 >> +++ xorp/xorp_install.bash 2011-09-23 17:05:34.021949091 +0200 >> @@ -19,7 +19,7 @@ fi >> >> # Add xorp user and group >> echo "Creating xorp user and adding xorp to xorp and root groups..." >> -adduser xorp >> +adduser --system --no-create-home xorp >> usermod -a -G xorp xorp >> usermod -a -G xorp root >> usermod -a -G xorp lanforge > > On Fedora Core 5, this does not work. The --no-create-home option > is not supported. The -M option appears to be, and it means do > not create a home dir. FC5 does not support the --system option > either. I've no idea what Debian and similar systems > support. > > If you'd like to make the script smart enough to detect which options > are available (maybe try each until something succeeds?), then > I'll apply the patch. > > Otherwise, I'll leave it as it is. > > Thanks, > Ben > >> >> >> _______________________________________________ >> Xorp-hackers mailing list >> Xorp-hackers at icir.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > Here is the patch for smart script! It checks if adduser supports --system and --no-create-home. Checking for -M option could be added, but I don't have fedora to test it. I'm running Ubuntu 11.04 with kernel 2.6.38.8 Signed-off-by: Igor Maravi? --- --- xorp/xorp_install.bash.orig 2011-09-23 17:08:41.405949155 +0200 +++ xorp/xorp_install.bash.new 2011-09-26 09:49:14.000000000 +0200 @@ -18,8 +18,21 @@ if [ `pwd` != "/usr/local/xorp" ] fi # Add xorp user and group + +#Check for adduser commands +adduserArgs="" +if adduser -h | grep ".--system" > /dev/null 2>&1 +then + adduserArgs="$adduserArgs --system" +fi + +if adduser -h | grep ".--no-create-home" > /dev/null 2>&1 +then + adduserArgs="$adduserArgs --no-create-home" +fi + echo "Creating xorp user and adding xorp to xorp and root groups..." -adduser xorp +adduser $adduserArgs xorp usermod -a -G xorp xorp usermod -a -G xorp root usermod -a -G xorp lanforge From igorm at etf.rs Mon Sep 26 01:32:19 2011 From: igorm at etf.rs (=?utf-8?B?Iklnb3IgTWFyYXZpxIci?=) Date: Mon, 26 Sep 2011 10:32:19 +0200 Subject: [Xorp-hackers] [PATCH1/3] main SConstract bugs In-Reply-To: <4E7CAF64.6060607@candelatech.com> References: <16371486e4d45cc2e1021459345b54c8.squirrel@kondor.etf.bg.ac.rs> <4E7CAF64.6060607@candelatech.com> Message-ID: > On 09/23/2011 06:43 AM, "Igor Maravi?" wrote: >> When I did "scons install" rtrmngr was looking for .xrls files in folder /xrl/targets not in folder /xorp/xrls, so I changed that. >> Also I removed ; from if statements. >> Also only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. >> When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. > > Please break this into 3 different patches for these 3 different > things. > > For the .xrls part, what error did you see? I don't see > any trouble with 'scons install' on my systems. What command > are you using for the compile? > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > Only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. Signed-off-by: Igor Maravi? --- diff -upNr xorp.orig/SConstruct xorp/SConstruct --- xorp.orig/SConstruct 2011-09-12 20:23:12.000000000 +0200 +++ xorp/SConstruct 2011-09-23 15:28:34.429947091 +0200 @@ -713,7 +713,7 @@ if not env['optimize'] == 'override': 'highest': '-O3', 'size': '-Os' } bigoflag = bigodict[env['optimize']] - if not env['optimize'] == 'no': + if not env['optimize'] == 'override': env.AppendUnique(CFLAGS = [ bigoflag ]) env.AppendUnique(CXXFLAGS = [ bigoflag ]) From igorm at etf.rs Mon Sep 26 01:43:53 2011 From: igorm at etf.rs (=?utf-8?B?Iklnb3IgTWFyYXZpxIci?=) Date: Mon, 26 Sep 2011 10:43:53 +0200 Subject: [Xorp-hackers] [PATCH] rtrmngr fixes In-Reply-To: <4E7CAE57.3070803@candelatech.com> References: <973d1d9e45952badf3153ac6c827c6b4.squirrel@kondor.etf.bg.ac.rs> <4E7CAE57.3070803@candelatech.com> Message-ID: <23b814ea08324b346d77339c3d978a10.squirrel@kondor.etf.bg.ac.rs> > On 09/23/2011 06:48 AM, "Igor Maravi?" wrote: >> cleaned_xrl should have reference to it. That reference should be argument of functions XRLDB::check_xrl_syntax and XRLDB::check_xrl_exists. >> Don't know why but it didn't wont to compile with out that fix. >> >> VALIDATE_XRLDB should be replaced with DEBUG_XRLDB >> >> BR >> Igor Maravi? >> >> Signed-off-by: Igor Maravi? >> --- >> >> diff -upNr xorp.old/rtrmgr/template_commands.cc xorp.mpls/rtrmgr/template_commands.cc >> --- xorp.old/rtrmgr/template_commands.cc 2011-03-22 22:08:58.000000000 +0100 >> +++ xorp.mpls/rtrmgr/template_commands.cc 2011-09-08 00:30:24.000000000 +0200 >> @@ -316,6 +316,7 @@ XrlAction::check_xrl_is_valid(const list >> // Then we can check it is a valid XRL as known by the XRLdb. >> // >> string cleaned_xrl; >> + const string& refToCleanedXRL = cleaned_xrl; >> >> // Trim quotes from around the XRL >> size_t start = 0; >> @@ -465,13 +466,14 @@ XrlAction::check_xrl_is_valid(const list >> } >> debug_msg("XrlAction after cleaning:\n%s\n", cleaned_xrl.c_str()); >> >> - if (xrldb->check_xrl_syntax(cleaned_xrl) == false) { >> + if (xrldb->check_xrl_syntax(refToCleanedXRL) == false) { >> error_msg = c_format("Syntax error in module %s XRL %s: " >> "invalid XRL syntax (check_xrl_syntax failed)", >> module_name.c_str(), cleaned_xrl.c_str()); >> return false; >> } >> - XRLMatchType match = xrldb->check_xrl_exists(cleaned_xrl); >> + >> + XRLMatchType match = xrldb->check_xrl_exists(refToCleanedXRL); >> switch (match) { >> case MATCH_FAIL: >> case MATCH_RSPEC: { > > What system are you compiling on, and can you show the exact > compiler command and errors? > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > When I compile with scons debug_xrldb=True first error is: g++ -o obj/i686-pc-linux-gnu/rtrmgr/template_commands.o -c -O1 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -DDEBUG_XRLDB=1 -Iobj/i686-pc-linux-gnu -I. -I. rtrmgr/template_commands.cc rtrmgr/template_commands.cc: In member function ?bool XrlAction::check_xrl_is_valid(const std::list >&, const XRLdb*, std::string&)?: rtrmgr/template_commands.cc:468:16: error: ?const class XRLdb? has no member named ?check_xrl_syntax? rtrmgr/template_commands.cc:474:33: error: ?const class XRLdb? has no member named ?check_xrl_exists? scons: *** [obj/i686-pc-linux-gnu/rtrmgr/template_commands.o] Error 1 scons: building terminated because of errors. Fix for that is to replace VALIDATE_XRLDB with DEBUG_XRLDB in xrldb.hh and xrldb.cc After that it compiles ok. I couldn't reproduce second error. It looked illogical anyway. This is the patch for that Signed-off-by: Igor Maravi? --- diff -upNr xorp.old/rtrmgr/xrldb.cc xorp.mpls/rtrmgr/xrldb.cc --- xorp.old/rtrmgr/xrldb.cc 2011-03-22 22:08:58.000000000 +0100 +++ xorp.mpls/rtrmgr/xrldb.cc 2011-09-07 16:13:24.000000000 +0200 @@ -160,7 +160,7 @@ XRLtarget::str() const XRLdb::XRLdb(const string& xrldir, bool verbose) throw (InitError) : _verbose(verbose) { -#ifdef VALIDATE_XRLDB +#ifdef DEBUG_XRLDB string errmsg; list files; @@ -209,7 +209,7 @@ XRLdb::XRLdb(const string& xrldir, bool #endif } -#ifdef VALIDATE_XRLDB +#ifdef DEBUG_XRLDB bool XRLdb::check_xrl_syntax(const string& xrlstr) const { diff -upNr xorp.old/rtrmgr/xrldb.hh xorp.mpls/rtrmgr/xrldb.hh --- xorp.old/rtrmgr/xrldb.hh 2011-03-22 22:08:58.000000000 +0100 +++ xorp.mpls/rtrmgr/xrldb.hh 2011-09-07 16:05:26.000000000 +0200 @@ -65,7 +65,7 @@ private: class XRLdb { public: XRLdb(const string& xrldir, bool verbose) throw (InitError); -#ifdef VALIDATE_XRLDB +#ifdef DEBUG_XRLDB bool check_xrl_syntax(const string& xrl) const; XRLMatchType check_xrl_exists(const string& xrl) const; #endif From igorm at etf.rs Mon Sep 26 01:46:37 2011 From: igorm at etf.rs (=?utf-8?B?Iklnb3IgTWFyYXZpxIci?=) Date: Mon, 26 Sep 2011 10:46:37 +0200 Subject: [Xorp-hackers] [PATCH2/3] main SConstract bugs In-Reply-To: <4E7CAF64.6060607@candelatech.com> References: <16371486e4d45cc2e1021459345b54c8.squirrel@kondor.etf.bg.ac.rs> <4E7CAF64.6060607@candelatech.com> Message-ID: <63a0688244df559f248eeb181391a4a0.squirrel@kondor.etf.bg.ac.rs> > On 09/23/2011 06:43 AM, "Igor Maravi?" wrote: >> When I did "scons install" rtrmngr was looking for .xrls files in folder /xrl/targets not in folder /xorp/xrls, so I changed that. >> Also I removed ; from if statements. >> Also only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. >> When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. > > Please break this into 3 different patches for these 3 different > things. > > For the .xrls part, what error did you see? I don't see > any trouble with 'scons install' on my systems. What command > are you using for the compile? > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > I removed ; from if statements. Signed-off-by: Igor Maravi? --- --- xorp/SConstruct.orig 2011-09-26 10:27:50.000000000 +0200 +++ xorp/SConstruct 2011-09-26 10:43:15.581919492 +0200 @@ -384,25 +384,25 @@ env['xorp_sourcedir'] = sourcedir # rt tst = ARGUMENTS.get('enable_boost', False) if tst and not (tst == "no"): - env['enable_boost'] = True; + env['enable_boost'] = True else: env['enable_boost'] = False tst = ARGUMENTS.get('enable_ustl', False) if tst and not (tst == "no"): - env['enable_ustl'] = True; + env['enable_ustl'] = True else: env['enable_ustl'] = False tst = ARGUMENTS.get('enable_tests', False) if tst and not (tst == "no"): - env['enable_tests'] = True; + env['enable_tests'] = True else: env['enable_tests'] = False tst = ARGUMENTS.get('enable_click', False) if tst and not (tst == "no"): - env['enable_click'] = True; + env['enable_click'] = True else: env['enable_click'] = False @@ -464,67 +464,67 @@ else: tst = ARGUMENTS.get('disable_ipv6', False) if tst and not (tst == "no"): - env['disable_ipv6'] = True; + env['disable_ipv6'] = True else: env['disable_ipv6'] = False tst = ARGUMENTS.get('disable_fw', False) if tst and not (tst == "no"): - env['disable_fw'] = True; + env['disable_fw'] = True else: env['disable_fw'] = False tst = ARGUMENTS.get('disable_libtecla', False) if tst and not (tst == "no"): - env['disable_libtecla'] = True; + env['disable_libtecla'] = True else: env['disable_libtecla'] = False tst = ARGUMENTS.get('disable_profile', False) if tst and not (tst == "no"): - env['disable_profile'] = True; + env['disable_profile'] = True else: env['disable_profile'] = False tst = ARGUMENTS.get('disable_warninglogs', False) if tst and not (tst == "no"): - env['disable_warninglogs'] = True; + env['disable_warninglogs'] = True else: env['disable_warninglogs'] = False tst = ARGUMENTS.get('disable_errorlogs', False) if tst and not (tst == "no"): - env['disable_errorlogs'] = True; + env['disable_errorlogs'] = True else: env['disable_errorlogs'] = False tst = ARGUMENTS.get('disable_tracelogs', False) if tst and not (tst == "no"): - env['disable_tracelogs'] = True; + env['disable_tracelogs'] = True else: env['disable_tracelogs'] = False tst = ARGUMENTS.get('disable_fatallogs', False) if tst and not (tst == "no"): - env['disable_fatallogs'] = True; + env['disable_fatallogs'] = True else: env['disable_fatallogs'] = False tst = ARGUMENTS.get('disable_infologs', False) if tst and not (tst == "no"): - env['disable_infologs'] = True; + env['disable_infologs'] = True else: env['disable_infologs'] = False tst = ARGUMENTS.get('disable_assertlogs', False) if tst and not (tst == "no"): - env['disable_assertlogs'] = True; + env['disable_assertlogs'] = True else: env['disable_assertlogs'] = False tst = ARGUMENTS.get('disable_otherlogs', False) if tst and not (tst == "no"): - env['disable_otherlogs'] = True; + env['disable_otherlogs'] = True else: env['disable_otherlogs'] = False @@ -574,7 +574,7 @@ if not env.GetOption('clean') and \ elif fnmatch.fnmatch(host_os, 'mingw32*'): osname = "Windows" conf.Define('HOST_OS_WINDOWS') - env['mingw'] = True; + env['mingw'] = True env['PROGSUFFIX'] = '.exe' elif fnmatch.fnmatch(host_os, 'linux*'): osname = "Linux" From igorm at etf.rs Mon Sep 26 01:58:12 2011 From: igorm at etf.rs (=?utf-8?B?Iklnb3IgTWFyYXZpxIci?=) Date: Mon, 26 Sep 2011 10:58:12 +0200 Subject: [Xorp-hackers] [PATCH3/3] main SConstract bugs In-Reply-To: <4E7CAF64.6060607@candelatech.com> References: <16371486e4d45cc2e1021459345b54c8.squirrel@kondor.etf.bg.ac.rs> <4E7CAF64.6060607@candelatech.com> Message-ID: <0fd113f46c92943125996a6697e1b967.squirrel@kondor.etf.bg.ac.rs> > On 09/23/2011 06:43 AM, "Igor Maravi?" wrote: >> When I did "scons install" rtrmngr was looking for .xrls files in folder /xrl/targets not in folder /xorp/xrls, so I changed that. >> Also I removed ; from if statements. >> Also only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. >> When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. > > Please break this into 3 different patches for these 3 different > things. > > For the .xrls part, what error did you see? I don't see > any trouble with 'scons install' on my systems. What command > are you using for the compile? > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > When I did "scons install debug_xrldb=True" rtrmngr was looking for .xrls files in folder /xrl/targets not in folder /xorp/xrls, so I changed that. This is the error when I run /usr/local/xorp/sbin/xorp_rtrmgr [ 2011/09/26 10:54:08.836134 ERROR xorp_rtrmgr:13960 RTRMGR rtrmgr/main_rtrmgr.cc:260 run ] Shutting down due to an init error: Error reading XRL directory /usr/local/xorp/share/xorp/xrl/targets: No such file or directory Signed-off-by: Igor Maravi? --- --- xorp/SConstruct.orig 2011-09-26 10:43:15.000000000 +0200 +++ xorp/SConstruct 2011-09-26 10:57:02.125919777 +0200 @@ -379,7 +379,7 @@ env['xorp_moduledir'] = env['libdir'] env['xorp_sbindir'] = env['sbindir'] # End-user binaries env['xorp_templatedir'] = env['datadir'] + '/templates' env['xorp_tooldir'] = env['libdir'] + '/xorp/bin' # tools/* -env['xorp_xrlsdir'] = env['datadir'] + '/xorp/xrls' # *.xrls +env['xorp_xrlsdir'] = env['datadir'] + '/xrl/targets' # *.xrls env['xorp_sourcedir'] = sourcedir # rtrmgr/util.cc and xif need this tst = ARGUMENTS.get('enable_boost', False) From igorm at etf.rs Mon Sep 26 02:01:21 2011 From: igorm at etf.rs (=?utf-8?B?Iklnb3IgTWFyYXZpxIci?=) Date: Mon, 26 Sep 2011 11:01:21 +0200 Subject: [Xorp-hackers] [PATCH] xorp_install script In-Reply-To: <9498baa19ad76537b1da92a0b7093dd3.squirrel@kondor.etf.bg.ac.rs> References: <9498baa19ad76537b1da92a0b7093dd3.squirrel@kondor.etf.bg.ac.rs> Message-ID: <795bbd379231ba5f078c37a1b1f1b884.squirrel@kondor.etf.bg.ac.rs> >> On 09/23/2011 08:15 AM, "Igor Maravi?" wrote: >>> When XORP user is initially created with xorp_install.sh script, I think that it is better to create user as system user without home dir. >>> BR >>> Igor Maravi? >>> >>> Signed-off-by: Igor Maravi? >>> --- >>> --- xorp/xorp_install.bash.orig 2011-09-23 17:08:41.405949155 +0200 >>> +++ xorp/xorp_install.bash 2011-09-23 17:05:34.021949091 +0200 >>> @@ -19,7 +19,7 @@ fi >>> >>> # Add xorp user and group >>> echo "Creating xorp user and adding xorp to xorp and root groups..." >>> -adduser xorp >>> +adduser --system --no-create-home xorp >>> usermod -a -G xorp xorp >>> usermod -a -G xorp root >>> usermod -a -G xorp lanforge >> >> On Fedora Core 5, this does not work. The --no-create-home option >> is not supported. The -M option appears to be, and it means do >> not create a home dir. FC5 does not support the --system option >> either. I've no idea what Debian and similar systems >> support. >> >> If you'd like to make the script smart enough to detect which options >> are available (maybe try each until something succeeds?), then >> I'll apply the patch. >> >> Otherwise, I'll leave it as it is. >> >> Thanks, >> Ben >> >>> >>> >>> _______________________________________________ >>> Xorp-hackers mailing list >>> Xorp-hackers at icir.org >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers >> >> >> -- >> Ben Greear >> Candela Technologies Inc http://www.candelatech.com >> >> > > Here is the patch for smart script! It checks if adduser supports --system and --no-create-home. > Checking for -M option could be added, but I don't have fedora to test it. > I'm running Ubuntu 11.04 with kernel 2.6.38.8 > > Signed-off-by: Igor Maravi? > --- > > --- xorp/xorp_install.bash.orig 2011-09-23 17:08:41.405949155 +0200 > +++ xorp/xorp_install.bash.new 2011-09-26 09:49:14.000000000 +0200 > @@ -18,8 +18,21 @@ if [ `pwd` != "/usr/local/xorp" ] > fi > > # Add xorp user and group > + > +#Check for adduser commands > +adduserArgs="" > +if adduser -h | grep ".--system" > /dev/null 2>&1 > +then > + adduserArgs="$adduserArgs --system" > +fi > + > +if adduser -h | grep ".--no-create-home" > /dev/null 2>&1 > +then > + adduserArgs="$adduserArgs --no-create-home" > +fi > + > echo "Creating xorp user and adding xorp to xorp and root groups..." > -adduser xorp > +adduser $adduserArgs xorp > usermod -a -G xorp xorp > usermod -a -G xorp root > usermod -a -G xorp lanforge > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers > Sorry for the bad patch... This is good patch for smart script. Signed-off-by: Igor Maravi? --- --- xorp/xorp_install.bash.orig 2011-09-23 17:08:41.405949155 +0200 +++ xorp/xorp_install.bash 2011-09-26 09:49:14.000000000 +0200 @@ -18,8 +18,21 @@ if [ `pwd` != "/usr/local/xorp" ] fi # Add xorp user and group + +#Check for adduser commands +adduserArgs="" +if adduser -h | grep ".--system" > /dev/null 2>&1 +then + adduserArgs="$adduserArgs --system" +fi + +if adduser -h | grep ".--no-create-home" > /dev/null 2>&1 +then + adduserArgs="$adduserArgs --no-create-home" +fi + echo "Creating xorp user and adding xorp to xorp and root groups..." -adduser xorp +adduser $adduserArgs xorp usermod -a -G xorp xorp usermod -a -G xorp root usermod -a -G xorp lanforge From greearb at candelatech.com Mon Sep 26 09:17:05 2011 From: greearb at candelatech.com (Ben Greear) Date: Mon, 26 Sep 2011 09:17:05 -0700 Subject: [Xorp-hackers] [PATCH1/3] main SConstract bugs In-Reply-To: References: <16371486e4d45cc2e1021459345b54c8.squirrel@kondor.etf.bg.ac.rs> <4E7CAF64.6060607@candelatech.com> Message-ID: <4E80A581.8060704@candelatech.com> On 09/26/2011 01:32 AM, "Igor Maravi?" wrote: >> On 09/23/2011 06:43 AM, "Igor Maravi?" wrote: >>> When I did "scons install" rtrmngr was looking for .xrls files in folder /xrl/targets not in folder /xorp/xrls, so I changed that. >>> Also I removed ; from if statements. >>> Also only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. >>> When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. >> >> Please break this into 3 different patches for these 3 different >> things. >> >> For the .xrls part, what error did you see? I don't see >> any trouble with 'scons install' on my systems. What command >> are you using for the compile? >> >> Thanks, >> Ben >> >> -- >> Ben Greear >> Candela Technologies Inc http://www.candelatech.com >> >> > > Only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. > When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. This code is already in an if statement that checks for override: # If the user didn't override our default optimization, then # sanitize user's CFLAGS/CXXFLAGS to not contain optimization options, # and map to an appropriate GCC flag. if not env['optimize'] == 'override': Are you sure your patch is needed? Thanks, Ben > > Signed-off-by: Igor Maravi? > --- > > diff -upNr xorp.orig/SConstruct xorp/SConstruct > --- xorp.orig/SConstruct 2011-09-12 20:23:12.000000000 +0200 > +++ xorp/SConstruct 2011-09-23 15:28:34.429947091 +0200 > @@ -713,7 +713,7 @@ if not env['optimize'] == 'override': > 'highest': '-O3', > 'size': '-Os' } > bigoflag = bigodict[env['optimize']] > - if not env['optimize'] == 'no': > + if not env['optimize'] == 'override': > env.AppendUnique(CFLAGS = [ bigoflag ]) > env.AppendUnique(CXXFLAGS = [ bigoflag ]) -- Ben Greear Candela Technologies Inc http://www.candelatech.com From greearb at candelatech.com Mon Sep 26 09:24:38 2011 From: greearb at candelatech.com (Ben Greear) Date: Mon, 26 Sep 2011 09:24:38 -0700 Subject: [Xorp-hackers] [PATCH] rtrmngr fixes In-Reply-To: <23b814ea08324b346d77339c3d978a10.squirrel@kondor.etf.bg.ac.rs> References: <973d1d9e45952badf3153ac6c827c6b4.squirrel@kondor.etf.bg.ac.rs> <4E7CAE57.3070803@candelatech.com> <23b814ea08324b346d77339c3d978a10.squirrel@kondor.etf.bg.ac.rs> Message-ID: <4E80A746.7090705@candelatech.com> On 09/26/2011 01:43 AM, "Igor Maravi?" wrote: >> On 09/23/2011 06:48 AM, "Igor Maravi?" wrote: >>> cleaned_xrl should have reference to it. That reference should be argument of functions XRLDB::check_xrl_syntax and XRLDB::check_xrl_exists. >>> Don't know why but it didn't wont to compile with out that fix. >>> >>> VALIDATE_XRLDB should be replaced with DEBUG_XRLDB Ok, the patch and description look good to me, but I cannot apply your patch. Please generate the patch with git and send it with git send-email Or, if that doesn't work for some reason, generate it and send it as email attachment to me. Hopefully that will come through clean. I can also manually apply small patches like this, but then you won't get commit credit..so I prefer to just receive proper patches. Thanks, Ben >>> >>> BR >>> Igor Maravi? >>> >>> Signed-off-by: Igor Maravi? >>> --- >>> >>> diff -upNr xorp.old/rtrmgr/template_commands.cc xorp.mpls/rtrmgr/template_commands.cc >>> --- xorp.old/rtrmgr/template_commands.cc 2011-03-22 22:08:58.000000000 +0100 >>> +++ xorp.mpls/rtrmgr/template_commands.cc 2011-09-08 00:30:24.000000000 +0200 >>> @@ -316,6 +316,7 @@ XrlAction::check_xrl_is_valid(const list >>> // Then we can check it is a valid XRL as known by the XRLdb. >>> // >>> string cleaned_xrl; >>> + const string& refToCleanedXRL = cleaned_xrl; >>> >>> // Trim quotes from around the XRL >>> size_t start = 0; >>> @@ -465,13 +466,14 @@ XrlAction::check_xrl_is_valid(const list >>> } >>> debug_msg("XrlAction after cleaning:\n%s\n", cleaned_xrl.c_str()); >>> >>> - if (xrldb->check_xrl_syntax(cleaned_xrl) == false) { >>> + if (xrldb->check_xrl_syntax(refToCleanedXRL) == false) { >>> error_msg = c_format("Syntax error in module %s XRL %s: " >>> "invalid XRL syntax (check_xrl_syntax failed)", >>> module_name.c_str(), cleaned_xrl.c_str()); >>> return false; >>> } >>> - XRLMatchType match = xrldb->check_xrl_exists(cleaned_xrl); >>> + >>> + XRLMatchType match = xrldb->check_xrl_exists(refToCleanedXRL); >>> switch (match) { >>> case MATCH_FAIL: >>> case MATCH_RSPEC: { >> >> What system are you compiling on, and can you show the exact >> compiler command and errors? >> >> Thanks, >> Ben >> >> -- >> Ben Greear >> Candela Technologies Inc http://www.candelatech.com >> >> > > When I compile with > scons debug_xrldb=True > > first error is: > > > g++ -o obj/i686-pc-linux-gnu/rtrmgr/template_commands.o -c -O1 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -DDEBUG_XRLDB=1 -Iobj/i686-pc-linux-gnu -I. -I. rtrmgr/template_commands.cc > rtrmgr/template_commands.cc: In member function ?bool XrlAction::check_xrl_is_valid(const std::list >&, const XRLdb*, std::string&)?: > rtrmgr/template_commands.cc:468:16: error: ?const class XRLdb? has no member named ?check_xrl_syntax? > rtrmgr/template_commands.cc:474:33: error: ?const class XRLdb? has no member named ?check_xrl_exists? > scons: *** [obj/i686-pc-linux-gnu/rtrmgr/template_commands.o] Error 1 > scons: building terminated because of errors. > > Fix for that is to replace VALIDATE_XRLDB with DEBUG_XRLDB in xrldb.hh and xrldb.cc > After that it compiles ok. I couldn't reproduce second error. It looked illogical anyway. > > This is the patch for that > Signed-off-by: Igor Maravi? > --- > > diff -upNr xorp.old/rtrmgr/xrldb.cc xorp.mpls/rtrmgr/xrldb.cc > --- xorp.old/rtrmgr/xrldb.cc 2011-03-22 22:08:58.000000000 +0100 > +++ xorp.mpls/rtrmgr/xrldb.cc 2011-09-07 16:13:24.000000000 +0200 > @@ -160,7 +160,7 @@ XRLtarget::str() const > XRLdb::XRLdb(const string& xrldir, bool verbose) throw (InitError) > : _verbose(verbose) > { > -#ifdef VALIDATE_XRLDB > +#ifdef DEBUG_XRLDB > string errmsg; > list files; > > @@ -209,7 +209,7 @@ XRLdb::XRLdb(const string& xrldir, bool > #endif > } > > -#ifdef VALIDATE_XRLDB > +#ifdef DEBUG_XRLDB > bool > XRLdb::check_xrl_syntax(const string& xrlstr) const > { > diff -upNr xorp.old/rtrmgr/xrldb.hh xorp.mpls/rtrmgr/xrldb.hh > --- xorp.old/rtrmgr/xrldb.hh 2011-03-22 22:08:58.000000000 +0100 > +++ xorp.mpls/rtrmgr/xrldb.hh 2011-09-07 16:05:26.000000000 +0200 > @@ -65,7 +65,7 @@ private: > class XRLdb { > public: > XRLdb(const string& xrldir, bool verbose) throw (InitError); > -#ifdef VALIDATE_XRLDB > +#ifdef DEBUG_XRLDB > bool check_xrl_syntax(const string& xrl) const; > XRLMatchType check_xrl_exists(const string& xrl) const; > #endif -- Ben Greear Candela Technologies Inc http://www.candelatech.com From igorm at etf.rs Mon Sep 26 09:43:54 2011 From: igorm at etf.rs (=?utf-8?B?Iklnb3IgTWFyYXZpxIci?=) Date: Mon, 26 Sep 2011 18:43:54 +0200 Subject: [Xorp-hackers] [PATCH1/3] main SConstract bugs In-Reply-To: <4E80A581.8060704@candelatech.com> References: <16371486e4d45cc2e1021459345b54c8.squirrel@kondor.etf.bg.ac.rs> <4E7CAF64.6060607@candelatech.com> <4E80A581.8060704@candelatech.com> Message-ID: <8db447f8811beceebef165419a0ca2b8.squirrel@kondor.etf.bg.ac.rs> > On 09/26/2011 01:32 AM, "Igor Maravi?" wrote: >>> On 09/23/2011 06:43 AM, "Igor Maravi?" wrote: >>>> When I did "scons install" rtrmngr was looking for .xrls files in folder /xrl/targets not in folder /xorp/xrls, so I changed that. >>>> Also I removed ; from if statements. >>>> Also only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. >>>> When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. >>> >>> Please break this into 3 different patches for these 3 different >>> things. >>> >>> For the .xrls part, what error did you see? I don't see >>> any trouble with 'scons install' on my systems. What command >>> are you using for the compile? >>> >>> Thanks, >>> Ben >>> >>> -- >>> Ben Greear >>> Candela Technologies Inc http://www.candelatech.com >>> >>> >> >> Only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. >> When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. > > This code is already in an if statement that checks for override: > > # If the user didn't override our default optimization, then > # sanitize user's CFLAGS/CXXFLAGS to not contain optimization options, > # and map to an appropriate GCC flag. > if not env['optimize'] == 'override': > > Are you sure your patch is needed? > > Thanks, > Ben > >> >> Signed-off-by: Igor Maravi? >> --- >> >> diff -upNr xorp.orig/SConstruct xorp/SConstruct >> --- xorp.orig/SConstruct 2011-09-12 20:23:12.000000000 +0200 >> +++ xorp/SConstruct 2011-09-23 15:28:34.429947091 +0200 >> @@ -713,7 +713,7 @@ if not env['optimize'] == 'override': >> 'highest': '-O3', >> 'size': '-Os' } >> bigoflag = bigodict[env['optimize']] >> - if not env['optimize'] == 'no': >> + if not env['optimize'] == 'override': >> env.AppendUnique(CFLAGS = [ bigoflag ]) >> env.AppendUnique(CXXFLAGS = [ bigoflag ]) > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > 100 % sure. > # If the user didn't override our default optimization, then > # sanitize user's CFLAGS/CXXFLAGS to not contain optimization options, > # and map to an appropriate GCC flag. This is for the upper line, not for the line that I changed. Here is the compiler output when patch is not applied. g++ -o obj/i686-pc-linux-gnu/libxipc/xrl_pf_factory.os -c -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. libxipc/xrl_pf_factory.cc g++ -o obj/i686-pc-linux-gnu/libxipc/xrl_pf_stcp.os -c -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. libxipc/xrl_pf_stcp.cc g++ -o obj/i686-pc-linux-gnu/libxipc/xrl_pf_stcp_ph.os -c -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. libxipc/xrl_pf_stcp_ph.cc As you can see there is no -O0 flag. I'l send you patches tomorrow, it's the end of work time in Serbia. Could you send me some instructions how to make git patches. I made patches with help of linux kernel official instructions. BR Igor Maravi? From greearb at candelatech.com Mon Sep 26 10:14:43 2011 From: greearb at candelatech.com (Ben Greear) Date: Mon, 26 Sep 2011 10:14:43 -0700 Subject: [Xorp-hackers] [PATCH1/3] main SConstract bugs In-Reply-To: <8db447f8811beceebef165419a0ca2b8.squirrel@kondor.etf.bg.ac.rs> References: <16371486e4d45cc2e1021459345b54c8.squirrel@kondor.etf.bg.ac.rs> <4E7CAF64.6060607@candelatech.com> <4E80A581.8060704@candelatech.com> <8db447f8811beceebef165419a0ca2b8.squirrel@kondor.etf.bg.ac.rs> Message-ID: <4E80B303.3080300@candelatech.com> On 09/26/2011 09:43 AM, "Igor Maravi?" wrote: >> On 09/26/2011 01:32 AM, "Igor Maravi?" wrote: >>>> On 09/23/2011 06:43 AM, "Igor Maravi?" wrote: >>>>> When I did "scons install" rtrmngr was looking for .xrls files in folder /xrl/targets not in folder /xorp/xrls, so I changed that. >>>>> Also I removed ; from if statements. >>>>> Also only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. >>>>> When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. >>>> >>>> Please break this into 3 different patches for these 3 different >>>> things. >>>> >>>> For the .xrls part, what error did you see? I don't see >>>> any trouble with 'scons install' on my systems. What command >>>> are you using for the compile? >>>> >>>> Thanks, >>>> Ben >>>> >>>> -- >>>> Ben Greear >>>> Candela Technologies Inc http://www.candelatech.com >>>> >>>> >>> >>> Only when value of 'optimize' is set to 'override', we should skip appending CFLAGS/CXXFLAGS. >>> When it's value is 'no', CFLAGS/CXXFLAGS still have some value to be appended. >> >> This code is already in an if statement that checks for override: >> >> # If the user didn't override our default optimization, then >> # sanitize user's CFLAGS/CXXFLAGS to not contain optimization options, >> # and map to an appropriate GCC flag. >> if not env['optimize'] == 'override': >> >> Are you sure your patch is needed? >> >> Thanks, >> Ben >> >>> >>> Signed-off-by: Igor Maravi? >>> --- >>> >>> diff -upNr xorp.orig/SConstruct xorp/SConstruct >>> --- xorp.orig/SConstruct 2011-09-12 20:23:12.000000000 +0200 >>> +++ xorp/SConstruct 2011-09-23 15:28:34.429947091 +0200 >>> @@ -713,7 +713,7 @@ if not env['optimize'] == 'override': >>> 'highest': '-O3', >>> 'size': '-Os' } >>> bigoflag = bigodict[env['optimize']] >>> - if not env['optimize'] == 'no': >>> + if not env['optimize'] == 'override': >>> env.AppendUnique(CFLAGS = [ bigoflag ]) >>> env.AppendUnique(CXXFLAGS = [ bigoflag ]) >> >> >> -- >> Ben Greear >> Candela Technologies Inc http://www.candelatech.com >> >> > > 100 % sure. > >> # If the user didn't override our default optimization, then >> # sanitize user's CFLAGS/CXXFLAGS to not contain optimization options, >> # and map to an appropriate GCC flag. > > This is for the upper line, not for the line that I changed. > > Here is the compiler output when patch is not applied. > > > g++ -o obj/i686-pc-linux-gnu/libxipc/xrl_pf_factory.os -c -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. libxipc/xrl_pf_factory.cc > g++ -o obj/i686-pc-linux-gnu/libxipc/xrl_pf_stcp.os -c -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. libxipc/xrl_pf_stcp.cc > g++ -o obj/i686-pc-linux-gnu/libxipc/xrl_pf_stcp_ph.os -c -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. libxipc/xrl_pf_stcp_ph.cc > > As you can see there is no -O0 flag. Please show me your exact compile commands: scons .... with and without your patch, and let me know why your change fixes something. I'm not that great with python, but I don't see what you are trying to accomplish with your change. As far as I can tell, if optimize is 'override', then the bigoflag will always be appended with your change, and the if branch you are modifying will always evaluate to 'true'. Maybe we should just add a new optimize option 'none' and change that inner if statement to check for none instead of 'no' ? > I'l send you patches tomorrow, it's the end of work time in Serbia. > Could you send me some instructions how to make git patches. > I made patches with help of linux kernel official instructions. Those instructions should work. Generally: Start with clean tree. Make one patch's worth of changes. git commit ... Make more changes git commit ... Then, use git format-patch to create a patch series: # I use something like this, for some kernel-tree patches: git format-patch --stat -p --raw -o ~/tmp/patches/ --signoff --subject-prefix="PATCH" 2bea038c52e88badbbd5b420c1de918f7f2579e9..ec0dd267bf7d08cb30e321e45a75fd40edd7e528 Then, use git send-email to send those patches. Here's an example of my usage. Obviously, change the email address(s) and patch name(s). git send-email --to=linux-nfs at vger.kernel.org --to=linux-kernel at vger.kernel.org /home/greearb/tmp/patches/0001-nfs-Fix-xpt_ready-list-corruption.patch You can try sending them to just yourself at first and make sure you can apply the patches with 'git am' to a clean tree. That is how I will apply your patches. Thanks, Ben > > BR > Igor Maravi? > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From igorm at etf.rs Tue Sep 27 04:30:04 2011 From: igorm at etf.rs (Igor Maravic) Date: Tue, 27 Sep 2011 13:30:04 +0200 Subject: [Xorp-hackers] [PATCH 1/1] rtrmgr fixes In-Reply-To: <1317123004-19000-1-git-send-email-igorm@etf.rs> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> Message-ID: <1317123004-19000-8-git-send-email-igorm@etf.rs> Signed-off-by: Igor Maravic --- :100644 100644 662c123... db5f9e8... M xorp/rtrmgr/xrldb.cc :100644 100644 ee5765c... a147366... M xorp/rtrmgr/xrldb.hh xorp/rtrmgr/xrldb.cc | 4 ++-- xorp/rtrmgr/xrldb.hh | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/xorp/rtrmgr/xrldb.cc b/xorp/rtrmgr/xrldb.cc index 662c123..db5f9e8 100644 --- a/xorp/rtrmgr/xrldb.cc +++ b/xorp/rtrmgr/xrldb.cc @@ -160,7 +160,7 @@ XRLtarget::str() const XRLdb::XRLdb(const string& xrldir, bool verbose) throw (InitError) : _verbose(verbose) { -#ifdef VALIDATE_XRLDB +#ifdef DEBUG_XRLDB string errmsg; list files; @@ -209,7 +209,7 @@ XRLdb::XRLdb(const string& xrldir, bool verbose) throw (InitError) #endif } -#ifdef VALIDATE_XRLDB +#ifdef DEBUG_XRLDB bool XRLdb::check_xrl_syntax(const string& xrlstr) const { diff --git a/xorp/rtrmgr/xrldb.hh b/xorp/rtrmgr/xrldb.hh index ee5765c..a147366 100644 --- a/xorp/rtrmgr/xrldb.hh +++ b/xorp/rtrmgr/xrldb.hh @@ -65,7 +65,7 @@ private: class XRLdb { public: XRLdb(const string& xrldir, bool verbose) throw (InitError); -#ifdef VALIDATE_XRLDB +#ifdef DEBUG_XRLDB bool check_xrl_syntax(const string& xrl) const; XRLMatchType check_xrl_exists(const string& xrl) const; #endif -- 1.7.4.1 From igorm at etf.rs Tue Sep 27 04:30:03 2011 From: igorm at etf.rs (Igor Maravic) Date: Tue, 27 Sep 2011 13:30:03 +0200 Subject: [Xorp-hackers] =?utf-8?q?=5BPATCH_0/1=5D_rtrmgr_fixes?= In-Reply-To: <1317123004-19000-1-git-send-email-igorm@etf.rs> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> Message-ID: <1317123004-19000-7-git-send-email-igorm@etf.rs> When I compile with scons debug_xrldb=True first error is: g++ -o obj/i686-pc-linux-gnu/rtrmgr/template_commands.o -c -O1 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -DDEBUG_XRLDB=1 -Iobj/i686-pc-linux-gnu -I. -I. rtrmgr/template_commands.cc rtrmgr/template_commands.cc: In member function ?bool XrlAction::check_xrl_is_valid(const std::list >&, const XRLdb*, std::string&)?: rtrmgr/template_commands.cc:468:16: error: ?const class XRLdb? has no member named ?check_xrl_syntax? rtrmgr/template_commands.cc:474:33: error: ?const class XRLdb? has no member named ?check_xrl_exists? scons: *** [obj/i686-pc-linux-gnu/rtrmgr/template_commands.o] Error 1 scons: building terminated because of errors. Fix for that is to replace VALIDATE_XRLDB with DEBUG_XRLDB in xrldb.hh and xrldb.cc After that it compiles ok. I couldn't reproduce second error. It looked illogical anyway. This is the patch for that Igor Maravic (1): rtrmgr fixes xorp/rtrmgr/xrldb.cc | 4 ++-- xorp/rtrmgr/xrldb.hh | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- 1.7.4.1 From igorm at etf.rs Tue Sep 27 04:30:02 2011 From: igorm at etf.rs (Igor Maravic) Date: Tue, 27 Sep 2011 13:30:02 +0200 Subject: [Xorp-hackers] [PATCH 3/3] SConstruct fixes In-Reply-To: <1317123004-19000-1-git-send-email-igorm@etf.rs> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> Message-ID: <1317123004-19000-6-git-send-email-igorm@etf.rs> Signed-off-by: Igor Maravic --- :100644 100644 8f2acf6... 3af1b39... M xorp/SConstruct xorp/SConstruct | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/xorp/SConstruct b/xorp/SConstruct index 8f2acf6..3af1b39 100644 --- a/xorp/SConstruct +++ b/xorp/SConstruct @@ -379,7 +379,7 @@ env['xorp_moduledir'] = env['libdir'] + '/xorp/sbin' # Protocol modules env['xorp_sbindir'] = env['sbindir'] # End-user binaries env['xorp_templatedir'] = env['datadir'] + '/templates' env['xorp_tooldir'] = env['libdir'] + '/xorp/bin' # tools/* -env['xorp_xrlsdir'] = env['datadir'] + '/xorp/xrls' # *.xrls +env['xorp_xrlsdir'] = env['datadir'] + '/xrl/targets' # *.xrls env['xorp_sourcedir'] = sourcedir # rtrmgr/util.cc and xif need this tst = ARGUMENTS.get('enable_boost', False) -- 1.7.4.1 From igorm at etf.rs Tue Sep 27 04:29:58 2011 From: igorm at etf.rs (Igor Maravic) Date: Tue, 27 Sep 2011 13:29:58 +0200 Subject: [Xorp-hackers] [PATCH 1/1] xorp_install.bash fix In-Reply-To: <1317123004-19000-1-git-send-email-igorm@etf.rs> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> Message-ID: <1317123004-19000-2-git-send-email-igorm@etf.rs> Signed-off-by: Igor Maravic --- :100644 100644 cf23c47... e1d52bb... M xorp/xorp_install.bash xorp/xorp_install.bash | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/xorp/xorp_install.bash b/xorp/xorp_install.bash index cf23c47..e1d52bb 100644 --- a/xorp/xorp_install.bash +++ b/xorp/xorp_install.bash @@ -18,8 +18,21 @@ if [ `pwd` != "/usr/local/xorp" ] fi # Add xorp user and group + +#Check for adduser commands +adduserArgs="" +if adduser -h | grep ".--system" > /dev/null 2>&1 +then + adduserArgs="$adduserArgs --system" +fi + +if adduser -h | grep ".--no-create-home" > /dev/null 2>&1 +then + adduserArgs="$adduserArgs --no-create-home" +fi + echo "Creating xorp user and adding xorp to xorp and root groups..." -adduser xorp +adduser $adduserArgs xorp usermod -a -G xorp xorp usermod -a -G xorp root usermod -a -G xorp lanforge -- 1.7.4.1 From igorm at etf.rs Tue Sep 27 04:29:59 2011 From: igorm at etf.rs (Igor Maravic) Date: Tue, 27 Sep 2011 13:29:59 +0200 Subject: [Xorp-hackers] [PATCH 0/3] SConstruct fixes In-Reply-To: <1317123004-19000-1-git-send-email-igorm@etf.rs> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> Message-ID: <1317123004-19000-3-git-send-email-igorm@etf.rs> First patch is for fixing compiling with scons optimize=no This is output without applied that patch: igor at igor-PC:~/xorpFixes/xorp.ct/xorp$ scons optimize=no scons: Reading SConscript files ... ... Optimize code: no ... scons: done reading SConscript files. scons: Building targets ... scons: Configure: creating obj/i686-pc-linux-gnu/xorp_config.h g++ -o obj/i686-pc-linux-gnu/cli/tools/cli_generic.o -c -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. cli/tools/cli_generic.cc /home/igor/xorpFixes/xorp.ct/xorp/xrl/scripts/clnt-gen -Iobj/i686-pc-linux-gnu/xrl/interfaces/../.. --output-dir obj/i686-pc-linux-gnu/xrl/interfaces xrl/interfaces/cli_processor.xif g++ -o obj/i686-pc-linux-gnu/xrl/interfaces/cli_processor_xif.os -c -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. obj/i686-pc-linux-gnu/xrl/interfaces/cli_processor_xif.cc /home/igor/xorpFixes/xorp.ct/xorp/xrl/scripts/clnt-gen -Iobj/i686-pc-linux-gnu/xrl/interfaces/../.. --output-dir obj/i686-pc-linux-gnu/xrl/interfaces xrl/interfaces/finder.xif /home/igor/xorpFixes/xorp.ct/xorp/xrl/scripts/tgt-gen -Ixrl/interfaces -Iobj/i686-pc-linux-gnu -I. --output-dir obj/i686-pc-linux-gnu/xrl/targets xrl/targets/finder_client.tgt ///// g++ -o obj/i686-pc-linux-gnu/libxipc/finder_client.os -c -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. libxipc/finder_client.cc ///// g++ -o obj/i686-pc-linux-gnu/libxipc/finder_client_observer.os -c -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. libxipc/finder_client_observer.cc /////// g++ -o obj/i686-pc-linux-gnu/libxipc/finder_client_xrl_target.os -c -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. libxipc/finder_client_xrl_target.cc ... I added //////. As you can see there is no -O0 flag below /////. And in the code we put it in the bigodict. I marked that place with <==== ... bigodict = { 'no': '-O0', <======= ... 'yes': '-O1', 'full': '-O2', 'highest': '-O3', 'size': '-Os' } ... >Maybe we should just add a new optimize option 'none' and change >that inner if statement to check for none instead of 'no' I think that we shouldn't add option none. To me none should be same as no. # If the user didn't override our default optimization, then # sanitize user's CFLAGS/CXXFLAGS to not contain optimization options, # and map to an appropriate GCC flag. As I could see from this comment override is same as default. This is the compiler output with applied patch igor at igor-PC:~/xorpFixes/xorp.ct/xorp$ scons optimize=no scons: Reading SConscript files ... ... Optimize code: no ... scons: done reading SConscript files. scons: Building targets ... scons: Configure: creating obj/i686-pc-linux-gnu/xorp_config.h //// g++ -o obj/i686-pc-linux-gnu/cli/tools/cli_generic.o -c -O0 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. cli/tools/cli_generic.cc /home/igor/xorpFixes/xorp.ct/xorp/xrl/scripts/clnt-gen -Iobj/i686-pc-linux-gnu/xrl/interfaces/../.. --output-dir obj/i686-pc-linux-gnu/xrl/interfaces xrl/interfaces/cli_processor.xif /// g++ -o obj/i686-pc-linux-gnu/xrl/interfaces/cli_processor_xif.os -c -O0 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. obj/i686-pc-linux-gnu/xrl/interfaces/cli_processor_xif.cc /home/igor/xorpFixes/xorp.ct/xorp/xrl/scripts/clnt-gen -Iobj/i686-pc-linux-gnu/xrl/interfaces/../.. --output-dir obj/i686-pc-linux-gnu/xrl/interfaces xrl/interfaces/finder.xif /home/igor/xorpFixes/xorp.ct/xorp/xrl/scripts/tgt-gen -Ixrl/interfaces -Iobj/i686-pc-linux-gnu -I. --output-dir obj/i686-pc-linux-gnu/xrl/targets xrl/targets/finder_client.tgt /// g++ -o obj/i686-pc-linux-gnu/libxipc/finder_client.os -c -O0 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/i686-pc-linux-gnu -I. -I. libxipc/finder_client.cc ... Now there are -O0 flag below //// Second patch is for removing ; behind True from SConstruct file Third patch is for replacing /xorp/xrls folder with /xrl/targets When I did "scons install debug_xrldb=True" rtrmngr was looking for .xrls files in folder /xrl/targets not in folder /xorp/xrls, so I changed that. This is the error when I run /usr/local/xorp/sbin/xorp_rtrmgr ... [ 2011/09/26 10:54:08.836134 ERROR xorp_rtrmgr:13960 RTRMGR rtrmgr/main_rtrmgr.cc:260 run ] Shutting down due to an init error: Error reading XRL directory /usr/local/xorp/share/xorp/xrl/targets: No such file or directory ... Igor Maravic (3): SConstruct fixes SConstract fixes SConstruct fixes xorp/SConstruct | 36 ++++++++++++++++++------------------ 1 files changed, 18 insertions(+), 18 deletions(-) -- 1.7.4.1 From igorm at etf.rs Tue Sep 27 04:30:00 2011 From: igorm at etf.rs (Igor Maravic) Date: Tue, 27 Sep 2011 13:30:00 +0200 Subject: [Xorp-hackers] [PATCH 1/3] SConstruct fixes In-Reply-To: <1317123004-19000-1-git-send-email-igorm@etf.rs> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> Message-ID: <1317123004-19000-4-git-send-email-igorm@etf.rs> Signed-off-by: Igor Maravic --- :100644 100644 955e743... 9f5dd79... M xorp/SConstruct xorp/SConstruct | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/xorp/SConstruct b/xorp/SConstruct index 955e743..9f5dd79 100644 --- a/xorp/SConstruct +++ b/xorp/SConstruct @@ -713,7 +713,7 @@ if not env['optimize'] == 'override': 'highest': '-O3', 'size': '-Os' } bigoflag = bigodict[env['optimize']] - if not env['optimize'] == 'no': + if not env['optimize'] == 'override': env.AppendUnique(CFLAGS = [ bigoflag ]) env.AppendUnique(CXXFLAGS = [ bigoflag ]) -- 1.7.4.1 From igorm at etf.rs Tue Sep 27 04:30:01 2011 From: igorm at etf.rs (Igor Maravic) Date: Tue, 27 Sep 2011 13:30:01 +0200 Subject: [Xorp-hackers] [PATCH 2/3] SConstract fixes In-Reply-To: <1317123004-19000-1-git-send-email-igorm@etf.rs> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> Message-ID: <1317123004-19000-5-git-send-email-igorm@etf.rs> Signed-off-by: Igor Maravic --- :100644 100644 9f5dd79... 8f2acf6... M xorp/SConstruct xorp/SConstruct | 32 ++++++++++++++++---------------- 1 files changed, 16 insertions(+), 16 deletions(-) diff --git a/xorp/SConstruct b/xorp/SConstruct index 9f5dd79..8f2acf6 100644 --- a/xorp/SConstruct +++ b/xorp/SConstruct @@ -384,25 +384,25 @@ env['xorp_sourcedir'] = sourcedir # rtrmgr/util.cc and xif need this tst = ARGUMENTS.get('enable_boost', False) if tst and not (tst == "no"): - env['enable_boost'] = True; + env['enable_boost'] = True else: env['enable_boost'] = False tst = ARGUMENTS.get('enable_ustl', False) if tst and not (tst == "no"): - env['enable_ustl'] = True; + env['enable_ustl'] = True else: env['enable_ustl'] = False tst = ARGUMENTS.get('enable_tests', False) if tst and not (tst == "no"): - env['enable_tests'] = True; + env['enable_tests'] = True else: env['enable_tests'] = False tst = ARGUMENTS.get('enable_click', False) if tst and not (tst == "no"): - env['enable_click'] = True; + env['enable_click'] = True else: env['enable_click'] = False @@ -464,67 +464,67 @@ else: tst = ARGUMENTS.get('disable_ipv6', False) if tst and not (tst == "no"): - env['disable_ipv6'] = True; + env['disable_ipv6'] = True else: env['disable_ipv6'] = False tst = ARGUMENTS.get('disable_fw', False) if tst and not (tst == "no"): - env['disable_fw'] = True; + env['disable_fw'] = True else: env['disable_fw'] = False tst = ARGUMENTS.get('disable_libtecla', False) if tst and not (tst == "no"): - env['disable_libtecla'] = True; + env['disable_libtecla'] = True else: env['disable_libtecla'] = False tst = ARGUMENTS.get('disable_profile', False) if tst and not (tst == "no"): - env['disable_profile'] = True; + env['disable_profile'] = True else: env['disable_profile'] = False tst = ARGUMENTS.get('disable_warninglogs', False) if tst and not (tst == "no"): - env['disable_warninglogs'] = True; + env['disable_warninglogs'] = True else: env['disable_warninglogs'] = False tst = ARGUMENTS.get('disable_errorlogs', False) if tst and not (tst == "no"): - env['disable_errorlogs'] = True; + env['disable_errorlogs'] = True else: env['disable_errorlogs'] = False tst = ARGUMENTS.get('disable_tracelogs', False) if tst and not (tst == "no"): - env['disable_tracelogs'] = True; + env['disable_tracelogs'] = True else: env['disable_tracelogs'] = False tst = ARGUMENTS.get('disable_fatallogs', False) if tst and not (tst == "no"): - env['disable_fatallogs'] = True; + env['disable_fatallogs'] = True else: env['disable_fatallogs'] = False tst = ARGUMENTS.get('disable_infologs', False) if tst and not (tst == "no"): - env['disable_infologs'] = True; + env['disable_infologs'] = True else: env['disable_infologs'] = False tst = ARGUMENTS.get('disable_assertlogs', False) if tst and not (tst == "no"): - env['disable_assertlogs'] = True; + env['disable_assertlogs'] = True else: env['disable_assertlogs'] = False tst = ARGUMENTS.get('disable_otherlogs', False) if tst and not (tst == "no"): - env['disable_otherlogs'] = True; + env['disable_otherlogs'] = True else: env['disable_otherlogs'] = False @@ -574,7 +574,7 @@ if not env.GetOption('clean') and \ elif fnmatch.fnmatch(host_os, 'mingw32*'): osname = "Windows" conf.Define('HOST_OS_WINDOWS') - env['mingw'] = True; + env['mingw'] = True env['PROGSUFFIX'] = '.exe' elif fnmatch.fnmatch(host_os, 'linux*'): osname = "Linux" -- 1.7.4.1 From igorm at etf.rs Tue Sep 27 04:29:57 2011 From: igorm at etf.rs (Igor Maravic) Date: Tue, 27 Sep 2011 13:29:57 +0200 Subject: [Xorp-hackers] [PATCH 0/1] xorp_install.bash fix Message-ID: <1317123004-19000-1-git-send-email-igorm@etf.rs> Patch for smart script! It checks if adduser supports --system and --no-create-home. Checking for -M option could be added, but I don't have fedora to test it. I'm running Ubuntu 11.04 with kernel 2.6.38.8 Igor Maravic (1): xorp_install.bash fix xorp/xorp_install.bash | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletions(-) -- 1.7.4.1 From greearb at candelatech.com Tue Sep 27 09:31:46 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 27 Sep 2011 09:31:46 -0700 Subject: [Xorp-hackers] [PATCH 1/3] SConstruct fixes In-Reply-To: <1317123004-19000-4-git-send-email-igorm@etf.rs> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> <1317123004-19000-4-git-send-email-igorm@etf.rs> Message-ID: <4E81FA72.2050808@candelatech.com> On 09/27/2011 04:30 AM, Igor Maravic wrote: > Signed-off-by: Igor Maravic > --- > :100644 100644 955e743... 9f5dd79... M xorp/SConstruct > xorp/SConstruct | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/xorp/SConstruct b/xorp/SConstruct > index 955e743..9f5dd79 100644 > --- a/xorp/SConstruct > +++ b/xorp/SConstruct > @@ -713,7 +713,7 @@ if not env['optimize'] == 'override': > 'highest': '-O3', > 'size': '-Os' } > bigoflag = bigodict[env['optimize']] > - if not env['optimize'] == 'no': > + if not env['optimize'] == 'override': > env.AppendUnique(CFLAGS = [ bigoflag ]) > env.AppendUnique(CXXFLAGS = [ bigoflag ]) Can that check ever be false? I think it cannot. And if it cannot, then I do not want to apply this patch. The reason I suggested adding none is if someone wants to use the compiler default and not use any -O option (which supports the current optimize=no behaviour in case someone finds that useful). Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Tue Sep 27 09:41:18 2011 From: noreply at github.com (noreply at github.com) Date: Tue, 27 Sep 2011 09:41:18 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] c52472: xorp_install: Use --system and --no-create-home i... Message-ID: <20110927164118.C6EC642634@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: c5247286fe2ae67a908203a1b73c748a425e62cc https://github.com/greearb/xorp.ct/commit/c5247286fe2ae67a908203a1b73c748a425e62cc Author: Igor Maravic Date: 2011-09-27 (Tue, 27 Sep 2011) Changed paths: M xorp/xorp_install.bash Log Message: ----------- xorp_install: Use --system and --no-create-home if supported. Signed-off-by: Igor Maravic Commit: 0f9516863322e2544253afc46e6424d6629505f7 https://github.com/greearb/xorp.ct/commit/0f9516863322e2544253afc46e6424d6629505f7 Author: Igor Maravic Date: 2011-09-27 (Tue, 27 Sep 2011) Changed paths: M xorp/SConstruct Log Message: ----------- Sconstruct: Remove un-needed semicolons. Signed-off-by: Igor Maravic Commit: 1b11ce80ad1f32f0ced3d746102656c33415859f https://github.com/greearb/xorp.ct/commit/1b11ce80ad1f32f0ced3d746102656c33415859f Author: Igor Maravic Date: 2011-09-27 (Tue, 27 Sep 2011) Changed paths: M xorp/SConstruct Log Message: ----------- SConstruct: Support debug_xrldb=True option. Replace /xorp/xrls folder with /xrl/targets When I did "scons install debug_xrldb=True" rtrmngr was looking for .xrls files in folder /xrl/targets not in folder /xorp/xrls. This is the error when I run /usr/local/xorp/sbin/xorp_rtrmgr ... [ 2011/09/26 10:54:08.836134 ERROR xorp_rtrmgr:13960 RTRMGR rtrmgr/main_rtrmgr.cc:260 run ] Shutting down due to an init error: Error reading XRL directory /usr/local/xorp/share/xorp/xrl/targets: No such file or directory ... Signed-off-by: Igor Maravic Commit: 8b3f50da0535d0335d1ef67fbdff87329dabcbff https://github.com/greearb/xorp.ct/commit/8b3f50da0535d0335d1ef67fbdff87329dabcbff Author: Igor Maravic Date: 2011-09-27 (Tue, 27 Sep 2011) Changed paths: M xorp/rtrmgr/xrldb.cc M xorp/rtrmgr/xrldb.hh Log Message: ----------- rtrmgr: Support compiling with debug_xrldb=True option. When I compile with scons debug_xrldb=True first error is: g++ -o obj/i686-pc-linux-gnu/rtrmgr/template_commands.o -c -O1 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -DDEBUG_XRLDB=1 -Iobj/i686-pc-linux-gnu -I. -I. rtrmgr/template_commands.cc rtrmgr/template_commands.cc: In member function ?bool XrlAction::check_xrl_is_valid(const std::list >&, const XRLdb*, std::string&)?: rtrmgr/template_commands.cc:468:16: error: ?const class XRLdb? has no member named ?check_xrl_syntax? rtrmgr/template_commands.cc:474:33: error: ?const class XRLdb? has no member named ?check_xrl_exists? scons: *** [obj/i686-pc-linux-gnu/rtrmgr/template_commands.o] Error 1 scons: building terminated because of errors. Fix for that is to replace VALIDATE_XRLDB with DEBUG_XRLDB in xrldb.hh and xrldb.cc Signed-off-by: Igor Maravic Compare: https://github.com/greearb/xorp.ct/compare/ce0bda5...8b3f50d From greearb at candelatech.com Tue Sep 27 09:41:33 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 27 Sep 2011 09:41:33 -0700 Subject: [Xorp-hackers] [PATCH 0/1] xorp_install.bash fix In-Reply-To: <1317123004-19000-1-git-send-email-igorm@etf.rs> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> Message-ID: <4E81FCBD.3010607@candelatech.com> On 09/27/2011 04:29 AM, Igor Maravic wrote: > Patch for smart script! It checks if adduser supports --system and --no-create-home. > Checking for -M option could be added, but I don't have fedora to test it. > I'm running Ubuntu 11.04 with kernel 2.6.38.8 I applied everything but the optimize SConstruct patch. It still needs work in my opinion. Your patches applied fine, but you need to add useful commit messages for each patch. The patch 0/X email never actually gets into git, it is just for humans to read. The comments you put in the 0/X emails are fine, but you need to add the comments for the individual patches as well. I fixed the commit messages this time, but please make sure you have good commit messages for future patches. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From igorm at etf.rs Wed Sep 28 05:39:36 2011 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Wed, 28 Sep 2011 14:39:36 +0200 Subject: [Xorp-hackers] [PATCH 1/3] SConstruct fixes In-Reply-To: <4E81FA72.2050808@candelatech.com> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> <1317123004-19000-4-git-send-email-igorm@etf.rs> <4E81FA72.2050808@candelatech.com> Message-ID: Yes that check will be false when optimize is set to override. override without options CFLAGS and CXXFLAGS is same as option none. Without my patch, there is no point for the line that I marked with <===, because that flag will never be appended to CFLAGS/CXXFLAGS in if statement that I proposed to change. bigodict = { 'no': '-O0', <=== # 'minimal' denotes only those optimizations # necessary to force gcc to perform the tree_sink # pass, to elide most STL template instantiations. 'minimal': "-O1 -fno-defer-pop -fno-delayed-branch \ -fno-guess-branch-probability -fno-cprop-registers -fno-if-conversion \ -fno-if-conversion2 -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts \ -fno-tree-dse -fno-tree-ter -fno-tree-lrs -fno-tree-sra \ -fno-tree-copyrename -fno-tree-fre -fno-tree-ch -fno-unit-at-a-time \ -fno-merge-constants", 'yes': '-O1', 'full': '-O2', 'highest': '-O3', 'size': '-Os' } Also if someone compiles with the command scons optimize=override CFLAGS=-01 CXXFLAGS=-O0 there is no need to to append something to CFLAGS/CXXFLAGS, when we want to override there behavior. I marked the lines with <==, and that is the if statement that I want to change. if not env['optimize'] == 'no': env.AppendUnique(CFLAGS = [ bigoflag ]) <== env.AppendUnique(CXXFLAGS = [ bigoflag ]) <== That's why I think that my patch should be applied. BR Igor Maravic 2011/9/27 Ben Greear : > On 09/27/2011 04:30 AM, Igor Maravic wrote: >> >> Signed-off-by: Igor Maravic >> --- >> :100644 100644 955e743... 9f5dd79... M ?xorp/SConstruct >> ?xorp/SConstruct | ? ?2 +- >> ?1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/xorp/SConstruct b/xorp/SConstruct >> index 955e743..9f5dd79 100644 >> --- a/xorp/SConstruct >> +++ b/xorp/SConstruct >> @@ -713,7 +713,7 @@ if not env['optimize'] == 'override': >> ? ? ? ? ? ? ? ? ? 'highest': '-O3', >> ? ? ? ? ? ? ? ? ? 'size': '-Os' } >> ? ? ?bigoflag = bigodict[env['optimize']] >> - ? ?if not env['optimize'] == 'no': >> + ? ?if not env['optimize'] == 'override': >> ? ? ? ? ?env.AppendUnique(CFLAGS = [ bigoflag ]) >> ? ? ? ? ?env.AppendUnique(CXXFLAGS = [ bigoflag ]) > > Can that check ever be false? ?I think it cannot. ?And if it cannot, > then I do not want to apply this patch. > > The reason I suggested adding none is if someone wants to use the > compiler default and not use any -O option (which supports the > current optimize=no behaviour in case someone finds that useful). > > Thanks, > Ben > > > -- > Ben Greear > Candela Technologies Inc ?http://www.candelatech.com > > From greearb at candelatech.com Wed Sep 28 09:14:52 2011 From: greearb at candelatech.com (Ben Greear) Date: Wed, 28 Sep 2011 09:14:52 -0700 Subject: [Xorp-hackers] [PATCH 1/3] SConstruct fixes In-Reply-To: References: <1317123004-19000-1-git-send-email-igorm@etf.rs> <1317123004-19000-4-git-send-email-igorm@etf.rs> <4E81FA72.2050808@candelatech.com> Message-ID: <4E8347FC.1030204@candelatech.com> On 09/28/2011 05:39 AM, Igor Maravi? wrote: > Yes that check will be false when optimize is set to override. > > override without options CFLAGS and CXXFLAGS is same as option none. > > Without my patch, there is no point for the line that I marked with > <===, because that flag will never be appended to CFLAGS/CXXFLAGS in > if statement that I proposed to change. > > bigodict = { 'no': '-O0',<=== > # 'minimal' denotes only those optimizations > # necessary to force gcc to perform the tree_sink > # pass, to elide most STL template instantiations. > 'minimal': "-O1 -fno-defer-pop -fno-delayed-branch \ > -fno-guess-branch-probability -fno-cprop-registers -fno-if-conversion \ > -fno-if-conversion2 -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts \ > -fno-tree-dse -fno-tree-ter -fno-tree-lrs -fno-tree-sra \ > -fno-tree-copyrename -fno-tree-fre -fno-tree-ch -fno-unit-at-a-time \ > -fno-merge-constants", > 'yes': '-O1', > 'full': '-O2', > 'highest': '-O3', > 'size': '-Os' } > > Also if someone compiles with the command > > scons optimize=override CFLAGS=-01 CXXFLAGS=-O0 > > there is no need to to append something to CFLAGS/CXXFLAGS, when we > want to override there behavior. > I marked the lines with<==, and that is the if statement that I want to change. > > if not env['optimize'] == 'no': > env.AppendUnique(CFLAGS = [ bigoflag ])<== > env.AppendUnique(CXXFLAGS = [ bigoflag ])<== > > That's why I think that my patch should be applied. Look at the entire section of existing code: If optimize == overide, then the entire branch is skipped: # If the user didn't override our default optimization, then # sanitize user's CFLAGS/CXXFLAGS to not contain optimization options, # and map to an appropriate GCC flag. if not env['optimize'] == 'override': # Never get here if optimize == override. env.Replace( CFLAGS = filter(lambda s: not s.startswith('-O'), Split(env['CFLAGS']))) env.Replace( CXXFLAGS = filter(lambda s: not s.startswith('-O'), Split(env['CXXFLAGS']))) bigodict = { 'no': '-O0', # 'minimal' denotes only those optimizations # necessary to force gcc to perform the tree_sink # pass, to elide most STL template instantiations. 'minimal': "-O1 -fno-defer-pop -fno-delayed-branch \ -fno-guess-branch-probability -fno-cprop-registers -fno-if-conversion \ -fno-if-conversion2 -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts \ -fno-tree-dse -fno-tree-ter -fno-tree-lrs -fno-tree-sra \ -fno-tree-copyrename -fno-tree-fre -fno-tree-ch -fno-unit-at-a-time \ -fno-merge-constants", 'yes': '-O1', 'full': '-O2', 'highest': '-O3', 'size': '-Os' } bigoflag = bigodict[env['optimize']] if not env['optimize'] == 'no': env.AppendUnique(CFLAGS = [ bigoflag ]) env.AppendUnique(CXXFLAGS = [ bigoflag ]) I'm not arguing that the current code is right, but just that your patch is not much better. I'll post my proposed fix for this later today... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Wed Sep 28 11:54:41 2011 From: noreply at github.com (noreply at github.com) Date: Wed, 28 Sep 2011 11:54:41 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 45d026: Add copyright header to bug_cather.hh Message-ID: <20110928185441.757A6424F7@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 45d0265e8ede357b966cfc055036a720ee958593 https://github.com/greearb/xorp.ct/commit/45d0265e8ede357b966cfc055036a720ee958593 Author: Ben Greear Date: 2011-09-28 (Wed, 28 Sep 2011) Changed paths: M xorp/libxorp/bug_catcher.hh Log Message: ----------- Add copyright header to bug_cather.hh Commit: 0dc522ad3c494706949a8235a14632acf4880121 https://github.com/greearb/xorp.ct/commit/0dc522ad3c494706949a8235a14632acf4880121 Author: Ben Greear Date: 2011-09-28 (Wed, 28 Sep 2011) Changed paths: M xorp/SConstruct M xorp/cli/cli_node_net.cc M xorp/libxorp/SConscript A xorp/libxorp/build_info.hh A xorp/libxorp/build_info.prefix A xorp/libxorp/create_buildinfo.sh M xorp/rtrmgr/main_rtrmgr.cc Log Message: ----------- build-info: Support auto-generated build information. This shows build date, git hash, recent git logs, etc. Verbose info is printed in the logs when rtrmgr starts, and a brief line of text is output for xorpsh on startup as well. Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/8b3f50d...0dc522a From noreply at github.com Wed Sep 28 12:25:58 2011 From: noreply at github.com (noreply at github.com) Date: Wed, 28 Sep 2011 12:25:58 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 1f32ab: build-info: Defaults to enabled. Message-ID: <20110928192558.EE65242641@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 1f32abb0fc86694dff4e740da5b57ae133884932 https://github.com/greearb/xorp.ct/commit/1f32abb0fc86694dff4e740da5b57ae133884932 Author: Ben Greear Date: 2011-09-28 (Wed, 28 Sep 2011) Changed paths: M xorp/SConstruct Log Message: ----------- build-info: Defaults to enabled. Also, don't re-create file when doing --help or clean. Signed-off-by: Ben Greear From noreply at github.com Wed Sep 28 14:06:49 2011 From: noreply at github.com (noreply at github.com) Date: Wed, 28 Sep 2011 14:06:49 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] f66bae: build-info: Add xorp version string to xorpsh. Message-ID: <20110928210649.EDBBA427FC@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: f66bae27f3ccd0d82b4e953ef99d1b84be87298a https://github.com/greearb/xorp.ct/commit/f66bae27f3ccd0d82b4e953ef99d1b84be87298a Author: Ben Greear Date: 2011-09-28 (Wed, 28 Sep 2011) Changed paths: M xorp/RELEASE_NOTES M xorp/SConstruct M xorp/cli/cli_node_net.cc M xorp/cli/cli_private.hh M xorp/libxorp/build_info.hh M xorp/libxorp/build_info.prefix M xorp/rtrmgr/main_rtrmgr.cc M xorp/rtrmgr/master_conf_tree.cc Log Message: ----------- build-info: Add xorp version string to xorpsh. This also makes the version available to all code, so remove the #define hack in master_conf_tree.cc This means one less place we have to change the xorp version. Also, add run-time info (uname -a, cat /etc/issue if it exists) to the xorp logs to aid trouble-shooting bug reports. Signed-off-by: Ben Greear From greearb at candelatech.com Wed Sep 28 14:14:35 2011 From: greearb at candelatech.com (Ben Greear) Date: Wed, 28 Sep 2011 14:14:35 -0700 Subject: [Xorp-hackers] [PATCH 1/3] SConstruct fixes In-Reply-To: <4E8347FC.1030204@candelatech.com> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> <1317123004-19000-4-git-send-email-igorm@etf.rs> <4E81FA72.2050808@candelatech.com> <4E8347FC.1030204@candelatech.com> Message-ID: <4E838E3B.5040509@candelatech.com> On 09/28/2011 09:14 AM, Ben Greear wrote: > On 09/28/2011 05:39 AM, Igor Maravi? wrote: >> Yes that check will be false when optimize is set to override. How about this patch. I think it basically does the same thing as you suggested, just cleaner code: diff --git a/xorp/SConstruct b/xorp/SConstruct index 81ced07..c094ea5 100644 --- a/xorp/SConstruct +++ b/xorp/SConstruct @@ -731,9 +731,8 @@ if not env['optimize'] == 'override': 'highest': '-O3', 'size': '-Os' } bigoflag = bigodict[env['optimize']] - if not env['optimize'] == 'no': - env.AppendUnique(CFLAGS = [ bigoflag ]) - env.AppendUnique(CXXFLAGS = [ bigoflag ]) + env.AppendUnique(CFLAGS = [ bigoflag ]) + env.AppendUnique(CXXFLAGS = [ bigoflag ]) # At least on Fedora 13, -Os breaks build with strict-aliasing # warnings. Code looks right to me, so going to just disable I'm also going to change the default optimize level to 'full' (-O2) unless someone has any objections. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Wed Sep 28 14:39:18 2011 From: noreply at github.com (noreply at github.com) Date: Wed, 28 Sep 2011 14:39:18 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 1a8e9c: build: Always add bigoflag unless using override. Message-ID: <20110928213918.3C60A4289D@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 1a8e9cd65d4d8941811c43ea71b6fe59aef62fca https://github.com/greearb/xorp.ct/commit/1a8e9cd65d4d8941811c43ea71b6fe59aef62fca Author: Ben Greear Date: 2011-09-28 (Wed, 28 Sep 2011) Changed paths: M xorp/SConstruct Log Message: ----------- build: Always add bigoflag unless using override. Reported-by: Igor Maravic Signed-off-by: Ben Greear Commit: bd10544921594e7fd5a9d2d671939b0d879923b1 https://github.com/greearb/xorp.ct/commit/bd10544921594e7fd5a9d2d671939b0d879923b1 Author: Ben Greear Date: 2011-09-28 (Wed, 28 Sep 2011) Changed paths: M xorp/SConstruct Log Message: ----------- compile: Use 'full' optimization by default: -O2 Slows down the compile a bit, but should produce faster executables. Users can always specify their preferred optimization if they want something different. Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/f66bae2...bd10544 From noreply at github.com Wed Sep 28 16:11:34 2011 From: noreply at github.com (noreply at github.com) Date: Wed, 28 Sep 2011 16:11:34 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 7ad274: mii: Fix strict-aliasing warnings when compilign ... Message-ID: <20110928231134.8CFAF428BE@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 7ad274763d95eacfb28c655057beb4e1c6ac5090 https://github.com/greearb/xorp.ct/commit/7ad274763d95eacfb28c655057beb4e1c6ac5090 Author: Ben Greear Date: 2011-09-28 (Wed, 28 Sep 2011) Changed paths: M xorp/fea/data_plane/ifconfig/ifconfig_media.cc Log Message: ----------- mii: Fix strict-aliasing warnings when compilign with -O2 This was seen on a Fedora 13 system (gcc 4.4.5) Signed-off-by: Ben Greear Commit: 8c691778aac058f8303142257bb89078830a54e4 https://github.com/greearb/xorp.ct/commit/8c691778aac058f8303142257bb89078830a54e4 Author: Ben Greear Date: 2011-09-28 (Wed, 28 Sep 2011) Changed paths: M xorp/contrib/olsr/message.hh M xorp/contrib/olsr/topology.cc Log Message: ----------- olsr: Fix un-used variable warnings. Seen on Fedora 13 (gcc 4.4.5) with -O2 optimization. Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/bd10544...8c69177 From igorm at etf.rs Wed Sep 28 23:16:12 2011 From: igorm at etf.rs (=?ISO-8859-2?Q?Igor_Maravi=E6?=) Date: Thu, 29 Sep 2011 08:16:12 +0200 Subject: [Xorp-hackers] [PATCH 1/3] SConstruct fixes In-Reply-To: <4E838E3B.5040509@candelatech.com> References: <1317123004-19000-1-git-send-email-igorm@etf.rs> <1317123004-19000-4-git-send-email-igorm@etf.rs> <4E81FA72.2050808@candelatech.com> <4E8347FC.1030204@candelatech.com> <4E838E3B.5040509@candelatech.com> Message-ID: Yes, that patch looks better. BR Igor Maravic 2011/9/28 Ben Greear : > On 09/28/2011 09:14 AM, Ben Greear wrote: >> >> On 09/28/2011 05:39 AM, Igor Maravi? wrote: >>> >>> Yes that check will be false when optimize is set to override. > > How about this patch. ?I think it basically does the same > thing as you suggested, just cleaner code: > > diff --git a/xorp/SConstruct b/xorp/SConstruct > index 81ced07..c094ea5 100644 > --- a/xorp/SConstruct > +++ b/xorp/SConstruct > @@ -731,9 +731,8 @@ if not env['optimize'] == 'override': > ? ? ? ? ? ? ? ? ?'highest': '-O3', > ? ? ? ? ? ? ? ? ?'size': '-Os' } > ? ? bigoflag = bigodict[env['optimize']] > - ? ?if not env['optimize'] == 'no': > - ? ? ? ?env.AppendUnique(CFLAGS = [ bigoflag ]) > - ? ? ? ?env.AppendUnique(CXXFLAGS = [ bigoflag ]) > + ? ?env.AppendUnique(CFLAGS = [ bigoflag ]) > + ? ?env.AppendUnique(CXXFLAGS = [ bigoflag ]) > > ? ? # At least on Fedora 13, -Os breaks build with strict-aliasing > ? ? # warnings. ?Code looks right to me, so going to just disable > > > I'm also going to change the default optimize level to 'full' (-O2) > unless someone has any objections. > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc ?http://www.candelatech.com > > From noreply at github.com Thu Sep 29 10:03:39 2011 From: noreply at github.com (noreply at github.com) Date: Thu, 29 Sep 2011 10:03:39 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] a44ec4: buildinfo: Make script deal better with missing p... Message-ID: <20110929170339.C6AB2428D9@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: a44ec46afdb6e6482911d738d009e6b50affa74d https://github.com/greearb/xorp.ct/commit/a44ec46afdb6e6482911d738d009e6b50affa74d Author: Ben Greear Date: 2011-09-29 (Thu, 29 Sep 2011) Changed paths: M xorp/SConstruct M xorp/libxorp/create_buildinfo.sh Log Message: ----------- buildinfo: Make script deal better with missing perl & git. Check for executables in the script and use dummy values if they are not available. Signed-off-by: Ben Greear From noreply at github.com Thu Sep 29 10:45:56 2011 From: noreply at github.com (noreply at github.com) Date: Thu, 29 Sep 2011 10:45:56 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 3a12a5: netbsd: Fix sockutil.cc build on netbsd. Message-ID: <20110929174556.75F0142676@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 3a12a5eebd295619b021f16b5f2b871fe232c690 https://github.com/greearb/xorp.ct/commit/3a12a5eebd295619b021f16b5f2b871fe232c690 Author: Ben Greear Date: 2011-09-29 (Thu, 29 Sep 2011) Changed paths: M xorp/libxipc/sockutil.cc Log Message: ----------- netbsd: Fix sockutil.cc build on netbsd. Error looks like: g++ -o obj/x86_64-unknown-netbsd5.1./libxipc/sockutil.os -c -O1 -g3 -Werror -W -Wall -Wwrite-strings -Wcast-qual -Wpointer-arith -Wcast-align -Woverloaded-virtual -ftemplate-depth-25 -pipe -fPIC -DXRL_PF=120 -D_FORTIFY_SOURCE=0 -Iobj/x86_64-unknown-netbsd5.1. -I. -I. libxipc/sockutil.cc cc1plus: warnings being treated as errors libxipc/sockutil.cc: In function 'void get_active_ipv4_addrs(std::vector >&)': libxipc/sockutil.cc:311: warning: deleting 'void*' is undefined libxipc/sockutil.cc:317: warning: deleting 'void*' is undefined Use malloc/free instead of new/delete[] Reported-by: Uwe <6bone at 6bone.informatik.uni-leipzig.de> Original patch from: Joerg Sonnenberger Signed-off-by: Ben Greear Commit: 4265327f3754f1a470c8555dc19cbb744aa19ce2 https://github.com/greearb/xorp.ct/commit/4265327f3754f1a470c8555dc19cbb744aa19ce2 Author: Ben Greear Date: 2011-09-29 (Thu, 29 Sep 2011) Changed paths: M xorp/fea/data_plane/control_socket/click_socket.cc Log Message: ----------- netbsd: Fix click mount command for netbsd. This patch is from the netbsd project: $NetBSD: patch-ab,v 1.9 2009/05/12 13:58:44 obache Exp $ Signed-off-by: Ben Greear Commit: 8ca3b19e03c541e384a06a6c65a3dcfeda0726ea https://github.com/greearb/xorp.ct/commit/8ca3b19e03c541e384a06a6c65a3dcfeda0726ea Author: Ben Greear Date: 2011-09-29 (Thu, 29 Sep 2011) Changed paths: M xorp/fea/data_plane/ifconfig/ifconfig_get_ioctl.cc Log Message: ----------- netbsd: Fix compile problem in ifconfig_get_ioctl. This is another malloc/free v/s new/delete[] bugfix, from the netbsd project: $NetBSD: patch-ac,v 1.5 2009/05/12 13:58:44 obache Exp $ Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/a44ec46...8ca3b19 From namnninh at yahoo.com Fri Sep 30 11:19:47 2011 From: namnninh at yahoo.com (Nam Ninh) Date: Fri, 30 Sep 2011 11:19:47 -0700 (PDT) Subject: [Xorp-hackers] A question about sock ID Message-ID: <1317406787.44998.YahooMailNeo@web161715.mail.bf1.yahoo.com> Hi; ? I am new user to XORP. ?I would like to ask about socket? kernel. I try to access to socket kernel through XORP XRL SOCK4.XRL. When I issue a call XrlSocket4V0p1Client::send_udp_open, Xorp returns a socket ID but? it is in the string format. ?My question is how I can get the actual socket ID from the kernel?? ?I dig in XORP code, I found a code: ? IoTcpUdpSocket::udp_open (string &error) { ?? ............. ?? _sock_fd = comm_open_udp (family(), COMM_SOCK_NONBLOCKING) .............. ? } where XorpFd? _sock_fd. in libcomm. The routinr comm_open_udp? returns an interger. It is a socket Id (or Fd) Thanks you. Nam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110930/2e53d6e8/attachment.html From noreply at github.com Fri Sep 30 14:10:28 2011 From: noreply at github.com (noreply at github.com) Date: Fri, 30 Sep 2011 14:10:28 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] cd5913: xlog: Simplify xlog framework. Message-ID: <20110930211028.35D9642881@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: cd59132234942330d01af1686a0cfa17d7787a53 https://github.com/greearb/xorp.ct/commit/cd59132234942330d01af1686a0cfa17d7787a53 Author: Ben Greear Date: 2011-09-29 (Thu, 29 Sep 2011) Changed paths: M xorp/libxorp/xlog.c M xorp/libxorp/xlog.h M xorp/rtrmgr/module_manager.cc Log Message: ----------- xlog: Simplify xlog framework. Try to check levels in the macros, before calling any functions. This should keep us from evaluating all of the foo.str().c_str() logic in un-used tracing code. Remove un-used locking code in xlog.* Remove macro-generated functions..they are not needed at all. Signed-off-by: Ben Greear Commit: 6a8b70cb6ed5e8a737cce546ae281608a6ffe75c https://github.com/greearb/xorp.ct/commit/6a8b70cb6ed5e8a737cce546ae281608a6ffe75c Author: Ben Greear Date: 2011-09-30 (Fri, 30 Sep 2011) Changed paths: M xorp/ospf/peer.cc Log Message: ----------- ospf: Remove some overly verbose trace debugging. This just spammed logs with info that wasn't much use. Signed-off-by: Ben Greear Commit: 1a954c6b31fef1d31f3a0e9f1ef431adf460d431 https://github.com/greearb/xorp.ct/commit/1a954c6b31fef1d31f3a0e9f1ef431adf460d431 Author: Ben Greear Date: 2011-09-30 (Fri, 30 Sep 2011) Changed paths: M xorp/ospf/xorp_ospfv2.cc Log Message: ----------- ospf: Set trace logging verbosity to high. This causes file:line numbers to be printed in the tracing messages, which is a big help for debugging. Signed-off-by: Ben Greear Commit: 5eb7467144b4a17244179bf0fe7d279f163c3031 https://github.com/greearb/xorp.ct/commit/5eb7467144b4a17244179bf0fe7d279f163c3031 Author: Ben Greear Date: 2011-09-30 (Fri, 30 Sep 2011) Changed paths: M xorp/ospf/peer.cc M xorp/ospf/peer.hh Log Message: ----------- ospf: Fix bad lsa retransmit timer bug. A user reported very slow OSPF convergence times when xorp was connected to a larger OSPF network. The root cause is that the LSA retransmit timer could get in a state where it rarely if ever fired due to it being constantly reset whenever an LSA arrived. It would eventually go to Full when all of the LSAs were (re)flooded to it, but this could take many minutes. The fix is to not restart the timer if it is already running. This bug appears to be quite old. Signed-off-by: Ben Greear Commit: 0598d01ff03f2ab5d71b2b79cf366e565e85c998 https://github.com/greearb/xorp.ct/commit/0598d01ff03f2ab5d71b2b79cf366e565e85c998 Author: Ben Greear Date: 2011-09-30 (Fri, 30 Sep 2011) Changed paths: M xorp/ospf/peer.cc Log Message: ----------- ospf: Improve some debugging messages. This proved helpful when tracking down the OSPF retransmit timer bug. Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/8ca3b19...0598d01 From greearb at candelatech.com Fri Sep 30 14:16:05 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 30 Sep 2011 14:16:05 -0700 Subject: [Xorp-hackers] OSPF slow-to-converge bug fixed. Message-ID: <4E863195.2040304@candelatech.com> A customer reported some problems with OSPF being very slow to go to 'Full' state. Turns out, there was a retransmit timer bug in ospf. It's been there for a while, probably back to at least 1.7 Anyway, it appears to be fixed now. So, if anyone had any issues with OSPF being slow to converge, please try out the top-of-tree and see if it works better for you. And of course everyone else is invited to try it as well, and let me know if you see any funny-ness. I also attempted some logging optimization. I believe the old code would compute all of the logging data arguments (like if you had XLOG_TRACE(true, "%s", foo.str().c_str()), then foo.str() would be called even if tracing was disabled). I think I have that fixed as well. Should make things perform better, but at a cost of slightly larger executables. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com