From owner-freebsd-hackers Sun Oct 19 07:16:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA07997 for hackers-outgoing; Sun, 19 Oct 1997 07:16:09 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA07991 for ; Sun, 19 Oct 1997 07:16:03 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id XAA00268; Sun, 19 Oct 1997 23:41:20 +0930 (CST) Message-Id: <199710191411.XAA00268@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jamil J. Weatherbee" cc: Mike Smith , Peter Dufault , freebsd-hackers@FreeBSD.ORG Subject: Re: Opinions wanted. In-reply-to: Your message of "Sun, 19 Oct 1997 01:28:22 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Oct 1997 23:41:18 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >>>> If an 8255 (digital I/O) 8-bit port is opened via open() call by the user >>>> as O_RDWR then it becomes an output, >> >> It makes little sense to model the 8255 like this. It would be much >> more sensible to allow open/close and require an ioctl to provide >> register access. > > I would have to disagree with this, here's how I have it configure itself. > > O_RDWR or O_WRONLY makes it an output > O_RDONLY makes it an input I'll reiterate the point, and clarify. It makes little sense to model the 8255 like this, as it is prohibitively restrictive. Each of ports A and B are split in half, and each half can be configured for input or output. You don't make allowance for this mode of operation. You also don't provide for use of the bit-port operations on port C. It makes little sense to model the port like this. If it's worth anything, I have been down this road a number of times with different I/O parts (8255, Z8536, AM29???) and every time the optimal solution has been either a driver which addresses the operational mode of the hardware on the other side of the device, or straight user-mode I/O. > I have completed my work and debugged it (it took much > longer than expected). I would now like to request to have some kernel > type person look at it and tell me if I have major league screwed up > anything (it works fine in all my tests). If it's only going to be used for your application, the fact that it works for you is probably enough. If you're aiming for mainstream integration, you've got a lot more ground to cover. 8) mike