Message-Id: <200804302135.56529.david-b@pacbell.net>
Date:	Wed, 30 Apr 2008 21:35:55 -0700
From:	David Brownell <david-b@...bell.net>
To:	Trent Piepho <tpiepho@...escale.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Ben Nizette <bn@...sdigital.com>,
	hartleys <hartleys@...ionengravers.com>,
	Mike Frysinger <vapier.adi@...il.com>,
	Bryan Wu <cooloney@...nel.org>
Subject: Re: [patch/rfc 2.6.25-git v2] gpio: sysfs interface

On Wednesday 30 April 2008, Trent Piepho wrote:
> >>>    /sys/class/gpio
> >>>    	...
> >>
> >> "simple"?  What I had was a lot simpler.
> >
> > But it had some "must fix" problems, which I told you when you
> > posted your first patch.  You didn't fix them.  And since then,
> > your pushback seems to rely very heavily on ignoring issues I
> > pointed out are "must fix" or "can't/doesn't work that way".
> 
> So what are these must fix problems? 

Not fixed in any update you sent to your original patch, in
the past three weeks, that's the key point.  In particular,
the number one issue was completely ignored.  (Your recent
responses haven't come across to me as helpful either..)


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

So, when I said that sysfs doesn't use names like "gpio-19" but instead
uses names like "gpio19" ... exactly what don't you agree with?

Your examples prove what I *did* say.  I don't know who you're trying
to argue with on other points, however.


> >> So, I want to set gpio 5 on a pcf9557 extender.
> >
> > Which isn't exactly where most folk start.  If it's something
> 
> It's where I started.

Which is fine.  The $SUBJECT patch provides a simple solution for it.
As well as for the other use cases I sketched.  With identifiers that
are much simpler, and harder to get wrong.


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

Those are *NOT* my words.  Again, I don't know what straw man you
are arguing with, but please stop painting my face on it, putting
your words in its mouth, and using that to claim you're disproving
something I've "said" (but haven't).

I did say your problem could be solved ... but with different
identifier syntax than you suggested.


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

Right, and since I *can* do stuff like that in busybox with ASH,
that quickly, I hope you'll agree your flamage has been blowing
things way out of proportion here.

 
> What is the reason to not have the label with gpio in sysfs?

Elaborated in my reply to Ben; see that.


> How does seeing the value, direction, and label of a gpio "muck around with
> its internal state?"

Userspace being able to MODIFY the direction and output value
is most certainly mucking around!!!


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

It's a question of how easy you make it to break things.
You seem to draw the "too easy" line differently than I do.
I don't want *anything* else mucking around with state my
drivers are responsible for managing.



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

Powered by blists - more mailing lists