From owner-freebsd-hackers Thu Aug 13 10:19:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA00731 for freebsd-hackers-outgoing; Thu, 13 Aug 1998 10:19:30 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles250.castles.com [208.214.165.250]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA00720 for ; Thu, 13 Aug 1998 10:19:27 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA00818; Thu, 13 Aug 1998 10:17:47 -0700 (PDT) Message-Id: <199808131717.KAA00818@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Karl Pielorz cc: hackers@FreeBSD.ORG Subject: Re: Device / Driver presentation advice needed... In-reply-to: Your message of "Thu, 13 Aug 1998 09:05:06 BST." <35D29E32.81A62F7D@tdx.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Aug 1998 10:17:47 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi All, > > I'm now getting on quite well with the device driver I'm writing, but I'm stuck > as to how best it is to present the 'device' to the outside world... > > If I reserve 3 bits of the minor number to indicate the actual card in the > system, I can then use the remaining 5 bits to give different 'presentations' of > the device (Is this good practice?) It's one way to do it. There is a lot more room in the minor though; 32 bits in fact. > The device in question has 8 x 16 bit input registers. I can either let the > application software select these via ioctl(), or I can use the minor bits to > map out say, > > /dev/daqb0a > /dev/daqb0b > .... > > (With 1 /dev/daqb device for each channel). > > Latency when switching between channels is fairly high (though exactly how high > I haven't measured yet - when you switch channels you have to wait for the > hardware to become ready again) > > Which is the preferred method? - by using the minor bits to map out multiple > devices (one per channel) or by making the application issue ioctl()'s to > control it? - Or is it just a design decision? If the device is slow, and the data rate low, an ioctl-based solution is probably as good as any, and simpler to implement. -- \\ 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-hackers" in the body of the message