linux-kernel - Re: [PATCH can-next v6] can: add tx/rx LED trigger support

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: <50451919.20205@hartkopp.net>
Date:	Mon, 03 Sep 2012 22:54:49 +0200
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Fabio Baltieri <fabio.baltieri@...il.com>
CC:	Marc Kleine-Budde <mkl@...gutronix.de>, linux-can@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Wolfgang Grandegger <wg@...ndegger.com>
Subject: Re: [PATCH can-next v6] can: add tx/rx LED trigger support

On 03.09.2012 20:29, Fabio Baltieri wrote:

> On Mon, Sep 03, 2012 at 08:13:35PM +0200, Kurt Van Dijck wrote:
>> On Mon, Sep 03, 2012 at 02:40:39PM +0200, Marc Kleine-Budde wrote:
>>> The net->ifindex is unique. But it's only an integer. Usually can0 has a
>>> ifindex != 0, so a simple can%d is contra productive here.
>>>
>>> Some pointers to related code:
>>> http://lxr.free-electrons.com/source/drivers/base/core.c#L1847
>>> http://lxr.free-electrons.com/source/drivers/base/core.c#L73
>>> http://lxr.free-electrons.com/source/include/linux/device.h#L695
>>>
>>> comments?
> 
> That would probabily makes really hard to choose the right
> default_trigger for led devices to get to the appropriate CAN LED in
> embedded systems, as trigger name would depend from other network
> devices and probing order (correct me if I'm wrong).
> 
> Something with device name would probaily be more appropriate here.
> 
>>
>> a very recent idea: something with netdevice notifiers and NETDEV_CHANGENAME ...
>> http://lxr.free-electrons.com/source/net/core/dev.c#L1030
>>
>> you could: rename the trigger, or if we think it's usefull,
>> block the netdev rename when its triggers are in use.
> 
> Blocking the rename looks overkill to me, what about using device name
> with an optional "port id" appended to it?  Sounds simpler...


The name of the device can only be changed when the interface is down.
Is it possible to put some scripting around it to detach and attach the leds
to the interfaces on ifup/ifdown triggers?

Regards,
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/