Hi Geert,
On Wed, May 23, 2018 at 7:44 PM, Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> 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 -- geert@xxxxxxxxxxxxxx
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
