linux-kernel - Re: [PATCH 2/3] gpiolib: add support for having symlinks under gpio class directory

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]

Date:	Fri, 11 Dec 2009 10:41:40 +0200
From:	Jani Nikula <ext-jani.1.nikula@...ia.com>
To:	ext Greg KH <gregkh@...e.de>
Cc:	bn@...sdigital.com,
	"dbrownell@...rs.sourceforge.net" <dbrownell@...rs.sourceforge.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"dsilvers@...tec.co.uk" <dsilvers@...tec.co.uk>,
	"ben@...tec.co.uk" <ben@...tec.co.uk>,
	"Bityutskiy Artem (Nokia-D/Helsinki)" <Artem.Bityutskiy@...ia.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH 2/3] gpiolib: add support for having symlinks under
	gpio class directory

On Thu, 2009-12-10 at 15:49 +0100, ext Greg KH wrote:
> On Thu, Dec 10, 2009 at 04:32:17PM +0200, Jani Nikula wrote:
> > We want to assign symbolic names to GPIO lines and hide the numbering
> > changes from userspace, because it is very painful to amend userspace
> > for every board revision.
> 
> True, just like it is hard to change the kernel for every type of
> configuration as well :)

As explained by Artem, the kernel might get that information from the
bootloader, for example, so once things are in place, there'd be no need
to modify either the kernel or the userspace.

> This is the problem that udev solves, from usersapce, but you don't have
> device nodes for it to manage, right?

When exporting a GPIO to sysfs, a struct device is created with 0,0 for
dev_t, so I suppose that's correct. 

Not having a device node limits the options with udev, right?

> This type of "policy" should be better off done in userspace whereever
> possible.  Can't you just have a udev rule to create symlinks from
> somewhere else, into /sys/class/gpio/ that show this type of information
> that you are wanting to have?

Let's see. 'udevadm monitor --env' gives me this when I 'echo add >
uevent' for an exported gpio #5:

UDEV  [1230784956.241303] add      /class/gpio/gpio5 (gpio)                     
UDEV_LOG=3                                                                      
ACTION=add                                                                      
DEVPATH=/class/gpio/gpio5                                                       
SUBSYSTEM=gpio                                                                  
SEQNUM=930                                                                      
UDEVD_EVENT=1

Now *assuming* we had /sys/class/gpio/gpioN/name, I could create very
crude udev rules along the lines of this:

SUBSYSTEM=="gpio", ACTION=="add", ATTR{name}!="", RUN="/bin/ln -s /sys$devpath /tmp/gpio-$attr{name}"
SUBSYSTEM=="gpio", ACTION=="remove", ATTR{name}!="", RUN="/bin/rm /tmp/gpio-$attr{name}"

Not exactly pretty, but seems to work (using another attr for testing).
Is there a more elegant way of doing this with udev when there are no
device nodes? Or is it even sensible to use udev without the device
nodes? And what would be the right place for the symlinks?

*If* we got that working in a sensible fashion, it'd be a matter of
adding the "name" attribute to each gpio.


BR,
Jani.


--
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/