| Keybuk | sadmac2: unless I'm mistaken | 13:17 |
|---|---|---|
| Keybuk | you've not described anything new, just used a different language to describe what we were already talking about | 13:18 |
| Keybuk | *and* haven't actually solved the filesystem mounting "problem" as defined | 13:18 |
| Keybuk | lit. that it is not possible to do native upstart mounting of filesystems _without_parsing_fstab_to_create_the_states/jobs_ | 13:19 |
| Keybuk | also you don't appear to solve the /usr/local must be mounted after /usr issue (but there's no pitfall either, since you parse fstab you can work out whether you need a dep) | 13:20 |
| sadmac2 | Keybuk: that its mostly the same is a good thing. Most of what's new is the rigor: its very meticulously defined. The other new thing is the very freeform way deps work. st(a: 1, *) -> b() and st(c: 1, *) -> d() means st(a: 1) depends on b(), st(c: 1) depends on d(), and st(a: 1, c: 1) depends on b() /and/ d() | 15:46 |
| sadmac2 | Keybuk: for the mountpoint issue we can just add one dep: mounted(mountpoint: %1) -> file_exist(name: %1) | 15:48 |
| sadmac2 | that state would have to be a bit special internally but its not hard to write | 15:49 |
| Keybuk | but you do have to preparse fstab | 15:50 |
| sadmac2 | Keybuk: I don't know that a lot of that information is defined anywhere else. You could rely on disklabels being equal to the mountpoint, but that's not good | 15:51 |
| Keybuk | still doesn't help | 15:56 |
| Keybuk | so we still need a binary to parse fstab and create upstart states/events/jobs for the information there | 15:56 |
| Keybuk | which is pretty much where I got to :p | 15:57 |
| Keybuk | the only real question is how much of that binary is logic only | 15:57 |
| Keybuk | and how much is implementation | 15:57 |
| Keybuk | ie. does it just say "when you see blah, run the upstart job blah" | 15:57 |
| Keybuk | or does it actually define what the upstart job is (fsck on ...) | 15:57 |
| sadmac2 | Keybuk: I don't think we need a binary | 15:57 |
| sadmac2 | Keybuk: its just a few calls to getmntent() | 15:58 |
| Keybuk | so you need a binary | 16:00 |
| sadmac2 | Keybuk: why put that in another application? its 3 lines of code | 16:00 |
| Keybuk | where else would you put it? | 16:00 |
| Keybuk | it's not something I'd want to hardcode into init | 16:00 |
| sadmac2 | Keybuk: it could essentially go in the state machine | 16:01 |
| Keybuk | only if init parses fstab | 16:01 |
| Keybuk | which is just wrong ;) | 16:01 |
| sadmac2 | Keybuk: ah, but the state machine isn't /in/ init anymore, remember? | 16:01 |
| Keybuk | especially if you wanted to develop a system that did rely on lvm labels, or btrfs, etc. | 16:01 |
| * Keybuk still doesn't think that's possible | 16:01 | |
| sadmac2 | its more than possible. its easy | 16:02 |
| sadmac2 | Init only needs 2 dbus methods (strictly speaking. there may be good cause for more): | 16:03 |
| sadmac2 | init.run(handle, script, script_on_fail) | 16:03 |
| sadmac2 | init.stop(handle) | 16:03 |
| sadmac2 | when a state comes up that corresponds to a job, it calls init.run("name_of_state(args: foo)", "exec /sbin/mytask", "emit failed job=$HANDLE") | 16:05 |
| sadmac2 | when the state machine gets a failed event, it downs the state matching the job argument thereof | 16:06 |
| sadmac2 | you're probably not putting /enough/ in userspace the way you're picturing it. Pid 1 is now just a glorified bash shell with really good session management | 16:07 |
| sadmac2 | (and dbus instead of stdin) | 16:07 |
| === notting_ is now known as notting | ||
| Keybuk | you know that pid 1 is in userspace, right? :p | 19:04 |
| Keybuk | I don't see what your split buys us, except a much more complex code base | 19:04 |
| sadmac2 | Keybuk: yeah, whatever the hell you call it :) | 19:06 |
| sadmac2 | Keybuk: the split is good for separation of concerns. From outside of the two, jobs are states, but from within, the state machine doesn't really know there's such a thing as jobs and the service manager doesn't know anything about states | 19:07 |
| Keybuk | but it doesn't work ;) | 19:08 |
| Keybuk | the two become so closely coupled, that you're inherently more inefficient by having the split | 19:08 |
| sadmac2 | Keybuk: They're pretty decoupled the way I set it up abouve | 19:08 |
| sadmac2 | *above | 19:08 |
| Keybuk | pid 1 would have only one method | 19:09 |
| Keybuk | exec() | 19:09 |
| Keybuk | takes a command, returns a handle | 19:09 |
| Keybuk | that handle/object would have only one signal complete() | 19:09 |
| Keybuk | and only one method stop() | 19:09 |
| Keybuk | complete would say what exit code, or signal, etc. | 19:09 |
| Keybuk | stop would send TERM/KILL | 19:09 |
| Keybuk | -- | 19:09 |
| Keybuk | which means it's incapable of doing anything on its own | 19:10 |
| Keybuk | the pid 2 would have the full state machine | 19:10 |
| Keybuk | but to do anything has to invoke all the methods and listen to signals on 2 | 19:10 |
| Keybuk | on 1, even | 19:10 |
| sadmac2 | it can't do anything automated on its own | 19:10 |
| Keybuk | this does not make anything simpler, it makes it much more difficult | 19:10 |
| sadmac2 | it costs little to invoke those methods | 19:11 |
| Keybuk | it costs impossibly more than just having a C method call to do it | 19:11 |
| Keybuk | bear in mind as well that pid 1 is the pid that knows about forks and children dying | 19:12 |
| sadmac2 | right | 19:12 |
| Keybuk | so even a status() call needs additional methods/signals to talk between the two | 19:12 |
| Keybuk | I don't see that this makes anything better | 19:12 |
| sadmac2 | status is either starting,started,stopping,or stopped | 19:15 |
| sadmac2 | that works from the previous mechanism | 19:15 |
| sadmac2 | the state machine only thinks about the service being in two of those: started and stopped | 19:16 |
| Keybuk | so pid 1 needs a state machine | 19:16 |
| Keybuk | in fact, pid 1 needs *the* state machine | 19:16 |
| Keybuk | so what is pid 2 doing? :p | 19:16 |
| sadmac2 | pid 2 = generate a list of what is supposed to be running. pid 1 = make the system reflect that, and scream when this is impossible. | 19:17 |
| Keybuk | I don't think you're buying anything by separating the two | 19:17 |
| Keybuk | except complexity for no good reason | 19:17 |
| sadmac2 | I want the two to be decoupled in the design. | 19:20 |
| sadmac2 | If they're in the same process or not. | 19:20 |
| Keybuk | they're decoupled in the *current* design (0.3/0.5) | 19:22 |
| Keybuk | they're in different .c files, after all | 19:22 |
| sadmac2 | if you look at the state machine as nothing but mathy bits and lights turning red and green; that is to say if you ignore the fact that programs are supposed to be started/stopped in relation to it, you should be able to add /exactly/ 3 things to it and have it able to manage services | 19:25 |
| sadmac2 | 1) rising edge actions: some arbitrary piece of code that is run when a state becomes up | 19:26 |
| sadmac2 | 2) falling edge actions: the same run when a state becomes down | 19:26 |
| sadmac2 | 3) fail-on events: the ability to have an event cause a state to go from up to down /without/ running the falling edge actions | 19:27 |
| Keybuk | err | 19:27 |
| Keybuk | but we're not writing a mathy state machine | 19:27 |
| Keybuk | we're writing something that programs are started and stopped by | 19:27 |
| Keybuk | I think it's dangerous to try and think the two are unrelated | 19:27 |
| sadmac2 | the state machine is unrelated to the services in the sense that the strings and integers you use in your program are unrelated to the electrical charges on the bits of sillicon in the box under your desk. | 19:29 |
| Keybuk | you mean they're the same thing? | 19:30 |
| Keybuk | which I think is my point | 19:30 |
| sadmac2 | I don't think they're the same thing. In a sense the first doesn't even exist. | 19:31 |
| Keybuk | services *are* the states | 19:32 |
| sadmac2 | for some value of services | 19:32 |
| sadmac2 | states don't have a pid, or a vm area, or a task_struct, or signal handlers.... | 19:33 |
| sadmac2 | states are conditions. they are true or false values | 19:33 |
| sadmac2 | you shouldn't need any system calls to set something to true or false | 19:34 |
| Keybuk | it being true is dependant on syscalls having been run | 19:34 |
| Keybuk | likewise it becoming false again is also dependant on that | 19:35 |
| sadmac2 | true | 19:35 |
| sadmac2 | but states don't /fail/ | 19:35 |
| sadmac2 | they can become false for any of umpteen reasons | 19:35 |
| sadmac2 | but there's no real "break" | 19:35 |
| Keybuk | I think you're thinking too much in terms of mystate and thystate | 19:38 |
| Keybuk | you need to think about dbus and apache | 19:38 |
| sadmac2 | mystate and thystate is a trivial problem | 19:38 |
| sadmac2 | dbus and apache are not | 19:38 |
| sadmac2 | but making dbus and apache /appear/ like mystate and thystate is | 19:38 |
| sadmac2 | so its two trivial problems or one complicated one | 19:39 |
| Turl | any way to speed up ubuntu boot process? I'm open to testing new things | 20:26 |
| Keybuk | roll it down a hill? | 20:44 |
| ion_ | Overclock the modem. | 20:45 |
| sadmac | Value Add! | 20:46 |
| === Turl1 is now known as TUr1 | ||
| === TUr1 is now known as Turl1 | ||
| === Turl1 is now known as Turl | ||
| === Turl1 is now known as Turl | ||
| === notting_ is now known as notting | ||
| mbiebl_ | Keybuk: hi | 22:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!