Flags as a system call API design pattern

Posted Feb 15, 2014 11:41 UTC (Sat) by khim (subscriber, #9252)
In reply to: Flags as a system call API design pattern by paulj
Parent article: Flags as a system call API design pattern

How do you reject unrecognised flags while still allowing for optional flags?

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.

Better then to have a single call that lets the application query for the accepted flags once.

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).