Ok. I guess it makes sense to handle all "events" in one way even if it's just a service started manually or in a runlevel file. But I want to stick with shellscripts and not write our own format yet again and as I understand it so will you. It will probably be simpler too to just have one way to "talk" with the daemon. As for the format I leave it up to you to decide, you'll probably change it a dozen times anyway. :P Just make something that works, that's all we can ask for. :D
New slogan for this project -> "Initng - everything is an event" :D Greets Jens Ismael Luceno wrote: > Jens Persson escribió: > >> What is better with events? Are there really a need for them? And do you >> mean to write a now format for the scripts or stay with shellscript? >> > > Events will let services react when something happens on the system, > i.e. if the system is about to suspend, a service can do something > before that happens. > > Events will be simpler, and can replace the ibin stuff (in a compatible > way if needed). > > I don't mean we should trow away sfiles, we only need a way to handle > events with them. > > >> Anyway, I can't see a need for events right now if that means to totally >> ditch service_file and start all over again. That would just be crazy. >> We need something that works today and not next month or next year or >> something. Why exactly are events better than the current stuff? >> > > Events will make possible the communication between initng and any other > process on the system, not just scripts. > > Also they will be able to modify already registered services, that's > needed in some circumstances... > > >> Ismael Luceno wrote: >> >>> The Problem >>> =========== >>> I really liked the idea of sfiles, but events simply screws up all. >>> >>> I mean, we don't have a way to handle events on sfiles, and all the >>> current functionality can be represented as events... >>> >>> What should we do about this? >>> >>> >>> Implementation >>> ============== >>> First, we need to define a protocol for external events. >>> >>> This will be the only interface available to any process outside of >>> initng. So that means it will be used by everything, even by ngc. >>> >>> I think it should be really simple. >>> >>> So it should be defined as something like: >>> >>> char **extern_event; >>> >>> In which each item has the form "name=val". >>> >>> >>> Transmission >>> ============ >>> The array can be passed to event subscribers as env[]. >>> It also can be transmitted to/from initng as plain text, one item per >>> line. >>> >>> So we could have something like: >>> >>> event=start >>> service=daemon/agetty >>> >>> or >>> >>> event=mount >>> device=/dev/sda3 >>> dir=/tmp >>> >>> >>> Internal/External event translation >>> =================================== >>> External events may produce internal events, and vice versa. >>> >>> Event translation will be handled by functions registered in the >>> event_type. >>> >>> To avoid loops, a "origin" flag should be placed in s_event, to >>> mark it as internal/external. >>> >>> >>> >>> > > -- _______________________________________________ Initng mailing list [email protected] http://jw.dyndns.org/mailman/listinfo/initng
