alias stanza wip patch

[Marc - A. Dahlhaus]

Am 16.06.2011 20:53, schrieb James Hunt:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Mark,

Hi Jamez,

(just kidding ;)

> On 15/06/11 01:02, Marc - A. Dahlhaus wrote:
>> Hi List,
>>
>> this is a first and for now only compile-tested draft of the alias stanza.
>> Tests for the stanza are missing.
>> The code for the alias stanza parsing is a copy of the one for the emits stanza.
>> The testsuite of a patched 1.3 runs fine (exept for the X11 dependent tests as my box has no X11 running).
>>
>> I'm unshure if the handling of blocked events with an alias configured works in this draft version, i'm still reading the code path of event.c and try to check if i'm not overlooking something.
>>
>> Currently i add all blocking aliases to the main jobs blocking queue/list and hope that the catch in the event_poll loop works out as expected.
>> I think there is a call to event_block missing for every alias event.
>> I still have to check out how the whole blocking event chain code works...
>>
>> Thanks,
>>
>> Marc
>>
> Thanks very much for this. One minor comment:
> 
> * init/job.c: job_emit_event(): Maybe "blocked_alias" would be easier to read than "blockedalias".

I changed it.

> What we're also going to need I think is a global hash to map alias names to actual job names to
> allow for the "start display-mananager" syntax to work. Essentially every place a job name can be
> specified via initctl, we should also accept an alias name. Ignoring initctl for now, maybe
> something like:
> 
> 
> typedef struct job_alias {
>     NihList   entry;
>     char     *name;    /* alias name */
>     Session  *session;
>     NihList   aliases; /* NihListEntry pointers to JobClass objects */
> } JobAlias;
> 
> NihHash job_aliases;
> 
> 
> Then, when a request comes in to start "display-manager", control_get_job_by_name() can quickly find
> the (hopefully) single match for "display-manager" in job_aliases and start a "gdm" Job instance (say).
> 
> Questions:
> 
> - - What if multiple .conf files *do* contain the same alias name? Even though this isn't legit, we
> need to ensure we handle the scenario.
> - - What if a job defines an alias for an existing job name?

First active job or alias should win and a job always should take
precedence before aliases.

I also thought about the handling in initctl, how about adding jobs and
aliases to a hash list, and use the list as a source of known jobs for
initctl.

typedef struct known_job {
    NihList   entry;
    char     *name;    /* job or alias name */
    Session  *session;
    JobClass *job;     /* pointer to JobClass object of real job */
    NihList   aliases; /* NihListEntry pointers to JobClass objects */
} NamedJob;

NihHash *known_jobs;

On any alteration of a Named Task (no matter if its a real job or an
alias) with initctl we could look up the name in the list of known jobs
and when we find one we use the first non manual JobClass we can find
for the interaction. We first check if *known_jobs->job is set and not
disabled by manual and use it or otherwise do the same checks for every
list entry in aliases.

That way we have no complicated error handling involved. We add a job to
its hash entry and is takes precedence even if aliases for the job were
parsed earlier. We can use the hash list for any initctl interaction.

I haven't read over the code of initctl and i did not look if a hash
list for job already exists in upstart that could be extended to handle
aliases so all of this should be taken with a grain of salt.

I don't think that we need to disable the sending of alias events for
jobs that are active and are not the first provider for a given alias.
All events depending on the alias are run by the first provider of the
alias so all should be well even if we encounter an event more than one
time.

What do you think?

Marc