[B.A.T.M.A.N.] Patch batman-adv for kernel 2.6.15

[B.A.T.M.A.N.] Patch batman-adv for kernel 2.6.15

[Franz Böhm]

Hi,

I am trying to get batman-adv (kernelland) running on Ubiquiti Networks 
hardware. Unfortunately the Ubiquiti SDK uses kernel 2.6.15 and 
batman-adv needs at least 2.6.20. I did have some success in patching 
and running batman-adv-kernelland 0.1 (r1176). I would of course prefer 
using batman-adv 0.2 but I do have problems implementing the older 
kernel workqueue API.

Perhaps someone can give me a hint on porting for example this function 
from send.c to the old workqueue API.

void send_outstanding_bat_packet(struct work_struct *work)
{
    struct delayed_work *delayed_work =
        container_of(work, struct delayed_work, work);
    struct forw_packet *forw_packet =
        container_of(delayed_work, struct forw_packet, delayed_work);
    unsigned long flags;

    spin_lock_irqsave(&forw_bat_list_lock, flags);
    hlist_del(&forw_packet->list);
    spin_unlock_irqrestore(&forw_bat_list_lock, flags);

    send_packet(forw_packet);

    /**
     * we have to have at least one packet in the queue
     * to determine the queues wake up time unless we are
     * shutting down
     */
    if ((forw_packet->own) &&
        (atomic_read(&module_state) != MODULE_DEACTIVATING))
        schedule_own_packet(forw_packet->if_incoming);

    forw_packet_free(forw_packet);
}

Kind regards,
Franz

Re: [B.A.T.M.A.N.] Patch batman-adv for kernel 2.6.15

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]

Hello Franz,

the workqueues are the most "non-trivial" thing which prevented us so far
from backporting batman-adv to these older kernel. I'd also be interested 
to integrate patches if anyone has a solution for this. :)

best regards,
	Simon


On Mon, Apr 12, 2010 at 09:28:30AM +0200, Franz Böhm wrote:
> Hi,
>
> I am trying to get batman-adv (kernelland) running on Ubiquiti Networks  
> hardware. Unfortunately the Ubiquiti SDK uses kernel 2.6.15 and  
> batman-adv needs at least 2.6.20. I did have some success in patching  
> and running batman-adv-kernelland 0.1 (r1176). I would of course prefer  
> using batman-adv 0.2 but I do have problems implementing the older  
> kernel workqueue API.
>
> Perhaps someone can give me a hint on porting for example this function  
> from send.c to the old workqueue API.
>
> void send_outstanding_bat_packet(struct work_struct *work)
> {
>    struct delayed_work *delayed_work =
>        container_of(work, struct delayed_work, work);
>    struct forw_packet *forw_packet =
>        container_of(delayed_work, struct forw_packet, delayed_work);
>    unsigned long flags;
>
>    spin_lock_irqsave(&forw_bat_list_lock, flags);
>    hlist_del(&forw_packet->list);
>    spin_unlock_irqrestore(&forw_bat_list_lock, flags);
>
>    send_packet(forw_packet);
>
>    /**
>     * we have to have at least one packet in the queue
>     * to determine the queues wake up time unless we are
>     * shutting down
>     */
>    if ((forw_packet->own) &&
>        (atomic_read(&module_state) != MODULE_DEACTIVATING))
>        schedule_own_packet(forw_packet->if_incoming);
>
>    forw_packet_free(forw_packet);
> }
>
> Kind regards,
> Franz
>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [B.A.T.M.A.N.] Patch batman-adv for kernel 2.6.15

[Franz Böhm]

Hi Simon,

I already thought it's much more difficult because otherwise someone 
else would have written a patch already :-) Perhaps I have to stay with 
batman-adv 0.1 the next time.

I am very unfamiliar with this kernel locking and work queueing voodoo. 
But those techniques already existed before 2.6.20 so shouldn't there be 
a quite simple solution?

Regards,
Franz


