Subject: Re: CVS commit: src/sys
To: Robert Elz <kre@munnari.OZ.AU>
From: Jonathan Stone <>
List: tech-kern
Date: 12/07/2004 11:20:09
In message <2415.1102398961@munnari.OZ.AU>Robert Elz writes
>    Date:        Mon, 06 Dec 2004 13:44:15 -0800
>    From:        Jonathan Stone <>
>    Message-ID:  <>
>  | 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.     [...]

Are you sure? Robert, maybe I'm wrong, but I seem to recall a time
when new-config supported just needs-count, not needs-flag; and that
the implementation we had didn't really work right with NLOOP > 1. In
fact, i think it _still_ doesn't. I even will plead no-contest to
propagating some of the lossage when I added SIOCSIFMTU support to if_loop.

>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)).

Huh?  That's *NOT* what loopback does. See smb's mention of a separate
Cisco-style nullif.

I'm also not any claims about using multiple loopback devices to count
various kinds of packets. There are too many places where kernel code
just grabs lo0 (or lo0ifp, now).

>But while there can be more than one, which is the way it has been
>for a long time now, [...]

<shrug>.  Maybe so. I'm still unconvinced that's necessary, or
correctly implemented, or useful.  I think I'd sooner have one correct
lo0, than start advertising cloning loopback devices that don't work
right in various corner cases.  Diving in and making the config-time->dynamic
change (with an explicit rejection of any discussion) makes it very hard
to achieve that.