On Tue, Oct 29, 2024 at 1:15 PM Rob Landley <r...@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?)
>
> 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.
>
so the reason we're here is really my fault ... what these folks _actually_
wanted was to just keep using https://code.google.com/archive/p/iotools/
but (with my other hat as "new third-party import approver" on) i did my
usual "lol, no" to a project with a dead upstream, and suggested that
toybox devmem was fairly close, and we just need a couple of extra things
(like the ability to choose a file, and the ability to not mmap()).
aiui they did need the ability to have an arbitrary number of
bytes/words/whatever, but no need for multiple [non-consecutive] addresses
in the same command.
> 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
>
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
