>>>>> On Sat, 8 Jul 2006 17:08:27 +0000 (UTC),
      christos@astron.com (Christos Zoulas) said:

> The ioctl number has the size encoded in the ioctl. In sysctl it is separate.
> So if you change the struct size in an ioctl, the ioctl number will change.
> In the sysctl case, the size is passed in separately.

I don't think that is a real issue.

In the dictionary case, if you add a new key to the dictionary,
you have to add a statement to check the existence of the key,
because the key is optional.

In the ioctl case, if you add a member to a struct, you have to check
the ioctl number, but you can share most of the implementation between
old compat code and new code anyway, especially if the difference is
only existence of new members at the end of the struct.

Note that you have to have a conditional statement to see the
existence of the optional member in the both ways.

And actually, not using dictionary may be win, because you can easily
omit old compat code in that way, so actual kernel size becomes smaller.
When you are using dictionary style, you should check existence of 
every key, so the code size is always larger.

For example, assume if you have 3 versions, first version has 10
members in its argument struct, second version has 12 members, and
third version has 15 members.

In the ioctl case, you only have to have 3 conditions, and you can
omit 2 of them, if user doesn't specify COMPAT option.
If you write test cases for them, you only need to check 3 cases.

In the dictionary style case, you have to have 15 conditional
statements, and you need to check 2**15 == 32768 test cases.
Which one is complex? It seems to be obvious for me.

I agree that there are some cases that dictionary style API is
appropriate. For example, it's really appropriate for REST-style
Web API. Because you can pass multiple different attributes at once,
so you can hide really long latency of the Internet.
But I don't think dictionary style is always win. Because it often
adds complexity as above.
-- 
soda