Subject: Re: CVS commit: src/sys
To: Jonathan Stone <email@example.com>
From: Robert Elz <kre@munnari.OZ.AU>
Date: 12/07/2004 12:56:01
Date: Mon, 06 Dec 2004 13:44:15 -0800
From: Jonathan Stone <firstname.lastname@example.org>
| I don't think so. I'm not even sure if multiple-loopback devices was a
| deliberate design decision, or if it predates the functional/semantic
| split of`needs-count' vs. ``needs-flag''.
It has to have been a deliberate design decision. You don't declare
an array of ifnet structures if you're only planning on allowing one of
them. That would be absurd. There was never a need to use the value
of NLOOP for anything, other than to test whether it was defined && > 0
(ie: it could have been used only in preprocessor conditionals, other
similar option variables are).
If the code had wanted just one there would have been just one
By all means go and figure out how or why multiple loopback interfaces
might be useful, or can't be, and then if having more than one cannot
be useful, make the code always have exactly one (I have seen Matt
Thomas' mail, and I agree, I'd also like to be able to route packets at
a loopback as a way to count & drop them, much simpler in the easy
cases that fiddling with ipf (or pf)).
But while there can be more than one, which is the way it has been
for a long time now, having the number that get created determined as
they're required (for whatever strange reason might exist) rather than
at compile time is certainly better.