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

[Joerg Wunsch]

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?

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.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)