tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Discussion regarding GSOC inetd task
In article <CABQqohWgtA8=-g5QPkL3RLE=z7NF1QS0S3BMSp8yQ_b3uSEVkg%mail.gmail.com@localhost>,
Marwan Basem <marob27105%gmail.com@localhost> wrote:
>-=-=-=-=-=-
>
>Subject: GSoC 2025 - Inquiry about inetd enhancements project
>
>Dear Mr. Zoulas and the NetBSD tech-userlevel team,
>
>I hope this email finds you well. My name is Marwan Basem (GitHub:
>https://github.com/MaroB05/), and I'm interested in contributing to NetBSD
>through the Google Summer of Code program by working on the inetd
>enhancements project.
k
>I have experience implementing various Unix utilities in C and developing a
>performance benchmarking tool called Bentest. While my background in
>network programming is limited, I'm eager to expand my skills in this
>domain and believe the inetd project would be an excellent opportunity for
>growth while contributing meaningfully to NetBSD.
>
>After reviewing the project description, I'd appreciate your guidance on:
>
>1. Which parts of the NetBSD codebase I should study first to understand
>the current inetd implementation
The source code is in /usr/src/user.sbin/inetd.
>2. Any design considerations or constraints I should be aware of for the
>proposed enhancements
Allowing users to schedule their own daemons has important security implications.
>3. Whether there are specific architectural approaches you'd prefer for
>features like pre-forking and per-service configuration
Nothing specific, you should check prior-art in pre-forking. Per service
configuration is already implemented.
>4. Are there any pit-falls which you would like to warn me about before
>working on the project?
Some of it (individual configuration files) has already been done.
>My initial approach would include:
>- Studying the current inetd codebase in NetBSD to understand its
>architecture
>- Comparing with other implementations (like xinetd) for per-service
>configuration approaches
>- Developing a test framework to validate functionality before and after
>changes
>- Measuring inetd's performance and resource usage for later reference.
>- Implementing the pre-forking feature with proper resource management
>- Designing a backward-compatible per-service configuration system
>- Enhancing the rate-limiting and logging features with configurable
>parameters
Sounds good. You should allocate time for documentation.
>I'm committed to learning what's necessary to complete this project
>successfully and would value any resources or direction you could provide
>to help me prepare a strong proposal.
>
>Thank you for your consideration.
You are welcome.
christos
Home |
Main Index |
Thread Index |
Old Index