netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: Kurt Van Dijck <kurt.van.dijck@eia.be>,
	Wolfgang Grandegger <wg@grandegger.com>,
	netdev@vger.kernel.org
Subject: Re: sysfs question
Date: Thu, 12 Nov 2009 18:44:36 +0100	[thread overview]
Message-ID: <4AFC4984.8000803@hartkopp.net> (raw)
In-Reply-To: <20091112090041.1536ccc8@nehalam>

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

  reply	other threads:[~2009-11-12 17:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200911021533.25345.matthias.fuchs@esd.eu>
     [not found] ` <20091106100427.GB323@e-circ.dyndns.org>
     [not found]   ` <20091109112331.GE323@e-circ.dyndns.org>
     [not found]     ` <4AF83EB7.3070401@grandegger.com>
     [not found]       ` <20091112100053.GA322@e-circ.dyndns.org>
     [not found]         ` <4AFBE0DD.1000408@grandegger.com>
2009-11-12 10:39           ` sysfs question Kurt Van Dijck
2009-11-12 17:00             ` Stephen Hemminger
2009-11-12 17:44               ` Oliver Hartkopp [this message]
2009-11-12 20:01                 ` Kurt Van Dijck

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=4AFC4984.8000803@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=kurt.van.dijck@eia.be \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    --cc=wg@grandegger.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).