Date: Tue, 29 Jul 1997 20:44:55 -0700 From: Sean Eric Fagan <sef@Kithrup.COM> To: hackers@freebsd.org Subject: Re: Location of copyin() and copyout().. Message-ID: <199707300344.UAA16264@kithrup.com> In-Reply-To: <199707300310.UAA12221.kithrup.freebsd.hackers@implode.root.com> References: Your message of "Wed, 30 Jul 1997 12:19:48 %2B0930." <199707300249.MAA17292@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199707300310.UAA12221.kithrup.freebsd.hackers@implode.root.com> you write: >If on the other hand you're copying from kernel<->kernel, then you can just >use bcopy. I'm afraid that I started reading this thread rather late into it >and don't have the original context...so what are we talking about? :-) Many kernel functions already use copyin/copyout. Consider fstat(). The last thing it does (before a return) is: error = copyout((caddr_t)&ub, (caddr_t)uap->sb, sizeof (ub)); Now consider ibcs2_fstat(). Rather than duplicate the work of fstat (which would really be a bad thing, because fstat may change and ibcs2_fstat may not be updated), ibcs2_fstat goes through some *HORRIBLE* hacks to allocate some space in user space, using the stackgap_alloc() function. If fstat used uiomove(), then it could go to a kernel address. (Admittedly, it would still have to be changed -- it would have to have a struct uio passed in, probably. But then ibcs2_fstat could call that common function, with less pain.) Mind you, I'm probably not going to stop using copyin()/copyout() myself... but it is something to consider. And it's a valid point. (Unless, of course, you don't think that the emulation support is worthwhile :).) Please let me know if this still isn't clear... I've been working on some other stuff, and am tired, and my explanation ability goes downhill quickly when I'm tired :).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707300344.UAA16264>