Hi Jonathan, I'm not sure how up-to-date the grid elements are. I've checked in some updates to the grid code, however.
> When I add support for grids, I get the following > error: > > CXX ../elements/grid/dsdvroutetable.cc > ../elements/grid/dsdvroutetable.cc: In member function > 'void > DSDVRouteTable::build_and_tx_ad(Vector<DSDVRouteTable::RTEntry>&)': > ../elements/grid/dsdvroutetable.cc:1500: error: cast > from 'unsigned char*' to 'unsigned int' loses > precision > ../elements/grid/dsdvroutetable.cc:1515: error: cast > from 'grid_hdr*' to 'unsigned int' loses precision > > These lines are macro calls to ASSERT_ALIGNED, which > is defined in grid.hh as follows: > > // packet data should be 4 byte aligned > #define ASSERT_ALIGNED(p) assert(((unsigned int)(p) % > 4) == 0) > > > First off, will the assumption of 4 byte alignment > hold true on 64-bit platforms? Yes. This assertion refers to packet formats, which need to be 4-byte aligned as that's the network format. The problem was that the formats themselves used types like 'unsigned int' that might turn into 64-bit types. I've updated this. > A temporary workaround (just casting it to an unsigned > long int) gets past that problem. However, a few files > later, I run into a much bigger problem, also in the > grid code: > > CXX ../elements/grid/gridheaderinfo.cc > ../elements/grid/gridheaderinfo.cc:61: warning: > invalid access to non-static data member > 'grid_hdr::version' of NULL object > ../elements/grid/gridheaderinfo.cc:61: warning: > (perhaps the 'offsetof' macro was used incorrectly) > ../elements/grid/gridheaderinfo.cc:62: warning: > invalid access to non-static data member > 'grid_hdr::type' of NULL object > ../elements/grid/gridheaderinfo.cc:62: warning: > (perhaps the 'offsetof' macro was used incorrectly) > ../elements/grid/gridheaderinfo.cc:63: warning: > invalid access to non-static data member > 'grid_hdr::ip' of NULL object > ../elements/grid/gridheaderinfo.cc:63: warning: > (perhaps the 'offsetof' macro was used incorrectly) > ../elements/grid/gridheaderinfo.cc:64: warning: > invalid access to non-static data member > 'grid_hdr::tx_ip' of NULL object > ../elements/grid/gridheaderinfo.cc:64: warning: > (perhaps the 'offsetof' macro was used incorrectly) > ../elements/grid/gridheaderinfo.cc:65: warning: > invalid access to non-static data member > 'grid_hdr::total_len' of NULL object > ../elements/grid/gridheaderinfo.cc:65: warning: > (perhaps the 'offsetof' macro was used incorrectly) > ../elements/grid/gridheaderinfo.cc:67: warning: > invalid access to non-static data member > 'grid_nbr_encap::dst_ip' of NULL object > ../elements/grid/gridheaderinfo.cc:67: warning: > (perhaps the 'offsetof' macro was used incorrectly) > ../elements/grid/gridheaderinfo.cc:69: warning: > invalid access to non-static data member > 'grid_loc_query::dst_ip' of NULL object > ../elements/grid/gridheaderinfo.cc:69: warning: > (perhaps the 'offsetof' macro was used incorrectly) > ../elements/grid/gridheaderinfo.cc: In function > 'String ghi_read_handler(Element*, void*)': > ../elements/grid/gridheaderinfo.cc:98: error: cast > from 'void*' to 'int' loses precision > > The error itself is again a 32-bit vs. 64-bit issue, > but some of the warnings indicate that there may be > other cleanups required. Error fixed! The warnings are hard to fix. > The test elements also hace a 32-bit-ism: > > CXX ../elements/test/upstreamnotifier.cc > ../elements/test/upstreamnotifier.cc: In function 'int > write_param(const String&, Element*, void*, > ErrorHandler*)': > ../elements/test/upstreamnotifier.cc:87: error: cast > from 'void*' to 'int' loses precision Fixed! > Finaly, these two warnings don't look serious to me, > but I'd value a second opinion simply because of the > above problems: > > CXX ../elements/ip/ipratemon.cc > ../elements/ip/ipratemon.cc: In destructor > 'IPRateMonitor::Stats::~Stats()': > ../elements/ip/ipratemon.cc:249: warning: overflow in > implicit constant conversion > ../elements/ip/ipratemon.cc:281: warning: overflow in > implicit constant conversion Not a problem, I think. Eddie > > Thanks, > > Jonathan Day > > --- Adam Greenhalgh <[EMAIL PROTECTED]> wrote: > >> We've had a number of problems with 64bit click on >> an AMD 64, I've >> posted some fixes to the list and we now seem to >> have it running ok >> now. Where we are seeing an issue is the polling >> driver for the e1000, >> I'm not totally sure whether the driver or the click >> linux integration >> or both are at fault. If I get a free moment, I'll >> look further, but >> life is a bit manic at the moment. >> >> Adam >> >> On 6/15/06, Jonathan Day <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> Yes, I'm using 1.5. I'm downloading the CVS files >> as I >>> type, to see if those work better. I guess I >> should >>> specify a little more precisely. I'm compiling on >> a >>> Broadcom BCM1250 (a dual-core system based on the >> SB1, >>> which is a processor based on version 0.95 of the >>> 64bit MIPS specification). >>> >>> This is a notoriously evil platform, so it is hard >> to >>> determine which problems lie in the Click code and >>> which lie in a CPU that surely must constitute >> cruel >>> and unusual punishment toards programmers. >>> >>> I am also going to do some tests to see if it is a >>> problem in the options I selected, so I can give a >>> more useful report on what the problem is, now >> that >>> it's clear that 64-bit platforms are working. >>> >>> Jonathan >>> >>> --- Bart Braem <[EMAIL PROTECTED]> wrote: >>> >>>> On Thursday 15 June 2006 01:28, Jonathan Day >> wrote: >>>>> Does anyone have a set of patches to make >> Click >>>> 64-bit >>>>> clean? If not, does anyone have any >> suggestions on >>>> how >>>>> I could fix the type length issues without >>>> breaking >>>>> any of the requirements of Click? >>>> Are you sure you are using the latest version of >>>> Click (at least 1.5 or even >>>> better CVS)? There have been reports on this >> list of >>>> Click running on 64 bit >>>> and there are certainly fixes in the Click >> source... >>>> Bart >>>> -- >>>> Bart Braem >>>> PATS research group >>>> Dept. of Mathematics and Computer Sciences >>>> University of Antwerp >>>> G2.36, Building G >>>> Middelheimlaan 1 >>>> 2020 Antwerpen, Belgium >>>> Phone: +32 (0)3 265.35.19. >>>> Fax: +32 (0)3 265.37.77. >>>> Web: www.pats.ua.ac.be >> _______________________________________________ >>>> click mailing list >>>> [email protected] >>>> >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam >> protection around >>> http://mail.yahoo.com >>> _______________________________________________ >>> click mailing list >>> [email protected] >>> >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
