From owner-freebsd-arch Mon Dec 7 11:00:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA00943 for freebsd-arch-outgoing; Mon, 7 Dec 1998 11:00:08 -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 LAA00930 for ; Mon, 7 Dec 1998 11:00:04 -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 TAA22411 for ; Mon, 7 Dec 1998 19:59:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA22831 for freebsd-arch@freebsd.org; Mon, 7 Dec 1998 19:59:56 +0100 (MET) Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA29723 for ; Mon, 7 Dec 1998 10:40:09 -0800 (PST) (envelope-from shmit@natasya.noc.erols.net) Received: from natasya.noc.erols.net (natasya.noc.erols.net [207.172.25.236]) by smtp3.erols.com (8.8.8/8.8.5) with ESMTP id NAA10630 for ; Mon, 7 Dec 1998 13:40:01 -0500 (EST) Received: (from shmit@localhost) by natasya.noc.erols.net (8.9.1/8.9.1) id NAA01809 for freebsd-arch@freebsd.org; Mon, 7 Dec 1998 13:40:01 -0500 (EST) Message-ID: <19981207134001.A1794@rcn.com> Date: Mon, 7 Dec 1998 13:40:01 -0500 From: Brian Cully To: freebsd-arch@FreeBSD.ORG Subject: Sysconfig, or, the SysV vs. BSD init wars Reply-To: shmit@rcn.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=CE+1k2dSO48ffgeK X-Mailer: Mutt 0.93.2i X-Sender: If your mailer pays attention to this, it's broken. X-PGP-Info: finger shmit@kublai.com for my public key. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Originally sent to freebsd-hackers, and re-sent here by the author, with apologies to those that have already seen it. -EE] (I hope I manage to state myself clearly in this message, but I'm a little confused as to how to relate everything.) I've spent the last few weeks working on and off on a replacement for /etc/rc, and given the recent traffic regarding such, I figured now's a good time to tell the world. The program itself, sysconfig (probably should be called sysinit, given it's functionality), should be called from init instead of /etc/rc, and sysconfig reads it's data out of /etc/system (or something). The syntax of the file looks like this: service = { enabled = "YES"; supplies = [ "service_1"; ...; "service_n"; ]; requires = [ "requirement_1; ...; "requirement_n"; ]; load = "startup script"; unload = "teardown script"; }; The supplies and requires nodes can be regular strings, too, instead of arrays, or even another dictionary (but that hasn't been written yet, it's of dubious value to me). The syntax should look like your everyday dictionary, and can have dictionaries or arrays nested indefinately within other dictionaries or arrays (which could be useful). The load and unload nodes can reference other nodes like this: load = "ifconfig $address $netmask"; or, if you want to leave local scope, you can reference an element in another node: load = "ifconfig $root.address $super.netmask"; So, if you want to config your ethernet interfaces: network = { enabled = "YES"; supplies = "network"; load = "ifconfig $address $netmask $media $options"; unload = "ifconfig $key down"; interfaces = [ "fxp0"; "lo0"; ]; fxp0 = { address = "207.172.25.236"; netmask = "255.255.255.0"; media = "media 100BaseTX mediaopt full-duplex"; }; lo0 = { address = "127.0.0.1"; netmask = "255.0.0.0"; }; }; As you can see, the name of the service is arbitrary for now, eventually, I want to have the service name be a module that can be loaded at run-time for third-party extension. If there is no module it'll use default behaviour (which will fail with the network example above). This requires ld.so and libc.so to be on the root partition, which is something we'll probably eventually need anyway, as the system becomes more and more dynamic. You can source other files, to assist in ease-of-maintenance for centralised distribution. The dictionary parsing stuff is sufficiently high-level as to allow for a menu-driven configurator for newbies (and random other uses, I'm using it in my RADIUS daemon, for example). The dictionary code is really only up to the task of parsing the config file and printing it out again right now, because that's as much functionality as I need for the moment (but it's very good about failure modes, giving you a nice stack backtrace). In the future, though, I want to make it more robust. I'm of two minds about the /etc/init.d/service start|stop functionality in SysV init, I want to implement it, but am not sure how, here's the way I see it: 1) Have the `load' and `unload' nodes just call external scripts to do the dirty work, that you can call yourself when you want to, or, 2) Have a `telinit' style program where you can say: telinit module unload telinit module load The perks here being that you could theoretically replace init eventually, and you can have sysinit do all the dependency tracking information so you can't easily unload a service that's in use by another service that's still up (which I think would be way cool, and worth the confusion over having to use a `telinit' style program). I've got my code to a point where it tracks down who supplies what, and with a little more work (in my copious spare time), it'll be able to track down dependencies and load programs. It doesn't do the object referencing I talked about above, because it's not useful to do that when I can't even load a program. :-) So in about a man-day or two, I should have it to the point where I can actually replace /etc/rc with it. Oh, yes, and it's also done completely in Objective C, because it made my life really easy while I was developing this. I'd really like feedback on this, because I'd like this to be used, or I'd at least like to stop wasting my time on it if it won't be. If you want the code send me mail, it's not very functional, but you will probably be able to see where I'm going. -- Brian Cully Macintosh -- we might not get everything right, but at least we knew the century was going to end. -- Douglas Adams, on the Y2K problem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 12 11:52:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21663 for freebsd-arch-outgoing; Sat, 12 Dec 1998 11:52:01 -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 LAA21636 for ; Sat, 12 Dec 1998 11:51:58 -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 UAA23359 for ; Sat, 12 Dec 1998 20:51:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA25155 for freebsd-arch@freebsd.org; Sat, 12 Dec 1998 20:51:51 +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 LAA21033 for ; Sat, 12 Dec 1998 11:44:34 -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 UAA08242 for ; Sat, 12 Dec 1998 20:44:00 +0100 (CET) To: arch@FreeBSD.ORG Subject: IFF_UP, IFF_RUNNING semantics... From: Poul-Henning Kamp Date: Sat, 12 Dec 1998 20:43:59 +0100 Message-ID: <8240.913491839@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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". In this model, IFF_UP would control the routes. Either by yanking the route when IFF_UP disappears, or by not selecting routes where the interface doesn't have IFF_UP set. Looking over the sources, it is obvious that very few people if any have any idea about the semantics about IFF_UP and IFF_RUNNING either. For an example why this is important imagine an UTP ethernet which doesn't receive a heartbeat. In that case the hardware knows the interface is down and the route should be disabled so the packets could attempt to flow another way. Words of wisdom on the subject kindly solicited. -- 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 From owner-freebsd-arch Sat Dec 12 13:00:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA25757 for freebsd-arch-outgoing; Sat, 12 Dec 1998 13:00:02 -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 NAA25728 for ; Sat, 12 Dec 1998 13:00:00 -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 VAA23928 for ; Sat, 12 Dec 1998 21:59:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA25462 for freebsd-arch@freebsd.org; Sat, 12 Dec 1998 21:59:58 +0100 (MET) Received: from octopus.originative.co.uk (originat.demon.co.uk [158.152.220.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA25630; Sat, 12 Dec 1998 12:57:22 -0800 (PST) (envelope-from paul@originative.co.uk) Received: by OCTOPUS with Internet Mail Service (5.5.1960.3) id ; Sat, 12 Dec 1998 20:56:01 -0000 Message-ID: From: Paul Richards To: "'Poul-Henning Kamp'" , arch@FreeBSD.ORG Subject: RE: IFF_UP, IFF_RUNNING semantics... Date: Sat, 12 Dec 1998 20:55:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----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". > In this model, IFF_UP would control the routes. Either by yanking > the route when IFF_UP disappears, or by not selecting routes where > the interface doesn't have IFF_UP set. > > Looking over the sources, it is obvious that very few people if any > have any idea about the semantics about IFF_UP and IFF_RUNNING either. > > For an example why this is important imagine an UTP ethernet which > doesn't receive a heartbeat. In that case the hardware knows the > interface is down and the route should be disabled so the packets > could attempt to flow another way. In this case I'd say the driver should drop IFF_UP but not IFF_RUNNING since while resources are allocated for it to run the hardware isn't allowing it to. In my lnc driver (which is the same as most drivers I think including the example in Stevens Illustrated Vol2) it's closely tied to the hardware. If the lance initialises ok and the chip is running then IFF_RUNNING is set. This either happens at boot or when IFF_UP is set and IFF_RUNNING isn't, in which case lnc_start is called. If IFF_UP is cleared i.e. the interface is going down, then the lance chip is stopped and IFF_RUNNING is cleared. Therefore, IFF_RUNNING is basically an indication of whether the lance chip is running or not. The driver doesn't do anything for things like heartbeat failures other than report them. I guess it might make sense to clear IFF_UP. I'm not sure how you'd restart the interface if a transient hardware problem went away though. It's not clear from Stevens exactly what he means by "resources allocated" and he only mentions IFF_RUNNING once and that's in a table on p.67 Vol2. From a quick grep of the networking sources (sys/net*) IFF_RUNNING seems to be virtually unused, it only appears in a handful of files, mainly pseudo drivers and even then it's just or'd with IFF_UP. Paul Richards Ph.D. Originative Solutions Ltd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message 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