[Click] [PATCH] patches for linux 2.6.24

[Ashish Sharma]

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.
> >  > >
> >  > > Joonwoo,
> >  > >
> >  > > Yes, it was related to a locking problem when I wanted to have the
> interfaces in promiscuous mode. It looks so that the dev_set_promiscuity
> function (in net/core/dev.c) requires the calling thread to hold rtnl mutex
> by calling rtnl_lock(), so I added this to anydevice.cc with the
> corresponding rtnl_unlock(). This eliminated the assertion problem I had. So
> far I haven't experienced any other problems with the patches yet. (By the
> way, I didn't get the patch you mentioned above.)
> >  > >
> >  > > Cheers,
> >  > > Norbert
> >  >
> >  > Hi Norbert,
> >  > I think you made a indentation mistake.
> >  > After fixing it, the RTNL_LOCK assertion was disappeared.
> >  > I'm attaching a mergered patch as click-1.6.0-linux-2.6.24-3.patch.gz
> as
> >  > well.
> >  >
> >  > ---
> >
> >
> > Hi forks,
> >  I've updated draft patch for linux 2.6.24.
> >  - fix spinlock init macro
> >  - re-enable skb_recycle
> >  - fix enormous memory leak in skb_recycle
> >
> >  Eddie,
> >  I guess, also the version of 2.6.19's skb_recycle needs
> >  skb_release_data for fix potential memory leakage.
> >  Please consider it.
> >
>
> Hi,
>
> I've overhauled the patchset.
> There was improvements about support non-x86 arch, backward
> compatibility for older versions of linux and cleaning up.
> IMHO, It might be appliable to tree.
> Eddie, please consider apply this patchset.
>
> The things changed after the last patch.
> * Linux-2.6.24-click:
> 1. Initial Linux-2.6.24 patch for Click.
> 2. Fix build failure for !CONFIG_X86_PAE
> 3. Fix incorrect type casting for non-32bit arch
> 3. Fix x86_64 build error
> 4. Fix undefined symbol hweight64
> 5. Fix build error about netfilter
> 6. Use ':' for initializing constant struct member
> 7. Undo unnecessary '::' -> ': :'
> 8. Undo unnecessary '::' -> ': :' #2
> 9. Revert off-topic patch for ipv4/arp
> 10. Undo unnecessary '::' -> ': :' #3
> 11. Revert off-topic patch for hwmon/w83627ehf.c
>
> * Click-1.6:
> 1. Fix packet::set_network_header
> 2. Fix ToHost set_mac_header
> 3. Fix ToHost set_mac_header
> 4. Improve support 64bit machines
> 5. Improve 64bit machines support #2
> 6. Kill build warning
> 7. Improve Backward compatibility for 2.6.19.2
> 8. Improve Backward compatibility for 2.6.19.2 #2
> 9. Fix regression for build non-32bit arch
>
> Both of patches contain one-shot patch as well.
>
> Thanks,
> Joonwoo
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
>


-- 

"For humans, honesty is a matter of degree. Engineers are always honest in
matters of technology and human relationships. That's why it's a good idea
to keep engineers away from customers, romantic interests, and other people
who can't handle the truth."
- Scott Adams, The Dilbert Principle