One to many mapping and IOCTL.

This project is going really great. After the one to one mapping, the next plan was to make one to many mapping.
The pool disk will be the one in which the file system will reside on. This pool device internally maps to the block devices of the original harddisks.

Krishna and I worked hard like never before.
The one to many consists of these steps.

  • Get the bio
  • Find in which disk the bio starts.
  • If bio starts and ends in the same device,
  • then change the block_dev and sector and send_bio;
  • else if the bio spans many devices,
  • then split_bio and call this same function recursively
This had lots of bugs. we spent some 2 days to make the code bug free (at least as far as we tested its bug free)
This module, while developing, by default spans only /dev/ram0,1. But we need the user to select the devices.

Here comes ioctl.

The only way user programs can communicate with driver is through IOCTL calls. Me and Krishna, now started concentrating on writing ioctls. We wrote the ioctl handling inside drivers. Santhosh started working on user commands. He creates c-programs, that get commands. Commands look something like,

$ pool add /dev/pool0 /dev/ram10 /dev/ram12

This means, Add /dev/ram10 and ram12 to /dev/pool0. This guy, gets the devices in command line arguement and put it in a datastructure. Finally, according to wat to be done (add, remove etc..), he passes the corresponding ioctl_command_number with the datastructure.

We get this datasructure inside the driver and we add the corresponding block_device objects of the devices to out list of devices handled by pool. Same applies for remove..

Some ioctl operations are left.. We are doing that.
Our next step will be, putting metadata on harddisks. We know nothing in this. Lots Lots of problem. As soon as we are done, I'll post the same here!
We've not yet touched the file system part. Problem lies there too....

GOD HELP US! :)

Posted in |

0 comments: