From owner-freebsd-arch Sat Dec 12 14:46:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA06652 for freebsd-arch-outgoing; Sat, 12 Dec 1998 14:46:41 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA06647 for ; Sat, 12 Dec 1998 14:46:38 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id XAA24872 for ; Sat, 12 Dec 1998 23:46:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA27256 for freebsd-arch@freebsd.org; Sat, 12 Dec 1998 23:46:27 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA05784 for ; Sat, 12 Dec 1998 14:38:01 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id XAA08572 for ; Sat, 12 Dec 1998 23:37:44 +0100 (CET) To: arch@FreeBSD.ORG Subject: Re: IFF_UP, IFF_RUNNING semantics... In-reply-to: Your message of "Sat, 12 Dec 1998 20:55:58 GMT." Date: Sat, 12 Dec 1998 23:37:43 +0100 Message-ID: <8570.913502263@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Paul Richards writes : >> -----Original Message----- >> From: Poul-Henning Kamp [mailto:phk@FreeBSD.ORG] >> Sent: Saturday, December 12, 1998 7:44 PM >> To: arch@FreeBSD.ORG >> Subject: IFF_UP, IFF_RUNNING semantics... >> >> I'm trying to unravel how IFF_UP and IFF_RUNNING is supposed to work. >> >> I would expect one of them (IFF_RUNNING ?) to mean "should be >> running" as in "root configured this one to be running" and the >> other (IFF_UP ?) to mean "is running" as in "hardware/protocols >> are ready to pass packets". > >I think that's more or less it. Stevens says IFF_RUNNING is "resources >are allocated" and IFF_UP is "interface is running". I've found what I think is the culprit: if_ioctl will slam the flags down on the interface, and call if_up() and if_down(), no matter what the poor driver thinks about the subject. That is wrong, no matter how we look at it, at least for some of the more advanced interfaces. Proposed solution: 1. Add IFF_DYNAMIC (0x20 is vacant), which means "keep you fingers away from my flags!). The driver is then responsible for the entire show. 2. add new function: if_route(struct ifnet *, int flag, u_char family) which will add the routes for the specified (or all if zero) address families and set "flag" in the if_flags. 3. add new function: if_unroute(struct ifnet *, int flag, u_char family) the opposite of above. 4. redefine if_up() and if_down() to call the above two functions. This even solves the extreeme case for PPP where an interface may be up for one protocol but not for another... If the driver doesn't carry IFF_DYNAMIC in its flags, everything is just like it used to be. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message