Date: Wed, 22 Jul 1998 14:55:55 -1000 From: "Randal S. Masutani" <randal@comtest.com> To: Mike Smith <mike@smith.net.au> Cc: Peter Dufault <dufault@hda.com>, john@ece.arizona.edu (John Galbraith), FreeBSD-hardware@FreeBSD.ORG Subject: Re: GPIB drivers? Message-ID: <199807230102.PAA23783@oldyeller.comtest.com> In-Reply-To: <199807230007.RAA02391@dingo.cdrom.com> References: Your message of "Wed, 22 Jul 1998 12:12:00 -1000." <199807222218.MAA23397@oldyeller.comtest.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 Jul 98, at 17:07, Mike Smith wrote: > > Freds driver is using copyin/copyout in the ioctl(). > > So is this bad to do this(copyin/out) here? > > It's bad insofar as using ioctl() for data transfer is generally > considered the wrong way to do it. You should be using read and write > to do data transfer. If not for data transfer how about configuring the driver settings like; timeout, bus timing, end of line char,...? > > case GPIBWRITE: > > error=copyin(gd->count,&count,sizeof(count)); > > if (error!=0) return(error); > > This should use fuword() I checked the fuword() manpage sound good. I guess i could use also suword() to return values to userspace? > > The standard read/write calls are using uiomove(). > > ... which is how IMHO it should be done. > > > I am not familiar with these issues but the driver does work. Why is bad > > to use copyin/out vs. uiomove? I would appreciate any input. > > copyin/out precludes calling the driver from elsewhere within the > kernel, and if you use it in a read/write/strategy routine, it means > you can't handle readv/writev easily. (The latter are a godsend if > you're trying to do scatter-gather style I/O). Not familiar with this (scatter-gather)concept, something I should learn? > The real problem is that GPIB is a bus, not a device. The GPIB driver > should be a bus controller, not a device, and it should have multiple > instances of a peripheral driver hung off it (one for each device on > the bus). > > You'd then open each peripheral and implicitly anything you wrote to/ > read from that peripheral would go to the device in question. > > This would make it much cleaner, eg. to support multiple processes > talking to multiple devices on the bus, as well as to embed some > intelligence into the kernel for some devices. You said it. That is exactly how I would like it to be done. I do have plans to make the application multi-treaded. My client does want to control several devices from multiple processes. I didn't mention this before because I was trying to do one step at a time, but I guess I just have to rewrite the whole driver from the beginning to do something like this. > > Compare GPIB to SCSI, if you like, for an idea as to what I mean. Randal ------------------------------------------------------------------------- ComTest Technologies, Inc. 3049 Ualena St., Suite 1005 Honolulu, Hawaii 96819 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807230102.PAA23783>