Date: Sun, 8 Jan 95 14:58:27 MST From: terry@cs.weber.edu (Terry Lambert) To: hsu@cs.hut.fi Cc: freebsd-hackers@freefall.cdrom.com Subject: Re: Porting cyclades driver; sigh Message-ID: <9501082158.AA28603@cs.weber.edu> In-Reply-To: <199501071844.UAA06214@smile.clinet.fi> from "Heikki Suonsivu" at Jan 7, 95 08:44:24 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Odd ones: NetBSD ttioctl has got struct proc * as its last argument; when > did this hop in NetBSD, or outa FreeBSD? Is it necessary? Well, I just > #ifdef it out for now and see how it explodes. I have looked at this code, and don't understand it either. I have a theory, but it depends on an extremely partial move, which is actually probably not the correct move. Hopefully, there are still NetBSD listeners on the list that can say "no, Terry, you fool, it's this...", or confirm or deny or otherwise provide input. The current proc might be necessary if you expected a kernel thread context switch in the middle of processing the ioctl. I don't see how this could actually happen given the rest of the code the way it is. Typically, you'd do this if you wanted to get data from the process address space for arguments that would occur after a long duration event has been satified subsequent to the context switch. In reality, this implementation can only interfere with an Xkernel/Streams based tty driver; on the other hand, they may not consider this something they want to do anyway, so it would be OK. The alternate implementation would be to copy the arguments down at the interface level, and never use the curproc after that. Since the return path must be through the same system call that got the process into the kernel, copyout could occur all at return time. There *is* a potential for saving several internal data copies if the ioctl went directly into and out of user space... this might be what they are trying to do. Since this is all predicated on a multithreaded/MP kernel and a particular approach to saving copies, I'd have to submit that this whole idea is probably not what they are doing... or if it is, it's a work-in-progress, since the per process open file table and other simple per-process structures that would be affected by kernel multithreading are still "broken" for that application in both BSD's. One final alternative may be a multiport driver binary compatability interface for BSDi drivers. I've talked about doing this for SCO drivers, and if this is it, it's extremely desirable, and ought to be migrated to FreeBSD as soon as possible. This condemning something because of its origin (note: NOT because of licensing -- that's perfectly reasonable to do) has got to stop. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9501082158.AA28603>