[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GSOC 2020] Draft of proposal
From: |
Alberto EFG |
Subject: |
[GSOC 2020] Draft of proposal |
Date: |
Fri, 27 Mar 2020 05:22:27 -0600 |
User-agent: |
mu4e 1.2.0; emacs 26.3 |
Hello, this is the draft of my proposal "GNU Guix: Syntax and semantics
of systemd units in the Shepherd"
Any feedback is welcomed :)
* Name
Alberto Eleuterio Flores Guerrero
* Email address
For Google: address@hidden
For GNU: address@hidden
* Title:
GNU Guix: Syntax and semantics of systemd units in the Shepherd
* Summary
The GNU Shepherd has a Scheme interface to define services, most importantly
their dependencies and actions associated with them. The goal of this project
is twofold. The first part consists in matching the semantics of systemd's
.service unit files, more precisely a subset thereof (for instance, the
DBus-related part may be omitted.) As part of this work, the Shepherd should be
extended with kernel Control Groups (cgroup) support on systems that support
it. The Shepherd should also be extended with a procedure to load a .service
file and return a <service> object.
The second part will consist in implementing other types of systemd units, in
particular systemd.socket activation and systemd.device.
* Benefits
Right now systemd is used by some of the biggest GNU/Linux distributions, this
includes the FSF approved distributions Parabola, Trisquel and PureOS. It is
pretty clear that systemd has the biggest user share of the Init systems
(although systemd is more than just an init system).
With this in mind, adding the ability to handle systemd unit files to the
Shepherd will have this benefits:
1. Shepherd will be extended to have a bigger API than it currently has, making
it more powerful.
2. Users will be able to use their custom systemd unit files with little or no
effort on Guix. This will also ease the work of migrating from most
distributions to Guix.
3. More distributions could be interested in adopting Shepherd as an
alternative to systemd.
** Considerations
Systemd is a project outside of Guix and Shepherd, it has been under heavy
development in recent years and the decisions by the developers are some times
criticized. Changes might be expected and compatibility might be broken from
time to time.
I understand this, and that my project will require continuos development and
manteinance after the end of Google Summer of Code, I am willing to work on
this for as long as possible.
* Objectives
1. Extend GNU Shepherd capabilities to handle systemd.service files
1.1 Add the appropriate mechanisms to GNU Shepherd API according to the
systemd.unit and systemd.service files.
1.2 Extend GNU Shepherd with cgroup support.
1.3 Add a library to parse systemd.service files and return an instance of
the <service> class.
2. Extend GNU Shepherd to handle other systemd.unit files, specifically
systemd.socket and systemd.device
** Notes
All the implementations of systemd unit files and cgroups will be according to
the Freedesktop specification.
https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
https://www.freedesktop.org/software/systemd/man/systemd.service.html
* Deliverables
1. The module service.scm should be extended for new methods and slots created
to match the systemd semantics. Specifically for systemd.service, systemd.socet
and systemd.device files.
2. Extend Shepherd to support cgroup.
3. A module written to parse systemd.unit files specifically systemd.service,
systemd.socket and systemd.device
4. The documentation for GNU Shepherd is written in the texinfo format in the
file shepherd.texi, this file will be updated to reflect the changes and new
capabilities of GNU Shepherd.
* Plan
** Before announcements (Today - May 4)
I would like to work during this period in my Scheme abilities, solve bugs for
Shepherd and Guix, get familiar with the coding standards, environment setup
and workflow.
** Community Bonding Period (May 4 - June 1)
In case I get accepted to work on this project, I would use this time to:
1. Compare systemd and GNU Shepherd API's to have a clear understanding of the
details of this project.
2. Talk with my mentor about the design of the modules to be implemented during
the project.
3. Become familiar with GNU Shepherd internals.
4. Work on my GOOPS abilities.
** Coding (June 1 - August 24)
*** Period 1 (June 1 - June 29 )
1. Extend GNU Shepherd to implement cgroup support on systems that support it.
2. Implement the missing mechanisms on GNU Shepherd of the systemd.service API.
*** Period 2 (July 1 - July 27)
3. Implement the missing mechanisms on GNU Shepherd of the systemd.socket API.
4. Implement the missing mechanisms on GNU Shepherd of the systemd.device API.
*** Period 3 (July 27- August 24)
1. Write a module to parse systemd.unit files and return them as a <service>
object.
2. Write documentation.
** After GSOC
I would like to work on extending GNU Shepherd, improving the documentation,
and making sure everything keeps working in case there are changes in systemd.
** How will everybody know whether things are on-track at the half-way
evaluation point?
For my code repository I can set up a Gitlab or any git repository or send the
code I write everyday to the mailing list. Whichever way my mentor feels is
more appropriate.
** Other activities
Part of my school semester will overlap, although my school activities are
mostly on weekends so it should not interfere with my work of GSOC.
* Communication
I can communicate using the Mailing Lists of GNU Guix. I already had and I have
sent a few patches already.
I can communicate in IRC with the nickname Blackbeard and with the Matrix
account @blackbeard:matrix.eunichx.us
* Qualification
** Why did this project appeal to you?
- It is a GNU project
- I would love to work on a Scheme project.
- I am a user of both Guix System, and Guix package manager. Sometime in the
past I installed GuixSD and thought "it would be easier for me to be able to
use systemd files" because I didn't know how to use Shepherd.
- I think this project could benefit users not used to Scheme and who want an
easy way to enjoy the benefits of Guix without taking much of their time.
** How will you benefit from it?
I will learn about GNU Shepherd internals and will be able to contribute more
to GNU Guix and become better at programming, specially in Scheme.
** Why are you particularly suited to work on this?
I am not a Computer Science student and I might not be really qualified,
however I particularly like Lisp, I am recognized as a small contributor in the
Acknowledgments of the book "How to Design Programs 2 Edition" (as Alberto E.
F. Guerrero) a book that teaches functional programming and test driven
development in Racket. I am also a proficient Emacs user with a huge
configuration and custom modes.
I've also read and worked through Structure and Interpretation of Computer
Programs, The Land of Lisp, among others. This means I can be an independent
learner and I would enjoy working in this project. I've also sent a couple of
patches to GNU Guix already and I try to help users on the #Guix IRC channel as
much as I can.
** Background
In the personal side, I am a promoter of Software Freedom. I am a student of a
master of Law of IT, because I want to promote and advocate for the human
rights in the digital world, and I've even met Richard Stallman in person a few
years ago when I assisted to one of his conferences in my country.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GSOC 2020] Draft of proposal,
Alberto EFG <=