James Chapman wrote:
>>> Wouldn't that effectively duplicate the code in udp_sendmsg()? If I
>>> don't use a socket, I'd also have to build an IP header and feed the
>>> frame into the IP stack for outbound routing. It doesn't feel like the
>>> right thing to do.
>>
>>
>> Thats what other tunnel dr
Hi James,
James Chapman schrieb:
> I thought seq_printf handled large output (multiple pages)? I am aware
> of the page size limitation of raw proc handlers.
No. It does detect the limitation, discards your output an lets you try again,
when the next invocation of *_show() has enough buffer spa
Patrick McHardy wrote:
James Chapman wrote:
[PPPOL2TP]: Add PPP-over-L2TP driver core.
A couple more comments:
- seq_file handling doesn't check seq_printf return values
ack
and
tries to dump the entire hash table at once, which might
exceed the available room.
I thought seq_prin
Hi Patrick,
Thanks for your comments so far. More questions below.
Patrick McHardy wrote:
James Chapman wrote:
Patrick McHardy wrote:
The interaction with UDP sockets looks pretty horrible IMO. On the
send side I don't see why you can't simply build the UDP header
yourself instead of doing t
James Chapman wrote:
> [PPPOL2TP]: Add PPP-over-L2TP driver core.
A couple more comments:
- seq_file handling doesn't check seq_printf return values and
tries to dump the entire hash table at once, which might
exceed the available room.
- there appear to be no checks for duplicate session ID
James Chapman wrote:
> Patrick McHardy wrote:
>
>> The interaction with UDP sockets looks pretty horrible IMO. On the
>> send side I don't see why you can't simply build the UDP header
>> yourself instead of doing these set_fs + sendmsgs hacks.
>
>
> Wouldn't that effectively duplicate the code
From: James Chapman <[EMAIL PROTECTED]>
Date: Sat, 24 Mar 2007 19:01:35 +
> > - list_for_each_entry_safe is only needed if you remove something
> > while iterating, its no replacement for locking
>
> I've gotten into a bad habit of always using list_for_each_entry_safe.
> I'll fix these (w
Patrick McHardy wrote:
James Chapman wrote:
[PPPOL2TP]: Add PPP-over-L2TP driver core.
This driver handles only L2TP data frames; control frames are handled
by a userspace application. The dfriver implements L2TP using the
PPPoX socket family. Data is sent or received using regular socket
sendm
Hi,
> Florian Zumbiehl wrote:
> >Hi,
> >
> >>+ * 251003 :Copied from pppoe.c version 0.6.9.
> >
> >you might want to have a look at the patches to the PPPoE code that were
> >posted to netdev recently, as some of them seem to apply to code that's
> >left over from pppoe.c.
>
> Do you mean
Florian Zumbiehl wrote:
Hi,
+ * 251003 :Copied from pppoe.c version 0.6.9.
you might want to have a look at the patches to the PPPoE code that were
posted to netdev recently, as some of them seem to apply to code that's
left over from pppoe.c.
Do you mean this change?
* 070228 : Fix t
James Chapman wrote:
> [PPPOL2TP]: Add PPP-over-L2TP driver core.
>
> This driver handles only L2TP data frames; control frames are handled
> by a userspace application. The dfriver implements L2TP using the
> PPPoX socket family. Data is sent or received using regular socket
> sendmsg() / recvmsg
Hi,
> + * 251003 : Copied from pppoe.c version 0.6.9.
you might want to have a look at the patches to the PPPoE code that were
posted to netdev recently, as some of them seem to apply to code that's
left over from pppoe.c.
Florian
-
To unsubscribe from this list: send the line "unsubscribe netd
12 matches
Mail list logo
