All of lore.kernel.org
 help / color / mirror / Atom feed
* can-j1939: semantics question
@ 2015-11-11 19:52 Kurt Van Dijck
  2015-11-11 20:49 ` Oliver Hartkopp
  0 siblings, 1 reply; 3+ messages in thread
From: Kurt Van Dijck @ 2015-11-11 19:52 UTC (permalink / raw)
  To: Oliver Hartkopp; +Cc: Alex Layton, linux-can

Hey,

I eventually got into investigating the necessary changes to drop
iproute2 from can-j1939.
We somewhat agreed that opening a can-j1939 socket and binding
to a CAN interface should activate can-j1939 processing for that
interface.
But how about deactivation?
Should the last can-j1939 socket on a CAN iface deactivate can-j1939 for
that iface when that socket closes?

Kind regards,
Kurt

^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: can-j1939: semantics question
  2015-11-11 19:52 can-j1939: semantics question Kurt Van Dijck
@ 2015-11-11 20:49 ` Oliver Hartkopp
  2015-11-12  8:39   ` Kurt Van Dijck
  0 siblings, 1 reply; 3+ messages in thread
From: Oliver Hartkopp @ 2015-11-11 20:49 UTC (permalink / raw)
  To: Alex Layton, linux-can, Kurt Van Dijck

On 11.11.2015 20:52, Kurt Van Dijck wrote:

> I eventually got into investigating the necessary changes to drop
> iproute2 from can-j1939.
> We somewhat agreed that opening a can-j1939 socket and binding
> to a CAN interface should activate can-j1939 processing for that
> interface.
> But how about deactivation?
> Should the last can-j1939 socket on a CAN iface deactivate can-j1939 for
> that iface when that socket closes?

At least this sounds like some kind of natural behaviour.

What would be the other option?

Would you still monitor address claiming inside the kernel without doing 
anything else?

Or is the address claiming in user space the last application that closes the 
last socket anyway??

Regards,
Oliver



^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: can-j1939: semantics question
  2015-11-11 20:49 ` Oliver Hartkopp
@ 2015-11-12  8:39   ` Kurt Van Dijck
  0 siblings, 0 replies; 3+ messages in thread
From: Kurt Van Dijck @ 2015-11-12  8:39 UTC (permalink / raw)
  To: Oliver Hartkopp; +Cc: Alex Layton, linux-can


> On 11.11.2015 20:52, Kurt Van Dijck wrote:
> 
> >I eventually got into investigating the necessary changes to drop
> >iproute2 from can-j1939.
> >We somewhat agreed that opening a can-j1939 socket and binding
> >to a CAN interface should activate can-j1939 processing for that
> >interface.
> >But how about deactivation?
> >Should the last can-j1939 socket on a CAN iface deactivate can-j1939 for
> >that iface when that socket closes?
> 
> At least this sounds like some kind of natural behaviour.
> 
> What would be the other option?

A special tool, intentionally not called 'ip' :-), that turns off
j1939 processing. Looks bad.

I'll stick to the 'natural behaviour'.

> 
> Would you still monitor address claiming inside the kernel without doing
> anything else?

no. And noone needs it anyway.

> 
> Or is the address claiming in user space the last application that closes
> the last socket anyway??

indeed, address claiming requires an open socket.

Thanks,
Kurt

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-11-12  8:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-11 19:52 can-j1939: semantics question Kurt Van Dijck
2015-11-11 20:49 ` Oliver Hartkopp
2015-11-12  8:39   ` Kurt Van Dijck

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.