Messages in this thread | | | Date | Mon, 13 Dec 1999 16:05:57 -0700 | From | Richard Gooch <> | Subject | Re: [patch] fastcall-2.3.32-B6, SYSENTER/SYSEXIT support |
| |
Peter Samuelson writes: > > [me] > > > We are still talking ia32 only, right? Because the SPARC people > > > would *really* have fun with this sort of proposal.... > > [Richard Gooch] > > I don't see why it should be restricted to ia32. The technique can > > just as easily be applied to other CPUs. > > If there are optimized system call paths for other archs that we > might want to make use of. This came out of the discussion of how > to make use of SYSENTER, after all.
It's not just about SYSENTER, though. It's about providing a framework so that each syscall can be optimised in the best way *for that syscall*, yet with a common ABI.
In some cases, a "syscall" won't actually involve a trap to the kernel, such as gettimeofday(). This is something that would benefit other architectures.
> > Why do you say the Sparc people would have fun? Is that "fun, as in > > we can do neat tricks with this", or "fun, as in break out the > > flamethrowers"? > > I was thinking that building the jump table on sparc{,64} would be > complex because of their sparse syscall numbers. On second thought > this wouldn't necessarily be the case.
I'm sure something can be arranged.
> But that brings up an interesting side issue: are we considering > multiple PER_* or just PER_LINUX?
I think PER_LINUX is the important one. Besides, this whole proposal involves changing the ABI, which we can do for PER_LINUX. For other binary formats, we have to stick to their ABI. So I don't see how a jump table would help here.
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |