)]}'
{
  "commit": "5eb3a8e164dc74497e9ecbf0d56f167f971cc770",
  "tree": "a25674805512fe2254540c66da707ea501a6a68c",
  "parents": [
    "e2d1f26d2a06271eed57b6f82124b1a3a0f07de3"
  ],
  "author": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Wed Mar 29 10:54:44 2017 -0400"
  },
  "committer": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Wed Mar 29 10:54:44 2017 -0400"
  },
  "message": "qio: Remove q-\u003elen\n\nq-\u003edlen is the amount of data bytes in the queue: the bytes that our\nclients are adding and removing.\n\nq-\u003elen was the amount of total bytes in the queue, including metadata,\nblock structs, and anything else.  If you had a block with 0 data bytes in\nthe queue, the size of the block itself counted against q-\u003elen.\n\nNote that the qlen() function actually returns q-\u003edlen.  The only time we\nreally used q-\u003elen was for flow control, and that\u0027s where it caused\nproblems.  I had a pipe where the reader didn\u0027t wake a writer.  The reader\nsaw \u0027was_unwritable\u0027, then popped a block of length 0, and did a retry\n(this was the Qcoalesce case).  However, popping that block made the queue\nwritable again, which was unexpected since the reader got nothing.\n\nInstead of mucking around with q-\u003elen and q-\u003edlen any further, I just\nyanked q-\u003elen completely.  It\u0027s not clear that we even wanted q-\u003elen, and\nit\u0027s been the source of bugs and confusion for a while now.\n\nSigned-off-by: Barret Rhoden \u003cbrho@cs.berkeley.edu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "8568990f2b085d6af22754e6b53bf78722f8e44e",
      "old_mode": 33188,
      "old_path": "kern/src/ns/qio.c",
      "new_id": "07c58c0baeea1a8f374720b419533853490326d1",
      "new_mode": 33188,
      "new_path": "kern/src/ns/qio.c"
    }
  ]
}