Re: Major # please :)
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
Re: Major # please :)
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. I am just about finished with a device driver for PCI DIO boards based around the 8C255 (number may be wrong ;). Specifically this is for the ComputerBoards DIO-24H DIO board. I have been using the 'development' major #, and I am ready to go about getting it committed into the CVS tree for whoever else may find it of use. Currently the system is used in conjunction with a home-brew card-access system, but future could include robotics and related fields. -- \\ 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
Re: Major # please :)
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. Also, how would you trap interrupts from such a card (for when using it as a digital input) from userland? 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. BTW: the URL for the card that was given to me for this project is at: http://www.computerboards.com/cbicatalog/cbiproduct.asp?dept%5Fid=224pf%5Fid=668mscssid=50A6V97GWTSH2J6N000JU4JKRUFAAEGB Product descriptions and a technical manual are linked from that page. -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
