From satyarthsingh115@gmail.com Wed Apr 2 17:57:07 2025 From: satyarthsingh115@gmail.com (Satyarth Singh) Date: Wed, 2 Apr 2025 22:27:07 +0530 Subject: [OpenAFS-devel] GSOC Project 2025 on Command Line Completion Message-ID: --000000000000cfcef00631ce8b63 Content-Type: text/plain; charset="UTF-8" Respected sir/madam, I have prepared a draft proposal for the GSOC project on implementing command line completion for OpenAFS. I have been going through the code base and trying to form an understanding of the architecture. Along with this I tried building and installing the source code but I was getting some errors. I am working on resolving the errors. I have prepared a draft proposal but I still have to make changes in it. It would be a great help if you could please review it and suggest any changes, if my proposal meets your requirement or not and whether the time line suggested by me needs to be stricter or can be relaxed in terms of deliverables. How should the testing be done and what methods are recommended? Is there any existing framework or should we use virtual machines? I have attached the proposal in the mail. Kindly review and provide feedback. Proposal link: GSOC draft proposal --000000000000cfcef00631ce8b63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Respected sir/madam,
I have prepared a draft proposal = for the GSOC project on implementing command line completion for OpenAFS. I= have been going through the code base and trying to form an understanding = of the architecture. Along with this I tried building and installing the so= urce code but I was getting some errors. I am working on resolving the erro= rs.

I have prepared a draft proposal but I still h= ave to make=C2=A0 changes in it. It would be a great help if you could plea= se review it and suggest any changes, if my proposal meets your requirement= or not and whether the time line=C2=A0suggested by me needs to be stricter= or can be relaxed in terms of deliverables.=C2=A0=C2=A0

=C2=A0How should the testing be done and what methods are recommende= d?
=C2=A0Is there any existing framework or should we use virtual= machines?=C2=A0
=C2=A0I have attached the proposal in the mail. = Kindly review and provide=C2=A0feedback.

Proposal = link:=C2=A0GSOC draft proposal
--000000000000cfcef00631ce8b63-- From jenishtogadiya549@gmail.com Thu Apr 3 00:57:23 2025 From: jenishtogadiya549@gmail.com (Jenish Togadiya) Date: Thu, 3 Apr 2025 05:27:23 +0530 Subject: [OpenAFS-devel] Introduction & Interest in OpenAFS Client/Server Load Testing with K6 Message-ID: My name is Jenish Togadiya, and I am interested in contributing to the OpenAFS Client/Server Load Testing with K6 project. I have experience in C programming, network programming, and performance testing. While I am new to k6, I am eager to learn and contribute effectively to this project. I have gone through the project description and would love some guidance on how to get started. Are there any specific repositories, documentation, or beginner-friendly tasks I should explore first? Looking forward to your guidance and contributing to OpenAFS. Best regards, Jenish Togadiya From alokdangre@gmail.com Thu Apr 3 08:46:46 2025 From: alokdangre@gmail.com (Alok Dangre) Date: Thu, 3 Apr 2025 13:16:46 +0530 Subject: [OpenAFS-devel] Re Message-ID: --0000000000007a3d740631daf9d3 Content-Type: text/plain; charset="UTF-8" confirm 146034 --0000000000007a3d740631daf9d3 Content-Type: text/html; charset="UTF-8"
confirm 146034
--0000000000007a3d740631daf9d3-- From anvit.pusalkar@gmail.com Thu Apr 3 18:03:12 2025 From: anvit.pusalkar@gmail.com (Anvit Pusalkar) Date: Thu, 3 Apr 2025 22:33:12 +0530 Subject: [OpenAFS-devel] Re: Pending Projects for GSoC Message-ID: --0000000000004af8cf0631e2bfcb Content-Type: text/plain; charset="UTF-8" Greetings, My name is Anvit Pusalkar and I'm a B.Tech computer science student from India. Are the projects listed as pending (https://www.openafs.org/projects.html) available to be worked on? Will they be accepted as a GSoC project? I have already sent a proposal on the idea "Implement Fileserver Memory Autotuning" (which is a GSoC approved project) . I am quite interested in OpenAFS and I would be interested in the pending idea "Make AFS support IPv6". Will that idea be considered for GSoC? Thank You. Regards, Anvit Pusalkar --0000000000004af8cf0631e2bfcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

My name is Anvit = Pusalkar and I'm a B.Tech computer science student from India.

Are the projects listed as pending (https://www.openafs.org/projects.html) avai= lable to be worked on? Will they be accepted as a GSoC project?
<= br>
I have already sent a proposal on the idea "Implement Fi= leserver Memory Autotuning" (which is a GSoC approved project) . I am = quite interested in OpenAFS and I would be interested in the pending idea &= quot;Make AFS support IPv6". Will that idea be considered for GSoC?

Thank You.

Regards,
Anvit Pusalkar

--0000000000004af8cf0631e2bfcb-- From akshikamunshi27@gmail.com Fri Apr 4 04:19:15 2025 From: akshikamunshi27@gmail.com (Akshika) Date: Fri, 4 Apr 2025 08:49:15 +0530 Subject: [OpenAFS-devel] Query regarding GSOC project Message-ID: --00000000000076c1900631eb5a74 Content-Type: text/plain; charset="UTF-8" Hey I am Akshika , I am a 3rd year Btech Student and have been into network security research for some time now. I am very keen to work on the GSOC project idea which involves making netcat-like utility for Rx protocol . I have a few doubts regarding the same. # What is the scope of the project? # Are there any specific features/pain-points that need to be prioritised in this new tool? (anything missing / extra to be added) # I have gone through the Rx protocol specifications(doc/txt/rx-spec.txt ) in the github repository and started setting up the project( Fixing errors that I am getting rn ) . What should be my next steps? --00000000000076c1900631eb5a74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey I am Akshika , I am a 3rd year Btech Student and have = been into network security research for some time now.=C2=A0 I=C2=A0am=C2= =A0very=C2=A0 keen to work on the GSOC project idea which involves making n= etcat-like utility for Rx protocol . I have a few doubts regarding the same= .

# What is the scope of the=C2=A0project?
# Are ther= e any specific features/pain-points that need to be prioritised in this new= tool? (anything missing / extra to be added)
# I have gone throu= gh the=C2=A0Rx protocol specifications(doc/txt/rx-spec.txt ) in the github = repository and started setting up the project( Fixing errors that I am gett= ing rn=C2=A0) . What should be my next steps?


=

--00000000000076c1900631eb5a74-- From akshikamunshi27@gmail.com Fri Apr 4 05:15:19 2025 From: akshikamunshi27@gmail.com (Akshika) Date: Fri, 4 Apr 2025 09:45:19 +0530 Subject: [OpenAFS-devel] Query reagrding extended coding period Message-ID: --0000000000000632cc0631ec2334 Content-Type: text/plain; charset="UTF-8" I see September 1 - November 9 marked as extended coding period on the gsoc timeline , does implementing NETCAT for Rx meet the eligibility criteria for this ? What will be the timeline for this project and what is the final deadline for its submission? --0000000000000632cc0631ec2334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I see September 1 - November 9 marked as extended coding p= eriod=C2=A0on the gsoc timeline=C2=A0=C2=A0, does implementing NETCAT for R= x meet the eligibility criteria for this ? What will be the timeline for th= is project and what is the final deadline for its submission?
--0000000000000632cc0631ec2334-- From projects.utkarshmaurya@gmail.com Fri Apr 4 18:34:30 2025 From: projects.utkarshmaurya@gmail.com (Utkarsh Maurya) Date: Fri, 4 Apr 2025 23:04:30 +0530 Subject: [OpenAFS-devel] [GSoC 2025] Proposal: Multi-page Folio Support in OpenAFS Linux Kernel Module Message-ID: --0000000000002af73e0631f74d62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear OpenAFS Developers, I hope this message finds you well. My name is Utkarsh Maurya, a Computer Science undergraduate with a strong interest in systems programming and Linux kernel development. I=E2=80=99m r= eaching out to express my interest in contributing to OpenAFS through Google Summer of Code 2025. Over the past few weeks, I=E2=80=99ve been exploring the OpenAFS codebase a= nd studying its interaction with the Linux kernel=E2=80=99s memory management subsystem=E2=80=94especially around the osi_VM interface. My proposal focus= es on integrating multi-page folio support into the OpenAFS Linux kernel module, aligning it with recent changes in the upstream kernel. I=E2=80=99ve prepared a draft proposal that outlines the project=E2=80=99s = motivation, technical background, deliverables, and timeline. I=E2=80=99d be very grate= ful if you could take a look and share any feedback or suggestions for improvement= . =F0=9F=94=97 Proposal Link: https://docs.google.com/document/d/197UpExN5kyjimYdr839tbah8Aj_Xj7s97LZWvbb= ePss/edit?usp=3Dsharing In support of this project, I=E2=80=99d also like to share some of my relev= ant work: myOwnOS: A bare-metal operating system for Raspberry Pi 3B. Baking Pi for RPi 3B: A port of the Baking Pi course using the GCC ARM EABI toolchain. Kernel Carnival: A Linux kernel lab environment for writing and testing kernel modules. I=E2=80=99m excited about the opportunity to contribute and learn through t= his project. Please let me know if there=E2=80=99s anything specific I should d= ive deeper into or revise in the proposal. Looking forward to your guidance. Best regards, Utkarsh Maurya projects.utkarshMaurya@gmail.com GitHub: https:github.com/pro-utkarshM --0000000000002af73e0631f74d62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear OpenAFS Developers,

I hope this message finds you well.
My name is Utkarsh Maurya, a Computer Science unde= rgraduate with a strong interest in systems programming and Linux kernel de= velopment. I=E2=80=99m reaching out to express my interest in contributing = to OpenAFS through Google Summer of Code 2025.

<= /div>
Over the past few weeks, I=E2=80=99ve been exploring= the OpenAFS codebase and studying its interaction with the Linux kernel=E2= =80=99s memory management subsystem=E2=80=94especially around the osi_VM in= terface. My proposal focuses on integrating multi-page folio support into t= he OpenAFS Linux kernel module, aligning it with recent changes in the upst= ream kernel.

I=E2=80=99v= e prepared a draft proposal that outlines the project=E2=80=99s motivation,= technical background, deliverables, and timeline. I=E2=80=99d be very grat= eful if you could take a look and share any feedback or suggestions for imp= rovement.

<= br>
In support of this project, I=E2=80=99d also lik= e to share some of my relevant work:

myOwnOS: A bare-metal operating system for Raspberry Pi 3B.
Baking Pi for RPi 3B: A port of the Baking Pi course u= sing the GCC ARM EABI toolchain.
Kernel Carnival: A = Linux kernel lab environment for writing and testing kernel modules.
<= div dir=3D"auto">
I=E2=80=99m excited about the = opportunity to contribute and learn through this project. Please let me kno= w if there=E2=80=99s anything specific I should dive deeper into or revise = in the proposal.

Looking= forward to your guidance.

Best regards,
Utkarsh Maurya
--0000000000002af73e0631f74d62-- From zhengfeili.alex@gmail.com Fri Apr 4 19:55:48 2025 From: zhengfeili.alex@gmail.com (Zhengfei Li) Date: Fri, 4 Apr 2025 14:55:48 -0400 Subject: [OpenAFS-devel] [GSoC Proposal FollowUp] Netcat for Rx by Zhengfei Li (Alex) In-Reply-To: References: Message-ID: --000000000000f8008a0631f86f77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear OpenAFS community and developers, I hope you all are doing well. I wish to follow up on my previous email regarding my proposal for Netcat for Rx. After discussing with GSoC Alumni, I got great advice on that I can show my skills and understanding of the project through a review of the source code. Therefore, I am writing to follow up with my edited proposal with a dedicated part demonstrating my understanding. When you have a moment, could you help me review my new proposal? I am really looking forward to your guidance and contributing to OpenAFS in the future! Best, Zhengfei Li (Alex) <--- Below is the plain text of my proposal ---> # Biography Greetings! I'm Alex, a graduating Computer Science major from Swarthmore College, passionate about file systems and networks projects. This fall, I will be joining the Carnegie Mellon University MSCS program, eager to explore deeper into networking. I have completed courses in OS and Computer Networks, gaining robust understanding of file systems, TCP/UDP, socket programming with C and Python. In the "Simple Firewall" course project, I extensively used netcat for tasks like debugging with manual protocol interactions and setting up simple server or listeners to test firewall rules. This experience greatly improved my understanding of network security and my skills in network analysis and troubleshooting. Familiarizing myself with the Rx protocol, I achieved a primary understanding that Rx is a connection-oriented protocol that operates over UDP and supports service multiplexing, and explored tools like `rxgen' and `rxdebug', though I have not yet used them productively. As a quick learner, I am confident converting my theoretical knowledge into implementation practices in days. I have work experience related to software. During summer 2023, I joined a Computer Education research team and collaborated on developing an interactive online exercise webpage based on an open-source project Runestone. I took a lead in program design and this experience also involves navigating extensive code bases, enhancing my ability to comprehend and contribute to large projects. The website is already live, with functionalities receiving acclaims from our faculties and students. In summer 2024, I worked as a Business Data Analyst intern at SETVI, a SaaS startup, where I greatly improved my communications and formalized my documentation practices. I am passionate about contributing to OpenAFS through the `netcat for Rx' project, observing it as a natural extension of my academic and personal interest. I really look forward to working with the community, learning more about OpenAFS, and developing tools for Rx-based services. ## Availability I plan to start this 12-week project on June 16, with a commitment around 8 hours on each weekday. In addition, I have daily family obligations of around 3 hours and allocate 1 hour daily to exercise. During the weekends, I plan to spend 5 hours on prototyping a startup idea. \newpage # Project Information ## Netcat for Rx OpenAFS uses RxRPC to support the distributed files system, which provides reliable ordered message delivery, multiplexed channels and built-in security features. However, there is no simple command-line utilities for Rx network debugging and investigation. This project proposes to build a netcat-like tool for Rx protocol. This would fill the gap in the current toolset for OpenAFS administration and development community. For the functionalities of `netcat for Rx', we hope to achieve the following objectives: - Test Rx network connectivity (e.g., with echo request) - Debug Rx interactions - Automate tests particularly for OpenAFS services. - Rx server and listener emulation Considering the massive amount of requests, C program with tight time and space complexity would be designed for performance. I plan to draw from established netcat sources and use cases (like port scanning) and design comparable utility functionalities. In addition, I would also investigate into unique features of Rx (like channel multiplexing) and devise helpful tools with reference to developers' daily experiences and demands. ## Background Understanding of Source In an effort to prepare for the development, I performed a review and research on both RxRPC implementation as well as the canonical netcat source code. A summary of my understanding is provided below: ### Understanding RxRPC With reference to rxrpc.rst, RxPRC is a reliable two-phase protocol built on UDP. The purpose is to create virtual network connections such that operational or control data and messages could be sent to the Andrew File System. The protocol adopts two-layer design using both session layer (for connections) and presentation layer (for conversion of data format). The two-phase protocol operation requires clients sending request blob, server processing requests, server replying, and clients receiving a blob of reply= . The architecture supports multiple virtual connections sharing the same transport endpoint, with each connection identified by 7 parameters (local/remote addresses, ports, direction, connection ID, service ID). For reliability, both hard-ACK and soft-ACK are available. For API, we can use AF\_RXRPC with control messages like RXRPC\_USERCALL\_ID, RXRPC\_ABORT as metadata. I also focused on source code like af\_rxrpc.c and ar-internal.h, and I gained a better idea of internal resource management, structured data handling, protocol mechanics and error handling. Such information contributes to my following understanding of this project: - Map RxRPC=E2=80=99s internal state management to a simplified interface = that can be controlled via command-line options. - Utilize RxRPC data structures and error-handling patterns to ensure that the new RxNetcat tool behaves predictably even under adverse network conditions. - Design test cases that mirror real-world scenarios in RxRPC communication, thereby reinforcing the tool=E2=80=99s reliability and diagn= ostic value. ### Understanding netcat Reviewing the netvat.c, I am again amazed by the compact yet versatile commandline utility supporting the operations from both client and server. Following is some of my observations that I hope to adopt in my future development: - Option Parsing and Configuration: processing command-line with standard libraries like getopt.h enables user-friendly and extensible functionality. Therefore, our RxNetcat can have operational flags for details indictating whether the tool connects to a remote host or listens for incoming connections. - Socket Management and I/O Multiplexing: Netcat=E2=80=99s implementation = of socket creation, connection, and data relay (via loops using select() or poll()) serves as an excellent model for building similar functionality tailored to Rx. This pattern is crucial for ensuring that the tool can handle multiple simultaneous I/O operations, which is particularly relevant given Rx=E2=80=99s multiplexed channel capabilities. - Error Reporting and Resource Clean-up: The emphasis on graceful error handling and proper resource deallocation in netcat=E2=80=99s codebase has = informed my approach to developing robust and maintainable code. ### Implications By synthesizing these approaches, the project will: - Adapt netcat=E2=80=99s straightforward, reliable network handling to wor= k with Rx=E2=80=99s unique protocol features such as channel multiplexing and buil= t-in security. - Enable diagnostic features like echo requests and connection tracing that reflect both the simplicity of netcat and the complexity of RxRPC. - Provide a foundation for automated testing and stress evaluation by mirroring netcat=E2=80=99s efficient I/O loop structure in an environment t= ailored for Rx. ## Project Schedule and Deliverables Following is a tentative plan with a duration of 12 weeks. For each phase, I summarized the objectives and the deliverables. ### Week 1-2 Objectives: - Conduct research on Rx protocol (and ideally gather user demand for the toolset) - Review netcat functionalities and code bases - Finalize the scope of features to be completed in 12 weeks Deliverables: - Scoping document of functionalities ### Week 3-6 Objectives: - Design the tool architecture and develop a command-line interface prototype - Iteratively improve the design based on the project scale and feedback Deliverables: - A documentation of functionalities with design - Code for prototype ### Week 7-10 Objective: - Implement the features - Implement ``simple'' unit tests for individual features Deliverables: - Code for implementation - Unit test report for features ### Week 11-12 Objectives: - Finalize the implementation - Conduct thorough testing that simulates a typical developer workflow - Finalize the documentation - Prepare for project evaluation Deliverables: - Complete code base - Comprehensive test files streamlining use cases - Complete user documentation and maintainer documentation - Final project report if needed ## Test Plan For each individual functionality, my unit tests will cover: - each individual modules - command line interface - memory safety For holistic testing, I plan to simulate a typical workflow of a developer by: - Simulate an OpenAFS environment - Stress testing the tool with high volumes of requests, incomplete requests and more to evaluate robustness - Evaluate program performance - Verify the accuracy of output presentation - Improve upon feedback On Thu, Mar 27, 2025 at 11:55=E2=80=AFAM Zhengfei Li wrote: > Dear OpenAFS community and developers, > > I hope this email finds you all well. > > My name is Alex (Zhengfei Li), a graduating Computer Science major from > Swarthmore College. I am writing to reach out regarding my Google Summer = of > Code proposal titled "Netcat for Rx". > > In my proposal, I plan to develop a Netcat-like command-line utility for > Rx and provide a simple tool for developers to test connectivity, debug, > and automate tasks. I would greatly appreciate any feedback or guidance o= n > the status of this project and my proposal. Specifically, I am eager to > understand: > - unique aspects of Rx that demand special attention > - suggestions on the tool's scope > - any potential pitfalls I should be aware of > > Thank you very much for your time reviewing my proposal. I am open to any > feedback, engaging with you, and refining my proposal with your expertise= . > > Best, > Alex > > <--- Below is the plain text of my proposal ---> > # Biography > > Greetings! I'm Alex, a graduating Computer Science major from Swarthmore > College, passionate about file systems and networks projects. > This fall, I will be joining the Carnegie Mellon University MSCS program, > eager to explore deeper into networking. > > I have completed courses in OS and Computer Networks, gaining a robust > understanding of file systems, TCP/UDP, and socket programming with C and > Python. In my "Simple Firewall" course project, I extensively used netcat > for tasks like debugging with manual protocol interactions and setting up > simple servers or listeners to test firewall rules. This experience great= ly > improved my understanding of network security and my skills in network > analysis and troubleshooting. > > Familiarizing myself with the Rx protocol, I achieved a primary > understanding that Rx is a connection-oriented protocol that operates ove= r > UDP and supports service multiplexing. I explored tools like `rxgen' and > `rxdebug', though I have not yet used it productively. I am a quick learn= er > and I am confident that I can convert my theoretical knowledge into > implementation practices in days. > > I have work experience related to software. During the summer of 2023, I > joined a Computer Education research team and collaborated on developing = an > interactive online exercise webpage based on an open-source project > Runestone. I took a lead in program design and this experience also > involves navigating extensive code bases, enhancing my ability to > comprehend and contribute to large projects. The website is already live, > with functionalities receiving acclaim from our faculties and students. I= n > the summer of 2024, I worked as a Business Data Analyst intern at SETVI, = a > SaaS startup, where I greatly improved my communications and formalized m= y > documentation practices. > > I am passionate about contributing to OpenAFS through the `netcat for Rx' > project, observing it as a natural extension of my academic and personal > interest. I really look forward to working with the community, learning > more about OpenAFS, and developing tools for Rx-based services. > > ## Availability > > I plan to start this 12-week project on June 16, with a commitment of > around 8 hours each weekday. In addition, I have daily family obligations > of around 3 hours and allocate 1 hour daily to exercise. During the > weekends, I plan to spend 5 hours on prototyping a startup idea. > > # Project Information > > ## Netcat for Rx > > OpenAFS uses RxRPC to support the distributed files system, which provide= s > reliable ordered message delivery, multiplexed channels and built-in > security features. However, there are no simple command-line utilities fo= r > Rx network debugging and investigation. This project proposes to build a > netcat-like tool for Rx protocol. This would fill the gap in the current > toolset for OpenAFS administration and development community. > > For the functionalities of `netcat for Rx', we hope to achieve the > following objectives: > -Test Rx network connectivity (e.g., with echo request) > -Debug Rx interactions > -Automate tests particularly for OpenAFS services. > -Rx server and listener emulation > > Considering the massive amount of requests, C programs with tight time an= d > space complexity would be designed for performance. I plan to draw from > established netcat sources and use cases (like port scanning) and design > comparable utility functionalities. In addition, I would also investigate > unique features of Rx (like channel multiplexing) and devise helpful tool= s > with reference to developers' daily experiences and demands. > > ## Project Schedule and Deliverables > > Following is a tentative plan with a duration of 12 weeks. For each phase= , > I summarized the objectives and the deliverables. > > ### Week 1-2 > > Objectives: > -Conduct research on Rx protocol (and ideally gather user demand for > the toolset) > -Review netcat functionalities and code bases > -Finalize the scope of features to be completed in 12 weeks > > Deliverables: > -Scoping document of functionalities > > ### Week 3-6 > > Objectives: > -Design the tool architecture and develop a command-line interface > prototype > -Iteratively improve the design based on the project scale and feedba= ck > > Deliverables: > -A documentation of functionalities with design > -Code for prototype > > ### Week 7-10 > > Objective: > -Implement the features > -Implement ``simple'' unit tests for individual features > > Deliverables: > -Code for implementation > -Unit test report for features > > ### Week 11-12 > > Objectives: > -Finalize the implementation > -Conduct thorough testing that simulates a typical developer workflow > -Finalize the documentation > -Prepare for project evaluation > > Deliverables: > -Complete code base > -Comprehensive test files streamlining use cases > -Complete user documentation and maintainer documentation > -Final project report if needed > > ## Test Plan > > For each individual functionality, my unit tests will cover: > -each individual modules > -command line interface > -memory safety > > For holistic testing, I plan to simulate a typical workflow of a develope= r > by: > -Simulate an OpenAFS environment > -Stress testing the tool with high volumes of requests, incomplete > requests and more to evaluate robustness > -Evaluate program performance > -Verify the accuracy of output presentation > -Improve upon feedback > --000000000000f8008a0631f86f77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear OpenAFS community and developers,

I hope you all are doing well. I wis= h to follow up on my previous email regarding my proposal for Netcat for Rx= .

After discussing with GSoC Alumni, I got great a= dvice on that I can show my skills and understanding of the project through= a review of the source code. Therefore, I am writing to follow up with my = edited proposal with a dedicated part demonstrating my understanding.
=

When you have a moment, could you help me review my new= proposal? I am really looking forward to your guidance and contributing to= OpenAFS in the=C2=A0future!

Best,
Zheng= fei Li (Alex)

<--- Below is the plain text of m= y proposal --->
# Biography

Greetings! I'm Alex, a = graduating Computer Science major from Swarthmore College, passionate about= file systems and networks projects.
This fall, I will be joining the Ca= rnegie Mellon University MSCS program, eager to explore deeper into network= ing.

I have completed courses in OS and Computer Networks, gaining r= obust understanding of file systems, TCP/UDP, socket programming with C and= Python. In the "Simple Firewall" course project, I extensively u= sed netcat for tasks like debugging with manual protocol interactions and s= etting up simple server or listeners to test firewall rules. This experienc= e greatly improved my understanding of network security and my skills in ne= twork analysis and troubleshooting.

Familiarizing myself with the Rx= protocol, I achieved a primary understanding that Rx is a connection-orien= ted protocol that operates over UDP and supports service multiplexing, and = explored tools like `rxgen' and `rxdebug', though I have not yet us= ed them productively. As a quick learner, I am confident converting my theo= retical knowledge into implementation practices in days.

I have work= experience related to software. During summer 2023, I joined a Computer Ed= ucation research team and collaborated on developing an interactive online = exercise webpage based on an open-source project Runestone. I took a lead i= n program design and this experience also involves navigating extensive cod= e bases, enhancing my ability to comprehend and contribute to large project= s. The website is already live, with functionalities receiving acclaims fro= m our faculties and students. In summer 2024, I worked as a Business Data A= nalyst intern at SETVI, a SaaS startup, where I greatly improved my communi= cations and formalized my documentation practices.

I am passionate a= bout contributing to OpenAFS through the `netcat for Rx' project, obser= ving it as a natural extension of my academic and personal interest. I real= ly look forward to working with the community, learning more about OpenAFS,= and developing tools for Rx-based services.

## Availability

= I plan to start this 12-week project on June 16, with a commitment around 8= hours on each weekday. In addition, I have daily family obligations of aro= und 3 hours and allocate 1 hour daily to exercise. During the weekends, I p= lan to spend 5 hours on prototyping a startup idea.

\newpage

= # Project Information

## Netcat for Rx

OpenAFS uses RxRPC to = support the distributed files system, which provides reliable ordered messa= ge delivery, multiplexed channels and built-in security features. However, = there is no simple command-line utilities for Rx network debugging and inve= stigation. This project proposes to build a netcat-like tool for Rx protoco= l. This would fill the gap in the current toolset for OpenAFS administratio= n and development community.

For the functionalities of `netcat for = Rx', we hope to achieve the following objectives:

=C2=A0- Test R= x network connectivity (e.g., with echo request)
=C2=A0- Debug Rx intera= ctions
=C2=A0- Automate tests particularly for OpenAFS services.
=C2= =A0- Rx server and listener emulation


Considering the massive am= ount of requests, C program with tight time and space complexity would be d= esigned for performance. I plan to draw from established netcat sources and= use cases (like port scanning) and design comparable utility functionaliti= es. In addition, I would also investigate into unique features of Rx (like = channel multiplexing) and devise helpful tools with reference to developers= ' daily experiences and demands.

## Background Understanding of = Source

In an effort to prepare for the development, I performed a re= view and research on both RxRPC implementation as well as the canonical net= cat source code. A summary of my understanding is provided below:

##= # Understanding RxRPC

With reference to rxrpc.rst, RxPRC is a reliab= le two-phase protocol built on UDP. The purpose is to create virtual networ= k connections such that operational or control data and messages could be s= ent to the Andrew File System.

The protocol adopts two-layer design = using both session layer (for connections) and presentation layer (for conv= ersion of data format).=C2=A0 The two-phase protocol operation requires cli= ents sending request blob, server processing requests, server replying, and= clients receiving a blob of reply.

The architecture supports multip= le virtual connections sharing the same transport endpoint, with each conne= ction identified by 7 parameters (local/remote addresses, ports, direction,= connection ID, service ID). For reliability, both hard-ACK and soft-ACK ar= e available.

For API, we can use AF\_RXRPC with control messages lik= e RXRPC\_USERCALL\_ID, RXRPC\_ABORT as metadata.

I also focused on s= ource code like af\_rxrpc.c and ar-internal.h, and I gained a better idea o= f internal resource management, structured data handling, protocol mechanic= s and error handling.

Such information contributes to my following u= nderstanding of this project:

=C2=A0- Map RxRPC=E2=80=99s internal s= tate management to a simplified interface that can be controlled via comman= d-line options.
=C2=A0- Utilize RxRPC data structures and error-handling= patterns to ensure that the new RxNetcat tool behaves predictably even und= er adverse network conditions.
=C2=A0- Design test cases that mirror rea= l-world scenarios in RxRPC communication, thereby reinforcing the tool=E2= =80=99s reliability and diagnostic value.


### Understanding netc= at

Reviewing the netvat.c, I am again amazed by the compact yet vers= atile commandline utility supporting the operations from both client and se= rver. Following is some of my observations that I hope to adopt in my futur= e development:


=C2=A0- Option Parsing and Configuration: process= ing command-line with standard libraries like getopt.h enables user-friendl= y and extensible functionality. Therefore, our RxNetcat can have operationa= l flags for details indictating whether the tool connects to a remote host = or listens for incoming connections.
=C2=A0- Socket Management and I/O M= ultiplexing: Netcat=E2=80=99s implementation of socket creation, connection= , and data relay (via loops using select() or poll()) serves as an excellen= t model for building similar functionality tailored to Rx. This pattern is = crucial for ensuring that the tool can handle multiple simultaneous I/O ope= rations, which is particularly relevant given Rx=E2=80=99s multiplexed chan= nel capabilities.
=C2=A0- Error Reporting and Resource Clean-up: The emp= hasis on graceful error handling and proper resource deallocation in netcat= =E2=80=99s codebase has informed my approach to developing robust and maint= ainable code.


### Implications

By synthesizing these appr= oaches, the project will:

=C2=A0- Adapt netcat=E2=80=99s straightfor= ward, reliable network handling to work with Rx=E2=80=99s unique protocol f= eatures such as channel multiplexing and built-in security.
=C2=A0- Enab= le diagnostic features like echo requests and connection tracing that refle= ct both the simplicity of netcat and the complexity of RxRPC.
=C2=A0- Pr= ovide a foundation for automated testing and stress evaluation by mirroring= netcat=E2=80=99s efficient I/O loop structure in an environment tailored f= or Rx.


## Project Schedule and Deliverables
Following is a te= ntative plan with a duration of 12 weeks. For each phase, I summarized the = objectives and the deliverables.
### Week 1-2
Objectives:

=C2= =A0- Conduct research on Rx protocol (and ideally gather user demand for th= e toolset)
=C2=A0- Review netcat functionalities and code bases
=C2= =A0- Finalize the scope of features to be completed in 12 weeks

Deli= verables:

=C2=A0- Scoping document of functionalities

### Wee= k 3-6
Objectives:

=C2=A0- Design the tool architecture and develo= p a command-line interface prototype
=C2=A0- Iteratively improve the des= ign based on the project scale and feedback

Deliverables:

=C2= =A0- A documentation of functionalities with design
=C2=A0- Code for pro= totype

### Week 7-10
Objective:

=C2=A0- Implement the feat= ures
=C2=A0- Implement ``simple'' unit tests for individual feat= ures

Deliverables:

=C2=A0- Code for implementation
=C2=A0-= Unit test report for features

### Week 11-12
Objectives:

= =C2=A0- Finalize the implementation
=C2=A0- Conduct thorough testing tha= t simulates a typical developer workflow
=C2=A0- Finalize the documentat= ion
=C2=A0- Prepare for project evaluation

Deliverables:

= =C2=A0- Complete code base
=C2=A0- Comprehensive test files streamlining= use cases
=C2=A0- Complete user documentation and maintainer documentat= ion
=C2=A0- Final project report if needed

## Test Plan
For ea= ch individual functionality, my unit tests will cover:

=C2=A0- each = individual modules
=C2=A0- command line interface
=C2=A0- memory safe= ty

For holistic testing, I plan to simulate a typical workflow of a = developer by:

=C2=A0- Simulate an OpenAFS environment
=C2=A0- Str= ess testing the tool with high volumes of requests, incomplete requests and= more to evaluate robustness
=C2=A0- Evaluate program performance
=C2= =A0- Verify the accuracy of output presentation
=C2=A0- Improve upon fee= dback=C2=A0 =C2=A0=C2=A0


On Thu, Ma= r 27, 2025 at 11:55=E2=80=AFAM Zhengfei Li <zhengfeili.alex@gmail.com> wrote:
Dear OpenAFS com= munity and developers,

I hope this email finds you all well.

= My name is Alex (Zhengfei Li), a graduating Computer Science major from Swa= rthmore College. I am writing to reach out regarding my Google Summer of Co= de proposal titled "Netcat for Rx".

In my proposal, I plan= to develop a Netcat-like command-line utility for Rx and provide a simple = tool for developers to test connectivity, debug, and automate tasks. I woul= d greatly appreciate any feedback or guidance on the status of this project= and my proposal. Specifically, I am eager to understand:
- unique aspec= ts of Rx that demand special attention
- suggestions on the tool's s= cope
- any potential pitfalls I should be aware of

Thank you very= much for your time reviewing my proposal. I am open to any feedback, engag= ing with you, and refining my proposal with your expertise.

Best,Alex

<--- Below is the plain text of my proposal --->
# Bi= ography

Greetings! I'm Alex, a graduating Computer Science major= from Swarthmore College, passionate about file systems and networks projec= ts.
This fall, I will be joining the Carnegie Mellon University MSCS pro= gram, eager to explore deeper into networking.

I have completed cour= ses in OS and Computer Networks, gaining a robust understanding of file sys= tems, TCP/UDP, and socket programming with C and Python. In my "Simple= Firewall" course project, I extensively used netcat for tasks like de= bugging with manual protocol interactions and setting up simple servers or = listeners to test firewall rules. This experience greatly improved my under= standing of network security and my skills in network analysis and troubles= hooting.

Familiarizing myself with the Rx protocol, I achieved a pri= mary understanding that Rx is a connection-oriented protocol that operates = over UDP and supports service multiplexing. I explored tools like `rxgen= 9; and `rxdebug', though I have not yet used it productively. I am a qu= ick learner and I am confident that I can convert my theoretical knowledge = into implementation practices in days.

I have work experience relate= d to software. During the summer of 2023, I joined a Computer Education res= earch team and collaborated on developing an interactive online exercise we= bpage based on an open-source project Runestone. I took a lead in program d= esign and this experience also involves navigating extensive code bases, en= hancing my ability to comprehend and contribute to large projects. The webs= ite is already live, with functionalities receiving acclaim from our facult= ies and students. In the summer of 2024, I worked as a Business Data Analys= t intern at SETVI, a SaaS startup, where I greatly improved my communicatio= ns and formalized my documentation practices.

I am passionate about = contributing to OpenAFS through the `netcat for Rx' project, observing = it as a natural extension of my academic and personal interest. I really lo= ok forward to working with the community, learning more about OpenAFS, and = developing tools for Rx-based services.

## Availability

I pla= n to start this 12-week project on June 16, with a commitment of around 8 h= ours each weekday. In addition, I have daily family obligations of around 3= hours and allocate 1 hour daily to exercise. During the weekends, I plan t= o spend 5 hours on prototyping a startup idea.

# Project Information=

## Netcat for Rx

OpenAFS uses RxRPC to support the distribut= ed files system, which provides reliable ordered message delivery, multiple= xed channels and built-in security features. However, there are no simple c= ommand-line utilities for Rx network debugging and investigation. This proj= ect proposes to build a netcat-like tool for Rx protocol. This would fill t= he gap in the current toolset for OpenAFS administration and development co= mmunity.

For the functionalities of `netcat for Rx', we hope to = achieve the following objectives:
=C2=A0 =C2=A0 -Test Rx network connect= ivity (e.g., with echo request)
=C2=A0 =C2=A0 -Debug Rx interactions
= =C2=A0 =C2=A0 -Automate tests particularly for OpenAFS services.
=C2=A0 = =C2=A0 -Rx server and listener emulation

Considering the massive amo= unt of requests, C programs with tight time and space complexity would be d= esigned for performance. I plan to draw from established netcat sources and= use cases (like port scanning) and design comparable utility functionaliti= es. In addition, I would also investigate unique features of Rx (like chann= el multiplexing) and devise helpful tools with reference to developers'= daily experiences and demands.

## Project Schedule and Deliverables=

Following is a tentative plan with a duration of 12 weeks. For each= phase, I summarized the objectives and the deliverables.

### Week 1= -2

Objectives:
=C2=A0 =C2=A0 -Conduct research on Rx protocol (an= d ideally gather user demand for the toolset)
=C2=A0 =C2=A0 -Review netc= at functionalities and code bases
=C2=A0 =C2=A0 -Finalize the scope of f= eatures to be completed in 12 weeks

Deliverables:
=C2=A0 =C2=A0 -= Scoping document of functionalities

### Week 3-6

Objectives:<= br>=C2=A0 =C2=A0 -Design the tool architecture and develop a command-line i= nterface prototype
=C2=A0 =C2=A0 -Iteratively improve the design based o= n the project scale and feedback

Deliverables:
=C2=A0 =C2=A0 -A d= ocumentation of functionalities with design
=C2=A0 =C2=A0 -Code for prot= otype

### Week 7-10

Objective:
=C2=A0 =C2=A0 -Implement th= e features
=C2=A0 =C2=A0 -Implement ``simple'' unit tests for in= dividual features

Deliverables:
=C2=A0 =C2=A0 -Code for implement= ation
=C2=A0 =C2=A0 -Unit test report for features

### Week 11-12=

Objectives:
=C2=A0 =C2=A0 -Finalize the implementation
=C2=A0= =C2=A0 -Conduct thorough testing that simulates a typical developer workfl= ow
=C2=A0 =C2=A0 -Finalize the documentation
=C2=A0 =C2=A0 -Prepare f= or project evaluation

Deliverables:
=C2=A0 =C2=A0 -Complete code = base
=C2=A0 =C2=A0 -Comprehensive test files streamlining use cases
= =C2=A0 =C2=A0 -Complete user documentation and maintainer documentation
= =C2=A0 =C2=A0 -Final project report if needed

## Test Plan

Fo= r each individual functionality, my unit tests will cover:
=C2=A0 =C2=A0= -each individual modules
=C2=A0 =C2=A0 -command line interface
=C2= =A0 =C2=A0 -memory safety

For holistic testing, I plan to simulate a= typical workflow of a developer by:
=C2=A0 =C2=A0 -Simulate an OpenAFS = environment
=C2=A0 =C2=A0 -Stress testing the tool with high volumes of = requests, incomplete requests and more to evaluate robustness
=C2=A0 =C2= =A0 -Evaluate program performance
=C2=A0 =C2=A0 -Verify the accuracy of = output presentation
=C2=A0 =C2=A0 -Improve upon feedback=C2=A0 =C2=A0=C2= =A0
--000000000000f8008a0631f86f77-- From sawezfaisals123@gmail.com Sat Apr 5 07:28:25 2025 From: sawezfaisals123@gmail.com (Md. Sawez Faisal) Date: Sat, 5 Apr 2025 11:58:25 +0530 Subject: [OpenAFS-devel] [GSCO-2025 ][Openafs devel] Proposal : Implementing Command line completions for OpenAfs CLI Tools Message-ID: --0000000000008b69c80632021e17 Content-Type: multipart/alternative; boundary="0000000000008b69c70632021e15" --0000000000008b69c70632021e15 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear OpenAFS Community, I hope this message finds you well. My name is Sawez Faisal, and I=E2=80=99= m excited to share my proposal for Google Summer of Code 2025, focusing on implementing Bash and Zsh shell completions for OpenAFS command-line tools The goal of this project is to make OpenAFS commands more intuitive and efficient to use by adding intelligent tab-completion. I plan to start with static completions for the most common commands, then expand to dynamic flag suggestions by parsing --help outputs and man pages. This approach ensures the completions stay up to date as the tools evolve. My background in C and shell scripting, along with my experience working on CLI tools, gives me a solid foundation for this task. I=E2=80=99ve attached my full proposal for your review and would greatly ap= preciate any feedback, especially on technical feasibility and alignment with OpenAFS=E2=80=99s priorities. I=E2=80=99m particularly interested in hearin= g which commands or use cases the community finds most challenging and would benefit most from this improvement. Best regards, Sawez Faisal sawezfaisals123@gmail.com --0000000000008b69c70632021e15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear OpenAFS Community,

I hope t= his message finds you well. My=20 name is Sawez Faisal, and I=E2=80=99m excited to share my proposal for Goog= le=20 Summer of Code 2025, focusing on implementing Bash and Zsh shell=20 completions for OpenAFS command-line tools

The goal of this project is to make OpenAFS commands more intuitive and=20 efficient to use by adding intelligent tab-completion. I plan to start=20 with static completions for the most common commands, then expand to=20 dynamic flag suggestions by parsing --help outputs and man=20 pages. This approach ensures the completions stay up to date as the=20 tools evolve. My background in C and shell scripting, along with my=20 experience working on CLI tools, gives me a solid foundation for this=20 task.

I=E2=80=99ve attached my full proposal for your review and woul= d=20 greatly appreciate any feedback, especially on technical feasibility and alignment with OpenAFS=E2=80=99s priorities. I=E2=80=99m particularly inte= rested in=20 hearing which commands or use cases the community finds most challenging and would benefit most from this improvement.

Best regards,
S= awez Faisal

sawezfaisals123@gmail.com



--0000000000008b69c70632021e15-- --0000000000008b69c80632021e17 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="GSOC_PROPOSAL.docx" Content-Disposition: attachment; filename="GSOC_PROPOSAL.docx" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_m93tubu60 UEsDBBQACAgIANIyhVoAAAAAAAAAAAAAAAALAAAAX3JlbHMvLnJlbHOtkk1LA0EMhu/9FUPu3Wwr iMjO9iJCbyL1B4SZ7O7Qzgczaa3/3kEKulCKoMe8efPwHNJtzv6gTpyLi0HDqmlBcTDRujBqeNs9 Lx9g0y+6Vz6Q1EqZXCqq3oSiYRJJj4jFTOypNDFxqJshZk9SxzxiIrOnkXHdtveYfzKgnzHV1mrI W7sCtftI/Dc2ehayJIQmZl6mXK+zOC4VTnlk0WCjealx+Wo0lQx4XWj9e6E4DM7wUzRHz0GuefFZ OFi2t5UopVtGd/9pNG98y7zHbNFe4ovNosPZG/SfUEsHCOjQASPZAAAAPQIAAFBLAwQUAAgICADS MoVaAAAAAAAAAAAAAAAAEQAAAGRvY1Byb3BzL2NvcmUueG1sjVLLTsMwELzzFZHviZP0IWQlqQSo EhJFSBSBuBl7mxpix7Ld19/jJE1aoAduOzvj2Zez2V5WwRaMFbXKURLFKADFai5UmaOX5Ty8RoF1 VHFa1QpydACLZsVVxjRhtYEnU2swToANvJGyhOkcrZ3TBGPL1iCpjbxCeXJVG0mdh6bEmrIvWgJO 43iKJTjKqaO4MQz14IiOlpwNlnpjqtaAMwwVSFDO4iRK8EnrwEh78UHLnCmlcAcNF6U9Oaj3VgzC 3W4X7Uat1Pef4LfFw3M7aihUsyoGqMiOjRBmgDrggTcgXbmeeR3d3i3nqEjjdBLG4zCeLJOYjBOS xu8Z/vW+Mezi2hQNewI+5mCZEdr5G3bkj4THFVXlxi+8ABXeP7aSIdWcsqLWLfzRVwL4zcF7XMj1 Hclj7p8jJWSSktH0bKTeoK1sYCuav1ekbdEBNl3bzccnMNeNNAAfO+Eq6NJ9+Oc/Ft9QSwcI3V9x x2QBAADbAgAAUEsDBBQACAgIANIyhVoAAAAAAAAAAAAAAAAQAAAAZG9jUHJvcHMvYXBwLnhtbJ2R y27CMBBF9/2KyGJLbBJIEHKM+lBXSEVqCt0h1xkSV4lt2QbB39c0appu69Xcuddn/KDrS9dGZ7BO alWgWUxQBEroSqq6QG/l83SJIue5qnirFRToCg6t2R3dWm3AegkuCgTlCtR4b1YYO9FAx10cbBWc o7Yd90HaGuvjUQp40uLUgfI4ISTDcPGgKqimZgCinrg6+/9CKy1u53O78moCj9ESOtNyD4zi37LU nrel7IClJPQHRe+NaaXgPjwJ28gPCy/fM3Aep3EeJ5ONVKfL4X2ZHbJ5NAocwh0+QXicksnDSbbV NKF4DLuRd/1bs9kiJmF9B356dMtrcCyluC/oXtvKsXwWYn1JHxtuufBhA5sTsqR41BiZe+mbV8NF gMyz5E9sZIV5lteWm8axRX6bOsgghg9hX1BLBwg2hsx3OAEAACYCAABQSwMEFAAICAgA0jKFWgAA AAAAAAAAAAAAABwAAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxztZTLboMwEEX3+QrkfTCQ Nm0iIF20lbLopqIfYGAAK34ge2iTfn2NkuYhpVEjkaWvx2eOJY/jxVoK7xOM5VolJPQD4oEqdMlV nZCP7HX8SBbpKH4HwdCV2Ia31nNnlE1Ig9jOKbVFA5JZX7eg3E6ljWTolqamLStWrAYaBcGUmmMG SU+Y3rJMiFmWIfGyTQv/Yeuq4gU866KToPBMC2pxI8A6IjM1YEK2a99xCD3fPhqyfeNIRnC1OhhI xgXquWVf8F0xbpmwYTR5qvvcL7T8rXzTpZN4WSMYxf60ndzYtsdax605Nl3e+9Gt9Hg2C65Tvbux 6nU290PaqE7mYNy8HGz20aW3Nh1SotIKM5YLOEjso0sSD4POGyC6Sx9P3C7ZKYxievKRpD9QSwcI eKUXTygBAAB/BAAAUEsDBBQACAgIANIyhVoAAAAAAAAAAAAAAAARAAAAd29yZC9kb2N1bWVudC54 bWztHcly2zj2Pl+B0iGVVFuWZTuJo7Q9kzibqzodT8s9qeobRD5SiEGCBYCylVOf5gOm+tK/ly+Z 9wCSkhzZ2iUnUaViSVyAh7cvWH7+53UiWQ+0ESo9rjV392oM0kCFIo2Pa79fvKkf1ZixPA25VCkc 1/pgav88+cfPV61QBXkCqWXYQmpa6riW67Rlgi4k3NQTEWhlVGTrgUpaKopEAMVHrXhDH9e61mat RqN4aVdlkOK9SOmEW/yp44Z/5VXRV2N/b+9JQ4PkFuE1XZGZsrXeXf33Elk+dzVNr1dKh5lWARiD iEik7zfhIq2aae5NMWBqp3ojm6bnUPOroS5HAXnlbw5aNF81WYGxi2AU2HOtYHvNvRvttbs8g0Fr 8WKtvdUqz8rWkmCa0SZcX+YZYSxDinaEFLbvBj4Aqnm4GFQ3cTZfe0P803w8WwP7VQNJ0DqLU6V5 R6IkISSMhsewxdoJClRHhX36zNyfc+0+2rYvgV21elwe1y7g2r7Ep2oN97wIRXlnz1/6FJQXJETW X9PUUmPwWbSsq3v4MdJL22qVxq+TrMuNML4R87m8e7BfXjk1o9caVXtOJ7RMxgMcZ6bBgO5B7eRt +8Mp29/bf8zOtcqU4ZLVGb1m/csrB+vkA7Lgi7X2+KY90l2jJO+9o/Ew0L/yBG7F0vCDLdbmV/CZ veECqXkvRjoAr6Mb81F5eISvUenLaXAxnuVbN/m7289AS5FeMt0S4XFNn4X7tbsBPEst6BTsL/jW TfAMoT9y2DfN/YN/xQQuaaGbtKj6/VZ48K2w7/LOajF/uADmyQQYtAGxsN284xS/p0P92bO9e4j9 oXsrlk58ujH099Q0JvHFuCcJgReKdSAWKbtCJLeWrV6IZdAzwKtIGfgtJ6PMc6tqxZXj2v7TJ/Sj A+izAL2HP3iEPIGe8uEyRWHUxlSARijVUFwbGJnq6kQZeAdSKuaMXmQYsmiSp+hhsR12xrrojrG+ yhnXwELlEIGPs102vUleGOyTswccHYHnyYgd2WGcveToW0ml/X2DMUgeUrCBzPBaQkCqQwSGYWDC Tv24AhcTOFbB92OtyO3D55FcYNyLoTBWi05uIWSmbywkvoHyOzqNseZJgu/tso9dQQNV+pKawYbx 7ifs2DApLoG1VZgn7GHSZ9ziy5nFT+w2yI1VCZM8jXMeg+8eCYJ/HxHWEYRAYbiFEHTVFUvyoItX If2k+swo2aO+pLqqS+iBpC7RVSygTLiDxColDUuQIVmOZK5HWkAayv7udyUe8/DSh+wOxp2nQUiX 2+B4IX3xps0ibhDX3AJSFlDnBRxpy4RllgeXEq9qQMOCzCjDUS62GE0gmwVdLiWkMZgvf/4F1zyw ss9sFxiyTMhUhK3yFIkZ5bLgduS6K47yZBXqhbRoEH/tskokjRWoDyRwnTpJQtbnOugKi1KQa9hh +Er5dI+ghtSJaZ+eJu4mhYOcW0jM9G63ynUAxJ/z65WeMuugnRPMtQ4sWs+4SO/tuNFV7ADXgSCe 63jOUlmmtPX2BJkItRPQ9cSrJh648Bu1F17UKo+7zHTJvFCoL8Flb5ause7wSMZiZkZsLU9Tve8j NtEjRM0dgLdYp43Tn37y1sjhyQRaZJYkKRY9rxY4WQgRskjlaeiM3Q0KoXSj2CMVM04GBqkS4rss BMC+yBQVvsCbdmlVAxVChxsgc4f26wwNV3BJpjLTQumxBnMAONkzR/Y8Q5i0s7AQFnYY9VABFw6G uIkFUhlA+NxwKZmntCEYITWoTcg2gkRwNUOjh1Z0h1G6zeJ/SpcM8w1yFMJqdY6NIa4yZwdn5qZ/ 58r6LOIUFnCcids/OiiojTRAk4gsd1x7/OQpPaJF3B386qI34PKpk/n0dv9qrb79PXKN744SX/Qw 3uU+cThdxuI7YJN7EFmcsYBX4j6DbV8ROOiGk/JzvnjqwoBNQxRpDAMSEdbfc2cf1xhTvchj1J+b RoDX86liCr0CzTCQEbEXJHQxv/z5t5TeyAgrPg/UO4pRQP5DYQtI9RvXEhoX/EPf0xBdS7J7PGFU UnA25BrpTjUr5s3cGrEtkf81Q4u7eYyLiKUAKJTOHEdoORHH6DKY7qzG8R3S5TOGBVz+gtq+UHN5 Rn0ZuvJrnnTQ5rrr2cvQJ3GUpdC3aCFUOdKO1Jr5jErQffEAO+UYKIztj2tHe/SvGF3V0Nwqdi2J sXfAidMO1l+E6dxgvXOfkWBnqa+poXB9V0mAWRyBEhcXwsqpahdTZo3HexFnpK3Ih0XczCX2k4X5 tHJ4nTQXjjs7/eWMXVAK6Ien9CsoYiR1e5pmnOe3pMLQuc/NbZ3OiQauM8bAdcYYuCWawlJaXGTI EnSHMOJMyKgBQ2FKeJpzipWDLmC8G0keGydlS8pYrXTElNtigQb0O+b0ODZAEML6PUVnRNQ2lge3 l3nvHTp3mJG+vkGplQi/o1d9Qf5xUaVwxQQw3mfu9BkPnXc8PQnGuR8rJQPZmnqeUWILAf0qWfjt 0ManpzSEeQAMtKY0F4UrIkHa9AapUZez+L6qNrPYz7aS+cy2ez40pXlS5GplT97AF947C8trzQLI 6gXLO6b4LJ8JqCBCOMuUOa493Xvm2xl6wqFs+AFngXlIGE5VWnJR2fYYIg5b7aKByk4vFuzMSCPy QoIhV3RTxGquh1jNw+bRYtQqW1gSuYbR+lELC+wlN93GH6Y7pBuLWkHpwWgYuDEP57S5N9yN+eOp nXmt/qiF3jAAiNz5IXiEXihpZLhGL2M2I3wrQPU6FT6mksYGcgLLeAwL1tu2cjkL0V9fcxLPFrvo Z0uiOfqpD6R9fvHi5YPYPp+fH5nJY+QG1BdLAApwnOhVbFg+J/nv64HCwLRAnKxAFLf+zGR/5lU/ RXYN2IuQZ/brfOnWodm84jzn2sydeZnPRN6WschtlqOWfAi78e5SFAQlbhYF65Gvqy0QyA9DpCGG 6wVwZBVzcXsMKWgqBPtU2iLZs1Eauo70IlScO+80CggV+MTUGmPraq0kBHrtpwoNzwVyGSPEYxfS QdgTUN+wNbIbMbKvwxjYKTcwVcy0Na5rNK7vUDoQkyl6/zSjL+8MEgVLNXK+OtFTMk9gSUHLl//+ bxC4FC3bfgbm0VbXro+B2rmb9evMPOM6douyl8k9lMby3EOlO8c79AXddpiWgU4W5IjNLHf72O2z 91MuupxxeNtq8oIVnXHTtdnD4VkZtMwn1g7Jj8ZO4n5YVJfLlK1UsQjwUSlidGKw7QhozcYue5kL 6Up1foGR5Tnil2Z/owNKacSGhGv82EGPR9DaIT+TjmeZ7BcT4TQPbFnSpkmIc0rlqut9EwKhe8cE ZTy4nUo32X5MjZt7M5Xu1dB80/WEDeVOAduwwVOgqDVSfWuquv9kgY2WE/t/6/WvBZao3fDMNpX6 2IrP9Klt55kXvsIisrOA5zCDlR9+dKWFyi0LTWahm7MKfKy3Ffr7S7FyW7SpS1l3WEqRGvRR/cZq zmbkhq8th7ol7Chhf09p7T/luhagqttows08oYxsQBnZMlPzdQZw5qTJuLhmU3vV3J844oK2GjmX fLGFOFPLzcFWbr6Wm4vF5KbF/oNiE/VHy0xuCpdxk3rYCrLmES2sd1Nplj3JBzsWIfpVtruSVPmW Kydz5dkgOzg9cyIfOmXCaWtJ4+Pix7vXO+wP9+XoJx/ZfWgzSHsCuy9S8aiN82v0pYMP7S29v4UK 6K1aiASXatvDemhkkZLf6mpFVZgQsE+oKjCrq75sHYlxjkS5yrEddCHM8d2HHwEu651+nT4fzYpj P67DjY9rPLOfVjvTvVTp1wuVVqa4Dr97xTXMUsQ4rNlibdqjqypdlVsA7TADlrbyCaE3bFJ23J51 uSGNYEScjuzfsyYD80PRabyIOOLtt9h7ng1WEpSWoOHLfUudxLGQ7zkIK52T4raioLW3br7hshLz C8/wLNKkMxus+61Mz/EF8HJ+Y/XWmrTq4620Omk9aLHBmq2vvLiNS+nDITG9Y9uL6cGZsCZ9IkRL 0VwaEtXbNBC0HsXPUZsu1FtXoLaVTC+Zhy322u0YNdPOXKsp0C7Ran9zi7G2jL9mxn/cYtXWRRtf GDtiEpcnBYPpoxsWBJ9BWY0c3BsftHA3MTIpZyCcj5l8sDLBfrIVbCfYTxD/tGW8ynyMVaeQPnQR Dugl+psLr1+rloyNzFRdkxn4objFM8ZT1PhF+QFYWIhoEfj6vTJvRiffuirCsItKJOVShQc8yZ67 UsralNLTH4nN7lBKRy12TiQY2btbOer4euoyrD22HUI0lZVdk5bZkt+T/1mZ/8ir2Sylm9cra1tL Cb4m7t822SpV5fL5CuX3RgfelRLEqPeN2xP43O0JvKZs4NGPJA1FjWUPvbHydNSReXXGQuZ3g/NR itugksW5CNc10+6HIscdyqnZbLEXYUircIbnx22JsCqZwAixnXcStATnv7HBSSQsz4xFWUh2ig3L fWURo5iegKtveS7B5g5rnXZ13AiRBged2eF9RK9ULkOGCoxOKwN/XFTSoXlqSR+NpTHlBtVjDlEr S8XV0VPVSVOlK0j799eNM+2oKCPNkRdyd7rULjtjBsADw4sDzyxyJ/tEu/lytNhJQhvvezi//PmX wD9/k3K9eTSRO/8mJXjzFIXDnWbthhqNPeDmyh38VhxA4E5cI5GgM2iKHTz9bJthFnbnz7i1mIk7 CUAEueRa9qszk3hH5dYdm1Sd1OVO5fJHunn/+JrxELFGEKGx6A1NM/QnKmXYOcfXh89Usl36sB63 VZnPF+rXebzSWI6bkQvHc/tcvDyYoeBsK6dlu87oVvNMIoCww4PLnYJqyJmRcAcM+pNNRJUldacu OY71G7t2uKT2DD6SQCi8ES9OoPEML1Eg6xZ0MnSCkd/slQ5dA4lQQMkLBJk7p8lPsaBT0/wxF+7E JCd7tI+CO16tr3AIb9vqlN7oQAqR8DzVQcZAxq74EQLlmfnH2l12Pmap33qC8Rp6vyUaWR3Z5qPL 5NHPbjgNau0CC/2sajnFoZzzuMBeFrfpuO0rhLH5bM8xVhe/Pzk6OCofeM915cI0mweH9EyxJ0H5 M86tG6cbc7dwkNwPq7LBY5FSg8f8CuziZtHVr3ly4UGNEmw+hEAkXPq7dADHuVZ2DAtYHNIroXG4 7njSAsH6olPgrURE46o4AR6/hEX0cPJ/UEsHCNZoTSc6DwAAoIEAAFBLAwQUAAgICADSMoVaAAAA AAAAAAAAAAAADwAAAHdvcmQvc3R5bGVzLnhtbNVY0VbjNhB971f46B2chJTNyVmzB7LlkJZl22b7 AbKtxDrIkirJhPD1Hcl2sCMbQsh2Wx5INGNJd+4djcb5+OkxZ8EDUZoKHqHh6QAFhCcipXwVob++ XZ9MUKAN5ilmgpMIbYhGny5++riearNhRAcwn+vpOkKZMXIahjrJSI71qZCEg28pVI4NDNUqXAuV SiUSojUsn7NwNBichzmmHNXLDMfeQjlNlNBiaU4TkYdiuaQJcUvB9OHAfctZvUCe7AMkx+q+kCew nsSGxpRRs3FgUJAn0/mKC4VjBtECHnQBsaYi+UyWuGBG26H6XVXDauQ+rgU3OlhPsU4ojdAtjYmC 5QUPFkTRJQJXdsl1j4tgbS41xRG6E0aU9mD262/BYmbdiYZpIqMm+EweMMcrrCgK7b73RHF44AGz CI1Kk37aGsa1ZaZ3bQzzVW0j/GR+14bxlJ3MnCmmKWDOqH0CJoZVxOEuD3J3ZD/WNBXrGTCjBCuR FFIqyIDLwoibjcwI3wIzqiDVDrLaoblm6OngUhBmm40EsSRWeKWwzCxo55qnlk3QnTkVOc5JvVdl dpD+vna5Eb4E25JQzx00Qf5w/RPBhKqhYWD1h6eF435ffW4ItsXmzFOocgRnJawYa5J+5Tve0sfJ o6kd3+D7lUg3vdJqiRPqQowJFAUANhwPLCS8NETBaDQo54rCMMrJ7QNr8fifET4u/8/0rriTDnEn R9Bo3KvR+PtrNNpTo7P/h0a9B/B1jZIMREqAh5ZGCyhVfPVLLjOsqfaUKt3B1u8xXxHVBHwolF4Q r+5O3YC+a/eFKFRCbIr5JDhX4Hx9EF7IlC+Ci+5EqT27eYLhcrO+3VzZmfmOaOccLJyYW8rv/eMJ ExWznmaErQtjAH+T6jAVtdG2Z4y8B9ZdkUOIsMxik8eC+amwfSCon+gW5FAAVwVjxPj71vZ95f8K 3WOJsKF82/gsettulW5Y3l9/+8pvZ/FtNjhvqr33hMi7xoS6K+uqyqOum/NNxRdOSE/trTxdR2qf yvs978Mth152gbFRXl6QxLvo7DX2Z2FfOlwPV1kA6Ydz1GC8xfe4i+9Dg7ql2q+YztgVSzuNGu16 l+59Kh0KdYalzREPbW1/jfyujqN6LYE6SsrapHtyvrMTeXvs7cvuWL1BN19znpJHj63SejSu/j35 /yiEcUXCL+8N1yGBeWI3pR5NqlcRylN7PMnSROjn8w/2EUVX2fMog1co9wPKMc/njVD0CRjFzPLu 3wVbd+D8R70T+k6HvErLrlEYI/J6uVQUMbQPFvyTfWkKSmZrOl3/EaHJYFJ1HuHzQnsp4GXa89kZ jvyzMxx1J1v9TV/8A1BLBwjKgs6q8wMAAAYTAABQSwMEFAAICAgA0jKFWgAAAAAAAAAAAAAAABIA AAB3b3JkL251bWJlcmluZy54bWztnUtu2zAYhPc9hSGgy0RvWTZiBwWKoOmiKJD0ALJMO0L5EETa Tra9VI/VK5SSH4mbiDEStpWDWdH6fw6pGWbxgQvl7PyW0d6SVLIQfOT4p57TIzwX04LPR86364uT 1OlJlfFpRgUnI+eOSOd8/O5sNeQLNiGVntfTS3A5XI2cG6XKoevK/IawTJ6KknDdm4mKZUo/VnN3 JappWYmcSKmVjLqB5yUuywrubJYRI2dR8eFmjRNW5JWQYqZOcsGGYjYrcrIZtorqkI3Xko8iXzDC 1XrbitBMad/ypijldrWlaf8lo9t5LD9kW5ZV3xdlrS31VpOCFuqu2Xy7zMqPHq2z2/NU6zZv3iSn lb7X/Krfg+XDyzkXVTah+mD0Qs5YH0s2karKcvVlwXp7T5dTfb7NFLqkulXoYeR4TUWfcKV0bZnR epI7Xp/vBdsVpyQvWEbXLa28Jre73nv/dFf/nG+rlMzUulx+repB6ZfZjNs5eg9H/y6FHDl9b1BP d+8nFnyqm/U6665+uMn4vPnTDNJwM3uzelUP7v2o3+VPr/6BXicLSol60uqvHz8tWPUjPzV4bdrP m9XDheBK1scs86IYOVd3bCJoI/3A5V4hl3vtgqv6TGfZgqrN0obggq4EF/hB3xBc0+5ScGFngkvD xBRc3e5ScFFXggvjKDYE17S7FFzcleCiII4MwTXtLgWXdCa4QRKagqvbXQqu35Xg4qQfGIJr2l0K Lu1KcEmY+obgmvb/Dc7dI9lnMTcA5r7Wa2DDqx3OtcOmRrehDbd24NQOUBrdRlbcWiFKOxRodBvb cGsHA+2gm9FtYsOtHXazw1tGt30rbq0Alx1IMrpNbbi1Q0l2yMbodmDDrR20eSWOhC/Gkb+OfjZo 5N8RMy7wcIGHCzxc4OECDxd4uMDDBR4u8N7oBV4EYgYxg5hBzCBmEDOIGcQMYgYxg5gNxByDmEHM IGYQM4gZxAxiBjGDmEHMIGYDMScgZhAziBnEDGIGMYOYQcwgZhAziNlAzH0QM4gZxAxiBjGDmEHM IGYQM4gZxGwg5hTEDGIGMYOYQcwgZhAziBnEDGIGMRuIefBiYuaCk3VdLmaz+6rSrzh/8ggs5O8Z wvf2kvce5v46yD1+p+1UWl6pO0q2xU8kq79EHb7NFNoR88kUoreZwqG8ePxODwW843d6KJEdv9ND Eer4nR7KPMfo9DGk8AZO+MPP5u+Ryl4EbjPzkSxolwUGWdguCw2yR5//v5dFBlncLosNsqRdlhhk /XZZ3yBL22WpQTZolw0eytwH/81i/BtQSwcIL1gJFMwDAAATYwAAUEsDBBQACAgIANIyhVoAAAAA AAAAAAAAAAASAAAAd29yZC9mb250VGFibGUueG1srZPBbsIwDIbve4oo99HCYZoQBU2bdhpMGvAA pnVppCSu4kDh7RcKSGjLJrpxS2Ln/z87zmiyM1ps0bEim8l+L5UCbU6FsutMLhev949SsAdbgCaL mdwjy8n4btQMS7KeRbhuedhksvK+HiYJ5xUa4B7VaEOsJGfAh61bJw25onaUI3NQNzoZpOlDYkBZ eZJx18hQWaocXyjfGLT+KOJQgw8VcKVqluMTnWiGFkyAXiiDLGbYiA8yYNuEvALHeMjZgs5kmsqk vQdG6f351LXpbaBWPq/O51twClYaD6HkaPbNdL43K9JRr8GtvZ5CStwqWhY3ivmPVm9qha5ttpij U2XrCtrPQvSs87XfSYysf+smXJBNyVIM7Jk2TqE7oHWAMlSgi1GVaofFb0jvYXwv5uALTftqYmlV +G8opvM4UnRYYOMpAlRgCRvtr30/sPwjV4f+/Gecuv6SDoWfFjz+BFBLBwigtjfyYAEAAOUEAABQ SwMEFAAICAgA0jKFWgAAAAAAAAAAAAAAABEAAAB3b3JkL3NldHRpbmdzLnhtbGWQPW7DMAyF957C 4F7LCdA/I3a2okunpAdgZDoWYImCRMdNT1+mRuChG8XvkY9Pu/23H4sLpew4NLApKygoWO5cODfw dXx/fIUiC4YORw7UwJUy7NuH3VxnElFVLnRDyPXcwCASa2OyHchjLjlSUNZz8ij6TGczc+piYks5 66gfzbaqno1HF6DVlT/MvpjrSMlSED1nW4G5gY56nEY54ukgHFVywbGBl+ptwTgJf1zjQAFFc9y5 pIkWgWUfUdbqsNyuwoBeUy1dd3Kjk+sndwSKpuT+ZfLOJs7cS6kjhvveWfpLBXfTzdPN0qyeZv2q 9hdQSwcIAz5QXPEAAABvAQAAUEsDBBQACAgIANIyhVoAAAAAAAAAAAAAAAATAAAAW0NvbnRlbnRf VHlwZXNdLnhtbL2Uy07DMBBF9/2KyFuUuLBACCXtgscSuihr5NqT1BA/ZLul/XvGaRShKjQtFJbx zL3nzjhJPt2oOlmD89LoglxmY5KA5kZIXRXkZf6Y3pDpZJTPtxZ8gr3aF2QZgr2l1PMlKOYzY0Fj pTROsYCPrqKW8XdWAb0aj68pNzqADmmIHmSS30PJVnVIHjZ4vOOinCR3u76IKgiztpacBSzTWKW9 Oge1PyBca7GXLm2TZahsevxSWn/xPcHqag8gVZwsnvcr3iz0S5oCap5x3U4KSGbMhSemsIG+xklo duZ5+kjC8Jkz1uO1OMgOL/4AL6pTi0bggoTjiGh9OtCUpeSAHiuFkgziogWII9kfxol2uZ0Ftv/H ohv0V+iv5o5uODIH7/HTxAm6imJSD+bwYVuDP3+Kne8gXq/UAhxKzp+gsx4MUSJ1zhb1D976oRCd 9fBFQAio+YuraJ3bCKOcNj/tySdQSwcIgmLaOWABAADjBQAAUEsBAhQAFAAICAgA0jKFWujQASPZ AAAAPQIAAAsAAAAAAAAAAAAAAAAAAAAAAF9yZWxzLy5yZWxzUEsBAhQAFAAICAgA0jKFWt1fccdk AQAA2wIAABEAAAAAAAAAAAAAAAAAEgEAAGRvY1Byb3BzL2NvcmUueG1sUEsBAhQAFAAICAgA0jKF WjaGzHc4AQAAJgIAABAAAAAAAAAAAAAAAAAAtQIAAGRvY1Byb3BzL2FwcC54bWxQSwECFAAUAAgI CADSMoVaeKUXTygBAAB/BAAAHAAAAAAAAAAAAAAAAAArBAAAd29yZC9fcmVscy9kb2N1bWVudC54 bWwucmVsc1BLAQIUABQACAgIANIyhVrWaE0nOg8AAKCBAAARAAAAAAAAAAAAAAAAAJ0FAAB3b3Jk L2RvY3VtZW50LnhtbFBLAQIUABQACAgIANIyhVrKgs6q8wMAAAYTAAAPAAAAAAAAAAAAAAAAABYV AAB3b3JkL3N0eWxlcy54bWxQSwECFAAUAAgICADSMoVaL1gJFMwDAAATYwAAEgAAAAAAAAAAAAAA AABGGQAAd29yZC9udW1iZXJpbmcueG1sUEsBAhQAFAAICAgA0jKFWqC2N/JgAQAA5QQAABIAAAAA AAAAAAAAAAAAUh0AAHdvcmQvZm9udFRhYmxlLnhtbFBLAQIUABQACAgIANIyhVoDPlBc8QAAAG8B AAARAAAAAAAAAAAAAAAAAPIeAAB3b3JkL3NldHRpbmdzLnhtbFBLAQIUABQACAgIANIyhVqCYto5 YAEAAOMFAAATAAAAAAAAAAAAAAAAACIgAABbQ29udGVudF9UeXBlc10ueG1sUEsFBgAAAAAKAAoA fAIAAMMhAAAAAA== --0000000000008b69c80632021e17-- From projects.utkarshmaurya@gmail.com Sat Apr 5 08:54:43 2025 From: projects.utkarshmaurya@gmail.com (Utkarsh Maurya) Date: Sat, 5 Apr 2025 13:24:43 +0530 Subject: [OpenAFS-devel] GSoC 2025 Proposal Follow-Up: Multi-page Folio Support for OpenAFS Message-ID: --000000000000844bb10632035170 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear OpenAFS Developers, I hope you're doing well. Just following up on my GSoC 2025 proposal regarding multi-page folio support in the OpenAFS Linux kernel module. I've been diving deeper into the codebase, especially around the osi_VM interface, and have updated my draft accordingly. =F0=9F=94=97 Proposal (Draft): < https://docs.google.com/document/d/197UpExN5kyjimYdr839tbah8Aj_Xj7s97LZWvbb= ePss/edit?usp=3Dsharing > I'd really appreciate any feedback you might have. A few relevant projects of mine: myOwnOS =E2=80=93 Bare-metal OS for Raspberry Pi 3B Baking Pi (RPi 3B) =E2=80=93 Port of the course using GCC ARM EABI Kernel Carnival =E2=80=93 Linux kernel module lab environment Thanks again, and looking forward to your thoughts! Best regards, Utkarsh Maurya Mail: projects.utkarshMaurya@gmail.com GitHub ID: @pro-utkarshM --000000000000844bb10632035170 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear OpenAFS Developers,

I hope you're doing we= ll.

Just following up on my GSoC 2025 proposal regarding multi-page = folio support in the OpenAFS Linux kernel module. I've been diving deep= er into the codebase, especially around the osi_VM interface, and have upda= ted my draft accordingly.

=F0=9F=94=97 Proposal (Draft): <https://docs.google.com/document/d/197UpExN5ky= jimYdr839tbah8Aj_Xj7s97LZWvbbePss/edit?usp=3Dsharing>

I'= d really appreciate any feedback you might have.

A few relevant proj= ects of mine:

myOwnOS =E2=80=93 Bare-metal OS for Raspberry Pi 3B
Baking Pi (RPi 3B) =E2=80=93 Port of the course using GCC ARM EABI
=
Kernel Carnival =E2=80=93 Linux kernel module lab environment

Th= anks again, and looking forward to your thoughts!

Best regards,
U= tkarsh Maurya
--000000000000844bb10632035170-- From mmeffie@sinenomine.net Mon Apr 7 13:56:31 2025 From: mmeffie@sinenomine.net (Michael Meffie) Date: Mon, 7 Apr 2025 08:56:31 -0400 Subject: [OpenAFS-devel] GSoC 2025 contributor proposal deadline Message-ID: <20250407085631.935033538f1ce7bd8419abdb@sinenomine.net> Hello, Just a reminder, the GSoC contributor proposal deadline is April 8th at 18:00 UTC. Interested contributors can register and submit project proposals on the GSoC site. If you've already submitted a proposal, you can update it before the April 8th deadline. Thank you all for the proposals submitted so far. We are excited and happy to see such a great response and interest in OpenAFS. Best regards, Mike -- Michael Meffie From akshikamunshi27@gmail.com Tue Apr 8 06:23:41 2025 From: akshikamunshi27@gmail.com (Akshika) Date: Tue, 8 Apr 2025 10:53:41 +0530 Subject: [OpenAFS-devel] Gsoc Proposal Message-ID: --000000000000fc7ddc06323d8e72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey there ! This is Akshika , I am a third year student pursuing Btech in India. I am interested in developing a netcat-like tool for the OpenAFS community under Gsoc'25 and have written a proposal for the same ( https://docs.google.com/document/d/1XFgrTYjmbIimVWS54UZGVzfjVlX62a1Y27ijiqt= PXCU/edit?usp=3Dsharing ). I am exploring the network security domain. Some relevant projects I have completed : - Chat Application using socket programming with encrypted communication - Created several vulnerable VMs to simulate real-world Network functions Virtualization and test security features . - Bash Scripting to automate network reconnaissance in Penetration Testing - Continually practice low-level programming , pointer arithmetic, and memory-efficient data handling problems in C language I'd really appreciate any feedback you might have, especially on technical feasibility and alignment with OpenAFS=E2=80=99s priorities Thanks Akshika Munshi --000000000000fc7ddc06323d8e72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey there !
This is Akshika , I am a thi= rd year student pursuing Btech in India. I am interested in developing a ne= tcat-like tool for the OpenAFS community under Gsoc'25 and have written= a proposal for the same (https://docs= .google.com/document/d/1XFgrTYjmbIimVWS54UZGVzfjVlX62a1Y27ijiqtPXCU/edit?us= p=3Dsharing).

I am e= xploring the network security domain. Some relevant projects I have complet= ed :
- Chat Application using socket programming wit= h encrypted communication
- Created several vulnerab= le VMs to simulate real-world Network functions Virtualization and test sec= urity features .=C2=A0
- Bash Scripting to automate = network reconnaissance in Penetration Testing
- Cont= inually practice low-level programming , pointer arithmetic, and memory-eff= icient data handling problems in C language=C2=A0
I'd really appreciate any feedback you might = have, especially on technical feasibility and alignment with OpenAFS=E2=80= =99s priorities
Thanks=C2=A0
= Akshika Munshi

--000000000000fc7ddc06323d8e72-- From christof.hanke@mpcdf.mpg.de Wed Apr 9 09:22:23 2025 From: christof.hanke@mpcdf.mpg.de (Christof Hanke) Date: Wed, 09 Apr 2025 10:22:23 +0200 Subject: [OpenAFS-devel] Linux-Kernel 6.14 Message-ID: <3613876.dWV9SEqChM@senf.mpcdf.mpg.de> Dear Developers, the buildservice for openSUSE complains about not being able to build the kernel-module for 6.14 The relevant patches https://gerrit.openafs.org/#/c/16277/ 4702930f8dd87a6cad1d59ef8c127003fded1f31 LINUX: Refactor afs_linux_dentry_revalidate() https://gerrit.openafs.org/#/c/16276/1 0306f3fdac736e15620f5802bdce510d25bb2450 Linux-6.14: Handle dops.d_revalidate with parent apply cleanly on the branch openafs-stable-1_8_x which I use for building the rpms. Interestingly they are marked as "Cannot Merge" in gerrit. However, using these patches the kernel-module is successfully compiled. Is it safe to use to current openafs-stable-1_8_x plus these two patches for latest openSUSE-Tumbleweed? Many thanks and please advise, Christof From cwills@sinenomine.net Wed Apr 9 14:39:48 2025 From: cwills@sinenomine.net (Cheyenne Wills) Date: Wed, 9 Apr 2025 07:39:48 -0600 Subject: [OpenAFS-devel] Linux-Kernel 6.14 In-Reply-To: <3613876.dWV9SEqChM@senf.mpcdf.mpg.de> References: <3613876.dWV9SEqChM@senf.mpcdf.mpg.de> Message-ID: <20250409073948.4ce7130a.cwills@sinenomine.net> Those 2 patches will be sufficient for Linux 6.14 -- Cheyenne Wills cwills@sinenomine.net On Wed, 9 Apr 2025 10:22:23 +0200 Christof Hanke wrote: > Dear Developers, > > the buildservice for openSUSE complains about not being able to build > the kernel-module for 6.14 The relevant patches > > https://gerrit.openafs.org/#/c/16277/ > 4702930f8dd87a6cad1d59ef8c127003fded1f31 LINUX: Refactor > afs_linux_dentry_revalidate() https://gerrit.openafs.org/#/c/16276/1 > 0306f3fdac736e15620f5802bdce510d25bb2450 Linux-6.14: Handle > dops.d_revalidate with parent > > apply cleanly on the branch openafs-stable-1_8_x > which I use for building the rpms. Interestingly they are marked as > "Cannot Merge" in gerrit. > > However, using these patches the kernel-module is successfully > compiled. > > Is it safe to use to current openafs-stable-1_8_x plus these two > patches for latest openSUSE-Tumbleweed? > > Many thanks and please advise, > > Christof > > > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel From mmeffie@sinenomine.net Fri Apr 11 13:33:04 2025 From: mmeffie@sinenomine.net (Michael Meffie) Date: Fri, 11 Apr 2025 08:33:04 -0400 Subject: [OpenAFS-devel] OpenAFS Release Team weekly meeting Message-ID: <20250411083304.5ef911c032137f786cd4ff2c@sinenomine.net> OpenAFS Release Team weekly meeting Date: April 10, 2025 Participants: - Stephan Wiesand, OpenAFS Release Manager - Ben Kaduk - Cheyenne Wills - Michael Meffie - Mark Vitale The OpenAFS Release Team meetings are held each Thursday at 12:00pm Eastern, 9:00am Pacific on Libera.Chat IRC channel #openafs-releaseteam. Release team working status is maintained at: https://wiki.openafs.org/devel/Whiteboard/ Discussion ========== * Ben is in the process of reviewing and merging proposed changes onto the openafs-stable-1_8_x branch for 1.8.14. * Mike is updating the NEWS file for 1.8.14 * Cheyenne reports some changes will be needed for Linux 6.15, mostly build system changes. * Mike has added more "nightly" buildbot builders. All of the nightly linux builders have --enable-checking in the configure options to convert compiler warnings to errors and run the TAP unit tests. Recent Changes ============== Merged onto 'openafs-stable-1_8_x' branch since 2025-03-14: 16021 viced: Log some basic fs_stateRestore stats 16020 viced: Log more state restore errors 16018 viced: Set FS_STATE_DUMP_MODE earlier 16019 viced: Raise fsstate loop detection limits 16017 viced: Use calloc for fsstate data 16016 viced: Fix minor log message mistakes 16012 rx: Add rxi_GetLocalAddr() prototype 16011 rx: Don't send packets to localhost if -rxbind set 16065 rx: Introduce 'rx_host' internal global 16010 Avoid rxi_tracename overflow 16008 LINUX: Block non-fatal signals when sleeping 16007 LINUX: Refactor afs_osi_Sleep 15801 rx: Print free and allocated counters as unsigned values 15817 volinfo: Refuse zero and non-numeric -volumeid 15812 AIX: Don't specify -qlanglvl=stdc99 for libuafs 15811 AIX: Declare syscall() 15810 AIX: Avoid COMPAT_43 for clang 15809 macos: Remove vestigial AFS_MOUNT_AFS references 15808 LINUX: Test for rcu_read_unlock with rcu_read_lock 15807 Remove almost all bcopy/bzero/bcmp calls 15806 make-release: create SHA256 checksums too 15805 make-release: Run git describe once Updated for 'openafs-stable-1_8_x' branch since 2025-03-14: 16179 DARWIN: Set parent of volume root vnodes 16285 viced: Remove RXAFS_GetVolumeInfo implementation 16298 Update NEWS for OpenAFS 1.8.14pre 16188 macos: Autodetect kernel headers path for afs.kext 16186 macos: Remove SDKROOT from AklogAuthPlugin project 16187 macos: Stop passing -sdk to xcodebuild 16189 macos: Add support for MacOS 15.X (Sequoia) 16190 macos: Support building solely with Xcode headers 16276 LINUX: Refactor afs_linux_dentry_revalidate() 16277 Linux-6.14: Handle dops.d_revalidate with parent Merged onto 'master' branch since 2025-03-14: 16360 doc: Fix man pages install target for kauth 16359 tests: Skip manpage tests if manpages aren't built 16358 tests: Search for man pages in objdir 16356 ptserver: Don't use rxgk by default in ptclient 14724 viced: Fix minor log message mistakes 16355 RedHat: Remove doc tarball sources 16350 doc: Generate PODs with installation paths 16353 doc: Fix server logs path in Windows docs 16352 doc: Fix server logs path in the Admin Guide 16351 doc: Fix bosserver log path 16349 doc: Add generate-pod variable substitution support 16348 doc: Recusively include files in generate-pod 16347 doc: Simplify generate-pod syntax 16354 doc: Add pod target to doc/man-pages/Makefile.in 16346 doc: Generate man pages with the build system 16345 Import of code from autoconf-archive 16344 Add ax_prog_perl_modules.m4 to autoconf-archives-files 16332 doc: Add missing line continuation in doc/man-pages/Makefile.in 16331 doc: Regenerate POD for html and AdminRef 16330 doc: Rename POD files to *.pod.template 16326 doc: Rename merge-pod to generate-pod 16328 doc: Avoid file slurping in merge-pod 16327 doc: Add generate-html --stylesheet option 16322 doc: Avoid creating .noinstall files 16321 doc: Introduce Makefile.vars.in 16320 doc: Add fssync-debug to FSSYNCDEBUG_PAGES 16319 doc: Use ln force option to install man pages 16318 doc: Add ln configure check 16317 doc: Use install -d to install directories 16316 doc: Do not install *.krb symlinks when kauth is disabled 16315 doc: Cleanup MAN1 and MAN8 makefile variables 15899 Linux CM: Fix leak of group_info on setpag() 16311 util: Remove redundant ktime_InterpretDate() prototype Updated for 'master' branch since 2025-03-14: 16364 volser: Avoid uninitialized use warning in CheckVolume() 16362 ktime: Add day range check to ktime_DisplayString() 16361 tests: Add ktime and kreltime tests 16312 util: Rename ktime struct members from min to minutes 16325 packaging: Remove old 1.4.0 patch file 12744 Do not submit: Check buildbot verification 16357 acl: Refactor acl_Internalize_pr 16333 util: Use correct length modifiers in fb64.c 16337 libafscp: Suppress macOS Kerberos (krb5_*) deprecated warnings 16336 aklog: Suppress macOS deprecated krb5_* warnings 16335 DARWIN: Include UKERNEL in OSATOMIC_USE_INLINED workaround 16334 DARWIN: Define AFS_64BITUSERPOINTER_ENV earlier 10291 bozo: add build support for pthreaded bosserver 16343 DARWIN: Correct size of arm64 LWP jmp_buf_type to 64-bits 16342 lwp: Re-indent ifdef maze in process.c 16341 DARWIN: Suppress deprecated warnings for growlagent 16340 rx: Disable rxi_syscallp in test programs on DARWIN 16339 afsd: Add informational message to vsys 16338 DARWIN: Remove define for AFS_SYSCALL 16324 Linux: Remove outdated redhat kernel package types 16323 cf: Remove REDHAT_BUILD_SYS dead code 15583 config: remove VIOC_STATISTICS _VICEIOCTL(68) 15900 rx/rxdebug: protect against wrong sized rx_debugStats reply 16296 tests: Remove libwrap wrapper script -- Michael Meffie From akarshisinha569@gmail.com Sun Apr 13 08:16:46 2025 From: akarshisinha569@gmail.com (Akarshi Sinha) Date: Sun, 13 Apr 2025 12:46:46 +0530 Subject: [OpenAFS-devel] GSoC'25 Proposal for Command Line Completion Message-ID: --0000000000008f5fee0632a3b8f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Sir/Ma'am, I hope this message finds you well. My name is Akarshi Sinha, and I=E2=80=99m currently a third-year undergradu= ate student pursuing B.Tech in Information Technology. I=E2=80=99ve been a Linu= x user for almost a decade and have gained hands-on experience with shell scripting, system programming in C, and tools like bash, zsh, and various Unix utilities as part of both personal projects and coursework. I recently submitted a proposal for Google Summer of Code 2025 titled =E2=80=9COpenAFS Command-line Completion.=E2=80=9D The core idea behind thi= s project is to enhance the user experience by implementing comprehensive shell completion support (for Bash and Zsh) to OpenAFS=E2=80=99s command-line tools (vos, fs= , pts etc), while also developing a parser to automate and simplify the maintenance of these completion scripts as the codebase evolves. I had intended to reach out earlier, but my end-semester exams unfortunately got delayed and coincided with the GSoC application period. I realize the importance of early communication and regret not reaching out prior to submission. However, I have put in sincere effort to understand the requirements and draft a proposal that aligns well with the goals of the OpenAFS project. OpenAFS-GSoC'25-Akarshi Sinha.pdf Proposal Link: https://drive.google.com/file/d/1xMzO_0q4m6eM9Wq_5VG8Q7_4WsNielmz/view?usp= =3Ddrivesdk I would be extremely grateful if you could kindly take some time to review my proposal and share any feedback, suggestions, or areas of improvement. Your guidance would be invaluable to me, and I remain genuinely enthusiastic about contributing to OpenAFS, both during GSoC and beyond. Thank you very much for your time and consideration. I look forward to the opportunity to learn from and work with the OpenAFS community. Warm regards, Sincerely, Akarshi Sinha --0000000000008f5fee0632a3b8f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Sir/Ma'am,

I hope this message finds you well.

My name is Akarshi Sinha, and I= =E2=80=99m currently a third-year undergraduate student pursuing B.Tech in = Information Technology. I=E2=80=99ve been a Linux user for almost a decade = and have gained hands-on experience with shell scripting, system programmin= g in C, and tools like bash, zsh, and various Unix utilities as part of bot= h personal projects and coursework.

I recently submitted a proposal for Google Summer of Code 2025 = titled =E2=80=9COpenAFS Command-line Completion.=E2=80=9D The core idea beh= ind this project is to enhance the user experience by implementing comprehe= nsive shell completion support (for Bash and Zsh) to OpenAFS=E2=80=99s comm= and-line tools (vos, fs, pts etc), while also developing a parser to automa= te and simplify the maintenance of these completion scripts as the codebase= evolves.

I had intended= to reach out earlier, but my end-semester exams unfortunately got delayed = and coincided with the GSoC application period. I realize the importance of= early communication and regret not reaching out prior to submission. Howev= er, I have put in sincere effort to understand the requirements and draft a= proposal that aligns well with the goals of the OpenAFS project.

Proposal Link:=C2=A0

I would be extremely grateful if you cou= ld kindly take some time to review my proposal and share any feedback, sugg= estions, or areas of improvement. Your guidance would be invaluable to me, = and I remain genuinely enthusiastic about contributing to OpenAFS, both dur= ing GSoC and beyond.

Tha= nk you very much for your time and consideration. I look forward to the opp= ortunity to learn from and work with the OpenAFS community.

Warm regards,
=
Sincerely,
Akarshi Sinha= =C2=A0



--0000000000008f5fee0632a3b8f4-- From projects.utkarshmaurya@gmail.com Mon Apr 14 14:27:46 2025 From: projects.utkarshmaurya@gmail.com (Utkarsh Maurya) Date: Mon, 14 Apr 2025 18:57:46 +0530 Subject: [OpenAFS-devel] Questions Before Starting on Multi-Page Folio Support in OpenAFS Message-ID: Dear OpenAFS Developers, I hope you're doing well! I'm reaching out to express my genuine interest in contributing to the OpenAFS project, particularly around the topic of multi-page folio support in the OpenAFS Linux kernel module. I=E2=80=99ve been closely following developments in memory management and distributed file systems, and I=E2=80=99m excited about the opportunity to explore how OpenA= FS can better leverage the folio API to improve efficiency. Before diving deeper into the work, I have a couple of questions to help guide my contributions: 1. Which areas of the OpenAFS codebase currently handle page-level operations that would benefit most from multi-page folio support? >From the description, it seems that the read/write and metadata paths are key candidates, but I would appreciate your insights on which areas might have the biggest impact in terms of performance or future maintainability. 2. How should I approach compatibility across kernel versions with differing levels of folio support? Is it better to use feature checks/macros for conditional support of multi-page folios, or is there a minimum kernel version we should target for full compatibility? Additionally, if there are any existing discussions, patches, or related resources (like LKML threads or kernel commits) that could provide more context on folio usage in OpenAFS, I=E2=80=99d be grateful for any pointers. I also wanted to mention that I=E2=80=99ve applied for the Google Summer of Code (GSoC) this year with the OpenAFS project. While I=E2=80=99m hopeful f= or that opportunity, I=E2=80=99m already eager to contribute in any capacity a= nd am excited to learn from the community. Thank you for your time, and I look forward to any guidance or feedback you might have. I=E2=80=99m excited to be part of the OpenAFS proj= ect and contribute where I can! Best regards, Utkarsh Maurya projects.utkarshMaurya@gmail.com GitHub: pro-utkarshM From ematlis@nd.edu Fri Apr 18 16:43:15 2025 From: ematlis@nd.edu (Eric Matlis) Date: Fri, 18 Apr 2025 11:43:15 -0400 Subject: [OpenAFS-devel] Openafs on kernel 6.14 Fedora 42 patched but fails to compile Message-ID: --00000000000009bd9106330f61f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear developers- patches https://gerrit.openafs.org/#/c/16277/ and https://gerrit.openafs.org/#/c/16276/1 fail to fix openafs-1.8.13.2 for compilation under Fedora 42 and kernel 6.14.2-300. The error I get using rpmbuild is: iomgr.c:50:23: error: =E2=80=98bool=E2=80=99 cannot be defined via =E2=80= =98typedef=E2=80=99 50 | typedef unsigned char bool; | ^~~~ iomgr.c:50:23: note: =E2=80=98bool=E2=80=99 is a keyword with =E2=80=98-std= =3Dc23=E2=80=99 onwards iomgr.c:50:1: warning: useless type name in empty declaration 50 | typedef unsigned char bool; This was after applying the patches manually with "patch -p1 < patchfile" to the source code extracted from the bunzip2 tar file, recreating the tar file, executing the procedure to turn tar files into a src rpm, and issuing "rpmbuild --rebuild xxx.src.rpm". Let me know if I can provide any other information. Thank you and please advise, Eric ********************************************** Eric Matlis Associate Research Professor 114 Hessert Laboratory Aerospace and Mechanical Engineering University of Notre Dame Notre Dame, IN 574-631-6054 --00000000000009bd9106330f61f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear developers-

patches=C2=A0htt= ps://gerrit.openafs.org/#/c/16277/ and=C2=A0https://gerrit.openafs.org/#/c/16276/1 fail to = fix openafs-1.8.13.2 for compilation under Fedora 42 and kernel 6.14.2-300.= =C2=A0 The error I get using rpmbuild is:

iomgr.c:50:2= 3: error: =E2=80=98bool=E2=80=99 cannot be defined via =E2=80=98typedef=E2= =80=99
=C2=A0=C2=A050 | typedef unsig= ned char bool;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0^~~~

iomgr.c:50:23: note: =E2=80=98b= ool=E2=80=99 is a keyword with =E2=80=98-std=3Dc23=E2=80=99 onwards<= span style=3D"color:rgb(0,0,0)">
iomgr.c:50:1: warning: useless = type name in empty declaration
=C2=A0=C2=A050 | typedef unsig= ned char bool;

This was after applyi= ng the patches manually with "patch -p1 < patchfile" to the so= urce code extracted from the bunzip2 tar file, recreating the tar file, exe= cuting the procedure to turn tar files into a src rpm, and issuing "rp= mbuild --rebuild xxx.src.rpm".

Let me know if I can prov= ide any other information.

Thank you and please advise,
Eric

**********************************************
Er= ic Matlis
Associate Research Professor
114 Hessert Labo= ratory
Aerospace and Mechanical Engineering
University = of Notre Dame
Notre Dame, IN
574-631-6054
--00000000000009bd9106330f61f2-- From cwills@sinenomine.net Sat Apr 19 00:18:54 2025 From: cwills@sinenomine.net (Cheyenne Wills) Date: Fri, 18 Apr 2025 17:18:54 -0600 Subject: [OpenAFS-devel] Openafs on kernel 6.14 Fedora 42 patched but fails to compile In-Reply-To: References: Message-ID: <20250418171854.454e9c9a.cwills@sinenomine.net> iomgr.c is not dependent on the Linux kernel (iomgr.c is used for some of the openafs servers and it's not used within the kernel module).=20 The error message is related to the C compiler and the -std=3Dc23 option. It appears that fedora 42 is setting the default compiler standard to -std=3Dgnu23, which in a superset of C23. =20 To build under fedora 42, you will need to use a CFLAG of -std=3Dgnu17 or -std=3Dc99. The coding standard that is used within OpenAFS is C89 plus a few extensions (or as the coding style doc states "C99 minus a few features). --=20 Cheyenne Wills cwills@sinenomine.net On Fri, 18 Apr 2025 11:43:15 -0400 Eric Matlis wrote: > Dear developers- >=20 > patches https://gerrit.openafs.org/#/c/16277/ and > https://gerrit.openafs.org/#/c/16276/1 fail to fix openafs-1.8.13.2 > for compilation under Fedora 42 and kernel 6.14.2-300. The error I > get using rpmbuild is: >=20 > iomgr.c:50:23: error: =E2=80=98bool=E2=80=99 cannot be defined via =E2=80= =98typedef=E2=80=99 > 50 | typedef unsigned char bool; > | ^~~~ > iomgr.c:50:23: note: =E2=80=98bool=E2=80=99 is a keyword with =E2=80=98-s= td=3Dc23=E2=80=99 onwards > iomgr.c:50:1: warning: useless type name in empty declaration > 50 | typedef unsigned char bool; >=20 > This was after applying the patches manually with "patch -p1 < > patchfile" to the source code extracted from the bunzip2 tar file, > recreating the tar file, executing the procedure to turn tar files > into a src rpm, and issuing "rpmbuild --rebuild xxx.src.rpm". >=20 > Let me know if I can provide any other information. >=20 > Thank you and please advise, > Eric >=20 > ********************************************** > Eric Matlis > Associate Research Professor > 114 Hessert Laboratory > Aerospace and Mechanical Engineering > University of Notre Dame > Notre Dame, IN > 574-631-6054 From ematlis@nd.edu Sat Apr 19 02:06:37 2025 From: ematlis@nd.edu (Eric Matlis) Date: Fri, 18 Apr 2025 21:06:37 -0400 Subject: [OpenAFS-devel] Openafs on kernel 6.14 Fedora 42 patched but fails to compile In-Reply-To: <20250418171854.454e9c9a.cwills@sinenomine.net> References: <20250418171854.454e9c9a.cwills@sinenomine.net> Message-ID: --000000000000cd81b10633173f0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the quick response. Using export CC=3D"gcc -std=3Dc99" befor= e rpmbuild --rebuild resolved this issue, however, not I get the following errors: osi_vnodeops.c: In function =E2=80=98afs_linux_dentry_revalidate=E2=80=99: osi_vnodeops.c:1636:10: error: =E2=80=98nd=E2=80=99 undeclared (first use i= n this function); did you mean =E2=80=98fd=E2=80=99? 1636 | if ((nd->flags & LOOKUP_RCU) !=3D 0) { | ^~ | fd osi_vnodeops.c:1636:10: note: each undeclared identifier is reported only once for each function it appears in osi_vnodeops.c: At top level: osi_vnodeops.c:1727:25: error: initialization of =E2=80=98int (*)(struct in= ode *, const struct qstr *, struct dentry *, unsigne d int)=E2=80=99 from incompatible pointer type =E2=80=98int (*)(struct dent= ry *, int)=E2=80=99 [-Wincompatible-pointer-types] 1727 | .d_revalidate =3D afs_linux_dentry_revalidate, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ osi_vnodeops.c:1727:25: note: (near initialization for =E2=80=98afs_dentry_operations.d_revalidate=E2=80=99) osi_vnodeops.c:1623:1: note: =E2=80=98afs_linux_dentry_revalidate=E2=80=99 = declared here 1623 | afs_linux_dentry_revalidate(struct dentry *dp, int flags) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ CC [M] Kpagcb.xdr.o make[6]: *** [/usr/src/kernels/6.14.2-300.fc42.x86_64/scripts/Makefile.build:207: osi_vnodeops.o] Error 1 make[6]: *** Waiting for unfinished jobs.... ********************************************** Eric Matlis Associate Research Professor 114 Hessert Laboratory Aerospace and Mechanical Engineering University of Notre Dame Notre Dame, IN 574-631-6054 On Fri, Apr 18, 2025 at 7:18=E2=80=AFPM Cheyenne Wills wrote: > iomgr.c is not dependent on the Linux kernel (iomgr.c is used for > some of the openafs servers and it's not used within the kernel > module). > > The error message is related to the C compiler and the -std=3Dc23 option. > > It appears that fedora 42 is setting the default compiler standard to > -std=3Dgnu23, which in a superset of C23. > > To build under fedora 42, you will need to use a CFLAG of -std=3Dgnu17 or > -std=3Dc99. > > The coding standard that is used within OpenAFS is C89 plus a few > extensions (or as the coding style doc states "C99 minus a few > features). > > -- > Cheyenne Wills > cwills@sinenomine.net > > > > On Fri, 18 Apr 2025 11:43:15 -0400 > Eric Matlis wrote: > > Dear developers- > > > > patches https://gerrit.openafs.org/#/c/16277/ and > > https://gerrit.openafs.org/#/c/16276/1 fail to fix openafs-1.8.13.2 > > for compilation under Fedora 42 and kernel 6.14.2-300. The error I > > get using rpmbuild is: > > > > iomgr.c:50:23: error: =E2=80=98bool=E2=80=99 cannot be defined via =E2= =80=98typedef=E2=80=99 > > 50 | typedef unsigned char bool; > > | ^~~~ > > iomgr.c:50:23: note: =E2=80=98bool=E2=80=99 is a keyword with =E2=80=98= -std=3Dc23=E2=80=99 onwards > > iomgr.c:50:1: warning: useless type name in empty declaration > > 50 | typedef unsigned char bool; > > > > This was after applying the patches manually with "patch -p1 < > > patchfile" to the source code extracted from the bunzip2 tar file, > > recreating the tar file, executing the procedure to turn tar files > > into a src rpm, and issuing "rpmbuild --rebuild xxx.src.rpm". > > > > Let me know if I can provide any other information. > > > > Thank you and please advise, > > Eric > > > > ********************************************** > > Eric Matlis > > Associate Research Professor > > 114 Hessert Laboratory > > Aerospace and Mechanical Engineering > > University of Notre Dame > > Notre Dame, IN > > 574-631-6054 > > --000000000000cd81b10633173f0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the quick=C2=A0response.=C2=A0 Using=C2= =A0export CC=3D"gcc -std=3Dc99" before rpmbuild --rebuild resolve= d this issue, however, not I get the following errors:

=
osi_vnodeops.c: In function =E2=80=98afs_linux_dentry_revalidate=E2=80=99:=
osi_vnodeops.c:1636:10: error: = =E2=80=98nd=E2=80=99 undeclared (first use in this function); did you mean = =E2=80=98fd=E2=80=99?
1636 | =C2=A0=C2=A0=C2=A0=C2= =A0if ((nd->flags & LOOKUP_RCU) !=3D 0) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0^~
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fd
osi_vnodeops.c:1636:10: note: e= ach undeclared identifier is reported only once for each function it appear= s in
osi_vnodeops.c: At top level:
osi_vnodeops.c:1727:25: error: = initialization of =E2=80=98int (*)(struct inode *, const struct qstr *, str= uct dentry *, unsigne
d int)=E2=80=99 from incompatible pointer t= ype =E2=80=98int (*)(struct dentry *, int)=E2=80=99 [-Wincompatible-pointer= -types]
1727 | =C2=A0=C2=A0.d_revalida= te =3D =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0afs_linux_dentry_revalidate,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0^~~= ~~~~~~~~~~~~~~~~~~~~~~~~
osi_vnodeops.c:1727:25: note: (= near initialization for =E2=80=98afs_dentry_operations.d_revalidate=E2=80= =99)
osi_vnodeops.c:1623:1: note: = =E2=80=98afs_linux_dentry_revalidate=E2=80=99 declared here
1623 | afs_linux_dentry_revali= date(struct dentry *dp, int flags)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
=C2=A0CC [M] =C2=A0Kpagcb.xdr.= o
make[6]: *** [/usr/src/kernels/= 6.14.2-300.fc42.x86_64/scripts/Makefile.build:207: osi_vnodeops.o] Error 1<= /span>
make[6]: *** Waiting for unfini= shed jobs....


**********************************************
Er= ic Matlis
Associate Research Professor
114 Hessert Labo= ratory
Aerospace and Mechanical Engineering
University = of Notre Dame
Notre Dame, IN
574-631-6054


On Fri, Apr 18, 2025 at 7:1= 8=E2=80=AFPM Cheyenne Wills <cw= ills@sinenomine.net> wrote:
iomgr.c is not dependent on the Linux kernel (iomgr.c is= used for
some of the openafs servers and it's not used within the kernel
module).

The error message is related to the C compiler and the -std=3Dc23 option.
It appears that fedora 42 is setting the default compiler standard to
-std=3Dgnu23, which in a superset of C23.=C2=A0

To build under fedora 42, you will need to use a CFLAG of -std=3Dgnu17 or -std=3Dc99.

The coding standard that is used within OpenAFS is C89 plus a few
extensions (or as the coding style doc states "C99 minus a few
features).

--
Cheyenne Wills
cwills@sinenomin= e.net



On Fri, 18 Apr 2025 11:43:15 -0400
Eric Matlis <ematlis= @nd.edu> wrote:
> Dear developers-
>
> patches https://gerrit.openafs.org/#/c/16277/ and
> https://gerrit.openafs.org/#/c/16276/1 fail to fix op= enafs-1.8.13.2
> for compilation under Fedora 42 and kernel 6.14.2-300.=C2=A0 The error= I
> get using rpmbuild is:
>
> iomgr.c:50:23: error: =E2=80=98bool=E2=80=99 cannot be defined via =E2= =80=98typedef=E2=80=99
>=C2=A0 =C2=A050 | typedef unsigned char bool;
>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~
> iomgr.c:50:23: note: =E2=80=98bool=E2=80=99 is a keyword with =E2=80= =98-std=3Dc23=E2=80=99 onwards
> iomgr.c:50:1: warning: useless type name in empty declaration
>=C2=A0 =C2=A050 | typedef unsigned char bool;
>
> This was after applying the patches manually with "patch -p1 <=
> patchfile" to the source code extracted from the bunzip2 tar file= ,
> recreating the tar file, executing the procedure to turn tar files
> into a src rpm, and issuing "rpmbuild --rebuild xxx.src.rpm"= .
>
> Let me know if I can provide any other information.
>
> Thank you and please advise,
> Eric
>
> **********************************************
> Eric Matlis
> Associate Research Professor
> 114 Hessert Laboratory
> Aerospace and Mechanical Engineering
> University of Notre Dame
> Notre Dame, IN
> 574-631-6054

--000000000000cd81b10633173f0f-- From kaduk@mit.edu Sat Apr 19 06:42:32 2025 From: kaduk@mit.edu (Benjamin Kaduk) Date: Fri, 18 Apr 2025 22:42:32 -0700 Subject: [OpenAFS-devel] Openafs on kernel 6.14 Fedora 42 patched but fails to compile In-Reply-To: References: <20250418171854.454e9c9a.cwills@sinenomine.net> Message-ID: On Fri, Apr 18, 2025 at 09:06:37PM -0400, Eric Matlis wrote: > Thank you for the quick response. Using export CC="gcc -std=c99" before > rpmbuild --rebuild resolved this issue, however, not I get the following > errors: > > osi_vnodeops.c: In function ‘afs_linux_dentry_revalidate’: > osi_vnodeops.c:1636:10: error: ‘nd’ undeclared (first use in this > function); did you mean ‘fd’? > 1636 | if ((nd->flags & LOOKUP_RCU) != 0) { > | ^~ > | fd That looks to be in the vicinity of the patches that should be adding support for 6.14 kernels -- can you post your config.log somewhere so we can tell if configure is finding the functions we expect? -Ben