2 NICs with Minix3?
AntoineLeca
Meilleurs vœux, Feliz año nuevo, Happy New Year,
I am trying to better understand how Minix networking works.
Specifically, to deal with the xx_table array which keeps the status
of each adapter.
Right now most drivers uses only 1 "port", probably to spare memory
(which was short on the original Minix-86.) The exceptions are the
original dp8390 (up to 3 ports) and the lance driver (up to 2 ports).
I should also add that Minix-vmd used more "ports" for the same
drivers, so "port" would indeed mean adapter (or MAC, media access
controller, a.k.a. "the chip"), and does not mean PHY (what links to
the RJ45 connector, to make it clear; so a typical switch might have
8/16/24 ports, PHYs, but only one adapter, one network chip.) Also
worth remembering here is that with Minix2/vmd all the drivers were in
the kernel, thus statically allocated before booting, while in Minix3
model they are more independant.
I have set up a virtual VMWare machine with 2 cards (this is OK), then
activated two "lance" ports (eth0 and eth1) at inet.conf, but chaos
followed. :-(
Then I went a bit back, and recompiled the rtl8139 network driver to
have two ports (increasing stack to 128kw), while still having only
one eth0 adapter in inet.conf: result under qemu was not prettier,
including syslib panic and PCI which returned -16... :-O
So I am wondering if the networking code presently can sustain more
than one "port"/adapter (of then same driver, of course);
And more generally how it is envisionned in the Minix 3 context?
I also have a proposed, alternative, design: I assume it should be
possible to start as much driver/service as one wants. I would then
expect each driver to service just one adapter, and let the
infrastructure launch two (or more) instances of the driver if need
arise, passing arguments to let them distinguish between themselves
and driving only one hardware chip each one.
Of course, this is very close to the present at_wini driver design,
where one instance is launched for each IDE controller (with its own
two "ports", master and slave, which are sharing resources; the sad
truth is that src/drivers/memory/ramdisk/etc/rc always starts exactly
two instances, based on the most common setup but quite uneasy to
adjust to other configuration :-/ ; but that is another story, it's
about configuration...)
With such a design, for all the network driver which can only have one
PHY attached to them, it should be possible to simplify a fair bit the
drivers, for example to use globals instead of pointers, and more
clearly differentiate uses of pointers because of multiple
(concurrent) messages from the merely designation of the "current"
port: the final intent is to identify the cases where some information
is unduly copied (I am under the impression this is the case for the
xxx_iovec/xxx_iovec_s arrays, which probably do not mix well with
having at the same moment a rx_mess and a tx_mess; and perhaps more
things.)
Antoine
D.C. van Moolenbroek
Funnily I reached the same conclusion a few days ago. The simple
reason for the failure is that in apparently all network drivers, PCI
device iteration is started from the beginning for each port probe
attempt. Hence, all attempts end up trying to reserve the same device,
and that fails for the second port onwards. This is easily fixed, but
I agree that having a separate driver process for each device is more
along the lines of the MINIX3 vision. :)
Regards,
David
