[GENETLINK] some thoughts on the usage

[GENETLINK] some thoughts on the usage

[Richard MUSIL]

Hello all,

I am currently writing virtual TPM device driver. This is supposed to
behave the same way as normal TPM but instead sending commands to
hardware device, it will pass them back to user space. Probably similar
in concept to tun/tap but with the difference it has nothing to do with
networking.

I am using genetlink for communication with user space "backend".
Virtual device manager can create certain number of devices (e.g. up to
8) and it works like this:

1) Create platform device (i.e. /dev/tpm#)
2) Register genetlink family for this device with name "/dev/tpm#"
3) Register ops for this family.

I have noticed that although ops for each family are the same (each
device is functionally same) I cannot use same genl_ops struct for
registration, because it uses internal member to link in list. Therefore
it is necessary to allocate new genl_ops for each device and pass it to
registration. But I cannot "officially" use this list to track those
genl_ops (so I can properly destroy them later), because there is no
interface. So I need to redo the management of the structures on my own.

Simple function genl_get_family_ops probably would do, but I do not
know, if what I am trying to do is the intended way of using genetlink,
so I am asking first. (Can write patch for it later.)

The second "inconvenience" is that for each family I register, I also
register basically same ops (basically means, the definitions, and doit,
dumpit handlers are same, though the structures are at different
addresses for reasons described above). When the handler receives the
message it needs to associate the message with the actual device it is
handling. This could be done through family lookup (using
nlmsghdr::nlmsg_type), but I wondered if it would make sense to extend
genl_family for user custom data pointer and then pass this custom data
(or genl_family reference) to each handler (for example inside
genl_info). It is already parsed by genetlink layer, so it should not
slow things down.

What would you say?

Richard

Re: [GENETLINK] some thoughts on the usage

[Thomas Graf]

* Richard MUSIL <richard.musil@st.com> 2007-08-10 10:45
> I have noticed that although ops for each family are the same (each
> device is functionally same) I cannot use same genl_ops struct for
> registration, because it uses internal member to link in list. Therefore
> it is necessary to allocate new genl_ops for each device and pass it to
> registration. But I cannot "officially" use this list to track those
> genl_ops (so I can properly destroy them later), because there is no
> interface. So I need to redo the management of the structures on my own.

The intended usage of the interface in your example would be to register
only one genetlink family, say "tpm", register one set of operations
and then have an attribute in every message which specifies which TPM
device to use. This helps keeping the total number of genetlink families
down.

> The second "inconvenience" is that for each family I register, I also
> register basically same ops (basically means, the definitions, and doit,
> dumpit handlers are same, though the structures are at different
> addresses for reasons described above). When the handler receives the
> message it needs to associate the message with the actual device it is
> handling. This could be done through family lookup (using
> nlmsghdr::nlmsg_type), but I wondered if it would make sense to extend
> genl_family for user custom data pointer and then pass this custom data
> (or genl_family reference) to each handler (for example inside
> genl_info). It is already parsed by genetlink layer, so it should not
> slow things down.

That's not a bad idea, although I think we should try and keep the
generic netlink part as simple as possible. There is a family specific
header, referred to as user header in genl_info which is basically
what you're looking for with the custom header. I believe making the
generic netlink family aware of anything beyond family id and operations
id only complicates things.

Re: [GENETLINK] some thoughts on the usage

[Richard MUSIL]

Thomas Graf wrote:
> * Richard MUSIL <richard.musil@st.com> 2007-08-10 10:45
>> I have noticed that although ops for each family are the same (each
>> device is functionally same) I cannot use same genl_ops struct for
>> registration, because it uses internal member to link in list. Therefore
>> it is necessary to allocate new genl_ops for each device and pass it to
>> registration. But I cannot "officially" use this list to track those
>> genl_ops (so I can properly destroy them later), because there is no
>> interface. So I need to redo the management of the structures on my own.
> 
> The intended usage of the interface in your example would be to register
> only one genetlink family, say "tpm", register one set of operations
> and then have an attribute in every message which specifies which TPM
> device to use. This helps keeping the total number of genetlink families
> down.

I got your point. The fact that there are several families of the same
device type seems however quite convenient. For example, I
create/register virtual device /dev/tpm0 and register family with the
same name for that device, the same for /dev/tpm1 etc. Then I got
straightforward association in between devices and families and get for
free the whole management what happen if I try to talk to device which
is not registered/present etc.
I could multiplex it over one channel, but I will need to make the
communication protocol more complex and make me handle all exceptions
myself.
Since in my case there will be probably not more than one device
present, and the device itself is quite "exotic" I would probably not
rewrite it to the multiplexing scheme, but I understand what you mean
and will take it into account next time I face decision how to use
genetlink.

However I am still wondering, whether the allocation of structures
(genl_family, genl_ops) should not be done by genetlink layer instead of
the user (I mean allocating copy of the struct passed by user). This is
for example, what TPM layer (tpm.c) does. This would come at slight cost
at memory usage and performance, but will protect the caller from
inspecting internal behavior and taking care of that. And internal links
would nicely help in keeping of track of allocated structures. I could
write a patch for this.

>> The second "inconvenience" is that for each family I register, I also
>> register basically same ops (basically means, the definitions, and doit,
>> dumpit handlers are same, though the structures are at different
>> addresses for reasons described above). When the handler receives the
>> message it needs to associate the message with the actual device it is
>> handling. This could be done through family lookup (using
>> nlmsghdr::nlmsg_type), but I wondered if it would make sense to extend
>> genl_family for user custom data pointer and then pass this custom data
>> (or genl_family reference) to each handler (for example inside
>> genl_info). It is already parsed by genetlink layer, so it should not
>> slow things down.
> 
> That's not a bad idea, although I think we should try and keep the
> generic netlink part as simple as possible. There is a family specific
> header, referred to as user header in genl_info which is basically
> what you're looking for with the custom header. I believe making the
> generic netlink family aware of anything beyond family id and operations
> id only complicates things.

Ok, this was just an idea ;-) - probably important only for high
performance genetlink users.

Richard