Re: devd/devctl
On Friday, September 12, 2003, at 06:26 pm, Suleiman Souhlal wrote: I was wondering if it would be a good idea to modify devd and devctl for them to handle other events than attaching and detaching devices.. For example, they could be used to mark a network interface as down, when the network cable is pulled out, and run dhclient when it is put back in. I think there are other applications too. Just something that occured to me in a slightly GT addled state. The GNOME folks have this really cool application at the moment called 'dashboard'. Basically it works by receiving what they've dubbed 'clue packets' from whatever application that you happen to be using at the time, and distributing these to multiple backend plugins that either: a) rewrite the clue packet so that it contains additional information, and/or trigger additional clue packets or b) process it in some way, and update the information that's being displayed by the dashboard The canonical example they use at the moment is receiving an e-mail from someone. Your e-mail app sends a clue packet with the e-mail address of the person you've received it from, and the various backends pull out their address details from your address book, a photo, their web page link (if your browser knows it), their picture, the last five messages they've sent you, and so on, and so forth. I wonder if this model could be adopted for kernel and system events. Instead of a devd, usbd, and others, we need a more generic eventd, which can receive events from the kernel, and distribute them to backends, which can act on them, or augment them as necessary. We've reached cruising altitude, so I can't provide web links, but a google for 'gnome dashboard' should turn up useful info. N ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devd/devctl
In message: [EMAIL PROTECTED] Brandon S. Allbery KF8NH [EMAIL PROTECTED] writes: : On Sat, 2003-09-13 at 18:49, M. Warner Losh wrote: : and you cannot tell dhclient that interfaces have arrived. : : dhclient(8) seems to think otherwise, although it doesn't explain quite : how (I assume it wants you to pause and resume via OMAPI/omshell(8) : since it doesn't appear to support interface objects according to the : documentation). dhclient(8) is wrong. dhclient can't do it in a meaningful way. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devd/devctl
In message: [EMAIL PROTECTED] Suleiman Souhlal [EMAIL PROTECTED] writes: : I was wondering if it would be a good idea to modify devd and : devctl for them to handle other events than attaching and detaching : devices.. For example, they could be used to mark a network : interface as down, when the network cable is pulled out, and run : dhclient when it is put back in. I think there are other : applications too. Yes. that has been the plan for some time now. However, dhclient is really lame in a lot of ways. Martin Blapp has made it a lot better of lates. In geral, I tend to believe that I shouldn't fix bugs in dhclient with devd things. However, a more general trend to more event types would be good because a device arriving isn't quite the same as a network interface arriving... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devd/devctl
On Sat, 13 Sep 2003, M. Warner Losh wrote: Yes. that has been the plan for some time now. However, dhclient is really lame in a lot of ways. Martin Blapp has made it a lot better of lates. In geral, I tend to believe that I shouldn't fix bugs in dhclient with devd things. However, a more general trend to more event types would be good because a device arriving isn't quite the same as a network interface arriving... In dhclient's defense, it's really designed to provide functionality on a wide variety of platforms, with a wide variety of dhcpd's, so it has issues. I think Martin did a good job of defining an improvement that applies to all/most platforms (only try to broadcast if we have link). That functionality is being ported back to the vendor, if it hasn't been already. If we want really cool whizbang features that are more specific to us, we _should_ be looking at stuff like devd. The trick is definig which problem space we're addressing at any given moment. :) Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devd/devctl
In message: [EMAIL PROTECTED] Doug Barton [EMAIL PROTECTED] writes: : That functionality is being ported back to the vendor, if it hasn't been : already. If we want really cool whizbang features that are more specific : to us, we _should_ be looking at stuff like devd. The trick is definig : which problem space we're addressing at any given moment. :) You can't do it in devd. You must be able to either (a) tell a running dhclient about arrival/departures of interfaces or (b) run multiple dhclients. Make dhclient do one or the other. devd can't help you here until one or the other of these work. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devd/devctl
On Sat, 13 Sep 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Doug Barton [EMAIL PROTECTED] writes: : That functionality is being ported back to the vendor, if it hasn't been : already. If we want really cool whizbang features that are more specific : to us, we _should_ be looking at stuff like devd. The trick is definig : which problem space we're addressing at any given moment. :) You can't do it in devd. You must be able to either (a) tell a running dhclient about arrival/departures of interfaces Ok, maybe I misunderstand, but wouldn't _this_ be the right thing for devd to do? In other words, devd should be able to notice this, and devd.conf should be able to define what I want to do with this like sending a signal to dhclient. Then we can move to the dhclient problem space, and define behavior in dhclient that says when X happens, I need to do Y. One way to do this would be to define multiple interfaces in dhclient.conf, and add an optional flag to each interface stanza. Then when dhclient receives a signal, it rescans the list of interfaces it knows about looking for link. This is just a conceptual example of course, other solutions might well be possible. or (b) run multiple dhclients. This is evil, and basically undoable with the current state of things, but it might be possible down the road, although I still think it's evil for other reasons. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devd/devctl
In message: [EMAIL PROTECTED] Doug Barton [EMAIL PROTECTED] writes: : On Sat, 13 Sep 2003, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Doug Barton [EMAIL PROTECTED] writes: : : That functionality is being ported back to the vendor, if it hasn't been : : already. If we want really cool whizbang features that are more specific : : to us, we _should_ be looking at stuff like devd. The trick is definig : : which problem space we're addressing at any given moment. :) : : You can't do it in devd. You must be able to either (a) tell a : running dhclient about arrival/departures of interfaces : : Ok, maybe I misunderstand, but wouldn't _this_ be the right thing for : devd to do? In other words, devd should be able to notice this, and : devd.conf should be able to define what I want to do with this like : sending a signal to dhclient. Then we can move to the dhclient problem : space, and define behavior in dhclient that says when X happens, I need : to do Y. You misundestand. devd *CANNOT* do this. I have a laptop that has a builtin rl0 interface. I plug in a wi0 interface. somehow we gotta deal. and you cannot tell dhclient that interfaces have arrived. : or (b) run multiple dhclients. : : This is evil, and basically undoable with the current state of things, : but it might be possible down the road, although I still think it's evil : for other reasons. why is this evil? dhclient can and does run on mulitple interfaces. it fails now because it specifically precludes it, but for no other good reasons. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devd/devctl
On Sat, 2003-09-13 at 18:49, M. Warner Losh wrote: and you cannot tell dhclient that interfaces have arrived. dhclient(8) seems to think otherwise, although it doesn't explain quite how (I assume it wants you to pause and resume via OMAPI/omshell(8) since it doesn't appear to support interface objects according to the documentation). -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineering, carnegie mellon univ. KF8NH URGENT! E-xpedient nuked APK subdomains; kf8nh.apk.net is DEAD. Sorry. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devd/devctl
On Sat, Sep 13, 2003 at 06:59:21PM -0400, Brandon S. Allbery KF8NH wrote: On Sat, 2003-09-13 at 18:49, M. Warner Losh wrote: and you cannot tell dhclient that interfaces have arrived. One way for it to tell that this has happened automatically is to get it to listen on a PF_ROUTE socket and check periodically for RTM_IFINFO messages. On another note, if I can sit down and play with it I may be able to get rid of the requirement for BPF from our port/import of isc-dhcp. IP_ONESBCAST means it shouldn't need to use raw sockets or BPF to transmit an undirected broadcast datagram. IP_RECVIFADDR/IP_SENDSRCADDR means it shouldn't need a socket per interface. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
devd/devctl
Hello all, I was wondering if it would be a good idea to modify devd and devctl for them to handle other events than attaching and detaching devices.. For example, they could be used to mark a network interface as down, when the network cable is pulled out, and run dhclient when it is put back in. I think there are other applications too. It would be a pretty cool thing to have, especially on laptops, but I don't really know how complex something like this would be to implement. -Suleiman Souhlal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
