> > I was under the impression that this was a no-no & one should use
> > copyin/copout & friends to access memory on users's stacks. Although
> > this appears to work on the i386, if I try this on the alpha I take a
> > fatal trap when accessing *set.
> >
> > So -- how does this work on the i386? Is the user's stack always
> > mappeped into the kernel's address space? Should it also work on the
> > alpha?
> >
> On i386, under the current implementation, the kernel can directly access
> curproc's address space (not just the stack, stack is used because we're
> sure the spare space won't/shouldn't be used by the user application).
> I don't know if the same is true for alpha, but this should definitely
> be considered an implementation dependent feature. I wish there were some
> other ways to bypass copyin/out in ioctls.
The problem wouldn't be a problem if the implementation portion of system
call code didn't make assumptions about whether data is in user- or
kernel-space. This has been an off and on topic of discussion for some
time now.
The ABI emulators use the stackgap because there are system call
implementations that expect to be moving their data structures to/from
user space. 8(
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
