Re: PF_NETLINK support in glibc

[kuznet@ms2.inr.ac.ru]

Hello!

> > >The glibc CVS tree doesn't seem to have support for the new PF_NETLINK  
> > >& rtnetlink socket family in Linux 2.1. 

Right, I see no reasons why glibc might be aware of netlink.

Guys, listen, leave this part to programs, which really use netlink.
There are not so much of them. glibc does not use it, hence it must
not contain any references.

> To make it useful at least support for rtnetlink (linux/rtnetlink.h) is needed.
> rtnetlink is the IPv4 routing table interface which is the main 
> use of netlink currently. 

rtnetlink definitions should not be referenced outside corresponding kernel modules,
it will result in impossibility to extend it. And it will be extended
permanently during corresponding kernel module updates.

Andy, I got an impression, that you still do not understand,
that at least the nearest 5 years these technologies will change permananently
and even faster than we will be able to follow them.
It does not depend on our desire, it is push of world,
which cannot be frozen by anyone.

> There is also a problem with NLMSG_NEXT IMHO: it doesn't return NULL at 
> the end or when the message is invalid like the similar cmsg function.
> The caller has to do the NLMSG_DONE check himself and call NLMSG_OK
> before looking at the message. I think it would be better if NLMSG_NEXT
> did all so that when it returns != NULL the pointer is guranteed to 
> be valid. Unfortunately that would be an API change for existing 
> netlink programs.

It is rather not an API, but convenience macros.

NLMSG_DONE? Seems, you misunderstood something. NLMSG_DONE is particular sort of message.

Why do you think that it would be better? 8)8)
Probably, you are right, but until now I was the only person, who
programmed it and this way is an abstraction of my experience, not more.

rtnetlink API contains only two general elements:
- struct nlmsghdr
- forced 32bit alignment

It is different of cmsg, because it is explicitly invariant, and
does not depend on particular hardware/OS, so that there are no reasons
to make any macros to manipulate it.

Alexey Kuznetsov