From: Hubert Denkmair <xor@xor.wtf>
To: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Subject: Re: "user id" for can usb adapters
Date: Mon, 13 Jun 2016 21:01:04 +0200 [thread overview]
Message-ID: <575F02F0.6070600@xor.wtf> (raw)
In-Reply-To: <575DB26E.2050306@hartkopp.net>
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
next prev parent reply other threads:[~2016-06-13 19:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-11 13:03 "user id" for can usb adapters Hubert Denkmair
2016-06-12 19:05 ` Oliver Hartkopp
2016-06-13 19:01 ` Hubert Denkmair [this message]
2016-06-14 6:39 ` Oliver Hartkopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=575F02F0.6070600@xor.wtf \
--to=xor@xor.wtf \
--cc=linux-can@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.