[Toybox] [PATCH] Support non memory mapped access
Rob Landley
rob at landley.net
Fri Nov 1 15:37:29 PDT 2024
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
More information about the Toybox
mailing list