)]}'
{
  "commit": "eb2b9311fd00a868e9bf85ab66e86b7dee1643e1",
  "tree": "69167d3359e5bde25f51b8596b65ceae3ebb6a17",
  "parents": [
    "c3896d2ca4dd97be290f000cb1079ed759d28574"
  ],
  "author": {
    "name": "Luis Carlos Cobo",
    "email": "luisca@cozybit.com",
    "time": "Sat Feb 23 15:17:14 2008 +0100"
  },
  "committer": {
    "name": "John W. Linville",
    "email": "linville@tuxdriver.com",
    "time": "Thu Mar 06 15:30:42 2008 -0500"
  },
  "message": "mac80211: mesh path table implementation\n\nThe mesh path table associates destinations with the next hop to reach them. The\ntable is a hash of linked lists protected by rcu mechanisms. Every mesh path\ncontains a lock to protect the mesh path state.\n\nEach outgoing mesh frame requires a look up into this table. Therefore, the\ntable it has been designed so it is not necessary to hold any lock to find the\nappropriate next hop.\n\nIf the path is determined to be active within a rcu context we can safely\ndereference mpath-\u003enext_hop-\u003eaddr, since it holds a reference to the sta\nnext_hop. After a mesh path has been set active for the first time it next_hop\nmust always point to a valid sta.  If this is not possible the mpath must be\ndeleted or replaced in a RCU safe fashion.\n\nSigned-off-by: Luis Carlos Cobo \u003cluisca@cozybit.com\u003e\nSigned-off-by: Johannes Berg \u003cjohannes@sipsolutions.net\u003e\nSigned-off-by: John W. Linville \u003clinville@tuxdriver.com\u003e\n",
  "tree_diff": [
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "37094942e728bb2b2b8404a387d220b453bf3db1",
      "new_mode": 33188,
      "new_path": "net/mac80211/mesh_pathtbl.c"
    }
  ]
}