new applet: devmem

[Ned Ludd]

On Sun, 2008-10-26 at 12:11 +0100, Denys Vlasenko wrote:
> On Sunday 26 October 2008 11:04, Rob Landley wrote:
> > On Sunday 26 October 2008 04:10:45 Mike Frysinger wrote:
> > > i dont think there's any pressing issues to not submit this upstream ?
> > > -mike
> > 
> > Seems fairly straightforward to me.  I remember Solar telling me he needed 
> > that a year ago, I forget why.

Rob,
Perhaps what you are recalling is that the TCT firmware for the Nail
included the devmem2 program. It was the only external program outside
of busybox that was in the tct/buildroot release. So it just seemed
logical to me that it should be an applet due to it's small size.


> Last time it was discussed on mailing list with Ned Ludd,
> but then Ned stopped responding to my mails before
> we had polished it enough for inclusion.

Denys,
Sorry my bad. I don't actually need the applet for any of my daily
busybox uses and can't really comment on the exact desired behavior.
Adding dave to the CC: (for any further input about the applet)

> 
> Basically the last mail in that exchange was:
> 
> ----------  Forwarded Message  ----------
> Subject: Re: uclibc development: busybox POV
> Date: Friday 20 June 2008 22:38
> From: Denys Vlasenko <vda.linux at googlemail.com>
> To: Ned Ludd <solar at gentoo.org>
> Cc: Rob Landley <rob at landley.net>, "Peter S. Mazinger" <ps.m at gmx.net>, Erik Andersen <andersen at codepoet.org>
> 
> On Friday 20 June 2008 21:51, Ned Ludd wrote:
> > > > The other attached is the devmem2 program made into an applet. I read
> > > > over the history of when it was submitted the first time and some valid
> > > > problems were raised. I've attempted to address every single one of them
> > > > so it would be suitable for inclusion in bb. 
> > > 
> > > I propose the following attached version. Can you test it?
> > > 
> > > Questions:
> > > 
> > > 1. Shouldn't read operation just print result, without
> > >    "Value at address 0x7 (0xf7f38007): xxx"?
> > >    It will be far easier to use from scripts and is generally
> > >    how Unix porgrams operate (e.g. wc -l).
> > > 
> > > 2. What if I dont want readback here? Say, my hardware doesn't like
> > >    stray read cycles?
> ...
> > <solar> prpplague: just got word back from vda(busybox maintainer) about
> > devmem inclusion to bb. He proposes a new applet. Mind taking a quick
> 
> Well, I'm not proposing new applet. It's YOUR applet,
> just a bit edited by me. The idea is not mine.
> 
> > peek? http://rafb.net/p/0eUU3J37.txt and
> > http://linbsd.net/~solar/8.patch
> > 
> > 06:45PM * prpplague/#edev looks
> > 
> > 06:46PM <prpplague> solar: hmm
> > 
> > 06:47PM <prpplague> solar: i can see his points as being made from a
> > software persons vantage
> > 06:47PM <prpplague> solar: but those features are there for a reason
> > 06:48PM <prpplague> solar: i'll have to test it on monday
> > <solar> ok. I'll mail him back
> > 06:57PM <prpplague> solar: the primary reason for that information is so
> > can check the status of before and after, for instance, many times if a
> > registers is related a multifunction gpio, you can write to the
> > register, but the write will not take effect
> > 06:58PM <prpplague> solar: so you can see what the value is before, what
> > you intend it to be, and what the result was
> > 06:58PM <prpplague> solar: otherwise you will indeed have to run the
> > command three times
> 
> I do see their reasoning, but read-write-read behavior means that
> applet is unusable for those who wants _only_ single_ write_ to occur.
> Whereas "single write" behavior can be scripted around
> so that you can do read-write-read if you want to.
> 
> See? it's a question "do we restrict the options of the user needlessly?"
> 
> > 06:59PM <prpplague> solar: maybe a flag can be used on compilation
> > 07:08PM <prpplague> solar: or is it that he was just questioning those
> > items at the momment and not changing them?
> > 07:10PM <prpplague> solar: that patch looks good
> > <solar> prpplague: but you still need the readback?
> > 07:19PM <prpplague> solar: yea i'd still prefer to have the readback
> > 07:19PM <prpplague> solar: buts that just me
> > -------------------------------------------------------------------------
> > 
> > Ok so the sound of it to me. Your patch looks good but the readback
> > within the same execve is ideal.
> --
> vda
> -------------------------------------------------------
> 
> 
> I dug out the last version and committed it to svn.
> 
> I am not happy with it still. Reading is too talkative
> (polluted with irrelevant text) for scripting,
> and writing does readback unconditionally, which
> sometimes may be wrong thing to do.
> 
> --
> vda

Thanks.