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
> check this return value in af_can.c or af_packet.c to set the appropriate
> sk_err.
>
> To fiddle in sk-specific data structures from a 'dumb' netdev driver looks
> really fishy ...
OK, interesting, then prepare a rfc patch and post it on the netdev ml.
For use (socketcan) it's a minor issue but a general solution would be
nice, indeed.
Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
