> > 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, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
