Messages in this thread | | | Date | Tue, 22 Apr 2008 23:23:31 +0100 | From | James Chapman <> | Subject | Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC |
| |
Jeff Garzik wrote: > Paul Fulghum wrote: >> Krzysztof Halasa wrote: >>> It's complex, I think kernel interface to generic HDLC would mean more >>> code than PPP implementation required for fixed lines. >>> Additional requirement - userspace daemon with additional plugin - may >>> not be the best thing for fixed lines either. >>> >>> That would break backward compatibility, too. >> >> I maintain both pppd and generic HDLC PPP >> interfaces for the synclink drivers. >> I would like to have a single PPP implementation, >> but what Krzysztof writes about compatibility and complexity >> (both in coding and user configuration) is a real issue. >> >> Many customers who choose to use generic HDLC PPP are *dead* >> set against the added complexity and (user space) >> components of using pppd even though it has more features. >> I say that having tried to persuade such users to use pppd. >> The response is usually "support the simpler generic >> HDLC PPP way of doing things or we will go elsewhere". >> Others require the extra features of pppd. >> >> I understand customer desires are not always rational >> or a primary concern when making these architectural >> decisions, but I know forcing the extra complexity and >> components of pppd on generic HDLC users will cause a >> lot of anger and defections.
Are there technical reasons or is the complexity just a lack of familiarity?
> The fact that Krzysztof's solution was _small_ and _clean_ and easily > maintainable was the reason I merged it [into my tree]. > > IMO sometimes "one size fits all" is not the best solution.
I guess what caught my eye is a PPP control protocol implementation being in the kernel. I'd seen syncppp before but I assumed it was there for legacy reasons. A while ago there seemed to be strong desire to move control protocols such as bridge spanning tree into userspace. Is this no longer the case?
-- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development
| |