James Carlson wrote:

Anders Persson writes:
So it appears that the best way would be to
provide a generic ksock_ioctl(), however, I still have to look into
how to filter out unsupported ioctls.

'switch' would probably be sufficient.  It's what we do elsewhere.

There'll likely be a fair bit of overlap between this project and the
existing netinfo interfaces.  I'd like to see the more-standard-like
ksock approach become the norm ... but that might be much longer term


I'm not sure of that.
I suspect you're thinking that the routing socket would be the
ideal thing to use here...

That's less than ideal (as was the pfild) and what I'd see as being
a compromise on the desired interaction with a purist view on
design.  A big problem with pfild using the routing sockets as "the"
solution was the need to maintain a second copy of the relevant
pieces of data.

Another problem here is that there is a window of time between
when a change happens on a network interface and the routing
socket message is delivered/received.  The netinfo interfaces
were aimed at eliminating that window opening.

But there is definately some possible overlap with ioctls such as
SIOCGIFADDR, SIOCGIFDSTADDR, etc, being just as useful as
the existing functions today.

Darren

_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to