chkconfig equivalent for upstart jobs on CentOS6

On RHEL6/CentOS6 what is the upstart way to:

chkconfig add my-svc
chkconfig my-svc on

Explanation: I have written an /etc/init/xvc0.conf job. I can do

start xvc0

on the CLI, but after reboot initctl list gives me

...
xvc0 stop/waiting
... 

So I need a way to insert my job in the boot upstart sequence.

(Incidentally, while researching this I found (Ububtu) posts advising to create the job as /etc/event.d/xvc0. That appears to be ineffectual - start xvc0 gives Unknown. What gives? And what is then the purpose of /etc/event.d?)

Cheers, alf

EDIT

While not a direct answer to my question I have found what follows:

1. If, in xvc0.conf I use the directive:

   start on runlevel [2345] stop on runlevel [016]

rather then the longhand:

start on runlevel 2
start on runlevel 3
...
stop on runlevel 0
...

The job is started at boot

1. I have found pointers to the (extremely confusing) directives:

   start on stopped rc RUNLEVEL=[2345] stop on starting rc RUNLEVEL=[016]

Which are also used in the prefdm.conf job and which also appear to work, but in a way that subtly differs from the former (did not understand how) and basically mess up what I am trying to do (which is, starting agetty on /dev/xvc0).

Even so, the question above stands - editing scripts (and in a language of a rather opaque syntax) in order to achieve automatic startup seems raher inconvenient to me.

Solution 1:

In the job itself using:

start on runlevel [2345] 
stop on runlevel [016]

rather then the longhand:

start on runlevel 2
start on runlevel 3
...
stop on runlevel 0
...

has the effect of starting the job at boot. Possible reason: every 'start' overrides the previous one (rather then adding to it).

As far as changing or documenting the starting/stopping of a job from the CLI, à la chkconfig, that appears not to be possible (a big upstart flaw, if you ask me). The other finer points go unaddressed, but see @MichaelHampton's comment to my question as to why the exercise is rather pointless anyway (in the RH universe, at least).