> Then you really need to do this on the devvp branch. It's the one that has
> support for cloning devices.

I'm affraid that the devvp branch will not solve all the problems I have
with IRIX /dev/usemaclone emulation. Apart from the cloning device
problem, I also have to handle:

1) non standard ioctl handing: most ioctl on /dev/usemaclone are defined
as plain _IO (not R, not W), but they do use the data argument: they are
really _IOR. I have to write a special handling in irix_sys_ioctl, which
will directly call the driver method without going through sys_ioctl.

2) one ioctl sets the return value. I can workaround this by setting
data to a place in the stackgap, in irix_sys_ioctl, then copying the
return value to the place pointed by data in the stackgap in the ioctl
method, then getting in from the stackgap when I'm back in
irix_sys_ioctl and set retval. Of course this remains simple because
this ioctl does not uses data in IRIX.

3) libc does a fchmod on /dev/usemaclone once it is open. The operation
will fail because root owns the device, but on IRIX, fchmod will return
0. libc expects this behavior and the program will fail if it is not
properly emulated. I therefore have to overload the setattr vnode
operation.

Problems #1 and #2 are orthogonal to the cloning device problem. Problem
#3 forces me to define a new vnode vector anyway, whether if I use devvp
or not. Except if someone has a better idea on how to handle this.

-- 
Emmanuel Dreyfus.  
Hiroshima 45. Tchernobyl 86. Windows 95. 
manu@netbsd.org