From 37686c87a971e09280712d45a11e9b262a79d1a9 Mon Sep 17 00:00:00 2001
From: saurav bharti <33656540+bhartisaurav@users.noreply.github.com>
Date: Sun, 11 Sep 2022 18:29:30 +0530
Subject: [PATCH 1/2] inorder-handler.md

---
 docs/inorder-handler.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 docs/inorder-handler.md

diff --git a/docs/inorder-handler.md b/docs/inorder-handler.md
new file mode 100644
index 0000000..600e8a3
--- /dev/null
+++ b/docs/inorder-handler.md
@@ -0,0 +1 @@
+Description of inoder-handler

From 47047f6762a7ee6a4021cec7f812ec45d71dba1f Mon Sep 17 00:00:00 2001
From: saurav bharti <33656540+bhartisaurav@users.noreply.github.com>
Date: Mon, 12 Sep 2022 10:23:31 +0530
Subject: [PATCH 2/2] update content

---
 docs/inorder-handler.md | 74 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 73 insertions(+), 1 deletion(-)

diff --git a/docs/inorder-handler.md b/docs/inorder-handler.md
index 600e8a3..51e5ade 100644
--- a/docs/inorder-handler.md
+++ b/docs/inorder-handler.md
@@ -1 +1,73 @@
-Description of inoder-handler
+# Description of inoder-handler
+
+### Brief about Virtio:  
+virtIO is a virtualization standard for network and disk device drivers. It was chosen to be the main platform for IO virtualization in KVM.
+
+### About virtio block:
+- The virtio-blk device presents a block device to the virtual machine.
+- Each virtio-blk device appears as a disk inside the guest.
+- Virtio-blk is an abstraction layer over devices in a paravirtualized hypervisor.
+- It mainly provides two abstractions:
+  - Request: Contains block request parsing abstraction.
+  - Executor: Contains a block request execution abstraction that is based on std::io::Read and std::io::Write.
+
+### Inorder-handler: 
+
+- This object is used to process the queue of a block device without making any assumptions about the notification mechanism.
+- For time being they used sepecific backend 'StdIoBackend' but in furture they wanted to implement the more generic and flexible one.
+- This queuehandler takes the request and process the request. Return the requests in the same order in which they received.
+```rs
+pub struct InOrderQueueHandler<M: GuestAddressSpace, S: SignalUsedQueue> {
+    pub driver_notify: S,
+    pub queue: Queue<M>,
+    pub disk: StdIoBackend<File>,
+}
+```
+
+- In this process_queue implementation, we follow various steps:
+  - First, we disable the notification event from guest drivers.  
+  - Then, we process the available chain of request through process_chain method.  
+  - If notification is enabled, then we process next set of chain of request.  
+
+```
+    pub fn process_queue(&mut self) -> result::Result<(), Error> {
+        
+        //basically telling the way of cosuming descriptor from the queue.
+        loop {
+            self.queue.disable_notification()?;
+
+            while let Some(chain) = self.queue.iter()?.next() {
+                self.process_chain(chain)?;
+            }
+
+            if !self.queue.enable_notification()? {
+                break;
+            }
+        }
+
+        Ok(())
+    }
+```
+
+
+- In this process_chain implementation, we take each request from chain of requests assuming there is no request parse error.   
+- Then, process each request and write into memory buffer.
+```
+fn process_chain(&mut self, mut chain: DescriptorChain<M::T>) -> result::Result<(), Error> {
+        let used_len = match Request::parse(&mut chain) {
+            Ok(request) => self.disk.process_request(chain.memory(), &request)?,
+            Err(e) => {
+                warn!("block request parse error: {:?}", e);
+                0
+            }
+        };
+```
+
+- After processing each request, it used to update the used ring through chain descriptor and the total length of the descriptor chain which was used (written to). It is also sent the notification if needed, based on request.
+```
+self.queue.add_used(chain.head_index(), used_len)?;
+
+        if self.queue.needs_notification()? {
+            self.driver_notify.signal_used_queue(0);
+        }
+```