"user id" for can usb adapters

"user id" for can usb adapters

[Hubert Denkmair]

Hi all,

for my candleLight adapter (gs_usb driver), I would like to implement a feature which is afaik currently not used in linux / socketcan:

A device ID that the user can assign and store permanently on CAN interfaces, e.g. a USB CAN interface.
This is not new - e.g. Peak System implements this in their Windows API.

One use case would be to build multiple measurement setups, each with more than one CAN adapter.

For example, at my company, we build test racks with several CAN interfaces.
Each test rack should run with the same (unmodified) software image.
To be able to build a stable environment, devices shall have a predictable name in each rack.

One way to achieve this would be to
- assign "user IDs" to the CAN interfaces (e.g. CAN A = 0, CAN B = 1, ...)
- have this id exported, e.g. as a sysfs attribute
- use udev to assign defined names for can interfaces with a certain id

Implementing a sysfs attribute for one driver is easy - and I did that for testing purposes.
But since this is (imho) a feature which could be useful for the whole socketcan infrastructure,
I would like to see a standardized method for the functionality.
We should also implement this in the pcan_usb linux driver.

I am aware that there is a file /sys/class/net/<device>/dev_id - but no idea if that would be the right place.
Seems to me as if adding a new sysfs attribute like /sys/class/net/<device>/user_id would be a better way to go.

So - any opinions on this?

Greetings,

Hubert

Re: "user id" for can usb adapters

[Oliver Hartkopp]

Hello Hubert, Max,

On 06/11/2016 03:03 PM, Hubert Denkmair wrote:
> for my candleLight adapter (gs_usb driver), I would like to implement a feature which is afaik currently not used in linux / socketcan:
>
> A device ID that the user can assign and store permanently on CAN interfaces, e.g. a USB CAN interface.
> This is not new - e.g. Peak System implements this in their Windows API.
>
> One use case would be to build multiple measurement setups, each with more than one CAN adapter.
>
> For example, at my company, we build test racks with several CAN interfaces.
> Each test rack should run with the same (unmodified) software image.
> To be able to build a stable environment, devices shall have a predictable name in each rack.
>
> One way to achieve this would be to
> - assign "user IDs" to the CAN interfaces (e.g. CAN A = 0, CAN B = 1, ...)
> - have this id exported, e.g. as a sysfs attribute
> - use udev to assign defined names for can interfaces with a certain id
>
> Implementing a sysfs attribute for one driver is easy - and I did that for testing purposes.
> But since this is (imho) a feature which could be useful for the whole socketcan infrastructure,
> I would like to see a standardized method for the functionality.
> We should also implement this in the pcan_usb linux driver.
>
> I am aware that there is a file /sys/class/net/<device>/dev_id - but no idea if that would be the right place.

Why not?

So far the dev_id is already used in some CAN drivers to identify 
instances/interfaces in CAN adapters that contain more than one CAN 
interface.

As this dev_id is established and already available e.g. for udev 
scripts I wonder if we only have to provide an interface to write this 
value (to set a specific value).

Is there a way to implement a handler that sets the dev_id into the 
hardware by writing to the sysfs entry??

This could be used e.g. for the PEAK USB interfaces too.

Regards,
Oliver


> Seems to me as if adding a new sysfs attribute like /sys/class/net/<device>/user_id would be a better way to go.
>
> So - any opinions on this?
>
> Greetings,
>
> Hubert
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: "user id" for can usb adapters

[Hubert Denkmair]

Thanks Oliver,

>> I am aware that there is a file /sys/class/net/<device>/dev_id - but no idea if that would be the right place.
> 
> Why not?

Hrm, I'm not sure.
Kernel documentation says:

---
What:           /sys/class/net/<iface>/dev_id
Description:
		Indicates the device unique identifier. Format is an hexadecimal
		value. This is used to disambiguate interfaces which might be
		stacked (e.g: VLAN interfaces) but still have the same MAC
		address as their parent device.
---

Unfortunately, the description is clearly targeted to devices with MAC-Addresses;
Anyways, I would read it as "for net devices sharing the same physical device, use dev_id to distinguish them".
Even if it isn't specified anywhere, as a application developer I would also presume that all the child devices of one parent would be numbered continuously from 0.
The user id, on the other hand, would be a random number that the device owner can choose on its own.

Also, if the dev_id is already used in socketcan context (the pcan pro driver seems to do), one might break existing applications by using the new feature.

Then, I don't know if a write to the dev_id attribute would be hard to implement / need changes in the network subsystem.
Using a new sysfs attribute would be easy-going, I guess.

Anyways, I'm by no means a experienced kernel developer and I will leave these decisions to people who are :-)

Cheers,

Hubert

Re: "user id" for can usb adapters

[Oliver Hartkopp]

Hi Hubert,

On 06/13/2016 09:01 PM, Hubert Denkmair wrote:

>>> I am aware that there is a file /sys/class/net/<device>/dev_id - but no idea if that would be the right place.
>>
>> Why not?
>
> Hrm, I'm not sure.
> Kernel documentation says:
>
> ---
> What:           /sys/class/net/<iface>/dev_id
> Description:
> 		Indicates the device unique identifier. Format is an hexadecimal
> 		value. This is used to disambiguate interfaces which might be
> 		stacked (e.g: VLAN interfaces) but still have the same MAC
> 		address as their parent device.
> ---
>
> Unfortunately, the description is clearly targeted to devices with MAC-Addresses;

Really? It is indented to disambiguate interfaces with the same MAC.
All CAN interfaces have the same MAC (00:00:00:00:00:00) :-)

In linux/include/linux/netdev.h the comment for dev_id is:

@dev_id:
Used to differentiate devices that share the same link layer address

And still we have no differentiating link layer address for CAN.

> Anyways, I would read it as "for net devices sharing the same physical device, use dev_id to distinguish them".
> Even if it isn't specified anywhere, as a application developer I would also presume that all the child devices of one parent would be numbered continuously from 0.
> The user id, on the other hand, would be a random number that the device owner can choose on its own.

I would tend to a increasing numbering as default. But 'root' should be 
able to set a user specified value into this dev_id. Especially when the 
interface is capable to store this dev_id (e.g. in EEPROM) the next time 
this value could be read from EEPROM and set into dev_id.

> Also, if the dev_id is already used in socketcan context (the pcan pro driver seems to do), one might break existing applications by using the new feature.

No. So far this dev_id was intended to be used as described above - but 
no one pushed this idea further. Your request proves the need for some 
dev_id again.

> Then, I don't know if a write to the dev_id attribute would be hard to implement / need changes in the network subsystem.

I don't know too. I think we would need some new callbacks in 
linux/include/linux/can/dev.h :

int (*do_set_dev_id)(struct net_device *dev, int dev_id);
int (*do_get_dev_id)(struct net_device *dev);

To read/write the dev_id to the EEPROM when supported.

So it would be 'just' to check whether sysfs dev_id can be made writable 
for CAN interfaces like tx_queue_len already is.

> Using a new sysfs attribute would be easy-going, I guess.

Don't know if it would be simpler.

> Anyways, I'm by no means a experienced kernel developer and I will leave these decisions to people who are :-)

I don't claim to have 'the best solution' - but making use of dev_id 
looks better than creating 'just another' configuration option.

Best regards,
Oliver