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

Re: [GSoC Report] Week 5 - Systemd Unit Translator

K Gopal,

K Gopal Krishna <kayg@riseup.net> writes:

> Here are the set of changes in the past week (July 06 - July 12):
>   - Added better support for socket files that use a custom service file instead
>     of a file with the same name as the socket file.
>   - The translator will now work with any supplied path instead of defaulting to
>     the current directory. This was done with a bit of `dirname` / `basename`
>     magic.
>   - Directory creation was changed to be more specific. Directories are now only
>     created if they're needed which means that a `xinet.d` directory will not be
>     created for a `service` type conversion, etc.
>   - Since xinetd is incapable of handling filesystem sockets, socket-activate
>     has been used as an alternative. Since there's an obvious feature disparity
>     here, additional logic is needed in order to better differentiate and
>     delegate tasks between both the tools.
>     An overview of how the socket-activate part of the script works:
>     - A bash script is created with the used $listenType; first making the
>       directory the socket is to be placed in and then pointing to the socket
>       itself. Thereafter, the service command is appended to the end.
>     - Something worth noting here is that the script does not set `-u` to avoid
>       failures due to the service commands referring to undefined variables as
>       is the case in `acpid.service`.
>     The resulting script is stored in a `socket-activate.d` sub-directory.
>   - Instead of having just one big file, the script has been divided into
>     smaller scripts that define functions related to a specific unit type. This
>     would be beneficial in the future when the translator makes use of
>     additional tools.
>     - `misc.sh`: Functions which have an all-around usage like create_dirs().
>                  This is sourced before the unit type is known.
>     - `parser.sh`: Functions responsible for parsing key-value pairs of each
>                    unit type. This is sourced before the unit type is known.
>     - `{service,socket,timer}.sh` are self-explanatory. These are sourced
>       on-demand -- once the unit type is known.
>   - Most of the translator is now commented with explanations. Maybe examples of
>     using the functions are needed?


What's the change of success ratio after this week's work?  That's our
figure of merit.

What's your plan for the next week?


Reply to: