Wolfgang Grandegger wrote:
> 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.
Yes. Will do.
The return value of the netdevice is processed in dev_hard_start_xmit() in
net/core/dev.c .
I first need to look, what could be the best way to pass the error up the
specific socket from there.
Regards,
Oliver
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
