Data Link protocol
Antoine Leca
drivers, http://wiki.minix3.org/en/DevelopersGuide/DataLinkProtocol
Thanks to David to put it online, it is quite useful.
I have a few question about it:
* Can Inet react correctly if a driver is first launched *after* Inet?
Among the questions it spawns: Is there a way to force Inet to re-read
its configuration file (without service down && service up, that is)?
My idea is to deal with drivers which "pops up" while the system is
running, like for example VPN tunnels implemented below IP; it also
eases development a lot if we are not required to 'service down' both
Inet and the driver then 'service up' both, particularly if we prefer to
have another working network kept running on the other network card...
* What is a "driver's label" (in the paragraph about Naming)
* The protocol is said to deal with only one message (in each direction)
at any time; but does the fact there are several ports have any impact?
In other words, if a card (hence the driver) has 4 ports, can it receive
(up to) four DL_READV_S message simultaneously, or only one?
* Is there any plan to lift that limitation in the future?
Of course the protocol as it stands does not allow stacking messages, so
obviously this would mean a protocol extension or a redesign. (I guess
that question should be answered by Tom�s, according to
http://wiki.minix3.org/en/StudentProjects.)
* There should be some additional documentation about failed
configuration: at least explain that errors here are indicated by
setting m2_i1 to some negative value.
* The protocol says statistics can be gathered at any time after
initialization; does it means a driver can be asked about statistics for
an un-configured port?
* How are read the statistics: the doc uses DL_GETSTAT, but the
description is more keen to DL_GETSTAT_S; unfortunately current drivers
have both, so it is not easy to decide it...
* Can we use sys_vsafecopy instead of sys_safecopyto/from?
* There should be a discussion about minimally-sized packets. For
example, it would be better/easier if the protocol guarantees that
packets are always bigger than ETH_MIN_PACK_SIZE.
* About DL_TASK_REPLY and its m2_l1 field: that field might be larger
than 32 bits, so while "lower 16 bits" is correct, "high 16 bits" is
not; furthermore, it seems it is ignored by Inet...
* Is there a way to force a port "down" (= disabled) while maintaining
the driver live? I believe it could be useful to forecast that (another,
distinct, question is to avoiding breaking Inet while doing so...)
(I read that the protocol allows to force a port up by (re-)configuring
it, even if it is already enabled.)
* How can a driver react when the link goes from up to down? In my
experience, it causes Inet to break subsequently :-( , since there is
no way to signal a abort on an initiated read or write operation (i.e.
after the initial DL_TASK_REPLY with DL_STAT=0.)
Same question in the reverse way, even if it does not cause wreckage.
I know the following is not exactly on topic, but the purpose is close
enough and there are no better place for it to be documented...
* What about the XXXETHn and XXXETHn_EA configuration variables
inherited from Minix[12] times (when drivers were kernel tasks, to be
launched at boot time)? Can we drop that altogether and replace it with
another system (like passing arguments)?
In particular, I am thinking (in relation to point 1 above) about a new
scheme where it would be Inet (or alternatively some related userland
utility) which starts the drivers, using informations taken from
extended inet.conf, where one could set up the IRQ, I/O or DMA port, PCI
address, MAC address or whatever in full text (and in a centralized
place), and where such informations would be passed as args to the
to-be-launched driver.
Antoine
D.C. van Moolenbroek
Thank you for your input, that was very useful. I've made a number of
changes to the document to some of cover your points, but since not
all of them fit in the scope of the document, allow me to respond to
all of them here..
> * Can Inet react correctly if a driver is first launched *after* Inet?
Yes, but only if inet was already configured to use it. As such this
is generally not very useful.
> Among the questions it spawns: Is there a way to force Inet to re-read
> its configuration file (without service down && service up, that is)?
Not currently, and this would not be entirely trivial to change,
either. Inet uses normal FS calls to read the configuration file a
start-up time, and registers as a driver afterward. At that point it
cannot use FS calls anymore, at least not until VFS has been made
asynchronous. An ioctl-based reconfiguration may be an alternative
here.
> * What is a "driver's label" (in the paragraph about Naming)
A label is a unique, stable name to identify a running driver process,
even across restarts of that particular driver process. The label can
be used to obtain the current endpoint of a driver process. This is
needed for recovery from a driver crash, because endpoints (process
identifiers) do change across driver restarts. The Reincarnation
Server manages labels, and the DataStore stores them. A process's
label is specified with 'service up' - the default is to just take the
file name of the binary.
This is not specific to ethernet drivers, so the document does not
cover this. A reference would be nice, but there's nothing to refer
to, yet..
> * The protocol is said to deal with only one message (in each direction)
> at any time; but does the fact there are several ports have any impact?
> In other words, if a card (hence the driver) has 4 ports, can it receive
> (up to) four DL_READV_S message simultaneously, or only one?
Simultaneously, as far as I can tell. Clarified in the document. The
problem with this whole ports concept is that it makes things hairy
and is hard to test -- this beside the driver crashes issue that you
wrote about earlier. It should really go ASAP.
> * Is there any plan to lift that limitation in the future?
> Of course the protocol as it stands does not allow stacking messages, so
> obviously this would mean a protocol extension or a redesign. (I guess
> that question should be answered by Tom s, according tohttp://wiki.minix3.org/en/StudentProjects.)
As far as I know, Jaswinder Singh is working on exactly this. He might
know more..
> * There should be some additional documentation about failed
> configuration: at least explain that errors here are indicated by
> setting m2_i1 to some negative value.
Good point. I also missed that any error except ENXIO will panic inet.
> * The protocol says statistics can be gathered at any time after
> initialization; does it means a driver can be asked about statistics for
> an un-configured port?
No, DL_CONF is always first as stated elsewhere. Changed the phrasing
here to be less misleading.
> * How are read the statistics: the doc uses DL_GETSTAT, but the
> description is more keen to DL_GETSTAT_S; unfortunately current drivers
> have both, so it is not easy to decide it...
Oops! Fixed.
> * Can we use sys_vsafecopy instead of sys_safecopyto/from?
Yes. Added a note about that as well.
> * There should be a discussion about minimally-sized packets. For
> example, it would be better/easier if the protocol guarantees that
> packets are always bigger than ETH_MIN_PACK_SIZE.
Good point. Apparently it does. Added.
> * About DL_TASK_REPLY and its m2_l1 field: that field might be larger
> than 32 bits, so while "lower 16 bits" is correct, "high 16 bits" is
> not; furthermore, it seems it is ignored by Inet...
Well, longs are 32-bit on the single platform that MINIX3 supports. I
am willing to bet that the protocol will be updated to get rid of this
ugliness before we have any port to a new architecture.
> * Is there a way to force a port "down" (= disabled) while maintaining
> the driver live?
Setting the IP address to 0.0.0.0 with ifconfig(8) might do it. I
believe the driver will then just stop getting new transfer requests.
> * How can a driver react when the link goes from up to down? In my
> experience, it causes Inet to break subsequently :-( , since there is
> no way to signal a abort on an initiated read or write operation (i.e.
> after the initial DL_TASK_REPLY with DL_STAT=0.)
> Same question in the reverse way, even if it does not cause wreckage.
I guess that if the device itself is not capable of acting as a sink
in such a case, the driver should act as a sink instead, as the
protocol has no provisions for this. I'm not sure if we have any
drivers that test link status for anything other than informational/
debugging purposes..
> * What about the XXXETHn and XXXETHn_EA configuration variables
> inherited from Minix[12] times (when drivers were kernel tasks, to be
> launched at boot time)? Can we drop that altogether and replace it with
> another system (like passing arguments)?
This is currently left entirely up to the driver. If this were to be
changed, I think it would be reasonable to at least make the ethaddr
configuration part of the protocol though, as people may want to
change their ethernet address after starting the driver.
Thanks again,
David