On Tue, 26 Jun 2012 18:14:39 +0000 (UTC), Thorsten Glaser <t...@mirbsd.de> wrote: > Mikael Pettersson dixit: > > >- having a vsyscall page at a fixed location (vdso is too horrible), and > >- updating a long word in it in each switch_to() > > sounds ok to me > > >- SMP is initially prohibited, the get_thread_area entry needs to be a > > proper function, so that a future SMP-capable system can be allowed, > > Do we need *MP on m68k at all?
Depends on your perspective. I know commonly available HW isn't SMP, but the architecture is SMP-capable, there have been some MP machines (DIAB produced some with 030 and 040, and I've seen VMEbus boards with dual 040 or 060). And a dual or quad core m68k for an FPGA should be doable given that both single-core m68k and multi-core non-m68k FPGAs already exist. I'm not suggesting that SMP HW will be available any time soon, but I'd rather keep the option open than design an ABI that cannot work at all in such a system. The get_thread_area vsyscall would still be orders of magnitude faster than the current syscall. > >I could probably implement something like that, but I'm not sure how > >the kernel maintainers would feel about a per-process vsyscall page... > > Not a kernel maintainer, but isn't that the whole point, to have the > page per-process so no kernel mode round-trips are required? Yes, but there's also a cost in that there's one more store on every context switch, and every page table must have one additional entry. Security-centric people dislike vsyscall pages and prefer vdsos since their address-space placements can be randomized, but that also makes vdsos slower to access. /Mikael -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20458.50642.999507.376...@pilspetsen.it.uu.se
