netdev - Re: network interface state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <473B8EEC.1010906@redhat.com>
Date:	Wed, 14 Nov 2007 16:12:28 -0800
From:	Ulrich Drepper <drepper@...hat.com>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org
Subject: Re: network interface state

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Miller wrote:
> Most daemons handle this by listening for events on the netlink
> socket, but I understand how that might not be practical for
> glibc.

Right, this cannot work.  I have no inner loop which I can control.  I
cannot install a listener.

At some point, when we have non-sequential, hidden file descriptors,
I'll be able to leave a socket file descriptor open.  But that's about
it.  Even then the generation counter interface is likely to be the best
choice.

> It's part of the link information, Look in ifinfomsg->ifi_type

Great, I fixed up the code.  I guess in future, once I can cache the
data, I'll simply read the RTM_GETADDR and RTM_GETLINK data all at once
and be done with it.

BTW, is it possible to send both these requests out before starting to
read the results?  This would reduce the amount of code quite a bit.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHO47s2ijCOnn/RHQRApIIAJwNATDabXkfszG2e+gtJWO9f4wm4wCdFuoQ
Yn40KK+cs9Di4fq+WKTQalo=
=q02M
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html