[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?

Good.

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?

Benda

Reply to: