Re: [Linux-ATM-General] Sync status in userspace

[Philip P. <phi...@re...>]

  Could that be handled in atm/common.c and then shared between atm/br2684.c and atm/pppoatm.c ?

Actually, netif_carrier_{on,off} in sched/sch_generic.c would also be a good place to handle that, wouldn't it?

But in the case of pppoatm.c, it never does a register_netdev().

Sigh.


On 9/13/10 1:42 PM, chas williams - CONTRACTOR wrote:
> sorry i mispoke.  i meant net/atm/br2684.c not the userspace control
> program.  like i said, i dont know of a way to get those atm events to
> a user space process.  you would need to add something like
> netevents/rt-netlink.
>
> On Mon, 13 Sep 2010 13:33:31 -0700
> Philip Prindeville<phi...@re...>  wrote:
>
>>    I looked in br2684ctl.c but didn't see (at least not in 2.5.1)
>> where carrier events were handled.  What am I missing?  I'd like to
>> port carrier transition handling to the PPP daemon for use with the
>> rp-pppoe and pppoatm userspace plugins.
>>
>> I looked in atm/br2684.c and noticed that it registers a notifier,
>> which it then uses to detect ATM_PHY_SIG_* events...
>>
>> atm/pppoatm.c has no such support, but I don't think it would be that
>> hard to add it.
>>
>> As for your comment, not sure I get it.  I thought that netlink
>> messages were agnostic (at least for the sender) about whether the
>> listener was in kernel or userspace?
>>
>>
>> On 9/13/10 10:16 AM, chas williams - CONTRACTOR wrote:
>>> in the kernel yes, but i dont know if there is a userspace
>>> mechanism to watch for this kind of thing.  as mentioned br2684ctl
>>> shows you how to watch for carrier changes in the kernel.
>>>
>>> On Mon, 13 Sep 2010 09:05:05 -0700
>>> Philip Prindeville<phi...@re...>   wrote:
>>>
>>>>     So I can't use rtnetlink RTM_NEWLINK messages to monitor state
>>>> changes?
>>>>
>>>>
>>>> On 9/13/10 8:29 AM, chas williams - CONTRACTOR wrote:
>>>>> this patch added event monitoring for the carrier/line status.  it
>>>>> also fixed some assumptions about the carrier state.  carrier is
>>>>> now assumed to be UP (it used to be not well defined) unless the
>>>>> hardware is capable of updating the state.  userspace can
>>>>> determine the carrier status by examining /sys/class/atm/<device
>>>>> instance>/carrier.  we dont have an ioctl or ethtool type
>>>>> instance>interface to get this data.
>>>>>
>>>>> On Mon, 13 Sep 2010 09:30:16 +0200
>>>>> Karl Hiramoto<ka...@hi...>    wrote:
>>>>>
>>>>>>      On 13/09/2010 6:32, Philip Prindeville wrote:
>>>>>>>      I think a few weeks ago I saw a patch fly by on
>>>>>>> linux-kernel on signaling sync status from the DSL driver to an
>>>>>>> upper layer, with the remark that it would be useful to
>>>>>>> userspace. There's something there.
>>>>>>>
>>>>>>> Ciao.
>>>>>>> Vincent.
>>>>>>>
>>>>>>> I'm not on linux-kernel but I'll check gmane... Thanks.
>>>>>>>
>>>>>>> Actually, just checked but couldn't find it.  If you remember
>>>>>>> who wrote it or what the subject was, that would help a lot...
>>>>>>>
>>>>>>>
>>>>>> I wrote the patch.  It should be in this list's archives and the
>>>>>> netdev list at the beginning of july.  The patches are in
>>>>>> mainline now, but only work on br2684 VCs so it passes the
>>>>>> LOWER_UP flag.
>>>>>>
>>>>>> The patches are in mainline now see commits
>>>>>> 49d49106fc6cbb48c832aa58e3e6cee8b49d5e8f,
>>>>>> 7313bb8f3dd6e28bcf9c42adfd54a5cf9a4949e0,
>>>>>> 005066122b58f3b350736cc896af46aea2e32d23,  and others for each
>>>>>> device.
>>>>>>
>>>>>> --
>>>>>> Karl