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.
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. 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 <[EMAIL PROTECTED]> To: Ned Ludd <[EMAIL PROTECTED]> Cc: Rob Landley <[EMAIL PROTECTED]>, "Peter S. Mazinger" <[EMAIL PROTECTED]>, Erik Andersen <[EMAIL PROTECTED]> 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 _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
