[RFC] syncppp broken - how to fix?

[RFC] syncppp broken - how to fix?

[Paul Fulghum]

In 2.6.0-test8 a patch from shemninger@osdl.org was
applied to drivers/net/wan/syncppp.c which breaks
syncppp when used with some wan drivers:

drivers/net/wan/cosa.c
drivers/net/wan/hostess_sv11.c
drivers/net/wan/wanpipe_multppp.c
drivers/char/synclink.c
drivers/char/synclinkmp.c
drivers/char/pcmcia/synclink_cs.c

The problem is the addition of a BUG_ON()
line in sppp_attach() which imposes the new
requirement that the net device priv member
be initialized *before* calling sppp_attach().

The priv member is not actually used in
sppp_attach(). The BUG_ON line does a sanity
check which touches priv member, which is not
set prior to calling sppp_attach() by the drivers
listed above.

So should all of the WAN drivers be changed to
accomodate this new requirement (which does not
seem to serve a purpose) ?

Or should the BUG_ON line be removed from
syncppp.c to return it to the original convention?

It seems odd to add a sanity check for a member
that is not used and is not set. It also seems
counter productive to modify multiple drivers
to set this value to accomodate the new sanity check
since that value is still not used in sppp_attach.


-- 
Paul Fulghum
paulkf@microgate.com

Re: [RFC] syncppp broken - how to fix?

[Paul Fulghum]

On Wed, 2004-03-03 at 13:49, Stephen Hemminger wrote:
> That assert can go, it is a left over from the conversion
> of the wan devices to use alloc_netdev.

OK

> The whole ppp structure layering
> is a mess; with a bad case of assumed encapsulation.

Agreed, it is *really* ugly.

I've decided to alter the synclink drivers to
work with and without the new assertion. That
way, our customers can download updated
drivers from our web site which will work
with any 2.6 kernel.

Removing the assertion fixes things for the
other drivers starting with kernel 2.6.5

--
Paul Fulghum
paulkf@microgate.com