Messages in this thread | | | From | Brad Hards <> | Subject | Re: alternate event logging proposal | Date | Wed, 25 Sep 2002 08:32:34 +1000 |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 25 Sep 2002 06:54, Tim Hockin wrote: > Jeff Garzik wrote: > > In existing drivers that call netif_carrier_{on,off}, it is perhaps even > > possible to have them send netlink messages with no driver-specific code > > changes at all. > > This is something that I have been asked to look at, here. Jeff, how > (or is?) any of the netlink info pushed up to userspace? The idea that > someone came to me with was to have something in (driverfs? netdevfs?) > that was poll()able and read()able. read() giving current state, and > poll() waking on changes. Or maybe two different files, but something. > Of course it'd be greate to be generic. I just assumed it would come > from netif_* for netdevices. > > Is this something planned? wanted? something I should bang out into > 2.5.x before end of next month? Wanted. Example: In desktop / consumer applications, you can use link-state change to do things like invoke the DHCP client daemon, or get yourself a link-local IP address.
> We could have a generic device-events file (akin to acpi events) that a > daemon dispatches events into user-land, or we could have a kernel->user > callback a la /sbin/hotplug, or we could have many device/subsys > specific files. > > Anyone have a preference? I liked the /sbin/hotplug arrangement (aka call_usermode_helper). In fact, my plan was to add the call_usermode_helper call to the netif_carrier_[on,off] functions. Unfortuantely, I've been to too many of Rusty's talks, and know that calling a function that is only safe in user context is unlikely to be a good idea in netif_carrier_[on,off], which are more than likely running in interrupt context.
Conceptually, I don't see (hot-plugging) a CAT-5 cable into a NIC to be that much different (from a userland view) to plugging the NIC into the PCI bus.
My big problem is that I am clueless, and call_usermode_helper isn't nice code. If someone in kernel-land could make call_usermode_helper safe in interrupt context, at least link-state reporting would be fairly trivial. It shouldn't be that hard - it's already using keventd. I just have no idea about clone_thread and stuff like that.
Brad
- -- http://conf.linux.org.au. 22-25Jan2003. Perth, Aust. Tickets booked. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org
iD8DBQE9kOgDW6pHgIdAuOMRAqojAJ0aiXkHtK0eo6/1Bg+Yo8zSzBCMSQCfXK0x 5CSmDWhwRiamJwttaxF6Eac= =hqKf -----END PGP SIGNATURE-----
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |