Hi Geert,
On Wed, May 23, 2018 at 7:44 PM, Geert Uytterhoeven
<[email protected]> wrote:
>>> At first sight (and looking in full-history-linux git history), I see no
>>> reason for the gap. I'd assume having a block with address and size aligned
>>> to 256 KiB (which the caller already takes care of: IO_SIZE is 256 KiB if
>>> 020/030 support is enabled) should be sufficient to use early termination
>>> tables.
>>
>> My guess is that someone wanted to catch out of bounds accesses by
>> leaving the unmapped areas in between ioremapped 256 kB chunks. The
>> unmapped gaps must 256 kB as well to avoid disturbing the alignment.
>>
>> The adjustment for gap size was dropped sometime between 2.4.30 and
>> 2.6.18. At the same time, a comment in get_io_area was removed that
>> stated 'leave a gap of IO_SIZE'. I haven't looked at the full history to
>> find out who removed that comment (and the adjustment).
>
> I can't seem to find the addition/removal of that comment (checked
> full-history-linux and the old m68k-linux CVS)?
Part of the problem may be that kmap.c was moved a few times during
integration of the nommu port.
I happen to have a few old kernel trees around that I can consult for
a rough history, and 2.4.30 still has the comment while 2.6.18 or
2.6.19 lost it.
Where is the old CVS hosted these days?
Cheers,
Michael
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> [email protected]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
