Re: bsd/linux ioctl.

2011-04-26 Thread Alexander Leidinger


Quoting Julian Elischer jul...@freebsd.org (from Fri, 22 Apr 2011  
18:28:06 -0700):


[linux ioctl compatibility]

So my first question is is this hack commonly known?
and secondly should we clean it up and put it in an ioctl(9) man page?

We should probably have such a page.  Do we have a driver porter's handbook?
a quick look failed to find any mention of this in any documentation.


The closest I can come up with regarding some Linux-FreeBSD porting is
  http://wiki.freebsd.org/AvoidingLinuxisms

It's not really what you asked for, but it's somewhat related.

Bye,
Alexander.

--
DEADWOOD:
Anyone in your company who is more senior than you are.

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


bsd/linux ioctl.

2011-04-22 Thread Julian Elischer
So at work (fusion-io)  we have a driver that runs on lots of OS, 
including FreeBSD

(hint: ask your fio sales rep, it's not on the website!).

But as usual the BSD way of doing the copy in and out of user space 
caused lots of grief.

Then suddenly I heard it was solved and I thought nothing more of it..

The following comment comes from the FreeBSD 'wrapper' in the driver,
talking about the ioctl code..

 /* Define dir as void in FreeBSD to prevent*/
 /* kernel from copying ioctl arguments in and  */
 /* out automatically. The driver expects to*/
 /* deal with copying itself. We also need to   */
 /* specify zero as a argument size to force*/
 /* generic IOCL code in kernel pointer to give */
 /* us the raw userland pointer unchanged.  */


So I never actually read this code before so my first reaction
was hmm that's neat, a cool workaround for people who want linux
or SysV compat ioctl behavior

So my first question is is this hack commonly known?
and secondly should we clean it up and put it in an ioctl(9) man page?

We should probably have such a page.  Do we have a driver porter's 
handbook?

a quick look failed to find any mention of this in any documentation.

Looking at ioctl we can see how this works:

Also see that because we force the size to be 0 or sizeof(int),
the driver has to know the size and can not do a size based version 
check as is sometimes done.


It seems a pity to force the size and direction information to be lost.
is it really necessary? It seems to me that we could still allow current
behaviour but allow this information through by testing for IOC_VOID 
in a few more places

and switching some of the tests around a bit..

from ioctl()

size = IOCPARM_LEN(com);
if ((size  IOCPARM_MAX) ||
((com  (IOC_VOID  | IOC_IN | IOC_OUT)) == 0) ||
#if defined(COMPAT_FREEBSD5) || defined(COMPAT_FREEBSD4) || 
defined(COMPAT_43)

((com  IOC_OUT)  size == 0) ||
#else
((com  (IOC_IN | IOC_OUT))  size == 0) ||
#endif
((com  IOC_VOID)  size  0  size != sizeof(int)))
return (ENOTTY);


if (size  0) {
if (com  IOC_VOID) {
/* Integer argument. */
arg = (intptr_t)uap-data;
data = (void *)arg;
size = 0;
} else
data = malloc((u_long)size, M_IOCTLOPS, 
M_WAITOK);

} else
data = (void *)uap-data;
if (com  IOC_IN) {
error = copyin(uap-data, data, (u_int)size);
if (error) {
if (size  0)
free(data, M_IOCTLOPS);
return (error);
}
} else if (com  IOC_OUT) {
/*
 * Zero the buffer so the user always
 * gets back something deterministic.
 */
bzero(data, size);
}
 [...]



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org