[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC update

From: Ioannis Panagiotis Koutsidis
Subject: Re: GSoC update
Date: Thu, 12 Jul 2018 15:13:36 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

> Could you expound a bit?  That’s a very short summary for all the sweat
> you’ve put in it.  :-)
My apologies, at the time I sent the mail in a hurry.
Basically now instead of converting unit files to services individually it happens in bulk so that it can check if there is a corresponding .socket file per service file (and the reverse). If there is a corresponding .socket file then the input and output of the .service will be redirected to the result of (accept) on the socket corresponding to the .socket file. It also makes the select that waits for the commands from herd to also wait for the sockets.

> Also, what is the patch against?  It’s not against ‘master’; I suppose
> it’s against the previous state of your own branch, do you have a copy
> of your repo on-line?
It's against the previous patch that I sent, but I can put the branch online.

> It’s OK that the thing doesn’t quite work—we knew it was not an easy
> task.  What’s disappointing though is that you didn’t come to us to
> discuss the issues until now.  GSoC is not about working in all
> loneliness separately from the rest of the group; it’s about becoming
> part of the group.
> On IRC Jelle and I (and possibly others) offered help on the ‘signalfd’
> issue; I also outlined reasonable milestones (first, only use
> signalfd(2) instead of SIGCHLD, then discuss together what it would take
> to Fiberize the whole thing.)  It’s sad that you remained stuck instead
> of taking this opportunity to discuss it with us.
Until now (in general, not only during the gsoc) I tried to solve any issues that had arisen when I was programming by myself, so it was a bit difficult to change that mindset - I will try to be more communicative after this however.

> The patch changes lots of things and unfortunately, without
> explanations, I do not understand what to do with it.  Like what’s the
> new feature?  How is it used?  What implementation choices were made?
> What’s left to be done?…
The new feature is initial support of .socket unit files. It is used like:
(let* ((port1 (open-input-file "/systemd/test.service"))
       (port2 (open-input-file "/systemd/test.socket")))
(apply register-services (unit-files->services `(("/systemd/test.service" "test" service ,(read-unit-file port1)) ("/systemd/test.socket" "test" socket ,(read-unit-file port2)))))
  (close-port port1)
  (close-port port2))

The things that are left are supporting more systemd options, and making it work properly.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]