sysfs question

sysfs question

[Kurt Van Dijck]

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

Re: sysfs question

[Stephen Hemminger]

On Thu, 12 Nov 2009 11:39:41 +0100
Kurt Van Dijck <kurt.van.dijck@eia.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.

Re: sysfs question

[Oliver Hartkopp]

Stephen Hemminger wrote:
> On Thu, 12 Nov 2009 11:39:41 +0100
> Kurt Van Dijck <kurt.van.dijck@eia.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

Re: sysfs question

[Kurt Van Dijck]

On Thu, Nov 12, 2009 at 06:44:36PM +0100, Oliver Hartkopp wrote:
> Stephen Hemminger wrote:
> > On Thu, 12 Nov 2009 11:39:41 +0100
> > Kurt Van Dijck <kurt.van.dijck@eia.be> wrote:
> > 
[...]
> > 
> > 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 :-)
> 
[...]
> 
> It's definitely no upper network layer stuff.
> 
Ack. It's definitely datalink or even physical layer we're talking about.
> Regards,
> Oliver

I also encountered an issue with regard to the uevent that is generated
when a netdevice is registered.
If I add sysfs files before register_netdevice, the system complains on
creating the sysfs files.
If I add those after register_netdevice, the uevent is _seems_ to have
triggered userspace already, where the udev (in fact, I use another
home-brew one for boot speed) does not find the extra sysfs file.

Is there a mechanism to hold temporarily the uevent until after the
driver has registered some extra sysfs files?

Kurt