Re: [patch] fastcall-2.3.32-B6, SYSENTER/SYSEXIT support

Richard Gooch (rgooch@ras.ucalgary.ca)
Sun, 12 Dec 1999 12:08:59 -0700

Artur Skawina writes:
> Richard Gooch wrote:
> >
> > I'm happy with the page mapping idea, but what concerns me is that we
> > can end up with a kernel which has a fair bit of code data embedded in
> > it, due to the increasing number of syscall instructions. Even if it's
> > contained in __init sections, it still bloats the kernel image. This
> > is a particular problem with embedded systems. Config options will
> > help here, but we have too many of those already.
>
> hmm, i can't see this taking more that a few hundred bytes. it's not
> like every syscall would need a special entry point, and every one
> of them would be in a dozen versions.
> What was proposed so far wouldn't involve more than having a pair of
> very simple ("lea 4(%esp),%ebp;sysenter"-type) sequences, possibly
> in two or three versions, plus a small routine for really special
> cases (gettimeofday).

If the end result costs us an extra page in an __init section, I won't
care. Not having seen a patch posted, I can't see how much space this
will take up. I may be worrying about nothing.

Actually, I suppose this is where Linus' syscall classes may come into
play. It's not something user-space should care about (referring back
to my jump table proposal), but it can make it easy for the kernel to
populate the jump table with a minimum of code.

For each syscall class and each implementation/CPU type, a function
can be called to populate N entries in the jump table. So with 3
classes and maybe 4 implementation/CPU types (I hope this is being
pessimistic), we have 12 functions in an __init section.

OK, I'm feeling much better about the whole idea. It looks like it
won't cause much bloat after all.

Linus: what do you think about the jump table idea? I really think
that user-space shouldn't have to worry about syscall classes. All
syscalls should have the same interface. It may not be as totally
optimised as some other proposals, but it should be close (within a
few cycles). And it's a lot simpler and cleaner, while still giving us
full flexibilty with the same ABI for all time.

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/