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