On Nov 26, 2007 4:31 PM, Scott James Remnant <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-11-26 at 13:40 -0700, Shawn Rutledge wrote: > > > On Nov 26, 2007 2:01 AM, Scott James Remnant <[EMAIL PROTECTED]> wrote: > > > disagree with your ratings as well (e.g. I would say that a monolithic > > > init is good, and plug-in based is bad). > > > > Why do you think so? > > > Plug-ins are also a major source of exploit attack vector, since they > allow you to load arbitrary code.
Yep that's a good point. > All init needs to do is spawn processes, and reap them when they die; > with some handling for determining when it needs to do the former and > working out what to do about the latter. Well at first glance I was inclined to think that when upstart aims to replace crond and atd, those might be good examples of functionality that could be plugins. Then again, the whole point is that events trigger processes to be launched, and the state of the system clock can be just another kind of event, so making upstart have cron functionality is pretty much aligned with its usual behavior. I suppose in the extreme case, anytime any process wishes to run another process as root, init could do it (via an IPC request of course); that way there is just one place where escalation of privileges is handled. But I'm sure you can think of some arguments against that (it sure isn't very traditional). > It's fine to write separate processes that communicate with init, and > ask it to spawn or stop processes on its behalf; but that's not a > plug-in architecture -- that's just decent IPC. On Nov 26, 2007 4:43 PM, Scott James Remnant <[EMAIL PROTECTED]> wrote: > Debugging interfaces ... why spend time developing debugging interfaces > for when init crashes? Why not spend that time making damned sure that > init can *NEVER* crash? Yep. > Upstart, in the extraordinarily unlikely circumstance that it might > crash (0.3.8 hasn't had a single report of one in the 1 year+ it's been > out), simply forks and dumps core in the child -- thus generating a So at least it doesn't halt the system, right? > Can save snapshots of the system status ... And why is this useful? If > you want to snapshot your system, hibernate it. One example I can think of (and of course I'm not speaking for Ismael) - Maybe it would be nice to define runlevels by example rather than by editing code. E.g. start the services that you want to be running, kill everything you don't, and then generate a runlevel definition based on the current system state. But that can be done by an external program easily enough. Not sure if it's even good idea... just an idea that's all. > Services garbage collector ... You don't bother to explain what you mean > here, so it's impossible to discuss. Maybe it has something to do with maintaining a pool of processes and scaling based on some sort of demand... but then init has to know too much to determine the demand. So some other process would be necessary to feed events to it when the demand happens (whatever form that takes). Or maybe to act like inetd or getty... start processes when a connection requires them, leave them up a while in case another connection requires them, then shut them down when they've been idle long enough. When devices are hotplugged, something needs to start relevant processes. This is already handled by messy script lashups on some distros, but it's conceivable to just treat that as any other event... init can respond to any event by launching any process, right? > Runlevel support ... Runlevels are ancient history, forget about them. As long as they are named rather than numbered, they could be useful, IMO. If you look at the list of plugins for init-ng, it's longer than I would have guessed. They made everything into a plugin... -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
