Explore Projects

VIRTIO_F_IN_ORDER is a new feature presented in VIRTIO 1.1. As mentioned on the project description page, VIRTIO_F_IN_ORDER is a feature that devices and drivers can negotiate when the device uses descriptors in the same order in which they were made available by the driver. This feature can help devices and drivers batch buffers and improve performance. Currently the devices and drivers available in Linux and QEMU do not support the VIRTIO_F_IN_ORDER feature. The only implementation is available in DPDK for the virtio-net driver. I will spend this summer to implement VIRTIO_F_IN_ORDER feature in both Linux and QEMU, and in both split and packed virtqueue layouts. Patches will be sent as soon as possible.

gccrs is a full alternative implementation of the Rust language ontop of GCC with the goal to become fully upstream with the GNU toolchain. One of the steps to reach its implementation counterpart's parity (rustc) is the support of inline assembly. Enabling this feature allows programmers to work on low level situation where some extra performance is always needed. The project focuses on adding implementation for two built-in Rust macros: asm!(), and global_asm!(). The gcc compiler will be able to detect parse the assembly code within asm!, and global_asm! macro, converting them to gcc assembly format to eventually generate code.

<p>JuxtaPiton is an architecture being developed at Princeton’s Parallel Group for heterogeneous ISA research. For this project, I will replace the existing PICORV32 core with the open-source ao486 core to have x86 ISA support along with the OpenSPARC T1’s SPARC V9. This kind of a heterogeneous system enables reuse of a lot of legacy x86 code. We also try to interface the L1 cache level of ao486 with the L1.5 cache subsystem of OpenPiton. This allows us to harness Piton’s P-Mesh subsystem which maintains cache coherency across both the cores.</p>

The rise of ARM processors has created new binary targets for pre-compiled executables. Additionally, there are tales of widespread use of operating systems that aren't linux? In the ideal case a `pack` user could create a build for an abritrary architecture and operating system, regardless of the host system they used to run the command. Expected outcome: Improved multi-architecture (including ARM) and multi-os "cross-compilation" support in [pack](https://github.com/buildpacks/pack/) Upstream Issue (URL): https://github.com/buildpacks/pack/issues/1459 and https://github.com/buildpacks/pack/issues/1460

This project aims to support the detection and reporting of SPDX License Expressions. Currently, FOSSology uses regular expressions, full-text match, and fuzzy match to scan licenses, stores all types of license expressions as a list of licenses, and wrongly classifies them as conjunctive licenses or disjunctive licenses. It also stores license exceptions as licenses and does not differentiate exceptions from licenses. In the project, I will be working on scanning license expressions using regular expressions with Ojo, storing them in the database, creating UI components to see license expressions in the file clearing page, and finally updating reports to export the expressions in the correct format.

A guest operating system (OS), running inside a Confidential Virtual Machine (CVM), does not know the state information, such as log data or memory usage, of the secure module COCONUT-SVSM, which is responsible for managing the CVM. This information can be useful for the guest OS to understand the environment it is running in. A new protocol has been defined to enable the retrieval of this information. This project implements this observability protocol. The work is divided into several steps, which are also the deliverables: the implementation of a SVSM-side handler for the protocol, a guest-side handler, which is a Linux device driver, and a user-space tool, which uses the Linux device driver to retrieve and save the information.

The most efficient algorithm to sample from a log-concave distribution, that volesti supports is the Hamiltonian Monte Carlo with leapfrog integration. The leapfrog method is an Euler method that in each step evaluates the gradient of the log-probability density function of the target distribution. To sample from a log-concave distribution volesti currently requires a function that evaluates this gradient as an input. However, there are plenty of applications that require sampling from a distribution where the gradient of the log-probability density function is unknown. This project will address this problem and will provide to volesti routines of automatic differentiation of a multivariate function. Then, a function that evaluates the log-density will suffice to sample from the target distribution.

<p>Volumetric viewing of scientific phenomena is an important feature in modern scientific visualizing tools because it can express specific phenomena which can’t be visualized using the default vertex based geometric renderers/rasterizers; as electron clouds and Van der Waals interactions, as well it’s been proposed in Molecular Graphics journal in 1989; so now is a proper time to integrate it into 3Dmol.js rendering system as It has already gained the level of maturity when volume rendering becomes an essential milestone. During my work I will investigate different approaches of visualizing volumes, select the techniques that are modern, efficient and fit the best to the existing code.</p>

This project aims to allow using dynamically loaded Clang plugins on windows by adding support for building LLVM and Clang as shared libraries on Windows with all the public c++ API exported and dynamically linking to them. Part of the process will be automated with a tool built using the Clang tooling API to automatically add export macros on the appropriate class and functions declarations in llvm public headers. Deliverables: End users can use custom clang plugins with official windows build of Clang. The llvm windows binary install size can be greatly decreased by dynamically linking llvm tools to the LLVM and Clang shared libraries.

<p>The current version of Pocket Code doesn't have support for <strong>particle physics</strong>. This project proposes to implement and integrate a particle system that would allow the addition of smoke, fire, and other such particle effects in the games! The visibility, position, type, velocity, color, and other such properties of the particles could be controlled using the new "particles" bricks that will be added as part of the project! This will enable effects like a glowing effect around coins and collectibles, glowing trail behind fast-moving objects like a ball or a meteorite, flames, smoke, explosions, etc. giving much greater freedom and control to users and allows them to let their creative juices flowing!</p>

The objective of this project is to provide alias support in concerto language . For example import statement like "import {document as d} from Library" to be supported by the end of this project. This would allow us to import two models with same name in a single file by aliasing them to different names which is currently not supported in the language. Doing this would require changes in both the concerto-parser and concerto-runtime . The project requires compiler design and programming language knowledge. The stack used in project is NodeJs and written in typescript. The concerto-parse is written in PEGJS.

Problem: Currently, Joomla items such as articles are limited to a single category, which makes it difficult to organize content that belongs to multiple contexts. While tags are sometimes used as a workaround, they do not integrate with core features such as routing, menus, and structured layouts in the same way as categories. Solution: This project introduces multi-category support by implementing a generic mapping table (#__category_item_map). It preserves backward compatibility and SEO integrity by using a "Primary Category" as the main reference for routing, workflows, and parameter inheritance. Deliverables: A new database schema, an updated backend interface for multi-category selection, frontend updates to reflect multi-category assignments in item views and category listings, model-level integration for custom fields, extended batch operations, unit tests, and documentation.

Workbench is a multi-language code sandbox for GNOME. It is prevalent in the GNOME Ecosystem and is helpful to both professional and amateur developers. It provides a sane environment where you can quickly iterate on code in a GNOME application without going through the usual slow recompile cycles. Typescript is a language developed by Microsoft that adds static type annotations to JavaScript. This language has been trendy in the JavaScript/Web Development industry, and recently, we have seen projects like ts-for-gir that allow TypeScript to be used to build GNOME applications. Adding TypeScript support to Workbench would help developers write more robust code instead of the usual fragile JavaScript and help GNOME app developers get the most out of the growing TypeScript ecosystem by using new and modern features and syntax like decorators, iterables, etc.

<p>The goal of this project is to enable the Trace Compass to analyze and display some basic information using Event Recording infrastructure. Trace Compass is a software for viewing and analyzing any type of logs or traces. The basic information to analyze and display information may include CPU usage, IRQ analysis(IRQ Statistics, IRQ Table, IRQ vs Count, IRQ vs Time), Linux Kernel(Control Flow, Resources) etc. The advanced support for Trace Compass could include dynamic memory traces, stack usage, network packet flow etc.</p> <p>If successful in the generation of trace data(LTTng) then, it can be transferred via TCP/UDP(TCP already available) method from target running RTEMS application to the host.</p>

<p>XMPP RFCs and Specifications define connection establishment over TCP, BOSH and websockets. Smack currently establishes connection between Server and Client using TCP and BOSH. BOSH suffers from high transport overhead as compared to TCP. Also various issues with long polling are suggested to have an impact upon BOSH based systems [RFC 6202 Section 2.2]. WebSocket provides an alternative to the limitation of inefficient communication between the server and the client by providing bi-directional, full-duplex, real-time client/server communications. The protocol consists of an opening handshake followed by basic message framing, layered over TCP [RFC 6455]. Adding WebSocket support to Smack will allow it to establish a continuous Client-Server connection with less overhead.</p>

Java PathFinder (JPF) is an extensible software analysis framework for java bytecode which can be used to check for concurrency defects like deadlocks, and unhandled exceptions like NullPointerExceptions and AssertionErrors. Symbolic PathFinder (SPF) is its extension that enables symbolic execution of java programs. This proposal outlines my plan to contribute to The JPF Team by working on the Support portfolio of solvers in SPF Project during Google Summer of Code 2025. The main goal of this project is to enable the simultaneous invocation of multiple constraint solvers, where execution halts as soon as any solver returns a satisfactory result. This approach is expected to enhance SPF's ability to handle a broader range of constraints. This Project will extend SPF branch sv-comp. The outcome will enhance SPF’s scalability and applicability in symbolic execution tasks.

<p>Rizin currently relies upon manually writing code for adding a new CPU or an IO port. This implementation is unfit as the vast and growing ecology of hardware components such as CPUs and SoCs regularly implement a part of architecture with custom instructions, registers, and address configurations with trivial differences, making it infeasible to maintain all of them inside Rizin.</p> <p>Providing a level of abstraction in handling this entropy in embedded systems, by supporting editable CPU and platform profiles is the goal of this project. This will also make adding and maintaining these ports easier with less interaction with Rizin’s core. This project also aims to add more flexibility in having a way of importing existing hardware data description documents so that reverse engineering on particular chipsets is easier. This will also help us to memory map the peripheral accesses and registers to provide a better reverse engineering experience. This, in turn, could also be extended to benefit Rizin in terms of compatibility and the end users in terms of user experience.</p>

This project aims to add VMM acceleration support to QEMU on FreeBSD, bridging the gap between QEMU’s userspace emulation and FreeBSD’s kernel-based VMM hypervisor. Currently, QEMU on FreeBSD lacks hardware acceleration, forcing users to rely on slower TCG emulation or switch to bhyve. I plan to modify QEMU’s memory management to work with VMM’s kernel-allocated guest memory. Additionally, I will adapt VMM to make non-critical devices (HPET, RTC) optional, letting QEMU handle them in user space. This would enable a hybrid interrupt model (kernel vLAPIC + emulated IOAPIC). The deliverables for this project would be a working -accel=vmm backend for QEMU. I will also add some changes to VMM, allowing some of the in-kernel devices to be made optional. Finally, I will add comprehensive documentation and benchmarks for the libvmmapi interface. This will enable near-native performance for QEMU on FreeBSD, expanding virtualization options while maintaining compatibility with existing QEMU tooling.

The current Continuum Mechanics has been undergoing continuous developments in the past years and has developed functionalities for solving and analyzing various structures which are important in the field of Mechanics like Beam, Truss and Cable. This project aims to improve the existing classes by implementing additional functionalities for plotting various graphs and diagram related to the existing structures in the Cable Module and introducing new classes to solve and analyze the Arch structure and introducing some new features for other existing classes. The features planned to be implemented for the Arch structure is a solver for finding the internal forces, reactions, bending moment developed in the Arch under external forces and moments and methods to get a detailed diagram and plot forces generated in the structure. The improvements in the Cable class would allow the user to plot the tensions developed in the Cable under various types of external loads and also get a detailed diagram which would be helpful in analyzing various details like the position and shape of the cable. The project's implementation will expand Sympy's capabilities, allowing users to tackle a broader range of engineering problems with ease.

The main goal of this project is to add support for handling runtime exceptions in SPF that will improve SPF's performance on SV-COMP benchmarks. There are two main reasons why SPF is losing many points in runtime exception verification tasks. First, SPF is not systematically exploring execution paths where symbolic variables could lead to runtime exceptions like NullPointerException and StringIndexOutOfBoundsException, resulting in many incorrect false results where actual exceptions are not detected. Second, the SV-COMP execution script is lacking proper property detection and result classification for runtime exception scenarios. To address these problems, we should extended SPF to have additional choices that will explore potential runtime exception scenarios when symbolic variables could represent values that can raise them. To deal with this, we can analyze why SPF outputs wrong answers for certain verification tasks and fix them. This systematic approach to runtime exception path exploration will help fix SPF's behavior, improving its scores on SV-COMP benchmarks. This project extends the SPF branch, sv-comp.

This proposal addresses the outdated support for Braille embossers in printing systems, which currently relies on shell scripts and PPD files. To modernize this support and ensure long-term sustainability, the plan is to transition to the newer CUPS infrastructure using Printer Applications. The project involves converting shell scripts into filter functions in libcupsfilters and developing a Printer Application for easy configuration of Braille embossers. The deliverables include a software solution for Braille embosser support within the CUPS ecosystem, enhancing accessibility and usability for users.

<p>coala is a linting and code fixing tool with support for many languages. Having a configuration file is essential to make full use of coala. Having a standardised configuration format like TOML helps. coala currently has an INI style configuration. Also, INI style configuration has certain limitations when it comes to custom sub-level parsing. The LineParser and ConfParser becomes complex and error-prone. This project will allow developers to quickly implement new features and will allow users to write configuration files in a format that they are already familiar with.</p> <p>This project would focus on :</p> <ol> <li>Allowing the user to create configuration files in TOML</li> <li>Providing coala with the functionality to create TOML configuration files from sections</li> <li>Creating a tool to convert .coafile to TOML configuration file</li> <li>Allowing coala-quickstart to generate configuration files in TOML as well.</li> <li>Creation of TOMLLintBear and a repository of good configuration files to allow users to easily bootstrap their projects.</li> </ol>

The project has the aim of providing offline data entry capability into the CARE form-based data collection system. Currently, users experience interruptions when network connectivity is lost, preventing data entry while in the field with the application opened in a disconnected state. This project will maintain coordination with CARE forms during offline status, allowing users to continue using the app normally.The approach will implement an offline-first architecture that includes application caching, local storage, and sync capabilities. I plan to implement caching while using Workbox and Service Workers to cache the appropriate application assets and form definitions so that the user interface can load and continue to operate without a network connection. I plan to use IndexedDB, managed through Dexie.js, to store the form responses as local data storage on the user’s device. After connectivity is re-established, an automatic background sync process will use React Query and PQueue to ensure reliable and conflict-free data sync with the established database on the central server. Conflict resolution strategies will be included to maintain integrity, safe and complete data from being 'lost' when multiple users could be updating the same data at the same time.