Re: Framework for hardware filter support?

[Daniel Santos <daniel.santos@pobox.com>]

Thanks for your response, Kurt.


On 02/13/2018 01:42 PM, Kurt Van Dijck wrote:
> On zo, 11 feb 2018 16:33:43 -0600, Daniel Santos wrote:
>>> where the CAN_RAW filter design would easily fit.
>> This is what I mean by a framework.  So the driver should inform the
>> core CAN driver what it's filtering capabilities are -- again, I would
>> have to study a number of devices to design this sanely.  It would seem
>> that iproute2 would be the best userland mechanism to specify them, and
>> it could pass an array of struct can_filter objects.  Then based upon
>> the hardware, it can apply or reject them.  It would also be nice for
>> iproute2 to query the driver and be able to report those capabilities.
> I remember this discussion has passed a few times already.
> The end result has always been to:
> 1. give the kernel/driver a list of id/masks.
> 2. The driver does no aggregation, the root operator should know
>    what to do.

I don't understand what driver aggregation means.  But yes, this makes
good sense.

> Maybe some day this will become limited for hardware that can do special
> tricks, like having a random list of identifiers.
> This can most probable be addressed in some clever way that is specific
> for the driver (like adding a list of id/masks where mask is always
> 0x7ff for a random canid list).
> Due to the driver doing smart things, the driver may not be capable of
> informing filtering capabilities in a static way. I would start without
> it.
>
> The support of hardware filters is hardware specific anyway, and
> intersects the multi-user principle. The only justification is ....
> that the root operator knows the hardware and the application.

Yes, perfect!

> What matters for a generic implementation is that the API is simple,
> clear and usable. That is where the id/mask list pops in.
> Operators that don't understand the id/mask list will probably fail
> anyway to use hardware filters on CAN. No framework can prevent that.
>
> Kurt
>

Yes, this makes great sense. And the driver (I presume) can always
reject the filter configuration if it can't do what is asked.  In the
case of the MCP2210, however, there is one small hole; it has a bit that
decides rather or not to rollover messages from it's first rx buffer to
it's second (and it only has two).  I'm wondering about some free-form,
driver specific configuration string to handle any loose ends of the
device?  Too ugly?

Then again, it supports 6 filters.  Perhaps a 7th filter could be passed
to specify the rollover configuration.  Uglier still? :)

And actually, the device has bits to en/disable filtering for each rx
buffer that can be changed (along with the rollover) while the link is
up.  I'm probably *really* reaching here.  I can't think of many reasons
to have to change this while the link is up and rather or not they are
enabled can be implied by the filter/mask array.

Thanks,
Daniel