From owner-freebsd-current Wed Mar 29 10:18:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.cdrom.com (mg134-053.ricochet.net [204.179.134.53]) by hub.freebsd.org (Postfix) with ESMTP id 0A3A237BCE2 for ; Wed, 29 Mar 2000 10:18:13 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA00436; Wed, 29 Mar 2000 10:21:29 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200003291821.KAA00436@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "David E. Cross" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Major # please :) In-reply-to: Your message of "Tue, 28 Mar 2000 20:42:51 EST." <200003290154.UAA87769@cs.rpi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Mar 2000 10:21:28 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Meaning no offense, but I can't think of a single good reason to write a > > device driver for one of these cards. (Unless you're trying to do > > pattern generation, and an 8255 is a terrible choice for that.) Worse > > than that though, there's _no_ standard for these cards' implementation, > > so a driver isn't going to be even vageuly portable. > > > > Use i386_set_ioperm() and just bit-bash it in userspace. > > The bit-bashing in userspace will make this even less portable. The idea is > liked by those around here of being able to do a 'set register 0', or > 'clear register 0' with an ioctl() and leaving the implementation to > "something else", which can key on what type of board it is and DtRT. It hardly matters whether this interface is abstracted across the kernel:userland boundary, or just somewhere within your application, eg. using a shared library. > Also, how would you trap interrupts from such a card (for when using it as > a digital input) from userland? Typically these cards don't offer interrupt generation. Iff your application is for a card that generates interrupts, and you actually need them (as opposed to being able to poll the card) then writing a tiny KLD driver is probably worthwhile for your application. > Since it is already written, and in operation. Unless we are low on major > numbers, or this could be better merged with another interface, it seems to > be a waste to not give it a major number. Bringing it into the base CVS > tree is another question entirely, but it would appear at least one has > already expressed an interest. We don't, typically, hand out major numbers for drivers that aren't part of the base system. There are 56 entries in the 200-255 range that are all available for use by deployed-but-local drivers; I'd recommend using one of those. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message