Re: alternate event logging proposal

Brad Hards (bhards@bigpond.net.au)
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/