Pradeep Pradeep | 2 May 2008 02:07
Picon
Favicon

[click] poblems while running make install

Hi everyone,
                   I have written and complied one click element. Later I made some changes to it. To compile it I ran make
install. Then the error messages which appeared were
          make install
make[1]: Entering directory `/home/krishna/Desktop/click-1.6.0/userlevel'
.../mkinstalldirs /click1.6/lib
for i in libclick.a; do /usr/bin/install -c $i /click1.6/lib/$i; done
/usr/bin/install: cannot remove `/click1.6/lib/libclick.a': Permission denied
make[1]: *** [install-lib] Error 1
make[1]: Leaving directory `/home/krishna/Desktop/click-1.6.0/userlevel'
make: *** [install] Error 1

      I removed the changes I made to my element (The element is the same element which compiled before). Now I when
I run make install the same error messages keep coming. Did I screw anything?

Regards,
Krishna.

       
---------------------------------
 Meet people who discuss and share your passions.  Join them now.
Jeff Enderwick | 2 May 2008 01:50
Picon
Favicon

Counters or other instrumentation

Using Click embedded in a Linux kernel. Wondering if there is any
infrastructure to maintain counters at each port, or other instrumentation
to see where the packets are going. If not, it might be a cool thing :-)
Roman Chertov | 2 May 2008 15:18
Picon
Favicon

Re: Counters or other instrumentation

Hello Jeff,
   Each ToDevice has a counter associated with it.   Additionally, you 
can use AverageCounter elements to provide you with count/rate 
statistics for packets and bytes.

Roman

Jeff Enderwick wrote:
> Using Click embedded in a Linux kernel. Wondering if there is any
> infrastructure to maintain counters at each port, or other instrumentation
> to see where the packets are going. If not, it might be a cool thing :-)
> 
> _______________________________________________
> click mailing list
> click <at> amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> 
Ashish Sharma | 6 May 2008 00:09
Picon

Re: [PATCH] patches for linux 2.6.24

Hi,
I am trying to install linux-module click on the latest Ubuntu Heron Hardy
distribution which comes with 2.6.24-16 kernel. While trying to apply your
attached patch, I got a bunch of reject files. I tried applying the same
patch to 2.6.24 and 2.6.24.3 and again a bunch of reject files. Could
someone please let me know if there is a latest patch somewhere that I
should apply, or atleast which kernel in the 2.6.24 series has a complete
patch. I am even willing to go with 2.6.19 series, but I wanted to check
with the mailing list first.
Also, does the latest Click on git repository has all the patches or do I
still need to apply the patch that was attached in the last email from
Joonwoo. (I got a bunch of patch rejects when I tried applying it to the
current click version from git repo).

Thanks for your help.
Ashish

On Mon, Apr 21, 2008 at 9:46 AM, Joonwoo Park <joonwpark81 <at> gmail.com> wrote:

> 2008/3/20, Joonwoo Park <joonwpark81 <at> gmail.com>:
> > 2008/2/14, Joonwoo Park <joonwpark81 <at> gmail.com>:
> >
> > > On Mon, Feb 11, 2008 at 05:10:18PM -0000, Egi, Norbert wrote:
> >  > > >I guess the assertion issue  is releated locking problem, I sent a
> patch for it.
> >  > > >Since I'm off for this week, I can't test your patch at this
> moment.
> >  > > >I'll dig these things at next week and I'll try NAPI as a possible
> >  > > >option for e1000 that you patched.
> >  > >
(Continue reading)

Bart Braem | 6 May 2008 10:03
Picon

Can/does cp_va_(k)parse check size of its arguments?

Hello,

One of our students encountered a nasty bug where he parsed an element  
configuration into variables that were too small: he used a cpUnsigned  
argument to put data in a uint8_t. The variables next to that uint8_t  
where overwritten and some bytes were mysteriously changed.
At first sight cp_va_kparse does check for this size problem but it  
does not seem to work, or am I mistaken?

Regards,
Bart
--

-- 
Bart Braem
PATS research group
Dept. of Mathematics and Computer Sciences
University of Antwerp
Campus Middelheim, G2.36
Middelheimlaan 1
B-2020 Antwerpen, Belgium
Phone: +32 (0)3 265.32.91
Fax: +32 (0)3 265.37.77
Web: www.pats.ua.ac.be
Bart Braem | 6 May 2008 10:13
Picon

Re: Coverity?

Picking up a very old mail here: do you have any problems with it if I  
try to restart this?
I have even found a mail from Coverity at the Click mailinglist to  
scan this project. It would be very good to give Click industry- 
quality code, the project would benefit a lot...

Regards,
Bart

On 21 May 2006, at 18:44, Eddie Kohler wrote:

> I think I submitted Click to coverity a while ago; have heard  
> nothing.  The
> "new" bug wasn't strictly speaking in click, but in linux.
>
> Eddie
>
>
> Bob Keyes wrote:
> > Has any thought been given to running Click through the Coverity bug
> > checker? It can be done for free for open source projects. I think  
> that
> > Coverity would find a lot of little nits pretty quickly, such as  
> the one
> > that Eddie found where a variable was named 'new' (doh!).
> >
> > I haven't actually tried Coverity bug I've heard nots of great  
> things
> > about it.
> > _______________________________________________
(Continue reading)

Javier Sánchez | 6 May 2008 18:14
Picon

Re: [PATCH] patches for linux 2.6.24

Hi,

I work with Hardy distribution without problems. You need to download 2.6.24
plain kernel at www.kernel.org and apply the patch to that. You need to
apply a patch for click 1.6 too (look for the oneshot patches on this
threat).

Dont use the debian method (dpkg) to compile the kernel, it has a big bug
and the headers are made corrupted. Use the traditional make method instead.

(patch linux, VANILLA KERNEL DIR)
patch -p1 -b <
/root/patches-linux-2.6.24-for-click/0000-Oneshot-linux-2.6.24.patch

make menuconfig

make bzImage

make modules

cp System.map /boot/System.map-2.6.24

cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.24

make modules_install

mkinitramfs -o /boot/initrd.img-2.6.24 2.6.24

EDIT GRUB (/boot/grub/menu.lst)

(Continue reading)

Eddie Kohler | 6 May 2008 19:06
Favicon

Re: Can/does cp_va_(k)parse check size of its arguments?

Unfortunately, there is no way in C/C++ varargs functions to reliably 
check sizes, and cp_va_kparse does not even try.  The best solution 
would be some sort of templatized version of cp_va_kparse, but that is 
not going to happen any time soon.

Eddie

Bart Braem wrote:
> Hello,
> 
> One of our students encountered a nasty bug where he parsed an element  
> configuration into variables that were too small: he used a cpUnsigned  
> argument to put data in a uint8_t. The variables next to that uint8_t  
> where overwritten and some bytes were mysteriously changed.
> At first sight cp_va_kparse does check for this size problem but it  
> does not seem to work, or am I mistaken?
> 
> Regards,
> Bart
Eddie Kohler | 6 May 2008 19:07
Favicon

Re: Coverity?

I certainly don't mind at all.

Eddie

Bart Braem wrote:
> Picking up a very old mail here: do you have any problems with it if I  
> try to restart this?
> I have even found a mail from Coverity at the Click mailinglist to  
> scan this project. It would be very good to give Click industry- 
> quality code, the project would benefit a lot...
> 
> Regards,
> Bart
> 
> On 21 May 2006, at 18:44, Eddie Kohler wrote:
> 
>> I think I submitted Click to coverity a while ago; have heard  
>> nothing.  The
>> "new" bug wasn't strictly speaking in click, but in linux.
>>
>> Eddie
>>
>>
>> Bob Keyes wrote:
>>> Has any thought been given to running Click through the Coverity bug
>>> checker? It can be done for free for open source projects. I think  
>> that
>>> Coverity would find a lot of little nits pretty quickly, such as  
>> the one
>>> that Eddie found where a variable was named 'new' (doh!).
(Continue reading)

Ashish Sharma | 7 May 2008 02:12
Picon

Re: [PATCH] patches for linux 2.6.24

Hi Javier,
That worked like a charm. Thanks so much for the help. When I received your
email, I was banging my head against the wall while doing the kernel
compilation for the 4th time thinking it was something that I did wrong in
the config file and it never even occurred to me that they could break the
make-kpkg/dpkg kernelbuild process  in Hardy. My neighbors thank you for
making me stop banging against their wall :)

I was trying to apply all the patches instead of the one-shot patch which
was creating all the problem.

Ashish

On Tue, May 6, 2008 at 9:14 AM, Javier Sánchez <javier.recacha <at> gmail.com>
wrote:

> Hi,
>
> I work with Hardy distribution without problems. You need to download
> 2.6.24 plain kernel at www.kernel.org and apply the patch to that. You
> need to apply a patch for click 1.6 too (look for the oneshot patches on
> this threat).
>
> Dont use the debian method (dpkg) to compile the kernel, it has a big bug
> and the headers are made corrupted. Use the traditional make method instead.
>
>
> (patch linux, VANILLA KERNEL DIR)
> patch -p1 -b <
> /root/patches-linux-2.6.24-for-click/0000-Oneshot-linux-2.6.24.patch
(Continue reading)


Gmane