Hi MichaelWhile I agree that there should be a way for userspace to get the list of supported operations, userspace apps will only actually care about that once, when they begin talking to kdbus, because (ignoring the live kernel patching that people have been working on recently) the list of supported operations isn't going to change while the system is running. While a u64 copy has relatively low overhead, it does have overhead, and that is very significant when you consider part of the reason some people want kdbus is for the performance gain. Especially for those automotive applications that have been mentioned which fire off thousands of messages during start-up, every little bit of performance is significant.
On Thu, Jan 22, 2015 at 11:18 AM, Michael Kerrisk (man-pages)
<mtk.manpages@xxxxxxxxx> wrote:
* API oddities such as the 'kernel_flags' fields. Why do I need to
be told what flags the kernel supports on *every* operation?
If we only returned EINVAL on invalid arguments, user-space had to
probe for each flag to see whether it's supported. By returning the
set of supported flags, user-space can cache those and _reliably_ know
which flags are supported.
We decided the overhead of a single u64 copy on each ioctl is
preferred over a separate syscall/ioctl to query kernel flags. If you
disagree, please elaborate (preferably with a suggestion how to do it
better).
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature