Comment # 6 on bug 1139983 from Stanislav Brabec

After a discussion with jbohac and mkubecek, I realized that there is indeed no
easy fix for this bug.

Fixing this bug means migrating of this code from POSIX getifaddrs() to
NETLINK_ROUTE netlink messages.

As another part of agetty.c already uses NETLINK_ROUTE netlink messages (the
changes monitor), it makes sense to write and use address parser in both cases.


The current implementation is incredibly ugly:

1. issue-generator listens to udev to monitor new network devices.

2. Dedicated code in the issue-generator generated an updated issue file which
lists network devices that are considered as relevant (text match is use for
this).

3. agetty reload feature reloads issue file.

4. agetty listens to NETLINK_ROUTE netlink messages and monitors all network
changes (new addresses, removed addresses, router advertisement, devices
added,...)

5. Whenever any netlink message is received, it is discarded, and getifaddrs()
is used to resolve IP addresses.

6. After receiving of any netlink messages, the whole issue file is rendered to
the memory, compared with the previous one, and if there is any text change and
users did not start to type yet, issue is re-rendered.


Caveats:

- However there are two processes monitoring interfaces changes, agetty always
does full evaluation of the issue file and evaluation of all addresses.

- agetty does full evaluation of all addresses even if no change in interfaces
or IP addresses appears (e. g. for every IPv6 RaS).


It also has some ugly aspects:

- On a very large router systems (thousands of IP addresses), NETLINK_ROUTE
netlink monitor messages can appear several times in a second, which can cause
unwanted load (or even getifaddrs() may fail).

- If there is a large number of interfaces, agetty may scroll.


So I am proposing some additional changes:

- Parse netlink messages in the monitor and ignore those that does not cause IP
address list or interface list change as soon as possible.

- Improve the special char format to implement
for-all-relevant-network-devices{write foo\n}. It would obsolete
issue-generator.

- Add an interfaces counter and IP addresses counter.

- If the number of relevant interfaces exceeds some limit (e. g. 5 interfaces),
skip IP listing at all, as it is probably a router system.

- If the number of global IP addresses exceed some limit (e. g. 3), write just
"multihoming". Otherwise type all global addresses (or primary addresses in
case of IPv4). If none,exists, use heuristic to get a best fit (link address,
ephemeral address with a longest validity time).