On Wed, Dec 16, 2009 at 09:38:27PM +0100, Oliver Hartkopp wrote:
>
> >>>>> I encountered this sk_error_report() during my current development.
> >>>>> It appears to be _the_ method of saying
> >>>>> "something got in error", which must first be set by ->sk_err.
> >>>> I wonder if socket layer error reporting is the right thing on netdriver
> >>>> level.
> >>>> ~/net-2.6/drivers/net$ find . -name \*.c | xargs grep sk_error
> >>>> returns nothing - and i'm sure accessing
> >>>> skb->sk->sk_error_report(skb->sk) on
> >>>> driver level will bounce quite hard on netdev-ML ;-)
> >>> well....ask them. I mean state our problem, give our sk_err solution and
> >>> ask if we can make it better.
> >> Good idea. We could combine the question with the patch. Either it goes
> >> in or they will advice us to use something else for error reporting to
> >> the user.
> > Ack.
>
> Hm.
>
> I won't stop you at all but i'm quite sure, that socket (error) handling is
> network layer and has nothing to do with netdevices.
>
> IMHO the right approach would be to extend the possible driver transmit return
> codes in include/linux/netdevice.h :
>
> enum netdev_tx {
> __NETDEV_TX_MIN = INT_MIN, /* make sure enum is signed */
> NETDEV_TX_OK = 0x00, /* driver took care of packet */
> NETDEV_TX_BUSY = 0x10, /* driver tx path was busy*/
> NETDEV_TX_LOCKED = 0x20, /* driver tx lock was already taken */
> };
> typedef enum netdev_tx netdev_tx_t;
>
> We could add something like NETDEV_TX_BADFRAME or NETDEV_TX_BADPACKET and
This looks like a _very_ good idea to me.
> check this return value in af_can.c or af_packet.c to set the appropriate
> sk_err.
well, that's the hardest part then, but still better than from a netdev
driver.
af_can.c should check that a frame would never return
NETDEV_TX_BADPACKET by itself. it's af_packet.c that created the
problem and needs such check.
>
> To fiddle in sk-specific data structures from a 'dumb' netdev driver looks
> really fishy ...
indeed.
>
> Regards,
> Oliver
>
Kurt
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
