[Toybox] [PATCH] Support non memory mapped access

[Karthik Ramasubramanian]

On Tue, Oct 29, 2024 at 10:15 AM Rob Landley <rob at landley.net> wrote:

> 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?)
>
Yes, we have to introduce an optional "-n"  parameter to indicate the
number of bytes/words/doublewords to be accessed.

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


> *shrug* Only difference between running it in a shell for loop and
> building it in is performance, and nobody's asked for performance...
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20241101/dfb144a8/attachment.htm>