On 11/1/24 14:30, Karthik Ramasubramanian wrote:
Should the sequential read case be supported? (Ala -r 37 maybe?)
Yes, we have to introduce an optional "-n" parameter to indicate the
number of bytes/words/doublewords to be accessed.
Have to, or _would_ have to if we went there?
I suppose at a certain point "dd | hd" becomes the obvious solution,
except for the read granularity part (and that's usually going to be
specific registers you're looking at..)
Also we have a potential use-case to access I/O port space in x86 which
"dd | hd" may not help with.
I saw Elliott's post in the musl list. (Ouch.)
Send me a patch when it's not merely "potential" but has an actual user.
(Infrastructure in search of a user bit-rots, something should be
regression testing it in a real workflow. I haven't got an obvious way
to test it here, and don't off the top of my head even know what I'd do
under qemu-system-x86_64 to test it. What surviving hardware needs this?)
Maybe that use-case can be supported using
"devio" sub-command in devmem.c to access registers in I/O space. Also I am
not anticipating any use-case to support accessing at
arbitrary/non-contiguous addresses.
I defer to Elliott on all this design-wise. (One output per line, or
space separated, with or without wordwrap...) However:
*shrug* Only difference between running it in a shell for loop and
building it in is performance, and nobody's asked for performance...
Before sending a patch, please explicitly tell me that you _have_
decided yes you really need whatever it is (multiple read support
instead of just a small shell script doing a for loop with the existing
command, etc). I don't want to stand in your way, but I don't have your
use cases so I'm not equipped to make that judgement call.
Rob
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
