netdev - Re: [GENETLINK] some thoughts on the usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070815175009.GA32236@postel.suug.ch>
Date:	Wed, 15 Aug 2007 19:50:09 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	Richard MUSIL <richard.musil@...com>
Cc:	netdev@...r.kernel.org
Subject: Re: [GENETLINK] some thoughts on the usage

* Richard MUSIL <richard.musil@...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.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html