Re: Newbie idiotic questions.
Daniel Phillips wrote:
>
> > because then you would be allocating the size of a pointer, not the size
> > of a structure
>
> Whoops Jeff, you didn't have your coffee yet:
Whoops yourself. The following patch brings your example into line with
the driver code. mpuout is a pointer to a structure not the structure itself
as the malloc assignment clearly indicates.
*** x.c-origSun Jun 17 13:19:33 2001
--- x.c Sun Jun 17 13:19:42 2001
***
*** 2,8
struct foo { int a; int b; };
! struct { struct foo foo; } *foobar;
int main (void)
{
--- 2,8
struct foo { int a; int b; };
! struct { struct foo *foo; } *foobar;
int main (void)
{
Now Prints:
8
4
4
--
Bob Dunlop FarSite Communications
[EMAIL PROTECTED] [EMAIL PROTECTED]
www.xyzzy.clara.co.uk www.farsite.co.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Newbie idiotic questions.
Hi,
Bill Pringlemeir wrote:
>
> I have been looking at the emu10k1 driver and I had a few questions
> about general idioms used there.
Warning I've not looked at that particular driver and would concider
myself a Linux kernel newbie. 20 years kernel hacking but only 9
months Linux with two drivers under my belt. One of which I'm now
trying to get into the standard tree.
> [main.c, line 175]
>
> for (count = 0; count < sizeof(card->digmix) / sizeof(card->digmix[0]);
>count++) {
>
> Isn't there some sort of `ALEN' macro available, or is this
> considered to muddy things by using a macro?
Some writers are good and some not so good. Personally I'd prefer an
ArrayLen style macro but some prefer to see it long hand. My usual style
would be to use the array size #def used to define the array. I'd shoot
whoever wrote digmix[9 * 6 * 2]; OK so I just peeked at the source :-)
I might be tempted to tidy this up whilst I was adding something
significant to the driver but not for the sake of it. If I tidied that
one up I'd have to change all the other occurances in a consistent manner,
seem like a lot of work for little or no gain.
> [main.c, line 223]
> if ((card->mpuout = kmalloc(sizeof(struct emu10k1_mpuout), GFP_KERNEL))
>
> Why is the struct type referenced for the allocation size? Why not,
>
> if ((card->mpuout = kmalloc(sizeof(card->mpuout), GFP_KERNEL))
>
> This seems to get the size for the actual object being allocated.
I prefer the struct construct and this also demonstrates why it's best
not to fiddle just for the sake of it. You've changed the allocation
from the size of the struct into the size of a pointer.
> [cardmi.c, line 42]
>
> static struct {
> int (*Fn) (struct emu10k1_mpuin *, u8);
> } midistatefn[] = {
> ...
>
> Why aren't all the gobs of constant data in this driver declared as
> constant? Do it give a performance advantage by having the data in a
> different MMU section and better cache effects or something?
const is better but frequently forgotten :-(
> Thanks for any helpful pointers. I did read the FAQ. I am just
> wonder if I would get screamed at for changing things like this and
> why... so I will probably get yelled at for suggesting them anyway,
> but at least I won't have went through the effort. Now that I have
> pointed that out, the will probably irk people even more...
Perhaps the biggest one is when making changes follow the style of the
existing file. Style changes in midstream only add to the confusion.
Don't change layout rules or methods of doing things unless you are
prepared to update the entire module and justify the changes to the
original module author who has every right to be highly critical.
--
Bob Dunlop FarSite Communications
[EMAIL PROTECTED] [EMAIL PROTECTED]
www.xyzzy.clara.co.uk www.farsite.co.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Newbie idiotic questions.
Hi,
Bill Pringlemeir wrote:
I have been looking at the emu10k1 driver and I had a few questions
about general idioms used there.
Warning I've not looked at that particular driver and would concider
myself a Linux kernel newbie. 20 years kernel hacking but only 9
months Linux with two drivers under my belt. One of which I'm now
trying to get into the standard tree.
[main.c, line 175]
for (count = 0; count sizeof(card-digmix) / sizeof(card-digmix[0]);
count++) {
Isn't there some sort of `ALEN' macro available, or is this
considered to muddy things by using a macro?
Some writers are good and some not so good. Personally I'd prefer an
ArrayLen style macro but some prefer to see it long hand. My usual style
would be to use the array size #def used to define the array. I'd shoot
whoever wrote digmix[9 * 6 * 2]; OK so I just peeked at the source :-)
I might be tempted to tidy this up whilst I was adding something
significant to the driver but not for the sake of it. If I tidied that
one up I'd have to change all the other occurances in a consistent manner,
seem like a lot of work for little or no gain.
[main.c, line 223]
if ((card-mpuout = kmalloc(sizeof(struct emu10k1_mpuout), GFP_KERNEL))
Why is the struct type referenced for the allocation size? Why not,
if ((card-mpuout = kmalloc(sizeof(card-mpuout), GFP_KERNEL))
This seems to get the size for the actual object being allocated.
I prefer the struct construct and this also demonstrates why it's best
not to fiddle just for the sake of it. You've changed the allocation
from the size of the struct into the size of a pointer.
[cardmi.c, line 42]
static struct {
int (*Fn) (struct emu10k1_mpuin *, u8);
} midistatefn[] = {
...
Why aren't all the gobs of constant data in this driver declared as
constant? Do it give a performance advantage by having the data in a
different MMU section and better cache effects or something?
const is better but frequently forgotten :-(
Thanks for any helpful pointers. I did read the FAQ. I am just
wonder if I would get screamed at for changing things like this and
why... so I will probably get yelled at for suggesting them anyway,
but at least I won't have went through the effort. Now that I have
pointed that out, the will probably irk people even more...
Perhaps the biggest one is when making changes follow the style of the
existing file. Style changes in midstream only add to the confusion.
Don't change layout rules or methods of doing things unless you are
prepared to update the entire module and justify the changes to the
original module author who has every right to be highly critical.
--
Bob Dunlop FarSite Communications
[EMAIL PROTECTED] [EMAIL PROTECTED]
www.xyzzy.clara.co.uk www.farsite.co.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Newbie idiotic questions.
Daniel Phillips wrote:
because then you would be allocating the size of a pointer, not the size
of a structure
Whoops Jeff, you didn't have your coffee yet:
Whoops yourself. The following patch brings your example into line with
the driver code. mpuout is a pointer to a structure not the structure itself
as the malloc assignment clearly indicates.
*** x.c-origSun Jun 17 13:19:33 2001
--- x.c Sun Jun 17 13:19:42 2001
***
*** 2,8
struct foo { int a; int b; };
! struct { struct foo foo; } *foobar;
int main (void)
{
--- 2,8
struct foo { int a; int b; };
! struct { struct foo *foo; } *foobar;
int main (void)
{
Now Prints:
8
4
4
--
Bob Dunlop FarSite Communications
[EMAIL PROTECTED] [EMAIL PROTECTED]
www.xyzzy.clara.co.uk www.farsite.co.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SyncPPP IPCP/LCP loop problem and patch
Paul Fulghum wrote: > > RFC1661 state table shows a transition to req-sent > from opened when a (properly formated with > correct sequence ID) cfg-ack is received. > > Syncppp does not do this (from sppp_lcp_input): ... > Maybe adding: > > case LCP_STATE_OPENED: >sppp_lcp_open (sp); >sp->ipcp.state = IPCP_STATE_CLOSED; >sp->lcp.state = LCP_STATE_REQ_SENT; >break; Thanks for the suggestion. I tried it and found that Linux syncppp does not have a LCP_STATE_REQ_SENT the nearest alternate being LCP_STATE_CLOSED. Looking at the RFC these are by no means compatable. Adding the extra state and coding the transitions would not be difficult but as I've looked at it I've seen more and more ommissions in the code. The magic number is not randomised very well, jiffies is not a great random number :-) Parameter negotiation only takes place for the magic number plus dummys for MRU and ACCM, I'm not even sure that enforcing and ACCM of all zeros is required. If the remote end sends us a config request without a magic number we end up testing an uninitialised variable, and so on. Who's the owner for syncppp.c ? I might be able to put some time in on it, but would hate to be sending patches into empty space. -- Bob Dunlop FarSite Communications [EMAIL PROTECTED] [EMAIL PROTECTED] www.xyzzy.clara.co.uk www.farsite.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SyncPPP IPCP/LCP loop problem and patch. Take 2
Paul Fulghum wrote:
> >
> > Thanks but I've already tried that. You get a slightly different pattern
> > to the loop but it still loops.
>
> What does the loop look like when the cfg-req is sent 1st?
Thanks for making me go back and look at it again guys. The reordering of
REQ and ACK does work to break the loop. Provided you apply the patch to
both ends of the link.
This is a much smaller patch, remains RFC1661 conformant and works against
all the platforms I've been able to test. Against an unpatched Linux it
still loops but no worse than before.
--- syncppp.c-orig Mon May 21 10:35:59 2001
+++ syncppp.c Thu May 24 15:55:55 2001
@@ -517,8 +517,10 @@
}
/* Send Configure-Ack packet. */
sp->pp_loopcnt = 0;
- sppp_cp_send (sp, PPP_LCP, LCP_CONF_ACK,
- h->ident, len-4, h+1);
+ if (sp->lcp.state != LCP_STATE_OPENED) {
+ sppp_cp_send (sp, PPP_LCP, LCP_CONF_ACK,
+ h->ident, len-4, h+1);
+ }
/* Change the state. */
switch (sp->lcp.state) {
case LCP_STATE_CLOSED:
@@ -534,7 +536,9 @@
sp->ipcp.state = IPCP_STATE_CLOSED;
/* Initiate renegotiation. */
sppp_lcp_open (sp);
- /* An ACK has already been sent. */
+ /* Send ACK after our REQ in attempt to break loop */
+ sppp_cp_send (sp, PPP_LCP, LCP_CONF_ACK,
+ h->ident, len-4, h+1);
sp->lcp.state = LCP_STATE_ACK_SENT;
break;
}
A colleage has suggested that we should apply the same ordering in the NAK
path and for similar code in the stopped state. Since I've not seen loops in
these areas I'm loath to make changes without the ability to test.
--
Bob Dunlop FarSite Communications
[EMAIL PROTECTED] [EMAIL PROTECTED]
www.xyzzy.clara.co.uk www.farsite.co.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
SyncPPP IPCP/LCP loop problem and patch. Take 2
Paul Fulghum wrote:
Thanks but I've already tried that. You get a slightly different pattern
to the loop but it still loops.
What does the loop look like when the cfg-req is sent 1st?
Thanks for making me go back and look at it again guys. The reordering of
REQ and ACK does work to break the loop. Provided you apply the patch to
both ends of the link.
This is a much smaller patch, remains RFC1661 conformant and works against
all the platforms I've been able to test. Against an unpatched Linux it
still loops but no worse than before.
--- syncppp.c-orig Mon May 21 10:35:59 2001
+++ syncppp.c Thu May 24 15:55:55 2001
@@ -517,8 +517,10 @@
}
/* Send Configure-Ack packet. */
sp-pp_loopcnt = 0;
- sppp_cp_send (sp, PPP_LCP, LCP_CONF_ACK,
- h-ident, len-4, h+1);
+ if (sp-lcp.state != LCP_STATE_OPENED) {
+ sppp_cp_send (sp, PPP_LCP, LCP_CONF_ACK,
+ h-ident, len-4, h+1);
+ }
/* Change the state. */
switch (sp-lcp.state) {
case LCP_STATE_CLOSED:
@@ -534,7 +536,9 @@
sp-ipcp.state = IPCP_STATE_CLOSED;
/* Initiate renegotiation. */
sppp_lcp_open (sp);
- /* An ACK has already been sent. */
+ /* Send ACK after our REQ in attempt to break loop */
+ sppp_cp_send (sp, PPP_LCP, LCP_CONF_ACK,
+ h-ident, len-4, h+1);
sp-lcp.state = LCP_STATE_ACK_SENT;
break;
}
A colleage has suggested that we should apply the same ordering in the NAK
path and for similar code in the stopped state. Since I've not seen loops in
these areas I'm loath to make changes without the ability to test.
--
Bob Dunlop FarSite Communications
[EMAIL PROTECTED] [EMAIL PROTECTED]
www.xyzzy.clara.co.uk www.farsite.co.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SyncPPP IPCP/LCP loop problem and patch
Paul Fulghum wrote: RFC1661 state table shows a transition to req-sent from opened when a (properly formated with correct sequence ID) cfg-ack is received. Syncppp does not do this (from sppp_lcp_input): ... Maybe adding: case LCP_STATE_OPENED: sppp_lcp_open (sp); sp-ipcp.state = IPCP_STATE_CLOSED; sp-lcp.state = LCP_STATE_REQ_SENT; break; Thanks for the suggestion. I tried it and found that Linux syncppp does not have a LCP_STATE_REQ_SENT the nearest alternate being LCP_STATE_CLOSED. Looking at the RFC these are by no means compatable. Adding the extra state and coding the transitions would not be difficult but as I've looked at it I've seen more and more ommissions in the code. The magic number is not randomised very well, jiffies is not a great random number :-) Parameter negotiation only takes place for the magic number plus dummys for MRU and ACCM, I'm not even sure that enforcing and ACCM of all zeros is required. If the remote end sends us a config request without a magic number we end up testing an uninitialised variable, and so on. Who's the owner for syncppp.c ? I might be able to put some time in on it, but would hate to be sending patches into empty space. -- Bob Dunlop FarSite Communications [EMAIL PROTECTED] [EMAIL PROTECTED] www.xyzzy.clara.co.uk www.farsite.co.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SyncPPP IPCP/LCP loop problem and patch
Paul Mackerras wrote: > > [EMAIL PROTECTED] writes: > > I've hit a problem with the syncPPP module within Linux. > > Seems to me that when you get the conf-request in opened state, you > should send your conf-request before sending the conf-ack to the > peer's conf-request. I think this would short-circuit the loop (I > could be wrong though, it's getting late). Thanks but I've already tried that. You get a slightly different pattern to the loop but it still loops. > That behaviour would be in line with the FSM in rfc1661, where the > action for event RCR+ in Opened state is "tld,scr,sca/8", i.e. the one > action involves sending both the conf-request and the conf-ack. It is > debatable to what extent that specifies the order of the messages but > it does list the conf-request first FWIW. RFC1661 states: multiple actions may be implemented in any convenient order. So if it had worked we'd still have been conformant. I've also tried dropping selected packets when I see the condition, simulating a noisy line or buggy driver whilst keeping the PPP state machine conformant. Problem is you need to generate the conf-ack to get the remote end into the LCP opened state whilst not dropping out of it yourself. -- Bob Dunlop FarSite Communications [EMAIL PROTECTED] [EMAIL PROTECTED] www.xyzzy.clara.co.uk www.farsite.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SyncPPP IPCP/LCP loop problem and patch
I've hit a problem with the syncPPP module within Linux.
Under certain conditions (hard to quantify exactly, but try several 8Mbps
streams hitting a relatively slow, say 200MHz processor) the LCP/IPCP
negotiation hits the following loop.
A side state Packet B side state
ACK sent
<-- LCP conf ACK
Opened
IPCP conf REQ -->
<-- LCP conf REQ
ACK sent
LCP conf ACK-->
Opened
<-- IPCP conf REQ
LCP conf REQ-->
ACK sent
<-- LCP conf ACK
Opened
IPCP conf REQ -->
<-- LCP conf REQ
ACK sent
LCP conf ACK-->
Opened
<-- IPCP conf REQ
LCP conf REQ-->
ACK sent
...
Basically one end has reached the IPCP level before the other. When it sees
an incoming LCP packet the RFC1661 state machine drops back to LCP but the
responses generated take the other end up to the IPCP level. The result is
an endless storm of small packets back and forth generating "IPCP when still
waiting LCP finish" messages.
Flip-flopping between IPCP and LCP like this seems to defeat the normal LCP
timeouts. I've searched the archives and found several solutions none of
which I found particularly satisfying. The best was "the driver will
eventually drop a packet breaking the loop", sorry but I try not to drop
packets in my drivers :-) Most of the rest shortened LCP timeouts or did
something else that modified the timing and I guess moved the problem for a
particular system, none of them seemed general purpose.
My solution in the patch that follows is to detect the flip-flop using a
counter and then after three occurrences with no genuine IPCP traffic to
modify behavior on receipt of the LCP conf REQ. After three attempts we
acknowledge the LCP conf REQ but stay in the opened state rather than
dropping back and restarting our own LCP negotiation. This is non-RFC1661
behavior unless you consider it part of the general loop avoidance directive.
I've tested this patch against an unmodified Linux system (where I first saw
the problem), a modified system (would be no good if it didn't work against
itself), NT RRAS and a small Cisco router. Of course I can't hit all timing
variants but it looks solid to me.
--- linux/include/net/syncppp.h.origMon May 21 11:01:29 2001
+++ linux/include/net/syncppp.h Mon May 21 11:01:28 2001
@@ -48,6 +48,7 @@
struct timer_list pp_timer;
struct net_device *pp_if;
charpp_link_state; /* Link status */
+ charipcp_b4_lcp;/* IPCP up error counter */
};
struct ppp_device
--- linux/drivers/net/wan/syncppp.c.origMon May 21 11:01:28 2001
+++ linux/drivers/net/wan/syncppp.c Mon May 21 11:01:25 2001
@@ -262,10 +262,14 @@
kfree_skb(skb);
return;
case PPP_IPCP:
- if (sp->lcp.state == LCP_STATE_OPENED)
+ if (sp->lcp.state == LCP_STATE_OPENED) {
+ sp->ipcp_b4_lcp = 0;
sppp_ipcp_input (sp, skb);
- else
+ }
+ else {
printk(KERN_DEBUG "IPCP when still waiting LCP
finish.\n");
+ sp->ipcp_b4_lcp++;
+ }
kfree_skb(skb);
return;
case PPP_IP:
@@ -529,6 +533,16 @@
sppp_ipcp_open (sp);
break;
case LCP_STATE_OPENED:
+ /* If it looks like we're looping in a IPCP<->LCP flip-
+* flop. ACK this one and stay open. Warning this is
+* non-RFC1661 behaviour.
+*/
+ if (sp->ipcp_b4_lcp > 3) {
+ printk (KERN_DEBUG "IPCP<->LCP loop avoidance\n");
+ sp->ipcp_b4_lcp = 0;
+ break;
+ }
+
/* Remote magic changed -- close session. */
sp->lcp.state = LCP_STATE_CLOSED;
sp->ipcp.state = IPCP_STATE_CLOSED;
--
Bob Dunlop FarSite Communications
[EMAIL PROTECTED] [EMAIL PROTECTED]
www.xyzzy.clara.co.uk www.farsite.co.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
SyncPPP IPCP/LCP loop problem and patch
I've hit a problem with the syncPPP module within Linux.
Under certain conditions (hard to quantify exactly, but try several 8Mbps
streams hitting a relatively slow, say 200MHz processor) the LCP/IPCP
negotiation hits the following loop.
A side state Packet B side state
ACK sent
-- LCP conf ACK
Opened
IPCP conf REQ --
-- LCP conf REQ
ACK sent
LCP conf ACK--
Opened
-- IPCP conf REQ
LCP conf REQ--
ACK sent
-- LCP conf ACK
Opened
IPCP conf REQ --
-- LCP conf REQ
ACK sent
LCP conf ACK--
Opened
-- IPCP conf REQ
LCP conf REQ--
ACK sent
...
Basically one end has reached the IPCP level before the other. When it sees
an incoming LCP packet the RFC1661 state machine drops back to LCP but the
responses generated take the other end up to the IPCP level. The result is
an endless storm of small packets back and forth generating IPCP when still
waiting LCP finish messages.
Flip-flopping between IPCP and LCP like this seems to defeat the normal LCP
timeouts. I've searched the archives and found several solutions none of
which I found particularly satisfying. The best was the driver will
eventually drop a packet breaking the loop, sorry but I try not to drop
packets in my drivers :-) Most of the rest shortened LCP timeouts or did
something else that modified the timing and I guess moved the problem for a
particular system, none of them seemed general purpose.
My solution in the patch that follows is to detect the flip-flop using a
counter and then after three occurrences with no genuine IPCP traffic to
modify behavior on receipt of the LCP conf REQ. After three attempts we
acknowledge the LCP conf REQ but stay in the opened state rather than
dropping back and restarting our own LCP negotiation. This is non-RFC1661
behavior unless you consider it part of the general loop avoidance directive.
I've tested this patch against an unmodified Linux system (where I first saw
the problem), a modified system (would be no good if it didn't work against
itself), NT RRAS and a small Cisco router. Of course I can't hit all timing
variants but it looks solid to me.
--- linux/include/net/syncppp.h.origMon May 21 11:01:29 2001
+++ linux/include/net/syncppp.h Mon May 21 11:01:28 2001
@@ -48,6 +48,7 @@
struct timer_list pp_timer;
struct net_device *pp_if;
charpp_link_state; /* Link status */
+ charipcp_b4_lcp;/* IPCP up error counter */
};
struct ppp_device
--- linux/drivers/net/wan/syncppp.c.origMon May 21 11:01:28 2001
+++ linux/drivers/net/wan/syncppp.c Mon May 21 11:01:25 2001
@@ -262,10 +262,14 @@
kfree_skb(skb);
return;
case PPP_IPCP:
- if (sp-lcp.state == LCP_STATE_OPENED)
+ if (sp-lcp.state == LCP_STATE_OPENED) {
+ sp-ipcp_b4_lcp = 0;
sppp_ipcp_input (sp, skb);
- else
+ }
+ else {
printk(KERN_DEBUG IPCP when still waiting LCP
finish.\n);
+ sp-ipcp_b4_lcp++;
+ }
kfree_skb(skb);
return;
case PPP_IP:
@@ -529,6 +533,16 @@
sppp_ipcp_open (sp);
break;
case LCP_STATE_OPENED:
+ /* If it looks like we're looping in a IPCP-LCP flip-
+* flop. ACK this one and stay open. Warning this is
+* non-RFC1661 behaviour.
+*/
+ if (sp-ipcp_b4_lcp 3) {
+ printk (KERN_DEBUG IPCP-LCP loop avoidance\n);
+ sp-ipcp_b4_lcp = 0;
+ break;
+ }
+
/* Remote magic changed -- close session. */
sp-lcp.state = LCP_STATE_CLOSED;
sp-ipcp.state = IPCP_STATE_CLOSED;
--
Bob Dunlop FarSite Communications
[EMAIL PROTECTED] [EMAIL PROTECTED]
www.xyzzy.clara.co.uk www.farsite.co.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
Re: SyncPPP IPCP/LCP loop problem and patch
Paul Mackerras wrote: [EMAIL PROTECTED] writes: I've hit a problem with the syncPPP module within Linux. Seems to me that when you get the conf-request in opened state, you should send your conf-request before sending the conf-ack to the peer's conf-request. I think this would short-circuit the loop (I could be wrong though, it's getting late). Thanks but I've already tried that. You get a slightly different pattern to the loop but it still loops. That behaviour would be in line with the FSM in rfc1661, where the action for event RCR+ in Opened state is tld,scr,sca/8, i.e. the one action involves sending both the conf-request and the conf-ack. It is debatable to what extent that specifies the order of the messages but it does list the conf-request first FWIW. RFC1661 states: multiple actions may be implemented in any convenient order. So if it had worked we'd still have been conformant. I've also tried dropping selected packets when I see the condition, simulating a noisy line or buggy driver whilst keeping the PPP state machine conformant. Problem is you need to generate the conf-ack to get the remote end into the LCP opened state whilst not dropping out of it yourself. -- Bob Dunlop FarSite Communications [EMAIL PROTECTED] [EMAIL PROTECTED] www.xyzzy.clara.co.uk www.farsite.co.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Detecting Red Hat builds ?
Hi, How can I determine if the build my device driver is being compiled under is a standard kernel.org one or a Red Hat one ? The problem is I have a driver that includes syncppp.h which in the releases from kernel.org is in linux/drivers/net/wan/ up to and including 2.4.2 after which it moves to linux/include/net/. Can cope with this easily enough with a "#if LINUX_VERSION_CODE > KERNEL_VERSION(2,4,2)" but unfortunatly the kernel source supplied with Red Hat 7.1 reports itself as 2.4.2 but already has the syncppp changes from 2.4.3. I was shown a trick to solve a similar problem under 2.2.x but the symbol defined as a side effect of including one of the standard system headers is no longer present :-( -- Bob Dunlop FarSite Communications [EMAIL PROTECTED] [EMAIL PROTECTED] www.xyzzy.clara.co.uk www.farsite.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New driver for FarSite synchronous cards
Hi, I've just completed the first draft of a new device driver for the FarSite Communications, FarSync T2P and T4P cards. These cards are intelligent synchronous serial cards supporting 2 or 4 ports running at up to 8Mbps with X.21, V.35 or V.24 signalling. This mail is basically a call for testers and reviewers, and a plea to find the overall maintainer for WAN card drivers. In house testing and review of the drivers is underway and until that is complete I can't put the sources on the company web site. However I have been given permission to place the sources on my home site so that I can hopefully get some early testing and reviews from the community. So please pull them apart guys. The sources are available at http://www.xyzzy.clara.co.uk/farsync either as a complete package with firmware, support utilities, driver etc for 2.2.x (from 2.2.15) and 2.4.x systems, or as a driver only patch for 2.4.3ac12. The latter I'm keen to get adopted as part of the standard kernel source (once reviewed of course) and hence the need to find the maintainer for that part of the kernel. If it's you please get in contact, meantime I'm going to assume it's the much overworked Alan Cox. Sources and patches at: http://www.xyzzy.clara.co.uk/farsync/ More info on cards and other drivers at: http://www.farsite.co.uk/ -- Bob Dunlop FarSite Communications [EMAIL PROTECTED] [EMAIL PROTECTED] www.xyzzy.clara.co.uk www.farsite.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New driver for FarSite synchronous cards
Hi, I've just completed the first draft of a new device driver for the FarSite Communications, FarSync T2P and T4P cards. These cards are intelligent synchronous serial cards supporting 2 or 4 ports running at up to 8Mbps with X.21, V.35 or V.24 signalling. This mail is basically a call for testers and reviewers, and a plea to find the overall maintainer for WAN card drivers. In house testing and review of the drivers is underway and until that is complete I can't put the sources on the company web site. However I have been given permission to place the sources on my home site so that I can hopefully get some early testing and reviews from the community. So please pull them apart guys. The sources are available at http://www.xyzzy.clara.co.uk/farsync either as a complete package with firmware, support utilities, driver etc for 2.2.x (from 2.2.15) and 2.4.x systems, or as a driver only patch for 2.4.3ac12. The latter I'm keen to get adopted as part of the standard kernel source (once reviewed of course) and hence the need to find the maintainer for that part of the kernel. If it's you please get in contact, meantime I'm going to assume it's the much overworked Alan Cox. Sources and patches at: http://www.xyzzy.clara.co.uk/farsync/ More info on cards and other drivers at: http://www.farsite.co.uk/ -- Bob Dunlop FarSite Communications [EMAIL PROTECTED] [EMAIL PROTECTED] www.xyzzy.clara.co.uk www.farsite.co.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Microsoft begining to open source Windows 2000?
Stuart MacDonald wrote: > > It seems to me this might be an opportunity... Or a trap. I'm not about to go anywhere near this and won't even look at the licience but I bet the M$ argument will go something like: You've looked at the code. You now know things that are propriatary to M$. You are not allowed to apply it to anything outside M$. Stop working on those free sources the forbidden knowledge might leak. You have me assimilated. -- Bob Dunlop [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Microsoft begining to open source Windows 2000?
Stuart MacDonald wrote: It seems to me this might be an opportunity... Or a trap. I'm not about to go anywhere near this and won't even look at the licience but I bet the M$ argument will go something like: You've looked at the code. You now know things that are propriatary to M$. You are not allowed to apply it to anything outside M$. Stop working on those free sources the forbidden knowledge might leak. You have me assimilated. -- Bob Dunlop [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
Dennis wrote: ... > objective, arent we? Nope. Are you claiming to be? > For example, if there were six different companies that marketed ethernet > drivers for the eepro100, you'd have a choice of which one to buy..perhaps ... Rant deleted I had a problem with eepro100. It was fixed same night cause I had the source. Don't even try to compare with MickyS**t. > The biggest thing that the linux community does to stifle innovation is to > bash commercial vendors trying to make a profit by whining endlessly about > "sourceless" distributions and recommending "open-source" solutions even > when they are wholly inferior. You're only hurting yourselves in the long > run. In that respect MS is correct, because those with the dollars to > innovate will stay away. When companys with less than a dozen people think it's worth while paying someone like me to develop code exclusivly for Linux we've got to have a chance. Source to binary ratio is probably 70/30 mainly because of code tied up in previous companys but they are trying. The project they're funding now is more like 90% GPL. Of course I could be producing crap code. 20 years kernel hacking and a cybernetics degree can't mean as much as being an MSCE. ps. This is definately a message from home and a bottom of a glass of whisky. -- Bob Dunlop [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
Dennis wrote: ... objective, arent we? Nope. Are you claiming to be? For example, if there were six different companies that marketed ethernet drivers for the eepro100, you'd have a choice of which one to buy..perhaps ... Rant deleted I had a problem with eepro100. It was fixed same night cause I had the source. Don't even try to compare with MickyS**t. The biggest thing that the linux community does to stifle innovation is to bash commercial vendors trying to make a profit by whining endlessly about "sourceless" distributions and recommending "open-source" solutions even when they are wholly inferior. You're only hurting yourselves in the long run. In that respect MS is correct, because those with the dollars to innovate will stay away. When companys with less than a dozen people think it's worth while paying someone like me to develop code exclusivly for Linux we've got to have a chance. Source to binary ratio is probably 70/30 mainly because of code tied up in previous companys but they are trying. The project they're funding now is more like 90% GPL. Of course I could be producing crap code. 20 years kernel hacking and a cybernetics degree can't mean as much as being an MSCE. ps. This is definately a message from home and a bottom of a glass of whisky. -- Bob Dunlop [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
