Messages in this thread | | | Date | Mon, 21 Sep 1998 15:21:30 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: Linux, UDI and SCO (long). |
| |
On Mon, 21 Sep 1998 kwrohrer@ce.mediaone.net wrote:
> And lo, Stephen Landamore saith unto me: > > > > At the moment, I am doing some driver writing with full cooperation from > > the manufacturer. What happened is that we approached them saying > > something along the lines of: "is a Linux driver available, and if not > > we'll offer to write one". They replied "there isn't, we'd love one but > > we don't have the resources to do it, here's some info, away you go" > > > > I think the key here is enlightenment. These guys are enlightened, one > > of THEIR requirements is that OUR code be GPL'd !!! > Of course. Wouldn't want to not learn from your work (if you're smarter > and/or know Linux better than their people) or not be able to give your > work out if someone else called up and wanted a Linux driver. > > Keith [SNIPPED]
Many manufacturers have to make embarrassing hardware bug-fixes in software. Some (read most) don't properly read or write from memory or ports because they simply decode a PAL, qualifying address/IO/MEM/READ/WRITE, without regard for the 4 states necessary to access an asynchronous bus. The result is that you need to wait 200 or more nanoseconds after an access before you do anything else. This lets the bus glitches settle down. The last device to put its data on the bus does win, however, putting data on the bus before somebody else stops driving it nearly always produces a clash with subsequent transients that have to die down.
Unfortunately, this is the way it's most always done with add-on cards and Software Engineers have to make these hardware errors go away.
I don't think that the "proprietary" nature of many manufacturer's software has anything to do with "Trade Secrets", rather they don't want others to know about their "dirty laundry" so they keep their hardware bug-fixes private.
The BIOS which others have mentioned is a case-in-point. The BIOS was designed so that there was a standardized interface to possibly differing hardware. It has been used, in addition, to mask terrible hardware.
The following is an example of a hardware bug-fix made in software. It is disassembled from a well-known BIOS. Note: The offset is wherever DEBUG loaded the contents of a file. It is not the actual BIOS address which will be in the F000 range.
-u 1328 0B1F:1328 E460 IN AL,60 0B1F:132A E460 IN AL,60 0B1F:132C E460 IN AL,60 0B1F:132E E460 IN AL,60 0B1F:1330 E460 IN AL,60 0B1F:1332 E460 IN AL,60 0B1F:1334 E460 IN AL,60 0B1F:1336 E460 IN AL,60 0B1F:1338 E460 IN AL,60 0B1F:133A 8BC6 MOV AX,SI 0B1F:133C 4E DEC SI 0B1F:133D 0BC0 OR AX,AX 0B1F:133F 75ED JNZ 132E 0B1F:1341 5E POP SI 0B1F:1342 8BE5 MOV SP,BP 0B1F:1344 5D POP BP 0B1F:1345 C20800 RET 0008 -q
As long as we have such atrocious hardware as this, that takes 2700 ns (9 * 300) to recover from a bus operation, there will probably not be any public disclosure available.
Incidentally, one of the things I do for a living is (unfortunately) make otherwise defective hardware "work". It may take 35 to 50 thousand dollars to fix a hardware problem once it's discovered in Production. It takes only a few thousand dollars to fix it in software. Some even think it's free. Software Engineers who know about hardware will always have a job!
If UDI catches on, none of these problems will go away. Instead there will just be more dummy reads, etc., hidden in the code. We had this problem with the DOS NDIS specification of which I was a contributor. The problems with hardware junk are just masked in the code so that, given a standardized interface, the possibility exists for the board to work. This was not the purpose of NDIS. Further, the persons who write such interface drivers are not normally competent.
Disassembly of many NDIS Ethernet Board Drivers discloses code making MS-DOS calls from interrupt-service routines, etc., real garbage that can't possibly work, but simply "function" for a short period of time.
It is much better for someone who is familiar with an OS and the nature of ISRs to write code that will function within that OS. Leaving it to a board manufacturer will most always fail.
Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : Linux version 2.1.118 on an i586 machine (66.15 BogoMips). Warning : It's hard to remain at the trailing edge of technology.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |