Re: [GENETLINK] some thoughts on the usage
Thomas Graf wrote: * Richard MUSIL [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GENETLINK] some thoughts on the usage
* Richard MUSIL [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GENETLINK] some thoughts on the usage
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
