Date: Thu, 23 Jul 1998 09:49:21 -0700 From: Mike Smith <mike@smith.net.au> To: john@ece.arizona.edu (John Galbraith) Cc: randal@comtest.com, dufault@hda.com, FreeBSD-hardware@FreeBSD.ORG Subject: Re: new GPIB driver Message-ID: <199807231649.JAA03068@antipodes.cdrom.com> In-Reply-To: Your message of "Thu, 23 Jul 1998 09:21:03 PDT." <199807231621.JAA10487@burdell.ece.arizona.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> >>>>> "Mike" == Mike Smith <mike@smith.net.au> writes: > > Mike> I don't like this at all (as I pointed out to Randal). GPIB > Mike> is a bus, and it should be treated like one. The GBIB > Mike> driver should provide GPIB I/O services to a set of > Mike> peripheral drivers (consider SCSI as an example). ioctl() > Mike> is not good for I/O. > > OK, I might take another shot at this. I do see your point. I will > try using the lower 5 bits of the minor number as the GPIB address > (with the 32 address being some sort of "global" control device?). > Bits above that will encode the card. Any flaws with this idea? If you're going to have the GPIB driver do everything, then that's probably OK. (Is there some sort of 'extended' addressing scheme that lets you put more than 31 devices on the bus? If so, save more room for the address; there's lots of room in the minor). > I am not very familiar with the SCSI driver. (I just got my first > SCSI machine ever a month ago - I like it, too). But now that you > mention it, I see that GPIB is set up the same way with the bus > controller and then any of a multitude of possible devices can be > hooked up to it. > > I think that the peripheral drivers should be implemented in userland, > IMHO. Would there be any advantages to those being in the kernel? Yes; not least the ability to export a GPIB-specific API between the GPIB and peripheral driver, as well as the ability to implement callbacks (the GPIB driver calls the peripheral driver instead of the other way around), which would be useful eg. for the system running in listener rather than talker mode. If you have a -current system (or just browse the relevant bits via FTP) have a look at how the 'ppbus' stuff works. There's an ISA driver that handles talking to the parallel port, and it exports an API up to the generic ppbus code, which in turn exports a completely hardware independant API to the peripheral drivers. IMHO this is how GPIB "should" be done; it means that writing a driver for a new card becomes nothing more than matching the established hardware<->gbpibbus API. > This is really great getting feedback from you guys - let me know any > other suggestions or concerns you might have. As I said to Randall, I think the first thing to do is to get your current, more-or-less Cawthorne-compatible driver out and being tested. This'll help Randal out, as well as help you iron out any problems in your TNT code, etc. Once that's looking good, you can attack the busification happy that the hardware will behave. If you want more input, just keeping asking. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199807231649.JAA03068>