On Wed, Nov 09, 2016 at 06:00:48PM +0000, Hefty, Sean wrote: > In any case, the two approaches are not exclusive. By forcing the > rule language into the framework, everything is forced to deal with > it. By leaving it out, each ioctl provider can decide if they need > this or not. If you want verbs to process all ioctl's using a > single pre-validation function that operates based on these rules > you can. Nothing prevents that. But ioctl providers that want > better performance can elect for a more straightforward validation > model. The pre-validation is tied into the hash expansion and will hopefully be the raw data to support a new discoverability scheme. So, making it optional really wrecks the whole design, I think. Also, this is really the best way to ensure that we have consistent checking and error reporting around attributes (eg what happens if the kernel does not support a requested attribute, or uses the wrong size, etc) It is very important these things use the correct errnos not the random mismatch we see today. I'm not seeing that it is a clear peformance loss (relative to open coding at least), the major work is the expansion to the hash table and doing a couple size tests along the way is not hard. Matan's revised series should be event better on this regard as I gave alot of feedback to speed it up at plumbers. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
