)]}'
{
  "log": [
    {
      "commit": "482a8524f85a7d8c40c6fb5d072e85bc2fef327f",
      "tree": "cbd4225da63a687dd70441d41aad35ff5c171f48",
      "parents": [
        "9ac4a16983ea4edf719c390a1a234d956947688d"
      ],
      "author": {
        "name": "Thomas Graf",
        "email": "tgraf@suug.ch",
        "time": "Thu Nov 10 02:25:56 2005 +0100"
      },
      "committer": {
        "name": "Thomas Graf",
        "email": "tgr@axs.localdomain",
        "time": "Thu Nov 10 02:26:41 2005 +0100"
      },
      "message": "[NETLINK]: Generic netlink family\n\nThe generic netlink family builds on top of netlink and provides\nsimplifies access for the less demanding netlink users. It solves\nthe problem of protocol numbers running out by introducing a so\ncalled controller taking care of id management and name resolving.\n\nGeneric netlink modules register themself after filling out their\nid card (struct genl_family), after successful registration the\nmodules are able to register callbacks to command numbers by\nfilling out a struct genl_ops and calling genl_register_op(). The\nregistered callbacks are invoked with attributes parsed making\nlife of simple modules a lot easier.\n\nAlthough generic netlink modules can request static identifiers,\nit is recommended to use GENL_ID_GENERATE and to let the controller\nassign a unique identifier to the module. Userspace applications\nwill then ask the controller and lookup the idenfier by the module\nname.\n\nDue to the current multicast implementation of netlink, the number\nof generic netlink modules is restricted to 1024 to avoid wasting\nmemory for the per socket multiacst subscription bitmask.\n\nSigned-off-by: Thomas Graf \u003ctgraf@suug.ch\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n"
    }
  ]
}