[11:19] <keesj> Hi
[11:19] <Keybuk> hey
[11:22] <keesj> I am playing with upstart. I am trying to implement a state machine for my system
[11:23] <keesj> I wonder if it makes sence :). the big idea would be to emit events from userland or the kernel and handle upon them in upstart
[11:24] <keesj> I have a 3 gui apps that will run (not at the same time)
[11:27] <keesj> I would like to be able to emit "high" level events "start_mass-storage-app" and translate that into  a few command (insmods perhaps) and starting a gui
[11:27] <keesj> can I emit such event from within a job
[11:28] <keesj> simply saying.. can I emit events from withing a jobs 
[11:36] <Keybuk> sure
[11:38] <keesj> by calling initctl ? 
[11:40] <Keybuk> right
[11:41] <keesj> there is no "emit" command"
[11:46] <Keybuk> there is
[11:46] <Keybuk> initctl emit
[12:12] <keesj> thanks
[12:12] <keesj> I installed upstart in a different directory... I need to prefix the initctl command :(
[12:12] <Keybuk> you can make an "emit" command by just symlinking to initctl :p
[12:12] <Keybuk> right
[12:13] <Keybuk> fixing that is on the TODO
[12:13] <keesj> that's nice
[12:21] <keesj> and would there be a way to store the current states so I can ask it again later? 
[12:22] <Keybuk> how do you mean?
[12:23] <keesj> just like runlevels work ( that you can ask the current runlevel)
[12:23] <Keybuk> still not 100% following
[12:23] <keesj> I would like to keep some variable to implement my state
[12:24] <keesj> if (in_mass_storage) and usb unplugged -> rmmod ...
[12:24] <keesj> in_mass_storage would be a state
[12:26] <keesj> in the sample scripts "they" do         set $(runlevel --set 1 || true)
[12:27] <keesj> to determine if an event gets handled based on the previous runlevel (this is sample code named rc1)
[12:28] <Keybuk> right, I'm kinda trying to get to that point
[12:28] <Keybuk> where upstart has states that are true or false
[12:28] <keesj> you are one of the developers, cool
[12:29] <Keybuk> heh, the upstart developer
[12:29] <keesj> yo!
[12:30] <keesj> I am currently testing by using a qemu (I first tried a chroot ) but the apparently was not the best way to do things
[12:30] <Keybuk> I just have it installed by default
[12:31] <Keybuk> it replaces sysvinit well enough
[12:31] <Keybuk> you can carry on running the old init scripts while playing/developing
[12:32] <keesj> I am playing with it for mamona so it is an embedded platform (under arm)
[12:33] <keesj> do you happen to know this package? http://smc.sourceforge.net/ (state machine compiler)
[12:39] <Keybuk> I don't, no
[12:41] <keesj> I used it a lot to create state machines. but basicaly you need "previous_state" + event to implement this 
[12:42] <Keybuk> right
[12:42] <Keybuk> depends what you want to do, really
[12:43] <keesj> the "quick" hack would be to misues the initctl to tell init to change it's own "environement"
[12:44] <keesj> thanks for your time btw (I really apreaciate it)
[12:44] <Keybuk> right, but I'm not sure I fully understand what you want to achieve
[12:47] <keesj> hmm . perhaps I am just thinking the wrong way around. let me try to give a simple example
[12:51] <keesj> my system can have twoo states "video playback" and "mass storage". 
[12:52] <keesj> if somebody presses the power button while in mass storage I don't like that so I would like to ignore a "power" event when in storage mode. 
[12:53] <keesj> I was thinking in the line of creating a "button" event handler that listend to power_on power_off event
[12:54] <keesj> other events would be something like usb_connected (being a good reason to switch to mass storage)
[13:00] <keesj> I think I am taling about level events
[13:00] <Keybuk> what other kinds of decision would you make based on these states though/
[13:04] <keesj> whell I have a few of those event flying in (usb state changes, button presses, system update event) I was also thinking of using this state when going in "suspend" mode
[13:04] <keesj> so that when I wakeup I know what program to start again
[13:05] <Keybuk> when suspending why do you need to stop programs?
[13:06] <keesj> good questions :p
[13:09] <keesj> currenty I had to do it because I don't get events when in suspend , so if the device is in video mode , I suspend , and plug it to a computer , I miss the "connected" event
[13:09] <keesj> (just like udev meesd to cache the events generated by the kernel , I guess this is not the scop of upstart :p
[13:13] <keesj> I am getting there !
[13:14] <Keybuk> not entirely sure yet what the scope of upstart is ;)
[13:16] <keesj> haha
[13:17] <keesj> the code looks very clean
[14:12] <keesj> are you at fosdem?
[14:20] <Keybuk> no
[14:23] <Keybuk> I've never been to one of those
[14:37] <Keybuk> http://upstart.ubuntu.com/wiki/RemoveEventArguments
[14:37] <keesj> I can be nice :op
[14:37] <Keybuk> Any objection?  no?  good!  :o)
[14:39] <keesj> haha
[14:39] <keesj> it
[14:41] <keesj> I really just should al be programmed in lua
[14:42] <Keybuk> why?
[14:44] <keesj> I see plenty discussion about creating, "combined events" or other other structs that would be possible if upstart used a scripting language for the events definitions
[14:44] <keesj> but the current aproach is also pretty clean i guess
[14:46] <keesj> >>from (tty-added or cua-added) and foo<< does that get interpreted every time an event would come?
[14:52] <Keybuk> the string? no
[14:52] <Keybuk> it's compiled into a match tree in memory
[14:53] <keesj> hmm that you can not replace by lua :)
[14:53] <Keybuk> what would lua gain though?
[14:56] <keesj> in this case nothing. but just like the current script  command you could script the behaviour (if an event is consummed by an handler)
[15:04] <keesj> my system looks a little like the stoplight (the left image) http://smc.sourceforge.net/Images/SmcEx4_Stoplight.png I get the same type of events (like a timeout ). I see very whell how to perform the "start,turn light etc" . 
[15:05] <keesj> you get the same "message" but want to perform something different(if you want me to stop just say so  , I am really trying to find a awy to do it)
[15:06] <keesj> I have put the different events in an event_handler that performs the few functions  
[15:06] <keesj> so I can not emit "switch_from_a_to_b"
[15:08] <Keybuk> hmm
[15:08] <Keybuk> currently Upstart's event matching is more functional than procedural
[15:09] <Keybuk> ie. you describe the state in which the job is running
[15:09] <Keybuk> inside the job itself, you have a shell script, so it's procedural
[15:09] <keesj> Yes , I Have the feeling I really am missing the point :p
[15:09] <Keybuk> I'm not sure I've got the point ;)
[15:09] <keesj> AM I trying to misue the system?
[15:09] <keesj> missue
[15:09] <Keybuk> I'm not quite sure what you're trying to do yet
[15:11] <keesj> in a perfect work I would like to say "emit go_into_mass_storage" where ever you come from
[15:12] <Keybuk> you wouldn't use an event like that
[15:12] <Keybuk> I'd define mass_storage as a state/job
[15:12] <Keybuk> so "start mass_storage"
[15:14] <keesj> yes I have this part http://paste-it.net/6595
[15:15] <keesj> so do I need to create a userland progress saying "emit stop_mass_storage" "emit start_video"
[15:17] <keesj> with just the start/stop the system looks like /etc/init.d/mass_storage [start|stop]
[15:18] <keesj> or would start mass_storage stop video?
[15:19] <keesj> the backwards compatible scripts use wmtp to "know" what the current runlevel is
[15:29] <keesj> I am getting there ... /initctl list
[15:29] <keesj> shows a list of active tasks, I can only have one state active at the time.....
[15:30] <Keybuk> so you'd make your states start and stop each other?
[15:30] <Keybuk> or be started and stopped by the same events
[15:31] <keesj> I will listen for event use the initctl to know the current state and react as supposed
[15:32] <keesj> I currently implemented it a separate jobs that are triggered by events (the switching between states) 
[15:33] <keesj> So I guess the second option
[15:34] <keesj> perhaps I might even use the list to do sanity checks
[15:53] <keesj> I will try to hack a version and try to post it to the list
[16:01] <Keybuk> shiny
[16:05] <keesj> I hope it wil work. (that there are no race cases...) 
[16:06] <keesj> it requires a state to keep running apparently a jobs that is started and exits is in a "stop" state again
[16:14] <Keybuk> (gdb) p *((EventOperator *)job->start_on->node->left)
[16:14] <Keybuk> $5 = {node = {parent = 0x662720, left = 0x0, right = 0x0}, type = EVENT_MATCH, 
[16:14] <Keybuk>   value = 0, name = 0x662670 "wibble=foo bar", env = 0x0, event = 0x0, 
[16:14] <Keybuk>   blocked = 0}
[16:14] <Keybuk> (gdb) p *((EventOperator *)job->start_on->node->right)
[16:14] <Keybuk> $6 = {node = {parent = 0x662720, left = 0x0, right = 0x0}, type = EVENT_MATCH, 
[16:14] <Keybuk>   value = 0, name = 0x6628a0 "wobble=foo bar", env = 0x0, event = 0x0, 
[16:14] <Keybuk>   blocked = 0}
[16:14] <Keybuk> (tangent:
[16:14] <Keybuk>  damn I was on good form when I wrote this, I predicted I'd need something a year down the line)
[16:14] <Keybuk> that was from
[16:15] <Keybuk> "wibble=foo bar" or wobble="foo bar"
[16:15] <Keybuk> so it handles quoting sensibly
[16:21] <keesj> can I get the event name inside my scripts?
[16:22] <keesj> UPSTART_EVENT...
[16:22] <Keybuk> right
[16:22] <Keybuk> $UPSTART_EVENTS in trunk
[16:33] <keesj> week-end here. thanks a lot for the help!
[16:33] <Keybuk> enjoy
[16:33] <keesj> thanks