[Toybox] [PATCH] Support non memory mapped access

[Rob Landley]

On 10/25/24 15:14, Karthik Ramasubramanian wrote:
>> I already stripped the android files off and applied it locally
>> yesterday, although that was mostly so I could go:
>>
>>     git diff -b HEAD^1 HEAD
>>
> Sorry that I added android files. I will remove them in the next patch
> revision.

Eventually I'd like to get to the point where Google can build without 
needing to snapshot generated files, but that's a separate issue...

>> Looking at it today, I _think_ the issue is that mmap() gets rounded up
>> to page size and if you either do a lot of data at a size larger than
>> bytes, or do an unaligned access that goes off the edge of the page,
>> this could go boing?

I misread:

-    map_len = (addr+bytes-map_off);
+      map_len = addr + (writing ? (toys.optc - 2) * bytes : bytes) - 
map_off;

It's not conditional on mmap vs non-mmap, it's conditional on read vs 
write. Which is related to...

>> My problem here is I dunno what the expected use case is: do you
>> normally read lots of things in sequence in a single invocation, or or
>> scattered around? My mental model before this was you run the command
>> once per read/write pair and stick a shell for loop around it if you
>> wanted anything fancier, neither of which would require a loop or more
>> than one lseek(), but apparently not...
>>
> The sequential use-case is:
> devmem -f ${path_to_file} ADDR WIDTH DATA1 DATA2 .. DATAn
> where each DATA is of size WIDTH bytes. Also this sequential use-case is
> currently supported only for write access. The sequential read access
> use-case
> is currently not supported in devmem. This sequential use-case supports
> writing to WIDTH * n contiguous bytes in a file/device.

Should the sequential read case be supported? (Ala -r 37 maybe?)

Is there an "upstream" for this? I'm not finding one in debian, and of 
course there wouldn't be a standard, but there is a busybox one from 
2008 with an initial checkin message of "new applet", and then Denys 
immediatly changing the UI a bit in the next commit. The copyright on 
the source file credits Jan-Derk Bakker in 2000...

https://github.com/denix0/devmem2

Which doesn't address this either.

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..)

*shrug* Only difference between running it in a shell for loop and 
building it in is performance, and nobody's asked for performance...

Rob