poke-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] add io space MMAP for memory mapping devices and files


From: Andreas Klinger
Subject: Re: [PATCH] add io space MMAP for memory mapping devices and files
Date: Tue, 2 Jan 2024 19:06:36 +0100

Hello Jose,

"Jose E. Marchesi" <jemarch@gnu.org> schrieb am Di, 02. Jan 18:16:
[...]
> > +  /* Format of handler:
> > +     mmap://BASE/SIZE/FILE-NAME  */
> 
> What about making BASE and SIZE optional, like:
> 
>   mmap://FILE-NAME[/BASE/SIZE]
> 
> If BASE is not specified then it is 0.
> If SIZE is not specified then it is the size of the file.
>
> Similarly in the dot-command:
> 
>   .mmap @var{filename}[, @var{base}, @var{size}]

Yes, I can change this. But it'll be only working for regular files where we can
ask with the stat syscall for the size of the file.

In case of a character device it's not possible to request for the size. I could
use the page size instead as default.

> Speaking of which, have you considered adding a flag (and extra optional
> arguments) to .file instead of introducing a new dot-command .mmap?
> Something like:
> 
>   (poke) .file/m foo.o
>   (poke) .file/m /dev/mem, 0x4804c000, 0x1000
> 
> WDYT?

Yes, I considered it. The reasons why I introduced a new command are:

- from use case perspective the .mmap command is mostly intended to be used
  together with device drivers (with mmap but no read or write operations) where
  there is no solution available at the moment. When using with regular files
  there should not be a difference in the output.

- with the .file implementation mostly stream functions (fread, fwrite, ...) are
  used whereas with the .mmap pure linux syscalls have to be used.

- opening, reading, writing and closing are for the most part different between
  .file and .mmap. There are only small parts in common.

- This means that with a flag solution we'll end up with a huge if-then-else in
  each of these functions, but the synergy is small.

Therefore I think readability is better with a separate command.

Best regards

Andreas

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]