WAN: new PPP code for generic HDLC - Kernel

This is a discussion on WAN: new PPP code for generic HDLC - Kernel ; On Sat, 12 Apr 2008 10:10:40 +0200 Krzysztof Halasa wrote: > Andrew Morton writes: > > > It never hurts to resend. It was 6000 patches ago and my mind is a blank. > > Sure, here is it. Some ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 55

Thread: WAN: new PPP code for generic HDLC

  1. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    On Sat, 12 Apr 2008 10:10:40 +0200
    Krzysztof Halasa wrote:

    > Andrew Morton writes:
    >
    > > It never hurts to resend. It was 6000 patches ago and my mind is a blank.

    >
    > Sure, here is it. Some description, well:
    >
    > PPP support in generic HDLC in Linux 2.6.25 is broken and will cause
    > a kernel panic when a device configured in PPP mode is activated.
    >
    > It will be replaced by new PPP implementation after Linux 2.6.25 is
    > released.


    Thats a pretty bad regression. Surely the correct fix is to revert the
    change series that caused the breakage then re-merge that and fixes for
    HDLC PPP for 2.6.26, not just leave it broken ?
    --
    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/

  2. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    Jeff Garzik writes:

    > applied


    [two of them]

    Great, thanks.
    --
    Krzysztof Halasa
    --
    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/

  3. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    Alan Cox writes:

    >> PPP support in generic HDLC in Linux 2.6.25 is broken and will cause
    >> a kernel panic when a device configured in PPP mode is activated.
    >>
    >> It will be replaced by new PPP implementation after Linux 2.6.25 is
    >> released.

    >
    > Thats a pretty bad regression. Surely the correct fix is to revert the
    > change series that caused the breakage then re-merge that and fixes for
    > HDLC PPP for 2.6.26, not just leave it broken ?


    It's not that simple - it was broken between 2.6.22 and 2.6.23 (2.6.23
    was already broken), I just haven't noticed (I don't use PPP myself,
    except for tests).

    author Peter P Waskiewicz Jr
    Fri, 6 Jul 2007 20:36:20 +0000 (13:36 -0700)
    commit f25f4e44808f0f6c9875d94ef1c41ef86c288eb2

    [CORE] Stack changes to add multiqueue hardware support API
    Add the multiqueue hardware device support API to the core network
    stack. Allow drivers to allocate multiple queues and manage them at
    the netdev level if they choose to do so.

    Added a new field to sk_buff, namely queue_mapping, for drivers to
    know which tx_ring to select based on OS classification of the flow.

    And it included:
    --- a/include/linux/netdevice.h
    +++ b/include/linux/netdevice.h
    @@ -565,9 +578,7 @@ struct net_device

    static inline void *netdev_priv(const struct net_device *dev)
    {
    - return (char *)dev + ((sizeof(struct net_device)
    - + NETDEV_ALIGN_CONST)
    - & ~NETDEV_ALIGN_CONST);
    + return dev->priv;
    }

    #define SET_MODULE_OWNER(dev) do { } while (0)


    HDLC PPP sits between hardware drivers and (in this case) syncppp.c,
    and it (hdlc_ppp module) was using netdev_priv() as a pointer to the
    memory allocated with (after) the netdev structure. dev->priv was used
    by syncppp.c.

    HDLC FR was also broken by this change but the fix was easy because
    there is no external protocol module to interface to.

    I didn't want to add to the HDLC PPP mess anymore and have rewritten
    it instead (in process, it turned out syncppp alone, and syncppp +
    HDLC have much more problems than I thought). Obviously I was way too
    late for 2.6.25 (past 2.6.25-rc5 and the new code wasn't much tested).


    Yes, I could add another dirty "interface fix" to the HDLC + syncppp
    combo (hdlc_ppp), but I don't really see a sense, especially that I
    have the new implementation ready and working (my time resources are
    currently quite limited and if I have to choose between adding another
    glue fix and writing a better PPP replacement I pick the latter).


    My original post: http://lkml.org/lkml/2008/3/12/277
    --
    Krzysztof Halasa
    --
    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/

  4. RE: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    > It's not that simple - it was broken between 2.6.22 and 2.6.23 (2.6.23
    > was already broken), I just haven't noticed (I don't use PPP myself,
    > except for tests).


    > author Peter P Waskiewicz Jr
    > Fri, 6 Jul 2007 20:36:20 +0000 (13:36 -0700)
    > commit f25f4e44808f0f6c9875d94ef1c41ef86c288eb2


    > [CORE] Stack changes to add multiqueue hardware support API
    > Add the multiqueue hardware device support API to the core network
    > stack. Allow drivers to allocate multiple queues and manage them at
    > the netdev level if they choose to do so.


    > Added a new field to sk_buff, namely queue_mapping, for drivers to
    > know which tx_ring to select based on OS classification of the flow.


    > And it included:
    > --- a/include/linux/netdevice.h
    > +++ b/include/linux/netdevice.h
    > @@ -565,9 +578,7 @@ struct net_device


    > static inline void *netdev_priv(const struct net_device *dev)
    > {
    > - return (char *)dev + ((sizeof(struct net_device)
    > - + NETDEV_ALIGN_CONST)
    > - & ~NETDEV_ALIGN_CONST);
    > + return dev->priv;
    > }


    What I find a bit disturbing is I found my original patchsets I
    submitted to the list that were committed for this patchset. My
    original patches don't have this change in them at all. :-(

    -PJ Waskiewicz
    --
    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/

  5. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    From: "Waskiewicz Jr, Peter P"
    Date: Mon, 14 Apr 2008 12:16:55 -0700

    > What I find a bit disturbing is I found my original patchsets I
    > submitted to the list that were committed for this patchset. My
    > original patches don't have this change in them at all. :-(


    Ummmm, if you remember we had to put that in because it was the
    only way to get your multiqueue changes to even work.

    So don't even act as if that got slipped in behind your back,
    unknowingly. You were absolutely informed about this.
    --
    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/

  6. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    Update:

    > Yes, I could add another dirty "interface fix" to the HDLC + syncppp
    > combo (hdlc_ppp), but I don't really see a sense, especially that I
    > have the new implementation ready and working (my time resources are
    > currently quite limited and if I have to choose between adding another
    > glue fix and writing a better PPP replacement I pick the latter).
    >
    >
    > My original post: http://lkml.org/lkml/2008/3/12/277


    David doesn't want the new PPP, insisting that I fix existing
    hdlc_ppp.c + syncppp.c combo instead, and that there are related bugs
    in drivers using syncppp.c alone (not hdlc_ppp) which I have to fix as
    well.

    Unfortunately I'm unable to do that. Even if I could add another
    workaround to hdlc_ppp to make it work with syncppp.c again, I can't
    fix the other drivers (if they are indeed broken) because of lack of
    hardware, and I can't really make significant changes to syncppp.c
    (to make them available to all drivers) because that could and would
    break those drivers.

    Comments?
    --
    Krzysztof Halasa
    --
    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/

  7. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    From: Krzysztof Halasa
    Date: Fri, 18 Apr 2008 17:58:48 +0200

    > Comments?


    I'll fix it properly because I know you won't do the work.
    You don't need to keep making excuses.
    --
    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/

  8. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    David Miller writes:

    > I'll fix it properly because I know you won't do the work.


    Great to read that.

    Just few friendly after all notes so that you don't waste your time
    learning that yourself:
    - my patch didn't give us a third PPP implementation, we already have
    three: generic PPP, syncppp and PPP for ISDN :-)
    - of those, both generic PPP and (I think) ISDN PPP are in a good
    shape
    - generic PPP is specialized for dial-up async devices and has the
    required features (in kernel and in userspace pppd) - auth,
    multi-line, compression etc. It's a "lets give /dev/ttyS* a network
    device" implementation.
    - ISDN PPP does for ISDN cards basically the same as generic PPP does
    for terminals. They are completely different from syncppp as the
    needs are completely different. Fixed-line PPP must be small and
    fast, and self-contained.


    Now syncppp.c and sync serial (HDLC) cards. We basically have three
    categories of hardware:
    - mostly old ISA cards (cosa, cyclom-2x, z85230, s502/s508, personally
    I have c101 and n2 for tests, and PCI wanxl400). I think Alan
    maintains Zilog drivers, other "old" drivers are not maintained at
    all. They use syncppp.c directly (except c101, n2 and wanxl using
    generic HDLC).
    The list was longer but few drivers have been removed recently.

    - cards with in-kernel obsolete drivers and users encouraged to use
    manufacturers' driver - lmc.

    - a bit more modern PCI cards such as pc300, pci200syn, synclinks,
    dscc4, farsync, some off-tree ones. They use generic HDLC.

    - I have offered to port any remaining old driver to generic HDLC if
    I'm sent a hardware sample. Synclink, dscc4 and farsync have been
    ported by other people.

    I would be surprised to find that the "old" drivers are still
    functional. Nevertheless syncppp.c is functional (though marginally)
    and I think there are no bugs related to dev->priv and netdev_priv()
    for those drivers.

    The real problem with old drivers is the lack of hardware. Personally
    I suspect they may have 0 users worldwide.


    Syncppp.c is the problem for newer cards:
    - the support has been broken recently due to netdev_priv() changes
    (could be band-aided).
    - it's missing IPv6 and adding it is not trivial
    - it's not RFC/STD-compliant at all, i.e. breaks many "MUST" rules and
    doesn't work with some other compliant implementations, and fixing
    that would be a real PITA,
    - the code is really hard to parse/understand/maintain, it looks a bit
    like it was written in some other language and then "compiled" into
    C machine code :-)
    - the lack of hardware makes doing significant changes to the drivers
    and syncppp almost impossible, without breaking them (if they aren't
    already broken).


    That's why I came to an idea that leaving syncppp and the old drivers
    in their current bit-rotting state which nobody can really fix, and
    using another (fourth, and third when syncppp eventually dies) PPP
    implementation is the only way out of this situation.

    HTH.
    --
    Krzysztof Halasa
    --
    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/

  9. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    Krzysztof Halasa wrote:
    > David Miller writes:
    >
    >> I'll fix it properly because I know you won't do the work.

    >
    > Great to read that.
    >
    > Just few friendly after all notes so that you don't waste your time
    > learning that yourself:
    > - my patch didn't give us a third PPP implementation, we already have
    > three: generic PPP, syncppp and PPP for ISDN :-)
    > - of those, both generic PPP and (I think) ISDN PPP are in a good
    > shape
    > - generic PPP is specialized for dial-up async devices and has the
    > required features (in kernel and in userspace pppd) - auth,
    > multi-line, compression etc. It's a "lets give /dev/ttyS* a network
    > device" implementation.


    Generic ppp isn't specialized at all, and it isn't limited to async
    serial devices. PPPoE, PPPoATM and L2TP use it.

    > - ISDN PPP does for ISDN cards basically the same as generic PPP does
    > for terminals. They are completely different from syncppp as the
    > needs are completely different. Fixed-line PPP must be small and
    > fast, and self-contained.




    > That's why I came to an idea that leaving syncppp and the old drivers
    > in their current bit-rotting state which nobody can really fix, and
    > using another (fourth, and third when syncppp eventually dies) PPP
    > implementation is the only way out of this situation.


    Can you elaborate on why the code that uses syncppp can't use the
    generic ppp code together with a userspace ppp control protocol
    implementation like pppd?


    --
    James Chapman
    Katalix Systems Ltd
    http://www.katalix.com
    Catalysts for your Embedded Linux software development

    --
    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/

  10. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    James Chapman writes:

    > Generic ppp isn't specialized at all, and it isn't limited to async
    > serial devices. PPPoE, PPPoATM and L2TP use it.


    Perhaps I should write "dial-up" and other non-fixed connections.

    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.

    Personally I think it could be acceptable but it's not for me to
    decide.
    --
    Krzysztof Halasa
    --
    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/

  11. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    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.


    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.

    Jeff



    --
    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/

  12. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    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.

    --
    Paul Fulghum
    Microgate Systems, Ltd.
    --
    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/

  13. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    From: Paul Fulghum
    Date: Tue, 22 Apr 2008 15:46:27 -0600

    > The response is usually "support the simpler generic
    > HDLC PPP way of doing things or we will go elsewhere".


    Users say this to strong-hand developers, it's not something you
    should ever take very seriously. And even if Linux may simply not be
    for them, well that's fine too, and implementing something as obscure
    as HDLC PPP one way or the other is not going to change that.

    I mean, be realistic here.

    Are we going to have three copies of code implementing the same
    thing because some HDLC PPP users threatened to defect? That's
    simply rediculious.
    --
    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/

  14. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    From: Jeff Garzik
    Date: Tue, 22 Apr 2008 16:50:41 -0400

    > 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.


    This is besides the point. We are discussing two things here:

    1) How to "correctly" fix the syncppp private area bug.

    2) How to, long term, support PPP properly in the kernel for
    various users.

    The fact that non-HDLC users of syncppp got left broken is why I
    objected to the change you merged in Jeff. It simply duplicated the
    majority of syncppp into the HDLC PPP code, which is just rediculious.

    That had nothing to do with whether we should, in the long term, use
    the generic PPP infrastructure we have now.

    I would have been more than happy if syncppp was retained and fixed
    properly, instead of being abandoned and duplicated in one fell swoop.
    We don't do things like that Jeff.
    --
    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/

  15. 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

    --
    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/

  16. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    From: James Chapman
    Date: Tue, 22 Apr 2008 23:23:31 +0100

    > 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?


    It is still the case, believe me :-)
    --
    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/

  17. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    David Miller wrote:
    > Users say this to strong-hand developers, it's not something you
    > should ever take very seriously. And even if Linux may simply not be
    > for them, well that's fine too, and implementing something as obscure
    > as HDLC PPP one way or the other is not going to change that.


    Certainly not a big deal for Linux, but more
    significant for vendors of HDLC hardware :-)

    David Miller wrote:
    > I would have been more than happy if syncppp was retained and fixed
    > properly, instead of being abandoned and duplicated in one fell swoop.


    I'd be happy with that also. I was responding to the
    suggestion of merging generic HDLC PPP with the pppd implementation.
    It's been suggested before, but doing so looks messy.

    James Chapman wrote:
    > Paul Fulghum wrote:
    >> 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.

    >
    > Are there technical reasons or is the complexity just a lack of
    > familiarity?


    From what I can tell it was an existing investment in scripts,
    training, tools, naming conventions, etc. Even when
    provided with new tools and scripts that do the same thing (as
    far as I could tell) the response was suprisingly vehement against
    change.

    --
    Paul

    --
    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/

  18. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    David Miller writes:

    > The fact that non-HDLC users of syncppp got left broken


    The fact is it isn't broken WRT dev->priv at least (I don't know about
    random unrelated breakage).

    The drivers:
    a) alloc a netdev
    b) set dev->priv to some private kmalloced area

    It was like that for years, and it worked. The commit in question
    changed netdev_priv() and the drivers don't use this function.

    netdev_priv() was introduced at some point in time to allow
    alloc_netdev() to optionally allocate additional memory for internal
    use by the driver. It had nothing to do with dev->priv except "priv"
    name. The drivers don't use it passing size 0.

    This is probably suboptimal (two+ allocations instead of one), if the
    drivers had maintainers with access to hardware I guess it would be
    optimized, but it has nothing to do with the regression.

    The regression is present in HDLC PPP only, becase HDLC PPP actually
    used netdev_priv() (unlike non-HDLC PPP cases) as a means of addressing
    the area following net_device struct and not for retrieving dev->priv,
    and then the semantics suddenly changed.

    > I would have been more than happy if syncppp was retained and fixed
    > properly, instead of being abandoned and duplicated in one fell swoop.


    I would be happy as well. The problem is that nobody shown any idea
    how to do it.

    I have offered: I will port any existing sync serial driver to generic
    HDLC if I'm sent a free hardware sample. That includes old ISA cards
    (I still have an old 2*PII-333 ISA test machine), and porting PC300
    T1/E1 code to pc300too.

    If some driver/hw has no users I think there is no point in keeping it
    on life support here. The same goes for syncppp - if/when the number
    of drivers using it drops to zero, we can let it go.
    --
    Krzysztof Halasa
    --
    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/

  19. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    From: Krzysztof Halasa
    Date: Wed, 23 Apr 2008 19:02:22 +0200

    > netdev_priv() was introduced at some point in time to allow
    > alloc_netdev() to optionally allocate additional memory for internal
    > use by the driver. It had nothing to do with dev->priv except "priv"
    > name. The drivers don't use it passing size 0.


    No, it was added as an optimization since the private
    area was allocated together with the struct netdev, and
    thus at a constant offset computable a compile time.

    It was never meant to provide a facility to have two private areas
    associated with a device, but unfortunately some broken stuff decided
    to use it that way.
    --
    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/

  20. Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC

    David Miller writes:

    > No, it was added as an optimization since the private
    > area was allocated together with the struct netdev, and
    > thus at a constant offset computable a compile time.


    That's essentially what I meant. And it has changed, call it whatever
    you wish.
    --
    Krzysztof Halasa
    --
    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/

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast