The official website of Harris Mohamed

Overview

I was selected to give a plenary presentation on Expanding Pattern-of-Life capabilities on Passive RF datasets. This will serve as a sequel to my work for the AMOS 2023 conference. This website will be updated after the conference has completed.

Overview

Sentinel Prime was a continuation of Project Sentinel. Sentinel Prime's goal was to detect and classify 3D objects in indoor environments in real time. Originally, the idea was to pair Sentinel with a camera and use the existing LIDAR sensor, then employ a signal fusion network to combine the data and outperform existing 2D and 3D pipelines. Then, the computation would be performed on an FPGA or embedded device to attain real-time computation. However, I set my timeline a little too aggressively. At the start, my approach was to use an NVIDIA Jetson Nano to run existing KITTI models (KITTI is a challenging 3D dataset, a useful benchmark for 3D object detection and classification). The Jetson Nano actually gave me a lot of grief. The primary issue was the ARM-based architecture, which required me to build several libraries from scratch, which took an extremely long time. In the end, I was only able to get a few models running, and had very little time to actually pair the camera and LIDAR sensor. However, I got to explore the state of the art in 3D classification, including testing of Google's Objectron model as well as some of the top-performing KITTI models. I also learned a lot about how to allocate time and perform literature reviews. Even though functionally Sentinel Prime was a failure, I learned a lot and will carry this forward in my career.

I also got the chance to test out some virtual simulators such as Microsoft AirSim, which I definitely aim to return to for another project.

Screenshot captured in the middle of an AirSim simulation

Advisor

Professor Deming Chen

Overview

Sentinel Prime was a continuation of Project Sentinel. Sentinel Prime's goal was to detect and classify 3D objects in indoor environments in real time. Originally, the idea was to pair Sentinel with a camera and use the existing LIDAR sensor, then employ a signal fusion network to combine the data and outperform existing 2D and 3D pipelines. Then, the computation would be performed on an FPGA or embedded device to attain real-time computation. However, I set my timeline a little too aggressively. At the start, my approach was to use an NVIDIA Jetson Nano to run existing KITTI models (KITTI is a challenging 3D dataset, a useful benchmark for 3D object detection and classification). The Jetson Nano actually gave me a lot of grief. The primary issue was the ARM-based architecture, which required me to build several libraries from scratch, which took an extremely long time. In the end, I was only able to get a few models running, and had very little time to actually pair the camera and LIDAR sensor. However, I got to explore the state of the art in 3D classification, including testing of Google's Objectron model as well as some of the top-performing KITTI models. I also learned a lot about how to allocate time and perform literature reviews. Even though functionally Sentinel Prime was a failure, I learned a lot and will carry this forward in my career.

I also got the chance to test out some virtual simulators such as Microsoft AirSim, which I definitely aim to return to for another project.

Screenshot captured in the middle of an AirSim simulation

Advisor

Professor Deming Chen

Overview

Sentinel Prime was a continuation of Project Sentinel. Sentinel Prime's goal was to detect and classify 3D objects in indoor environments in real time. Originally, the idea was to pair Sentinel with a camera and use the existing LIDAR sensor, then employ a signal fusion network to combine the data and outperform existing 2D and 3D pipelines. Then, the computation would be performed on an FPGA or embedded device to attain real-time computation. However, I set my timeline a little too aggressively. At the start, my approach was to use an NVIDIA Jetson Nano to run existing KITTI models (KITTI is a challenging 3D dataset, a useful benchmark for 3D object detection and classification). The Jetson Nano actually gave me a lot of grief. The primary issue was the ARM-based architecture, which required me to build several libraries from scratch, which took an extremely long time. In the end, I was only able to get a few models running, and had very little time to actually pair the camera and LIDAR sensor. However, I got to explore the state of the art in 3D classification, including testing of Google's Objectron model as well as some of the top-performing KITTI models. I also learned a lot about how to allocate time and perform literature reviews. Even though functionally Sentinel Prime was a failure, I learned a lot and will carry this forward in my career.

I also got the chance to test out some virtual simulators such as Microsoft AirSim, which I definitely aim to return to for another project.

Screenshot captured in the middle of an AirSim simulation

Advisor

Professor Deming Chen

Overview

Sentinel Prime was a continuation of Project Sentinel. Sentinel Prime's goal was to detect and classify 3D objects in indoor environments in real time. Originally, the idea was to pair Sentinel with a camera and use the existing LIDAR sensor, then employ a signal fusion network to combine the data and outperform existing 2D and 3D pipelines. Then, the computation would be performed on an FPGA or embedded device to attain real-time computation. However, I set my timeline a little too aggressively. At the start, my approach was to use an NVIDIA Jetson Nano to run existing KITTI models (KITTI is a challenging 3D dataset, a useful benchmark for 3D object detection and classification). The Jetson Nano actually gave me a lot of grief. The primary issue was the ARM-based architecture, which required me to build several libraries from scratch, which took an extremely long time. In the end, I was only able to get a few models running, and had very little time to actually pair the camera and LIDAR sensor. However, I got to explore the state of the art in 3D classification, including testing of Google's Objectron model as well as some of the top-performing KITTI models. I also learned a lot about how to allocate time and perform literature reviews. Even though functionally Sentinel Prime was a failure, I learned a lot and will carry this forward in my career.

I also got the chance to test out some virtual simulators such as Microsoft AirSim, which I definitely aim to return to for another project.

Screenshot captured in the middle of an AirSim simulation

Advisor

Professor Deming Chen

Video summarizing Project Sentinel

Overview

Project Sentinel doubled as my junior year research project as well as a submission to the 2019-2020 TiM $10K Challenge. The TiM $10K Challenge is an annual competition hosted by SICK. Inc, a German company that manufactures sensors for factory and logistics automation. The goal of the challenge is to use a TiM781 2D LIDAR sensor in any unique way. A colleague and I heard about this challenge and sent a proposal for an autonomous robot that could navigate indoor environments and detect intruders. This was inspired by the lack of any companies developing indoor LIDAR applications (the only company we could find had went bankrupt). Our proposal was accepted and we set out to design the robot. My colleague designed a novel mechanism which could rotate the LIDAR sensor in 3 dimensions, in a gimbal-like fashion. The robot would use a SLAM algorithm to map the environment. Unfortunately, the complexity of the algorithm and the time constraint of being a full-time student in college led to the algorithms never being finished. Even though we did not place in the competition, we were extremely proud of the progress we made. As electrical lead, my responsibility was to get Sentinel operational and communicating with the various sensors and databases.

Robot sensors and hardware

MPU-6050 accelerometer, which was used to correctly orient the LIDAR data in 3D space
The robot's ambulation was controlled by 2 motors and the robot mechanism was controlled by its own motor.
Arduino MEGA: Control the motors with a PID algorithm was tuned to rotate the mechanism in a smooth manner.
Raspberry Pi 3: Communicate with LIDAR sensor via Ethernet. Communicate with AWS servers using WiFi.

Sentinel in all of his glory

Software

Point-cloud clustering algorithm implemented in Python
AWS DynamoDB for data storage and S3 buckets to store visualization files
Electron application to view environment scans

Screenshot of the Electron application with a point cloud loaded in

Overview

I've always had an interest in using AI for text generation. One of my friends is a part of a website called Hybris Forum where they publish articles discussing technology, culture, and the dysfunction of technology with society. That same friend suggested I write an article as well, but writing it definitely not my strong suit. This was the perfect opportunity to experiment with text generation AIs. The current state of the art is GPT-3, a transformer network developed by OpenAI. Unfortunately, GPT-3 is not available to the public, because the text it generates is too realistic to that written by humans.

Rather than go through the effort of training my own network, I decided to use GPT-2. The creators have open sourced a smaller version of GPT-2, which implies that it is bad enough to be given open access to, which is something I found out firsthand. The way I generated the article was by writing a long essay, and then finetuning the 355M model of GPT-2. After this, I generated lots of output text with input prompts. It was pretty painful to sort through the outputs and get something usable, and after spending a few days I didn't have enough text for an essay. Out of frustration, I turned to InferKit, a working demo of GPT-2. This was useful for the transitions in the essay.

Check my Git to find the final Colab notebook I used. Unless GPT-3 gets released, I won't be pursuing this project any further. I would honestly call this a failure, but the final essay (also on my Git) is pretty coherent.

Overview

The RISC-V pipelined CPU is the capstone assignment in ECE 411: Computer Organization and Design. This is an intensive course that teaches fundamentals in computer architecture and then those fundamentals are designed in System Verilog. Working in a group with 2 others, we designed a 5-stage 32-bit classic RISC-V processor that could perform hazard detection and data forwarding.

My contributions

I played a significant role in implementing the base CPU and had the chance to augment the CPU with the RISC-V M extension, which supports multiplication and division operation. I decided to use the well-known Wallace Tree to achieve a faster multiplication than an algorithm like add-shift. For the divider, I used a shift-subtract algorithm.

Future work

Although I enjoyed this course, I feel that I could accomplish a lot more with more time. I am planning to revisit this CPU design and augment additional features, such as a tournament branch predictor, multiple-way L1 caches, and . My ultimate goal is to program an FPGA with this CPU and run actual code on it. I might even pursue Tomasulo’s algorithm, as that algorithm makes much more sense to me than a pipeline. Due to academic integrity violations, I can’t upload the CPU from my class but I will update my GitHub if I make something else not in a class.

Overview

This was the final project for ECE 408, Applied Parallel Programming. We had a selection of open-ended problems to choose from for our final; my group and I chose to speed up the smallpt implementation of raytracing, which only works on spheres.

Output of the raytracing algorithm

Details

The smallpt implementation of raytracing works by passing in a description of the “scene”, which consists of objects (spheres), lights, and a camera. The algorithm then approximates the complicated rendering equation by replacing the ray integral with a monte carlo sample that has the same average value as the integral. A series of samples are averaged to output a smooth image. The picture above is an example of the output of the raytracing algorithm. We were given the original smallpt implementation, which was run on a CPU and served as our benchmark to beat. The sequential implementation uses a recursive approach to approximate the rendering equation.

The algorithm was ported over to CUDA by utilizing two CUDA kernels. The first kernel is used to initialize random numbers and the other kernel is for running the ray tracing code parallelized across the pixels. For the class, we had to time our kernels on the university GPU cluster, which uses TITAN V GPUs. I used my 2060S to test out the code locally.

After porting the algorithm over to CUDA, we further improved the raytracing algorithm by:

Downsampling: A good enough image (constrained by the professor to be ~100 MSE when compared to the sequential output) can be achieved by passing in less samples for the monte carlo portion of the algorithm. In the original implementation, we used 5000 samples, but we were able to reduce this by half and remain within the bounds. This kind of output could be upscaled using DLSS if a higher resolution output is required.
Depth constraining: The ray bounding portion of the algorithm is where the load imbalance comes in. Not every ray in the scene bounces the same number of times, so not every thread does the same amount of work. I confirmed this by using the NVIDIA Nsight Compute Profiler on my personal GPU (2060S). The profiler warned me that we were exceeding 80% of the GPU compute resources and it pointed to the radiance function as the source. After some experimenting, we noted that rays that continue after 10 bounces do not contribute to the final image enough, so we capped the ray bounce limit to 10.
Double replacement: The original code used doubles, which we replaced with single-precision floats. This uses half the bits but gets an acceptable MSE.
Fast math: There is a compiler option called -use_fast_math. This flag tells CUDA to use intrinsic float functions that are faster but might be less accurate. This aggressively optimizes the float functions, and I saw a huge speedup on my personal GPU.

Our results are summarized below:

Algorithm	System	Code	Time(s)	MSE
Sequential	Ryzen 7 2700X	Sequential, Iterative	2040	N/A
Downsampling	TITAN V (RAI)	Parallel	14	50.27
Downsampling	NVIDIA 2060S	Parallel	141	49.9
Depth Constraint	TITAN V (RAI)	Parallel	13	31.5
Depth Constraint	NVIDIA 2060S	Parallel	13	32.6
Single-point floats	TITAN V (RAI)	Parallel	19	32.4
Single-point floats	NVIDIA 2060S	Parallel	17	32.5
cuRAND	TITAN V (RAI)	Parallel	10	33.2
cuRAND	NVIDIA 2060S	Parallel	14	33.3
All optimizations combined	TITAN V (RAI)	Parallel	2	50.5
All optimizations combined	NVIDIA 2060S	Parallel	3	50.5

Overview

This was the final project for ECE 391, an intensive design course where I worked with a group of 4 to write code to design a unix-like operation system. This operating system (dubbed LC-4 after our university’s toy ISA, LC-3) featured device drivers (for terminal, file system, interrupt controller, real-time clock), support for system calls, context-switching, virtualization, and a round-robin scheduler.

Details

The following are some details that I worked on to implement this OS.

Device Drivers
- Interrupt controller: I programmed the PIC-8925A interrupt controller to interface with our OS. After this was complete, we could have the keyboard and real-time clock register as interrupts.
- Real-time clock: All programs need some way to track time. I studied the datasheet for the RTC chip in order for it to interface with our OS.
System calls
- Once the interrupts were enabled, I set up support for system calls to be made.
Context-switching
- In order to run user programs, there is a context-switch that needs to happen: from the kernel space to the user space. This context switch needed considerable assembly code and something or other
Scheduling
- This was one of my favorite parts of the OS. At the point, we had three terminals and coded them such that they ran all at once. The scheduler would context switch between all 3 terminals using a special clock chip that was connected to interrupt line 0

One of my group members uploaded a video of our final OS here.

Overview

This was our final project for ECE 385, an introductory course about realizing digital designs on FPGAs. The project is named "Project LD", which is short for "Projects Legends Never Die", which is a nod to our professor, whose profile picture on our class website is the "Legends Never Die" meme.

Details

This project was originally meant to be augmented reality beer pong (without the beer). The goal was to track a bouncing ping pong ball using a camera in 3-dimensions in realtime and then superimpose the path of the bouncing ball on the video feed as well as superimpose the path that should have been taken to get the ball into the cup. We were able to get a successful 2D track of the ball's position and scale, but did not have time to work on the 3D track. For this project, we used the DE2-115 expansion board with the Altera Cyclone IV E FPGA. We were provided with the 1.3 megapixel camera module, and spent a majority of the project interfacing the camera with the FPGA. By the end of 2 weeks, we were able to have a fully functioning 1.3 megapixel camera outputting its feed via VGA to a computer monitor. In addition, we were able to interface the NIOS II E microcontroller as a System-on-chip to toggle the camera settings. We made heavy use of exposure, red gain, blue gain, and green gain settings to achieve the best picture quality we could. The tracking was done very similar to how the visual effects software Adobe After Effects achieves its 2D motion track: In After Effects, you choose the point you want to track, and it generates a small box on the screen. Frame-by-frame, it then tracks the change in position and scale by looking at the change in high contrast points within the box. We made an FPGA-module to do the exact same thing, except in realtime. It worked rather well, but could not keep the track if the ball was dropped. The reason for this is we need to add a module that accomplishes frame interpolation. Since a falling ball falls very fast relative to the frame, comparing the frame before the drop to the frame after the drop will show a large vertical change between frames. Frame interpolation will guess where the ball would have been between the frames, and would allow for a much better track.

Progress video

The HackMe Group

Overview

Every year, UIUC holds a competition called a Hackathon. The hackathon is a 36-hour competition where the competitors are asked to design (usually code) anything. At the end of the 36 hours, the results are judged based on merit and usefulness of the submissions. One of my friends has always had an interest in the concept of Electroencephalography (EEG waves). While usually used for diagnosing brain disorders (such as epilepsy and seizure-related disorders), there is actually much more information that can be gleaned from these EEG waves - and this premise is where Project HackMe was born. Everyone's brain generates miniscule electrical impulses (miniscule here meaning ~50 microvolts). By finding the frequency of these waves and then doing some signal processing, we can characterize a person's state. One of the key features of our project to show we could do all of this non-invasively and still gather useful information from the data gathered. Then, we can map a person's waves to thoughts by using advanced machine learning techniques.

Details

The idea is novel, but is a bit ambitious for a 36 hour competition. Instead, we set out to do a proof of concept where we would show that waves could be captured and then translated to a rough thought. My friend had already purchased some electrodes. We then took these electrodes and fed them directly into a 24-bit ADC (During the competition, there was no additional filtering done to the signal. Given more time, we would have designed a low pass filter circuit to properly filter the input signal). The ADC was a part of a Raspberry Pi 3 shield, which allowed us to easily access the data using simple Python scripts. Since the Raspberry Pi has WiFi built-in, it was simple to upload this data to an Azure database (we used Azure because it was free, however, it was not worth it. We lost countless hours trying to set it up on the Raspberry Pi). Once the data was on the server, the project split into a few different areas: Internet of Things (IoT) and Classification. These sections are discussed in more detail below.

