From owner-cvs-src@FreeBSD.ORG Tue Jun 17 19:55:40 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 920EC37B401; Tue, 17 Jun 2003 19:55:40 -0700 (PDT) Received: from nemesis.lonestar.org (nemesis.lonestar.org [204.178.74.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7B7F43FE9; Tue, 17 Jun 2003 19:55:39 -0700 (PDT) (envelope-from uhclem@nemesis.lonestar.org) Received: from localhost (6428 bytes) by nemesis.lonestar.org via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident using unix) id for ; Tue, 17 Jun 2003 21:55:31 -0500 (CDT) (Smail-3.2.0.111 2000-Feb-17 #17 built 2003-Jan-8) Message-Id: Date: Tue, 17 Jun 2003 21:55:31 -0500 (CDT) To: mdodd@FreeBSD.ORG From: uhclem@freebsd.org (Frank Durda IV) Sent: Tue Jun 17 2003, 21:55:31 CDT cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: nyan@jp.FreeBSD.org cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/matcd creativeif.h matcd.c matcd_data.h matcd_isa.c matcddrv.h options.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2003 02:55:41 -0000 [-]Please use the bus_space staff. [0]On Tue, 17 Jun 2003, Frank Durda IV wrote: [0]And on what company/school staff would this person be on? [0]Please elaborate. In the dimmness of the morning, the use of "staff" (apparently in place of "stuff") was why I was asking for clarification of the terse statement. I suppose I should have assumed staff==stuff, but you never know for sure. This resulted in additional traffic: [1]mdodd@FreeBSD.ORG writes: [1]inb()/outb() are not portable. Their use here doesn't need to be, for hardware like this that only exists in the Intel PC world, and as far as I know, only in the ISA world. No PCI cards exist with this interface that I'm aware of, at least not from Creative Labs the main seller of these drives. [1]mdodd@FreeBSD.ORG continues: [1]FreeBSD uses a mechanism borrowed from [1]NetBSD that hides the platform specifics behind a common API. [1] [1]See mcd(4) and scd(4) for example. As to mcd/scd happening to know about these calls you mention, drivers I did review back in December, but the actual call to these functions is hidden behind a further macro within MCD, which at the time I assumed bottomed-out into an inb/outb inline somewhere. I guess I should have chased MCD_WRITE and MCD_READ down on the off chance that someone had changed this hardware access method actually being used. In any event, had I known about this back in January/February despite the lack of documentation back then (and apparently still none except in another operating system), documentation which would hopefully indicate that these calls absolutely positively did not have any artifacts or behavior outside of generating an IN or OUT operation to the appropriate port, AND that they were globally available AND that they were the preferred method for doing I/O over inb()/outb() that was used for the previous twenty plus years, had this been documented, I probably would have switched at that point. I should mention that the Matsushita hardware is timing-picky on certain things and if you noticed the use of inb/outb (as was used by this driver in 2.1.5 thru 4.x releases with no complaint before now), you should have also noticed that I have to disable all interrupts while issuing commands to ensure the timing is achieved. Switching to a far more convoluted way to just do an IN or OUT BYTE instruction on Intel platform (the only thing the host adapters were ever made for) is a potential failure point, and smells like a bloater. After spending days trying to figure out the mechanisms surrounding the sc->port_bst/bsh STUFF in order to get anything working earlier in this project (90% of the time was spent just figuring out how hint port and other values reach drivers now so probe/attach would work again), the lack of a man page for bus_space_read/bus_space_write and friends in my opinion all tend to make people use as few of the such calls as possible. Honestly, I found that quite enough deck chairs had been randomly re-arranged and then not documented in the driver to kernel interfaces (an interface that stayed largely unchanged in BSD for the first twenty years or so) to make this effort consume large quantities of time, far more than it should have done. And of course the biggie: As inb/outb macros still work on the target hardware and processor, and work as they did in the previous life of this driver, so why dump success? Why even scout around on the off chance that using inb/outb is not the preferred way to do things any more? I don't usually go looking in dark alleys to see if any have muggers. The requirements set forth back in December by the mailing list were simple: 1. Change the license agreement on the code so it is liked. 2. Make the code compile without warnings. Here we are. No one really asked that driver actually function or for the documentation to be updated, but I assumed that part... :-) Hmm. I just re-confirmed that GCC still sticks the inb/outb opcode inline in the code at the appropriate place in the assembler/object just like it used to. That's important to this driver, because it means no non-specified or concealed branching, no pushing parms on stacks, no possible faulty processor serialization/parallelization assumptions, no calls or returns with their timing or trap penalties, and no possible loss of processor (assuming disable_intr/enable_intr really disables interrupts at least as well as spl(7) used to), any or all of which could cause this driver to not be able to control the hardware. This is a piece of hardware was designed for the single-task, 100% dedicated CPU you had in the MS-DOS world, not the multi-tasking or even multi-processor environment we have here. Still, by careful management of I/O and processor distractions, matcd works quite nicely without permanently hogging the/a processor, and has been tested on quite slow one and two-processor configurations, where most ISA-based systems live. By all means, do document these substitute I/O calls you mention, detailing any timing/interrupt aspects that arise from their use (and how to avoid them when using the preferred scheme) when compared to a good old (and predictable) inline inb/outb/inw/outw opcodes. Such documention covering these points up would certainly increase the basic awareness of these functions, and explain their pitfalls, if any. I'll be happy to experiment with this alternate method, but would rather wait until detailed documentation appears on their use and side-effect potentials. If things look and test out safe, I'll switch. Frank Durda IV |"You didn't see the notice about the or | rule change? It is on display That Anti-spam address expires Jun 30th | in a locked filing cabinet in a http://nemesis.lonestar.org | disused bathroom in the basement Copr. 2003, ask before reprinting. | with a sign on the door saying..."