Anders Persson writes: > > 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.
I would think that ksock_ioctl() would be an excellent place to test for that relevance. Just return EINVAL if it's not allowed. Heck, you can even do EINVAL as the "default:" rule and only allow the ones you *know* are good. I think there's a distinction between the design pattern using function calls versus a single entry point (which was the question), and the scope of the allowable features (not the question). > 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. Indeed. > 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. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
