Re: [avrdude-dev] Include GPIO sysfs patch in next release?

[Benjamin Henrion]

On Fri, May 11, 2012 at 3:29 PM, Joerg Wunsch <address@hidden> wrote:
> As Benjamin Henrion wrote:
>
>> Sure, but that does not mean because it is a minority that it should
>> not go in.
>
> I did not say so, but it's reducing its priority, compared to things
> that are important for every AVRDUDE user.  If you look in the patch
> trackers, there are many things around waiting for integration, but
> our (i.e., the maintainers') time is finite, so we have to prioritize,
> at least mentally.
>
>> I will write a blog post on how it works for me.
>
> A blog post is *not* documentation to me.  (It might be useful in
> addition to regular documentation, no question.)
>
> I need at least one of the two documentation files (avrdude.1, and
> docs/avrdude.texi) patched, preferrably both.  Both could use the same
> wording, of course, and if someone cannot test one of them due to the
> lack of tools (like the texinfo suite), the patch could be made
> "blindly", just indicate this in the patch description.
>
>> Right now I have a gentoo ebuild + patch-for-gpio file, it works.
>
> I never indicated any doubts about its functionality.
>
>> > Would someone be willing to add documentation for it? My main goal
>> > for AVRDUDE 6.0 is to fix all of the outstanding Xmega issues, and all
>> > my available resources are tied up with this.
>
>> Yes, the gpio enabling requires some commands to enable them, but
>> that's 4 shell commands to expose the GPIOs in /sys/class/gpio.
>
> I cannot see the relation between your statement, and the text you
> quoted from me.
>
> I wrote that my time until AVRDUDE 6.0 is tied up with fixing various
> Xmega stuff (I've been shoving in front of me for too long already),
> so I don't have free cycles to write the documentation patch myself.
>
> You are replying something about shell commands ...
>
>> > Besides, I wonder whether the --enable-gpio feature would better be
>> > auto-probed in configure.ac?
>>
>> Sure, if you do not want to activate that feature in your build, that
>> should not go in.
>
> Still, having the code in on a system that could otherwise support the
> feature at all (*) would not hurt those who don't want to use it.  Am
> I missing something?  It's common practice for AVRDUDE to include all
> programmer handling code that would *potentially* be applicable for a
> particular target system, without requiring the user to include or
> exclude each of them by configure options (as, e.g. OpenOCD is doing).
>
> (*) I'm not knowledgable enough about *which* Linux systems are
> candidates for it.  Every Linux with a recent enough kernel?  (Which
> one?)  Every Linux that has /sys/class/gpio around?  Something else?

Sysfs+gpio is in linux since 2.6.28:

http://lxr.free-electrons.com/source/Documentation/gpio.txt

To my mind, potentially all the openwrt routers with a kernel upper
than .28 should be able to work with gpio+sysfs exposure.

I have a bunch of them at home, but I need to make update of the
avrdure openwrt with the gpio patch to see how it behaves, but avrdude
is available as a binary for openwrt since backfire:

http://downloads.openwrt.org/backfire/10.03.1/adm5120_router_be/packages/

> IMHO, the autoconf.ac stuff could just determine, based on something
> like those symptoms I mentioned, whether the respective system
> supports the feature or not, and then enable it.  If it's not enabled
> by default on systems that *could* potentially use it, each user who
> actually wants it were forced to compile their own, customized binary,
> because maintstream distribution maintainers will regularly miss to
> add this option to their configuration scripts.

For now, I would say disable it by default, people who want tge
feature will just have to add a ./configure --enable-gpio option.

I will try to give a shot to the avrdude+gpio patch against openwrt if
I find the time this week-end.

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."