From owner-freebsd-arch@FreeBSD.ORG Mon May 13 20:12:02 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BD888803 for ; Mon, 13 May 2013 20:12:02 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 98E1B830 for ; Mon, 13 May 2013 20:12:02 +0000 (UTC) Received: from dhcp-10-2-212-236.hudson-trading.com (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8ECA8B918; Mon, 13 May 2013 16:11:59 -0400 (EDT) Message-ID: <51914914.805@FreeBSD.org> Date: Mon, 13 May 2013 16:12:04 -0400 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Extending MADV_PROTECT References: <201305071433.27993.jhb@freebsd.org> <201305090814.52166.jhb@freebsd.org> <20130509123147.GT3047@kib.kiev.ua> <201305101535.50633.jhb@freebsd.org> <20130511043606.GE3047@kib.kiev.ua> In-Reply-To: <20130511043606.GE3047@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 13 May 2013 16:11:59 -0400 (EDT) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 20:12:02 -0000 On 5/11/13 12:36 AM, Konstantin Belousov wrote: > On Fri, May 10, 2013 at 03:35:50PM -0400, John Baldwin wrote: >> Ok, here is a patch for 8 that reworks this to use a procctl(). If this looks >> reasonable I will port this to HEAD as two pieces: the first to add >> procctl() and the second to add PROCSPROTECT. > > This looks fine. > > Do we need the genericity of the ioctl for procctl ? > Ptrace(2) does not need the size encoded. > > I mean, the call is never marshalled to some unknown driver which needs > a size of parameters unknown to the generic layer. I suppose that all > additions to procctl() would have the size of the control structures > pre-defined. Then, you could just do copyin and, if needed, copyout > discrimating on the command code, and not on the encoding of the size in > the command. > > Also, command could be int and not long then, eliminating the need for > compat32 wrapper. Well, the generic-ness of ioctl() seemed useful to me. Also, I think with this model you could make fo_ioctl() for a process fd just do this: proc_ioctl(..., u_long cmd, caddr_t data) { pid = ; return (kern_procctl(td, P_PID, pid, cmd, data)); } So you could reuse procctl constants as ioctls for proc descriptors. It is true that unlike drivers there is currently no method to provide a "hook" to support new commands (they would just have to be added by hand into sys_process.c for now). Also, if we need to "thunk" structures for compat32 support in the future it is better if the kern_procctl() version takes a KVA rather than a UVA. OTOH, it is more boilerplate code to put in. In terms of a compat32 wrapper: id_t is a uint64_t, so a wrapper would be required regardless. -- John Baldwin