Re: [PATCH v2 1/2] can: add support for filtering own messages only

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 6 May 2021 at 07:26, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
> On 05.05.21 20:54, Erik Flodin wrote:
> > On Wed, 5 May 2021 at 11:15, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
> >> On 05.05.21 10:37, Erik Flodin wrote:
> >>
> >>>>> Add a new flag to can_rx_register/unregister that, when set, requires
> >>>>> that the received sk_buff's owning socket matches the socket pointer
> >>>>> given when setting the filter. This makes it possible to set a filter
> >>>>> that matches all frames sent on a given socket and nothing else.
> >>>>
> >>
> >> (..)
> >>
> >>>>
> >>>> Wouldn't that already match your requirements?
> >>>
> >>> I guess that would require me to use two sockets: one for sending
> >>> (with RECV_ONLY_OWN_MSGS set) and one for receiving. The problem might
> >>> then be how to avoid the second socket seeing the frames sent from the
> >>> first, without disabling loopback completly?
> >>
> >> This is indeed a question of the application layout.
> >>
> >>   From what I understood your main requirement is to double check the
> >> outgoing traffic whether is has been sent.
> >
> > What I would like to have is:
> > 1. Be notified when a frame has been sent. I send (from user space) a
> > single frame and wait until I get confirmation before sending the next
> > to give other nodes on the bus a slot to start sending, even if their
> > frames have ID with lower priority.
>
> o_O
>
> Sorry, but I have problems to get behind your use-case.
>
> 1. You are sending a frame
> 2. You get a confirmation
> 3. You are waiting some time (which is not written above), to give other
> nodes a slot??

No explicit sleep is needed. The machine is sufficient slow so that
just waiting for the confirmation before sending the next frame is
enough. But if the frames are queued in the socket/device then the
frames are sent back-to-back.

> 4. goto 1??

Yes.

// Erik



[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux