James Carlson wrote:
Anders Persson writes:
- Special-casing nonblocking mode seems odd. Are no other ioctls
relevant?
SIOCATMARK? FIONREAD?
In the current design, all ioctls that affect sockets would be
represented explicitly by a function. SIOCATMARK is handled
(ksock_atmark()); I mention it in the text, but I seems like I forgot to
add it to the function listing. However, I completely forgot about
FIONREAD, and a function would have to be added to handle it.
What's the rationale for function-per-ioctl rather than just having
ksock_ioctl() and (if necessary) ksock_fcntl()?
Not all ioctls that would normally apply to userland sockets are relevant
for kernel sockets (e.g., SIOCSPGRP), so there needs to be some facility
to verify that a given ioctl is allowed depending on the type of socket.
When I initially went through the list of interesting ioctls it was quite
short (FIONBIO, SIOCATMARK), and I thought the function-per-ioctl
would be suitable mechanism for filtering out unsupported ioctls.
I reviewed the ioctls again, and it now appears that things are a bit
more complex. For example, SCTP have a few additional ioctls that
needs to be supported. 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.
Anders
_______________________________________________
networking-discuss mailing list
[email protected]
