Extending MADV_PROTECT

[Konstantin Belousov]

On Mon, May 13, 2013 at 04:12:04PM -0400, John Baldwin wrote:
> On 5/11/13 12:36 AM, Konstantin Belousov wrote:
> > 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 = <get pid from f_data>;
> 	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.
Yes, I just do not see much need in it, but this is your call, finally.

> 
> In terms of a compat32 wrapper: id_t is a uint64_t, so a wrapper would
> be required regardless.
> 
> -- 
> John Baldwin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130514/12931794/attachment.sig>