On Tue, 2005-03-15 at 08:01 -0500, Bill Rugolsky Jr. wrote: > If it is some huge bloated behemoth that may die due to bugs, Any software can crash due to bugs. The same is true for someone writing some hypothetical D-BUS replacement on top of netlink or whatever. But you might notice that the D-BUS authors care a lot about checking for bugs; for example, there's a lot of unit tests, patches are reviewed carefully, etc. > or gets > killed by the OOM-killer, etc., The OOM killer is really just a last gasp for the kernel; I've seen several kernel hackers like Alan Cox say that it isn't even guaranteed to kick in or work. I do think we should be able to exclude certain applications from it though like the system bus. > then apps must reliably reconnect. If > it _can_ crash, it _will_ crash, quite often for certain workloads. D-BUS is designed to be reliable. Anyways, I'm confused as to how we started talking about reliability in a conversation about upgrades. > If it is compact, simple, and never crashes, then a less complex model > fault model may be appropriate. But, at a minimum, I'd expect the > system dbus to be able to checkpoint its state and rexec itself, with > file-descriptors held open across exec() if necessary. It certainly > wouldn't be the first daemon with such requirements. That's not written though, and we need to work with what we have now. > I'd like to see all of networking handled dynamically, so that the Linux > networking stack can be used to its full potential. The same is true > for storage mgmt (which looks more like networking every day). But if > dbus is not going to be as robust as init, What makes you think it's not?
Attachment:
signature.asc
Description: This is a digitally signed message part