On Fri, May 30, 2008 at 04:06:04PM -0400, Colin Walters wrote: > implemented in userspace, but that doesn't mean it's just another daemon, > any more than TCP stacks that live in userspace in some old operating system > designs could just be restarted at any time without any obvious side effects > on the system. I would suggest you take a look at the failover work people have done in user space and also the higher level communication protocols. There is a reason it is done higher up the stack - you want to deal at transaction level. I can *turn off* my NFS server, go for lunch, come back, turn it on and my client -keeps working-. I can restart the old X font server live I can restart all my web services while using them and I maybe get a reset or odd error then it recovers I can unplug and replug hard disks and it'll recover nowdays in almost all cases Software should try and limp on and/or recover itself nicely. That way you'll get a usable product that degrades acceptably. You wouldn't build a house that fell down if any single brick cracked. > Speaking of userspace kernel integration, I'd be pretty surprised if you > could reliably stop the fuse service too; given all the discussion about > nearly unfixable race condititons in rmmod that have ( > http://lwn.net/Articles/31474/). Fuse is pretty close and its considered a bug that it isn't 100% perfect on this yet. > Auditing every program and making them able to cleanly support restarts of > system services like HAL, NetworkManager, and PackageKit would be a huge > task, for similar reasons because these services build up state. It might It would be a huge step forward if they firstly just restarted as a default response to dbus went away. Almost every one of them builds up a new state when run from startup and it'll be far better than "oh reboot again" Windows mentality crap. Some like NetworkManager need to be a bit smarter - but not a lot. > sort of work most of the time, but what you *really* do not want is for the > system to sometimes break when the user plugs in a USB key when the > background package upgrade happened to restart the bus at just the wrong > time. Most of the time is better than not restarting which means it *never* works. Which do you prefer Insert USB key - nothing happens Repeat 50 times, reboot or Insert USB key - nothing happens Repeat - ah success Aaln -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
