netdev - Re: sysfs question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AFC4984.8000803@hartkopp.net>
Date:	Thu, 12 Nov 2009 18:44:36 +0100
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Stephen Hemminger <shemminger@...tta.com>
CC:	Kurt Van Dijck <kurt.van.dijck@....be>,
	Wolfgang Grandegger <wg@...ndegger.com>, netdev@...r.kernel.org
Subject: Re: sysfs question

Stephen Hemminger wrote:
> On Thu, 12 Nov 2009 11:39:41 +0100
> Kurt Van Dijck <kurt.van.dijck@....be> wrote:
> 
>> Hi,
>>
>> Within the socketcan project, we came into a situation that
>> might benefit with input from the netdev mailing list.
>>
>> The main issue is the policy to add sysfs properties in
>> /sys/class/net/canX.
>>
>> The reason for this is that cards (devices) with multiple network
>> interfaces may require properties per network.
>>
>> An obvious property would be the 'channel number of the card'. Other
>> properties could be things like type of output circuitry, ..., rather
>> hardware specific.
>>
>> I see currently 3 options:
>> 1) such properties in /sys/class/net/canX would be allowed.
>> 2) such properties would belong in /sys/class/net/canX/<subdirectory tbd>/
>> 3) such properties would go somewhere else.
>>
>> Some input with regard to sysfs policies would be helpfull.
>>
>> Kurt
> 
> It sounds like the property you are proposing is a property of the
> upper network layer not the hardware. Putting more properties in sysfs
> is good if is hardware related, but awkward if it is really a protocol
> attribute.

Then it would be good here :-)

The problem that can occur here is:

You plug-in a PCMCIA CAN card that has two CAN controllers on-board.

That means, you're getting two CAN independed network interfaces can0 and can1
pointing to ONE pcmcia device. Both of the CAN netdevs may have different
bitrates or other CAN controller specific settings (like the type of output
circuitry Kurt mentioned).

Finally the PCMCIA card itself may contain a serial number and/or a license
information that needs to be made available.

It's definitely no upper network layer stuff.

Regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html