<disclaimer>It's ok for me to trim the Cc: list if noboy objects.Don't hesistate to ask for clarification if my english comes from Mars.</disclaimer>

Krzysztof Halasa <khc@pm.waw.pl> :[...]> Addressing the second problem (unknown data length) requires the caller> (user-space utils) to supply allocated space size. The kernel would> update the size to reflect the actual amount of data required, allowing> the caller to allocate more space and try again (or ignore the unknown> interface).

If size/limit of an underlying object is in a structure for other purposethan debygging, it means something (S) is working with an object and it (S)doesn't know what it is. Design proble: always work with an object whose identity you know or simply pass a reference to someone knowing better.

I don't see why a 'size' parameter is required. Thus I'm fine with thefollowing (we are lucky enough that there is enough space in union ifr_ifru to hold ifru_settings):

> What is important here is that inner union consists of pointers> to *_proto / *_settings structs and not of the structs themselves.

Agree on this.

> Another solution - using a different ifreq structs for different tasks> (something like the sockaddr_*) - sort of:[...]

I am not too fond of this and, again, what are these 'size' for ?If it's supposed to replace/duplicate ifreq, the 'settings' part shouldbe a pointer imho. Same reason as before: size change => compatibility problems for tools (we have sources but downgrading tools when returning toprevious kernel sucks).