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/