Simon Wunderlich schrieb:
> Hello Franz,
>
> the workqueues are the most "non-trivial" thing which prevented us so far
> from backporting batman-adv to these older kernel. I'd also be interested 
> to integrate patches if anyone has a solution for this. :)
>
> best regards,
> 	Simon
>
>
> On Mon, Apr 12, 2010 at 09:28:30AM +0200, Franz Böhm wrote:
>   
>> Hi,
>>
>> I am trying to get batman-adv (kernelland) running on Ubiquiti Networks  
>> hardware. Unfortunately the Ubiquiti SDK uses kernel 2.6.15 and  
>> batman-adv needs at least 2.6.20. I did have some success in patching  
>> and running batman-adv-kernelland 0.1 (r1176). I would of course prefer  
>> using batman-adv 0.2 but I do have problems implementing the older  
>> kernel workqueue API.
>>
>> Perhaps someone can give me a hint on porting for example this function  
>> from send.c to the old workqueue API.
>>
>> void send_outstanding_bat_packet(struct work_struct *work)
>> {
>>    struct delayed_work *delayed_work =
>>        container_of(work, struct delayed_work, work);
>>    struct forw_packet *forw_packet =
>>        container_of(delayed_work, struct forw_packet, delayed_work);
>>    unsigned long flags;
>>
>>    spin_lock_irqsave(&forw_bat_list_lock, flags);
>>    hlist_del(&forw_packet->list);
>>    spin_unlock_irqrestore(&forw_bat_list_lock, flags);
>>
>>    send_packet(forw_packet);
>>
>>    /**
>>     * we have to have at least one packet in the queue
>>     * to determine the queues wake up time unless we are
>>     * shutting down
>>     */
>>    if ((forw_packet->own) &&
>>        (atomic_read(&module_state) != MODULE_DEACTIVATING))
>>        schedule_own_packet(forw_packet->if_incoming);
>>
>>    forw_packet_free(forw_packet);
>> }
>>
>> Kind regards,
>> Franz
>>
>>     

Re: [B.A.T.M.A.N.] Patch batman-adv for kernel 2.6.15

[Gus Wirth]

On 04/12/2010 12:28 AM, Franz Böhm wrote:
> Hi,
> 
> I am trying to get batman-adv (kernelland) running on Ubiquiti Networks 
> hardware. Unfortunately the Ubiquiti SDK uses kernel 2.6.15 and 
> batman-adv needs at least 2.6.20. I did have some success in patching 
> and running batman-adv-kernelland 0.1 (r1176). I would of course prefer 
> using batman-adv 0.2 but I do have problems implementing the older 
> kernel workqueue API.

I'm doing a lot of work with Ubiquiti devices and have had great success
with the stock OpenWrt trunk in their Bullet2HP, regular Bullet and
MiniStation and PicoStation products. Their XR2 and XR9 cards are giving
me problems right now, so I can't recommend them.

Which SDK are you working with, and for which product?

Is there any particular reason you want to use their SDK?

It might be possible to just substitute the kernel and keep the rest of
the SDK as is. Unless there is something tied directly to the kernel,
that may be an easier approach.

Gus

Re: [B.A.T.M.A.N.] Patch batman-adv for kernel 2.6.15

[Franz Böhm]

Hi Gus,

I am using Ubiquiti SDK v5.1.2 together with Nanostation M5 and Bullet 
M5. I already thought about trying newest OpenWrt but it doesn't support 
DFS. Ubiquiti products instead are tested to comply with european 
regulations. Although the tests did not take brand new ETSI regulations 
into account.

There is some binary code in the SDK like the special Atheros wireless 
driver. I don't think it's promising to replace the kernel.

It seems like I have to do my testing with batman-adv-kernelland 0.1 for 
a while.

Regards,
Franz


Gus Wirth schrieb:
> On 04/12/2010 12:28 AM, Franz Böhm wrote:
>> Hi,
>>
>> I am trying to get batman-adv (kernelland) running on Ubiquiti Networks 
>> hardware. Unfortunately the Ubiquiti SDK uses kernel 2.6.15 and 
>> batman-adv needs at least 2.6.20. I did have some success in patching 
>> and running batman-adv-kernelland 0.1 (r1176). I would of course prefer 
>> using batman-adv 0.2 but I do have problems implementing the older 
>> kernel workqueue API.
> 
> I'm doing a lot of work with Ubiquiti devices and have had great success
> with the stock OpenWrt trunk in their Bullet2HP, regular Bullet and
> MiniStation and PicoStation products. Their XR2 and XR9 cards are giving
> me problems right now, so I can't recommend them.
> 
> Which SDK are you working with, and for which product?
> 
> Is there any particular reason you want to use their SDK?
> 
> It might be possible to just substitute the kernel and keep the rest of
> the SDK as is. Unless there is something tied directly to the kernel,
> that may be an easier approach.
> 
> Gus
>