Patrick McHardy wrote:

I have a set of patches coming up that introduce a rtnetlink API
for adding/modifying/deleting software network devices. I would
prefer if you could switch this driver over instead of doing the
"create N devices during loading" that many current drivers do,
leaving you with 20 unused devices after boot.
  

Hi Patrick,

next Friday? Too late ;-)

Ok, your approach is indeed an interesting idea and we would look on it,
as we also not interested in creating unused devices and do any double
work.

And it allows you have both loopback and non-loopback devices
in case that would be useful.

(..)
Qdiscs might change skb->cb. Maybe use skb->sk?


  

The loopback functionality in CAN is a bit tricky (maybe you can take a
look into the Documentation patch [7/7] at chapter 3.2 and 4.1.4).

The problem is, that we need a per socket(!) option that enables the
loopback for the sent CAN-Frames or not, so the information about
loopback a skb content or not is contained inside the skb sent down to
the CAN netdevice. If the CAN networkdevice is not capable to perform a
loopback itself (see dev->flags, chapter 6) the CAN core has to do the
loopback as a fallback.

The use of skb->cb is also needed in the receive path to recognize and
trash loopback'ed CAN-frames inside the *originating* socket (see
chapter 4.1.4).

Please consider the referenced documentation and give me a feedback, if
you have a better idea how to deal with variable loopbacks on driver
level (with is vital for CAN).

Thanks for your feedback,
Oliver