I don't know what else to tell you. They really do suck. Trap-gates are faster and safer. Call-gates are... prettier, more elegant.
Have a look at Linux 2.0 implementation. You'lll see an interrupt handler copying registers to the stack, and *then* invoking the call gate. So basically, doubling the work. And no, interrupts are not safer, as they don't provide stack isolation. This is done *manually* in the Linux implementation.
It's probably much a much narrower/null lead these days with massive caches, but back in 98, it was serious business.
I seriously doubt that. I was working extensively with x86 assembly in 98, and actually implemented call-gate systems in some of my pet projects. Granted, they were pet projects, not a mainstream piece of OSS, but I don't share that experience.
he various kernel mailing lists are abound with discussions on people wanting to try out call-gates, and finding out that *they suck*.
AFAIK, the implementation 2.0/2.2 still uses a call gate. Not directly, but inside the IV.
Also, SYSENTER wasn't switched to until we ran into the P4's massive pipeline stall on trap-gates, which the AMD K6 did *not* exhibit. It wasn't a fundamental problem with the trap-gate itself, but a quirk of the Netburst architecture.
It is a fundamental problem with the trap gate. The pipeline size and the agressive branch prediction mechanism only made it worse. Shorter pipelines don't suffer as much, as they are faster to clean and less prone to stupid execution stalls. Also, there was a huge amount of optimization done on silicon for this since 32 bit operating systems using interrupts became mainstream, and the same can't be said for the architecturally complex call-gate solution. SYSENTER simplifies a lot, but performs basically the same task as a call gate.
The fact that the unices/dos used entry 0x80 in the IDT, and NT used 0x2e, and 95 used 0x30, with call-gates to VxD code (eventually gotten rid of) doesn't mean the methodology of the trap was what was inherited
Actually, the fact that many other architectures do not provide any other user-defined global entry point besides the interrupt table has a huge weight in it; I don't see any problem with the metodology, if you're implementing a portable system. I see problems with a specific implementation of it on an operating system designed from the ground up for x86, and one of those problems is that whoever implemented it clearly had no clue about how it worked.