IoT: As a commercial product, we imagined this being a beanie. The concept was that the beanie could house a custom PCB to perform the wave extraction and signal processing. It would then send the results to the cloud for further post processing and analysis. The idea of a beanie came up because people wear beanies for extended periods of time and we would be able to extract much more data and thus make meaningful observations on the resulting data. To demonstrate an IoT application, we showed that we could toggle the lights in a room just by thinking. This was shown by hooking an LED up to a Particle IoT board and toggling it based on the output from the EEG headset. We ended up with a very sophisticated mood ring.

Classification: Analyzing the frequency content of the waves can indicate the general feeling of the user. Some of the most common EEG waves:

Delta (3 Hz): Most commonly found in deep cycles of sleep
Theta (3.5 to 7 Hz): Most commonly found in children. Implies an abnormality in the person if they are an adult
Alpha (7.5 to 13 Hz): Most commonly found in people who are relaxing and is eradicated by any deep concentration
Beta: (14 - 38 Hz): Most commonly found in people who are thinking a lot of thoughts at once
Gamma: (38 - 42 Hz): Greater than the frequency of neuronal firing, gamma waves relate to processing of different brain areas at once.

The data was sent into a rudimentary Matlab linear classifier. Given more time, this would probably be implemented with a CNN that would be trained per individual user. This project was very well received at the 2019 Hackathon. It won the Caterpillar and Particle Design Awards, and was also a runner-up for the Hackathon. More information can be found here.

IFE competition, summer 2018

Overview

Illini Formula Electric (IFE) is a club at UIUC where we design and build a formula-style electric racecar from scratch. The club is entirely student-run. In the summer we compete at the FSAE competition in several events. I was a member of IFE for two years, detailed below.

2017-2018

We were limited to 300V (that limit has since be raised to 600V). The battery that our car runs off of is comprised of 336 LiFePO4 cells that are wired together in a series-parallel combination that yields 300V and 175A overall. The competition rules require us to monitor the temperature and voltage of each battery cell. The old method of doing this was using the Elithion Proprietary Battery Management System (BMS). This system only runs on very old team laptops, which are archaic, cumbersome, and limited to a hardwire connection. As a freshman, I designed a PCB that could read data off the CAN bus and then output it over bluetooth to a laptop. I also developed a GUI that was capable of outputting the data in realtime. This was done in C# using the .NET framework.

Screenshot of GUI application

2018-2019

After my first year on IFE, I got promoted to the leader of the Data Acquisition and Quantitative Analysis (DAQA) team, whose primary goal is to log data from all the sensors on the car, timestamp them, and then upload it to a server. It gathers data from 4 accelerometers, 30 strain gauges, a GPS, the position of the steering wheel, the coolant temperature, the brake pressure, the throttle and regen pedal potentiometer, CAN, hall effect sensors, and the voltage of the low voltage battery pack. The system consisted of Raspberry Pi Zero boards with a custom PCB on top of each Pi. There would be one board near each tire and one in the center, by the driver's seat, which would distribute the data evenly across each board. Each Pi would then send data to the central pi, which would then timestamp and upload the data. The data would then be parsed and analyzed using AWS. Due to time constraints and hardware issues, the final system did not work as intended. However, it was a valuable learning experience.

Render of board developed for DAQA

Close up of STEVE's flight controller

Overview

S.T.E.V.E. (which stands for Self Teaching Elevated Vehicle Entity), is a drone designed from scratch that was designed to serve as an aid during natural disasters. S.T.E.V.E. was designed for Senior Tech, which was a high school capstone course where we could work on any STEM related project for a year. The concept was to create an autonomous drone capable of surveying locations where individuals stranded in dangerous situations could be without risking the life of an emergency responder. To accomplish this, we made a fully featured drone with a custom flight controller, camera to view the surroundings (to live stream what the environment looks like back to a VR headset at the base station), a speaker with an onboard AI (to communicate to a victim of a natural disaster), and sensors (to make sure it doesn't fly into any obstacles as well as update location). Even though we were extremely ambitious and did not meet all of our goals, this project was ultimately a success. The project was met with high praise and was presented at a limited engineering expo at Navistar. This is also the project that made me realize I wanted to be a Computer Engineer, as this project was worked on during the time in which I applied to colleges. Working on this project made me realize my love for combining hardware and software to produce something greater than the sum of its parts.

Progress video

Flight Controller

A crucial part of any drone is the flight controller. The flight controller is responsible for controlling the speed of each motor to Most drone projects will use an inexpensive off-the-shelf flight controller that takes care of all the flight algorithms. All you have to do is plug in the motors and battery to have a functional drone. However, we thought it would be better as a learning experience if we designed and programmed the flight controller from scratch. We used an Arduino MEGA as our primary microcontroller and an inexpensive MPU-6050 as our Inertial Measurement Unit (IMU). We then progreammed a PID controller to realize our flight controller. This took a bulk of our school year (and grew into a thousand line plus program) but was an incredibly rewarding experience. The microcontroller was programmed in C/C++ using the Arduino IDE.

Proof of concept of PID

Camera/Virtual Reality Headset

The goal here was to come up with a way to stream camera footage from the drone back to a virtual reality headset. This could be used to allow emergency responders to remotely survey a disaster area without the need to send in personnel. From an engineering standpoint, it is an interesting feature to try to implement. We used a Raspberry Pi 3 as the computer and Raspberry Pi Camera for the camera. There were two reasons we went with this combination: (1) Raspberry Pis (and their cameras) are cheap, easy-to-use and well documented, and (2) This allowed to split the hardware for the project into two categories: flight essential and not flight essential. One of the most important factors optimized in a flight controller is how long the main loop of the code takes. The faster (typically) the better. By separating the hardware into what was essential for flight and what wasn't, we could could aggressively optimize the flight controller and still have other devices on the drone. If we tried to get the Arduino to compute and transfer the camera footage, the flight loop might get severely impacted and the drone would no longer fly smoothly.

Speaker/AI

This is also not flight essential hardware and was supported by the Raspberry Pi (this was made simple by the fact that there is an audio out jack on the Pi). The main goal here was to give STEVE a natural language artificial intelligence so that STEVE could talk to people and let them know help is on the way. The initial thought was to use simple if-else constructs and hard-code the speaker outputs (i.e. "Help is on the way"), but then we had the idea of using IBM AI APIs to get a natural language output from the Raspberry Pi. After struggling for a few weeks with the IBM documentation, we contacted them and they sent us a sample Android app that used their APIs. After this, it was easy to link this with the Raspberry Pi and output it through the speaker. We trained the AI and attempted to make the outputs as helpful as possible in the relevant situation.

Object detection and location updates

One fundamental aspect of a drone is to not fly into nearby objects. Real drones use laser-detection to detect nearby objects, but those sensors are expensive and difficult to get working so we chose to use inexpensive ultrasonic sensors. Our end goal was to have 6 sensors in each axis, 3 in each direction (for instance, we would have 3 pointing directly upwards and 3 pointing directly downwards, thus covering the z-axis). We used a MUX shield, which adds 37 additional inputs to the Arduino and we ended up writing our own custom drivers to capture the ultrasonic values (it turns out provided library functions start to fail when you try to use an external shield). The driver code worked perfectly fine, but due to time constraints we were not able to interface it with the rest of the drone. We were able to add an off-the-shelf GPS module, which was capable of logging the drone's coordinates. Combined with the ultrasonic sensors, we were able to show that we could capture coordinates in 3-dimensions.

GPS output visualized

Even though we were not able to meet all of the goals we set for the project, we consider STEVE an incredible success.

Overview

This course is all about the synthesis between hardware and software, working together to make a Linux-like operating system. This starts from nothing more than a few boot files. The final operating system has a read-only filesystem, interrupt support, device support (Keyboard, Interrupt Controller, Real time clock), paging, and a round-robin scheduler for multitasking. The operating system was completed in a group of 4.

Concepts covered:

Interfacing C to assembly, macros, stack frame and calling convention
Synchronization: primitives, memory semantics, mutual exclusion, semaphores, scheduling, and race conditions
Interrupts: controlling generation and handling, chaining, cleanup code, interactions with device functionality
Resource management: virtualization and protection, virtual memory and hardware support
Exceptions and signals: exceptions due to instructions, memory accesses, and floating-point operations; signal semantics and delivery
Device programming: basic abstractions, character and block devices
File system abstractions: disk layout, access control lists and capabilities, log-structured and traditional filesystems as design problem
I/O interface: file descriptors, buffering, control operations, memory mapping

Harris Mohamed

About

Academic Research and Publications

Personal Projects

Industry Experience

Teaching Experience

Coursework