<div dir="ltr"><div dir="ltr"><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 29, 2024 at 10:15 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/25/24 15:14, Karthik Ramasubramanian wrote:<br>
>> I already stripped the android files off and applied it locally<br>
>> yesterday, although that was mostly so I could go:<br>
>><br>
>>     git diff -b HEAD^1 HEAD<br>
>><br>
> Sorry that I added android files. I will remove them in the next patch<br>
> revision.<br>
<br>
Eventually I'd like to get to the point where Google can build without <br>
needing to snapshot generated files, but that's a separate issue...<br>
<br>
>> Looking at it today, I _think_ the issue is that mmap() gets rounded up<br>
>> to page size and if you either do a lot of data at a size larger than<br>
>> bytes, or do an unaligned access that goes off the edge of the page,<br>
>> this could go boing?<br>
<br>
I misread:<br>
<br>
-    map_len = (addr+bytes-map_off);<br>
+      map_len = addr + (writing ? (toys.optc - 2) * bytes : bytes) - <br>
map_off;<br>
<br>
It's not conditional on mmap vs non-mmap, it's conditional on read vs <br>
write. Which is related to...<br>
<br>
>> My problem here is I dunno what the expected use case is: do you<br>
>> normally read lots of things in sequence in a single invocation, or or<br>
>> scattered around? My mental model before this was you run the command<br>
>> once per read/write pair and stick a shell for loop around it if you<br>
>> wanted anything fancier, neither of which would require a loop or more<br>
>> than one lseek(), but apparently not...<br>
>><br>
> The sequential use-case is:<br>
> devmem -f ${path_to_file} ADDR WIDTH DATA1 DATA2 .. DATAn<br>
> where each DATA is of size WIDTH bytes. Also this sequential use-case is<br>
> currently supported only for write access. The sequential read access<br>
> use-case<br>
> is currently not supported in devmem. This sequential use-case supports<br>
> writing to WIDTH * n contiguous bytes in a file/device.<br>
<br>
Should the sequential read case be supported? (Ala -r 37 maybe?)<br></blockquote><div>Yes, we have to introduce an optional "-n"  parameter to indicate the number of bytes/words/doublewords to be accessed.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Is there an "upstream" for this? I'm not finding one in debian, and of <br>
course there wouldn't be a standard, but there is a busybox one from <br>
2008 with an initial checkin message of "new applet", and then Denys <br>
immediatly changing the UI a bit in the next commit. The copyright on <br>
the source file credits Jan-Derk Bakker in 2000...<br>
<br>
<a href="https://github.com/denix0/devmem2" rel="noreferrer" target="_blank">https://github.com/denix0/devmem2</a><br>
<br>
Which doesn't address this either.<br>
<br>
I suppose at a certain point "dd | hd" becomes the obvious solution, <br>
except for the read granularity part (and that's usually going to be <br>
specific registers you're looking at..)<br></blockquote><div>Also we have a potential use-case to access I/O port space in x86 which "dd  | hd" may not help with. 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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
*shrug* Only difference between running it in a shell for loop and <br>
building it in is performance, and nobody's asked for performance...<br>
<br>
Rob<br>
</blockquote></div></div>