public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Chapman <jchapman@katalix.com>
To: Jeff Garzik <jeff@garzik.org>,
	Paul Fulghum <paulkf@microgate.com>,
	Krzysztof Halasa <khc@pm.waw.pl>
Cc: David Miller <davem@davemloft.net>,
	alan@lxorguk.ukuu.org.uk, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC
Date: Tue, 22 Apr 2008 23:23:31 +0100	[thread overview]
Message-ID: <480E6563.9020109@katalix.com> (raw)
In-Reply-To: <480E4FA1.5020508@garzik.org>

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


  parent reply	other threads:[~2008-04-22 22:24 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-12 18:21 WAN: new PPP code for generic HDLC Krzysztof Halasa
2008-03-12 18:30 ` [PATCH] " Krzysztof Halasa
2008-03-12 18:52   ` Stephen Hemminger
2008-03-12 19:25     ` Krzysztof Halasa
2008-03-12 19:38   ` Jan Engelhardt
2008-03-12 20:10     ` Krzysztof Halasa
2008-03-12 22:12       ` Jan Engelhardt
2008-03-14 14:16       ` Krzysztof Halasa
2008-03-14 14:20 ` [PATCH v2] " Krzysztof Halasa
2008-03-25 14:39   ` Krzysztof Halasa
2008-03-25 14:55     ` Jeff Garzik
2008-03-25 15:50       ` Krzysztof Halasa
2008-03-26 23:05       ` Krzysztof Halasa
2008-03-25 23:14     ` David Miller
2008-03-26 15:01       ` Krzysztof Halasa
2008-04-11 21:35     ` Krzysztof Halasa
2008-04-12  5:14       ` Andrew Morton
2008-04-12  8:10         ` Krzysztof Halasa
2008-04-12  8:50           ` Jeff Garzik
2008-04-12 19:25             ` Krzysztof Halasa
2008-04-12 10:59           ` Alan Cox
2008-04-12 20:19             ` Krzysztof Halasa
2008-04-14 19:16               ` Waskiewicz Jr, Peter P
2008-04-14 21:09                 ` David Miller
2008-04-18 15:58               ` Krzysztof Halasa
2008-04-18 22:32                 ` David Miller
2008-04-21 15:30                   ` Krzysztof Halasa
2008-04-21 19:31                     ` James Chapman
2008-04-22 19:06                       ` Krzysztof Halasa
2008-04-22 21:46                         ` Paul Fulghum
2008-04-22 20:50                           ` Jeff Garzik
2008-04-22 22:05                             ` David Miller
2008-04-23 17:02                               ` Krzysztof Halasa
2008-04-23 22:49                                 ` David Miller
2008-04-24  0:48                                   ` Krzysztof Halasa
2008-04-24  1:08                                     ` David Miller
2008-04-24 13:12                                       ` Krzysztof Halasa
2008-04-24 13:30                                         ` David Miller
2008-04-24 13:39                                           ` Krzysztof Halasa
2008-04-24 13:55                                             ` David Miller
2008-04-24 20:46                                               ` Krzysztof Halasa
2008-04-24 20:44                                                 ` Alan Cox
2008-04-25 11:10                                                   ` Krzysztof Halasa
2008-05-12 10:32                                                   ` David Miller
2008-05-14 12:45                                                     ` Krzysztof Halasa
2008-05-19 17:00                                                       ` [PATCH] WAN: protect HDLC proto list while insmod/rmmod Krzysztof Halasa
2008-05-19 21:06                                                         ` David Miller
2008-05-22 10:27                                                         ` Jeff Garzik
2008-05-14 16:17                                                     ` [PATCH v2] Re: WAN: new PPP code for generic HDLC Krzysztof Halasa
2008-04-24 20:50                                                 ` Krzysztof Halasa
2008-04-22 22:23                             ` James Chapman [this message]
2008-04-22 22:51                               ` David Miller
2008-04-22 22:02                           ` David Miller
2008-04-22 23:52                             ` Paul Fulghum
2008-04-12  9:12   ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=480E6563.9020109@katalix.com \
    --to=jchapman@katalix.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@davemloft.net \
    --cc=jeff@garzik.org \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paulkf@microgate.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox