[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [patch] fastcall-2.3.32-B6, SYSENTER/SYSEXIT support
From:       Richard Gooch <rgooch () ras ! ucalgary ! ca>
Date:       1999-12-12 18:51:26
[Download RAW message or body]

Kai Henningsen writes:
> rgooch@ras.ucalgary.ca (Richard Gooch)  wrote on 12.12.99 in \
> <199912120704.AAA12363@vindaloo.ras.ucalgary.ca>: 
> > I propose a much simpler abstraction: set up a global page (which
> > always appears at a fixed address in user-space), and set up a jump
> > table. Have one jump vector per system call. That's the ABI. End of
> > story.
> 
> I really like that.

Thanks.

> > So I suggest a few possibilities for working around this:
> > 
> > 1) the kernel reserves a page (or pages) which is mapped into each
> > process at the same VA, but is written to by user-space. Perhaps a
> > syscall/ioctl to write-protect the region once initialised
> > 
> > 2) have a single module which contains all the code data variants and
> > writes the appropriate selection to the global page(s)
> > 
> > 3) have a collection of modules, one for each CPU (implementation)
> > type, and user-space picks the correct one to load. The module
> > initialises the global page.
> 
> All of these share a serious problem: they depend on userspace code
> to initialize the userspace-kernel interface.

I know: I listed this as one of the disadvantages.

> That means you need a _different_ userspace-kernel interface just so
> these solutions can be made to work.

Yeah, the standard syscall interface, as I mentioned. This isn't so
bad, as we need to support the standard interface for a long time
anyway. Otherwise we break binary compatibility for *everything*.
Red rag to David Parsons ;->

> This is madness.

I wouldn't go quite that far.

> Now, you could go around this by having the kernel put default code
> there that's exchanged during boot - but it still seems to me it's
> far better to just have the kernel do the right thing from the
> start.

Yeah, I agree it's not as clean as the kernel doing it. I don't really
like any of the three options I presented. I'm just tossing out ideas.

				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/


[prev in list] [next in list] [prev in thread] [next in thread]