> 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/