So what are these must fix problems? You don't want all the gpios to appear
in sysfs by default in case there are many. So have them only appear when
they are requested by something. Problem solved.
Someone might label the chip with a label using a '/'. First of all, that's
nothing but speculation on a problem that will probably never happen. Do any
existing chip labels use a '/'? Is it really that hard to just not label the
chip that way? But suppose someone just can't avoid it, one line of code,
that I posted, is all it takes to fix this.
Multiple chips with the same label. That's more annoying, but still
easy to fix in a number of ways:
1) If the label isn't unique, don't register that chip with sysfs.
2) If the label isn't unique, appended a suffix to make it so.
3) Always add a sequence number the end of the chip label. This is quite
common in fact.
The sysfs control interface won't be able to handle gpios named this way. Or
doing so will be "too hard". Not true, I wrote and posted code that did it.
It was simpler than the initial code you wrote for the control interface, and
much simpler than the latest with all the gpiochip stuff. BTW, my code also
worked for unexporting gpio 0....
You say nothing in sysfs works this way, but I don't agree. Take a look at
/sys/class/net, you have names like "tap0", "eth0", "eth1", "lo", etc. This
is exactly what I'm saying to do. The first "eth" gpio chip you register is
appears as eth0 in sysfs, the second as eth1, and so on.
The directories are not just named "netdev0", "netdev1", "netdev2", with some
sort of mapping file telling you ethernet devices are using numbers 2-3.
Look at PCI, you have files like "/sys/bus/pci/devices/0000:01:05.0" and
"/bus/pci/devices/0000:00:0d.2". It's not "pci1", "pci2", "pci3", with a
"bus0" directory telling you that the bus starts at device 3 and has 6
devices.
Look at ACPI, it's /sys/bus/acpi/devices/{LNXSLPBN:00,LNXPWRBN:00,LNXSYSTM:00}
and "device:00", "device:01". It uses useful names before the number when
they exist, and just "device" when it doesn't. This is what I'm saying to do
for gpios.
In fact, what you want - just naming gpios from each device sequentially as
the are dynamically assigned, and then having another set of directories that
allow one to calculate what which one belongs to a given chip - seems to be a
lot harder to find an existing example of.
It's where I started. You say your system works for everything that matters
and just dismiss the problems I'm solving as irrelevant with a wave of your
hand. That's very convenient for you, but where does it leave me?
Your worried about the memory usage of some extra sysfs files, but include
python on your device? IMHO, if you can't do this simple task in 5 minutes
with just busybox, the system is making things too hard.
I seem to be doing it just fine. I never posted the latest version of my
code since you didn't respond to my April 7th email.
What is the reason to not have the label with gpio in sysfs?
How does seeing the value, direction, and label of a gpio "muck around with
its internal state?"
Of course, one can still change a gpio via /dev/mem or i2c-dev, depending on
the source. How is being able to do this via sysfs any different? Yes, the
user could mess the driver up, if they don't know what they are doing. Just
like there are a hundred other ways to do this via raw device access,
/dev/mem, i2c-dev, and so on. I guess instead of looking down on everyone and
assuming no one else knows what they are doing and must be protected, I prefer
to assume users aren't idiots, and if they can be trusted with /dev/hda they
can be trusted with gpios in sysfs.
--
