[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