What about this kind of layout?
device can_id can_mask userdata matches ident
1234567812345678 123 12345678 12345678 1234567 isotpe
device can_id can_mask userdata matches ident
can0 12345678 12345678 12345678 1234567 isotpe
device can_id can_mask userdata matches ident
1234567812345678 123 12345678 0000000012345678 1234567 isotpe
device can_id can_mask userdata matches ident
mcp251xfd0 12345678 12345678 0000000012345678 1234567 isotpe
12345678901234567890123456789012345678901234567890123456789012345678901234567890
Only the "matches" could lead to a length beyond 7 characters then and
would lead to a garbled output at the end of that line.
Best regards,
Oliver
On 2/7/23 10:17, Oliver Hartkopp wrote:
Hi Marc,
not sure on which architecture your proc output was created.
On 2/6/23 20:45, Marc Kleine-Budde wrote:
On 06.02.2023 20:43:05, Marc Kleine-Budde wrote:
The table "/proc/net/can/rcvlist_all" is garbled if the interface
names are longer than 5 characters.
Consider IFNAMSIZ when formatting the table so that it looks like
this:
| receive list 'rx_all':
| device can_id can_mask function userdata
matches ident
| any 000 00000000 8e807747 9bc49fd8
0 raw
| device can_id can_mask function userdata
matches ident
| mcp251xfd0 000 00000000 8e807747 ec6d80a2
| 0 raw
^^^^^^
Doh! That's my fault, the proc output is OK. fixed.
On my x86-64 with IS_ENABLED(CONFIG_64BIT) it looks even worse:
cat /proc/net/can/rcvlist_all
receive list 'rx_all':
(any: no entry)
device can_id can_mask function userdata matches
ident
vcan0 000 00000000 00000000cb627637 00000000afdf543a 0 raw
device can_id can_mask function userdata matches
ident
vcan1 000 00000000 00000000cb627637 0000000020f218f6 0 raw
I wonder if we should clean up this proc stuff in general.
As you can see the "function" value is identical and points to "raw_rcv"
but the pointer is (of course) a pseudonym to not leak any kernel
pointer to the user space. IMO we could drop this column as the "ident"
column identifies the can_rx_register() user anyway.
The 'userdata' column is still helpful to identify different socket
instances while debugging. But maybe we can "fold" the address in a way
that it is always 32 bit?!?
With such kind of clean up the output of a proc line would fit into 80
chars again - even with your suggestion for IFNAMSZ.
What do you think about such clean up?
Best regards,
Oliver