>I suspect that bit can be fixed if need be. Its nice to keep a constant
>naming between cisco/ppp modes. cisco/ppp autodetect is also possible
>and would be rather nice to support
Indeed. And let me just throw out another thought. A clean abstraction
of the various portions of the PPP functionality is beneficial in other
ways. My personal pet project being to add L2TP support to the kernel
eventually. A good abstraction of the framing capabilities and basic
PPP processing would be rather useful in that project.
>> Or is it to *add* generic PPP support to syncppp, leaving (at least
>> temporarily) the existing PPP capability in syncppp for
>> compatibility? (implying a new syncppp flag USE_GENERIC_PPP?)
>Assuming this is a 'when 2.5 starts' discussion I'd like initially to
>keep the syncppp api is but the pppd code going via generic ppp - and
>yes it would break configs.
>Clearly thats not 2.4 acceptable
I would agree that such a project would be 2.5 material.
I'll try to keep up with things on the list, but if this goes off-list,
I would appreciate being kept in the loop if possible. :) Thanks!
-- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/