From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23988 invoked by uid 1002); 6 May 2003 23:56:42 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 18510 invoked from network); 6 May 2003 23:56:38 -0000 X-Authentication-Warning: bru-cse-075.cisco.com: wmertens owned process doing -bs Date: Wed, 7 May 2003 01:56:36 +0200 (CEST) From: Wout Mertens X-X-Sender: wmertens@bru-cse-075.cisco.com To: Martin Schlemmer cc: Wolfram Schlich , Gentoo-Dev mailinglist In-Reply-To: <1052253448.7144.34.camel@nosferatu.lan> Message-ID: References: <20030505202336.ALLYOURBASEAREBELONGTOUS.I23529@bla.fasel.org> <1052167146.4459.41.camel@nosferatu.lan> <1052246617.7144.9.camel@nosferatu.lan> <1052253448.7144.34.camel@nosferatu.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [gentoo-dev] rc-scripts/init: new service dependency X-Archives-Salt: f123e3c8-cb56-4331-9096-a71ce1683359 X-Archives-Hash: 447f3a6dbd0aee2a92aada8e5738fa6b On Tue, 6 May 2003, Martin Schlemmer wrote: > On Tue, 2003-05-06 at 21:59, Wout Mertens wrote: > > > That's what I meant: when the service is called for an action (start, > > stop, restart, reload, custom things), runscript will run the event() > > function for all the scripts that are subscribed to that script, and then > > those scripts can figure out what to do with it themselves... > > > > And the gentoo-net scripts that I am working on will go down a > > user-configurable list when certain things happen. (interface up/down, ip > > address changed, etc. > > > > The design pattern we're looking at here is events and interested parties, > > and it's just a matter of defining what events we handle and how we notify > > the parties. > > > > So in the network context: > > -------- add to /etc/conf.d/net --------- > modules_eth0="static route firewall" > ----------------------------------------- > > -------- add to /etc/init.d/net.eth? ---- > depend() { > subscribe after ${modules_eth0} > } > ----------------------------------------- > > and if net.eth0 starts (meaning the interface is present for example), > it will run the 'static' module to set the static ip, then do the > routes, and lastly add firewall/whatever rules. Same in reverse if > its stopped. Actually, his is what I want to implement in gentoo-net, but it isn't what I described :) I described the reverse: In your example, interpreted by what I meant, if you start /etc/init.d/static, it will, after running the start function in /etc/init.d/static, run the event function in /etc/init.d/net.eth?, with arguments "static" "start" "after". So the net.eth? script gets notified about the static script being started, without the static script having to do anything. And it calls the event() function because you don't necessarily want to start the service when another one started, so that way you can choose what you do. > Note that above might be too simplified, and out of context. > > This brings up a question or two: > > 1) should this work for all rc-scripts, or should we maybe > add a /etc/init.d/modules/ that have very job specific > scripts that are related to net.* (net.eth?, net.ppp?, net.foo) > 2) if yes to 1), will we need it for anything else than net.* stuff ? Very generally speaking, we want to be able to run scripts when some device or service changes state. In gentoo-net, that is the network interface device and the IP "device" (e.g. when the IP address changes you want to update your dynamic dns entry). But what about hotplugged devices? Cardbus, usb, pci? These, too, are interesting to run scripts against, for instance to automatically mount a usb storage device. Right now, Mandrake has something in place that handles some hotplugging events, but networks aren't handled. In 2.6, the kernel will have a more generic devices tree (sysfs), which might or might not consider bringing a network device up a hotplug event, easy to handle in a generic way. So what I'm saying is that it could be useful to set up a generic framework that handles all these things, and reroute the packages that do their own thing to use that interface: hotplug, pcmcia_cs, dhcpcd, ppp and so on all have hooks that can be executed when something happens, and they could thus be written to send an event instead of doing something. So what I would like to see is that you can subscribe to generic user-definable events, and that triggering an event will cause all the subscribed initscripts to be notified. > 3) you mentioned a few events ... do we really need them all, or could > we get away with a 'start/stop' only ? I think that the overhead required to implement start/stop is roughly the same as doing it for a number of events, so I wouldn't want us to cut ourselves short... > To get it running, is not the issue. The bigger issue is getting it > functional, without too much bloat/speed decrease/complexity, with > a stable API that do not have to change every few months. Basically > we will need to think what exactly is needed, and will be needed. Here's two possibilities for doing things after a network interface came up: 1) semi-hardcoded: - put a bunch of SysV init style symlinks to initscripts in /etc/conf.d/net.d/ifup.d/ - the interface comes up - start/stop each of them in order, with $INTERFACE set to the interface, Pro: Easy to write, the user has full control over what gets started or stopped Con: hard to maintain the SysV init style directory, each event needs a directory, solves only one problem. 2) event based: - the initscripts put subscribe statements in their depend() code - the interface comes up - the event dispatcher runs the subscribed initscripts event() functions, with details about the event (who, what and args). Pro: Easy to write the initscripts, solves many problems. The event dispatcher shouldn't be difficult. Con: Need to find a nice way for a user to disable an initscript, so it doesn't get events. Example: the net may be up, but the user doesn't want wwwoffle to be brought online. Thoughts? Wout. -- gentoo-dev@gentoo.org mailing list