Flags as a system call API design pattern
Flags as a system call API design pattern
Posted Feb 14, 2014 20:34 UTC (Fri) by paulj (subscriber, #341)In reply to: Flags as a system call API design pattern by nybble41
Parent article: Flags as a system call API design pattern
That isn't really optional then. Rather, using the API becomes potentially a hand-shaking process ("let me try see if the kernel knows this new flag.. Hmm, no. What about this one ..." etc.). Better then to have a single call that lets the application query for the accepted flags once.
In network protocols too, specifying unused flags as "Must Be Zero" has meant that later, when people wanted to use them, they often effectively could not (sometimes it is not possible to fall-back, there may be no opportunity to probe for supported flags). MBZ bits often end up being completely useless and wasted.
Posted Feb 15, 2014 11:41 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Optional flags do not exist period. There are only “flags you don't care about” and “flags you do care about”. Think FUTEX_PRIVATE. It was added as very much “optional” flag to make pthreads faster. For pthreads implementation it's “optional” flag. But for something like NaCl that same flag is very much a mandatory flag because it's use prevents information leaks. Why? “Let me try see if the kernel knows this new flag” is very simple and cheap if you do it right (take a look on GLibC—it contains dozeons of such cases).
Flags as a system call API design pattern
How do you reject unrecognised flags while still allowing for optional flags?
Better then to have a single call that lets the application query for the accepted flags once.