[Click] compile time fixes

Remo Strotkamp remo at nec-labs.com
Wed Apr 28 18:02:23 EDT 2004


Hey again,

here we go with compile time error fixes:

#1: 
change line 114 of include/net/checksum.h from
  sum = csum_partial( src, len, sum);
to 
  sum = csum_partial( (const unsigned char*) src, len, sum);


#2:
in click/include/atomic.hh line 46: change from
      atomic_clear_mask(u,  &_val);
to
    atomic_clear_mask(u, (long unsigned int*) &_val);


#3: Now this one I have a really bad feeling about as it's in
  files called atomic and atomic operations aren't my thingie!!!
  So the problem was that for arm there is no atomic_set_mask   
  defined. So I took the include/asm-sh/atomic.h as a template to
  add a new atomic_set_mask function in include/asm-arm/atomic.h
  (somebody who knows anything about these things will HAVE to have
   a look at this hack, cuz I don't)

--> add to include/asm-arm/atomic.h:
  static inline void atomic_set_mask(unsigned long mask, unsigned long
*addr)
{
	unsigned long flags;

	local_irq_save(flags);
	*addr |= ~mask;
	local_irq_restore(flags);
}

and change line 53 in click/include/click/atomic.hh from
    atomic_set_mask(u, &_val);
to
    atomic_set_mask(u, (long unsigned int*) &_val);

#4
Now this one is getting even stranger....
There are two static_assert statements in include/click/atomic.hh that
make 
absolutely no sense:
 Line 71:    static_assert("no support for SMP on non-i386 machines");
 Line 98:    static_assert("no support for SMP on non-i386 machines");

I don't know what the intention of these statements are. Maybe
static_assert had a different synthax
in previous versions and these statements got never changed. Or they
were supposed to be error
printouts, but use the wrong function. Or maybe their purpose is to keep
it all being compiled on 
platforms like mine....   In either case I'll need feedback in order to
know what do do about it all.
For the moment I just commented them out, so it at least compiles and I
can hunt down more errors....

#5:  _aligned is used but never defined in
elements/grid/gridproxy.cc.....
   here's what I did, based on elements/ip/ipencap.{hh,cc}

  Add to grid/gridproxy.hh: 
#if HAVE_FAST_CHECKSUM && FAST_CHECKSUM_ALIGNED
  bool _aligned;
#endif

add to elements/grid/gridproxy.cc line 22
#include <click/error.hh>
#include <click/standard/alignmentinfo.hh>


and to grid/gridproxy.cc on line 76:
#if HAVE_FAST_CHECKSUM && FAST_CHECKSUM_ALIGNED
  // check alignment
  {
    int ans, c, o;
    ans = AlignmentInfo::query(this, 0, c, o);
    _aligned = (ans && c == 4 && o == 0);
    if (!_aligned)
      errh->warning("IP header unaligned, cannot use fast IP checksum");
    if (!ans)
      errh->message("(Try passing the configuration through
`click-align'.)");
  }
#endif


that's it, after these changes it compiled through.... didn't have time
to test it on the
arm platform yet, probably tomorrow...

hope this is of any help


remo



On Tue, 2004-04-27 at 20:44, Eddie Kohler wrote:

> Hi Remo,
> 
> On Apr 27, 2004, at 3:40 PM, Remo Strotkamp wrote:
> >  #1 for userland click on an alignement picky machine, the compile 
> > fails
> >     for elements/userlevel/fromfile.cc for line:
> >              memcpy(buffer, chunk, sizeof(*ph));
> >
> >    which is not really surprising as ph doesn't seem to be defined
> >    anywhere. I got it to compile by inserting the following line right
> >    before the offending one (WARNING: I don't know if that's the right
> >     thing to do AT ALL, but it makes it compile and I don't plan to use
> >    FromFile....)
> >
> >              const fake_pcap_pkthdr *ph;
> 
> Thanks for reporting this bug!  We've fixed it in CVS.  (The right fix
> is to use 'size' instead of 'sizeof(*ph)'.)
> 
> >  #2  when crosscompiling the kernel (had quite some rejects with the 
> >      different patches (click, click-wifi, arm, xscale,....) the
> >      click-wifi module wouldn't compile. The reason here seemed to have
> >      been that the drivers/net/wifi/click-wifi.c is missing an #include
> >      <linux/init.h> line...
> >      (but that might be due to the patch rejects and me not cleaning up
> >       the mess properly )
> >
> >
> >  while trying to configure the click router, the scrip tells me that I 
> > need to apply the provided patches, even though I did. Anybody any
> >  ideas where that one's coming from?
> 
> It looks like you need to patch
> 
> >  /usr/local/arm/src/linux-2.4.19/include/asm/proc/pgalloc.h: In 
> > function `pte_t*
> >     pte_alloc_one(mm_struct*, long unsigned int)':
> >  /usr/local/arm/src/linux-2.4.19/include/asm/proc/pgalloc.h:25: invalid
> >     conversion from `void*' to `pte_t*'
> 
> this line by adding an explicit "(pte_t *)" cache before the call
> to 'kmem_cache_alloc'.
> 
> The Click patches implement several cleanups to kernel sources, but
> we've only cleaned up files we've needed in the past.  When you port
> to a new architecture, you may need to:
> 
> 1. Introduce explicit casts from 'void *' (as above).  C++ doesn't
>     allow implicit casts from void*.
> 
> 2. Change "::" in asm statements to ": :".  It looks like your second
>     error is of this type, but in my patched 2.4.20 kernel, the line
>     has been patched correctly.  Maybe it's not in our 2.4.19 patch?
> 
> 3. Fix "const" bugs and pointer cast bugs (i.e. where function A is
>     declared to return 'const unsigned char *' but it actually returns
>     'const char *').
> 
> Anyway, what would help us the most would be for you to fix the problems
> you're seeing now, then report the complete list when you're done.
> 
> Thanks!!
> Eddie


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://amsterdam.lcs.mit.edu/pipermail/click/attachments/20040428/218bd2d2/attachment.htm


More information about the click mailing list