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

[Jose E. Marchesi]

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

Sounds like using mmap actually requires having a good idea of the range
to access in the file.  If calculating a reasonable default for the size
is as complicated or arbitrary as you describe, it is better to not have
defaults for them.

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

These are compelling reasons.  I agree.
Thanks for explaining.