Hi Luke.
>>> 1. You refer to an "NE2000" card. Presumably you're aware that
>>> those normally don't work in an XT as they require an AT style
>>> connector and the similar NE1000 card with its XT style
>>> connector has to be used instead.
> My main concern for development is to have a card which:
> Most people can get hold of, or already have.
I can't speak generally, but certainly in this part of Scotland, and
in the south Lincolnshire area of England, clones of both the NE1000
and NE2000 are easily available. However, according to posts I've seen
on the Linux-Kernel mailing list, NEx000 clone cars are essentially
unknown in the USA, and the varius 3Cxxx cads are the ones that are
easy to get hold of...
> Will work with my hub.
In that case, were you aware of the following:
1. The basic difference between an NE1000 card and an NE2000 card
is that the NE1000 ports have to be read in 8-bit chunks, and
the NE2000 ports normally have to be read in 16-bit chunks.
2. Both NE1000 and NE2000 cards come in thee following varieties
(most of which I have examples of):
1. BNC connector for coax segments at 10 Mbps.
2. RJ45 connector for CAT-5 cable at 10 Mbps.
3. 15-pin D-type connector for whatever suits.
4. Any two of the above, selected by jumpers.
5. Any two of the above, auto-detected.
6. All three of the above, auto-detected.
As a result, your second concern is basically irrelevant.
> An ne1000 driver can be done later, but to make sure that
> everybody can join in for now, the more popular the card the
> better.
That sort of decision appears to be a geographically based one, so may
not produce the result you are expecting...
> To start with, I intend to write the driver, and then some code
> that will tell me when a packet has arrived, if it is for this
> machine, and what protocol it is using. And I'll go from there.
> (I haven't read that far ahead ;-)
Probably a better decision would be to split networking into two
layers, with the upper layer doing everything that can be done without
accessing the card itself, and the lower layer doing only that which
can't be done without accessing the card...
On this basis, the easiest inteerface to implement would be the
loopback interface, which doesn't need any card at all. The low-level
'driver' for it would simply take whatever comes in to it on one side
and return the same as having arrived on the other.
Also, the advantage of splitting the code up as stated is that extra
interface cards can easily be added by just writing the low-level
driver routines, and the high-level routines, if done correctly, will
need no tweaks at all...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
