[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ethernet card?



In our last episode, dempson@actrix.gen.nz (David Empson) said:

>Do you mean random garbage or consistent garbage?  If it is random, then
>it will probably not be possible to use this - another driver might
>claim it if it ever reported that it was a hard drive.

It's definitely not type "disk" or "tape" or anything else standard. I
think, in fact, that it may not be garbage per se after all - it may be
a vendor specific type. As I note, the device predates SCSI-II, and there
was no comm type then, so this seems likely. I should have a better idea of
this when I can get a look at it from Linux. The comment field is garbage,
but I think it's consistent at least, which does give the driver something
to work with if the device is simply "unknown".

There are other SCSI-ethernet adaptors out there, and some are probably
more compliant to the newer standard. All will probably require separate
drivers, though. A layered driver approach might be good for this, since the
ethernet half could conceivably be reused and a separate SCSI driver written
for each device. A chance exists to design a novel API between the two. ;)

>If it is consistent (but undocumented) then the SCSI Mangaer may report
>it as an "unknown" device.  The device driver could claim all unknown
>devices then do SCSI I/O calls to get more specific information, and
>un-claim devices which turn out to be something else.

Makes sense.

>Apple had implemented support for their EtherTalk card in System 6.0.1,
>and 6.0.1 was shipped with this support included, with the exception of
>the actual device driver and the modified "Network" control panel which
>would have allowed selecting between LocalTalk and EtherTalk.

Another thing that would have to be written.

>If you wanted to support protocols other than AppleTalk, it would be
>necessary to include some kind of low-level protocol routing facility,
>which would identify which protocol stack was to be used for each
>incoming packet.  A totally different protocol stack mechanism would be
>needed for TCP/IP support.

Certainly a lot more work, but I do think it would be better (for someone)
to do this than it would be to hardwire it for TCP/IP support. But it's
basically programming a big chunk of operating system to do it.

I assume Derek Taubert must have written GSOS drivers for his adapted ISA
ethernet cards; these might be useful at least for the ethernet half of
things on the GS.

-- 
Marc Sira			   |
{ub675,toh}@freenet.victoria.bc.ca | "Your god drinks...p-p-peach nectar!"
{aa,xx}382@freenet.carleton.ca	   '