From mboxrd@z Thu Jan 1 00:00:00 1970 From: Havoc Pennington Date: Fri, 11 Apr 2003 19:29:20 +0000 Subject: Re: [ANNOUNCE] udev 0.1 release Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Fri, Apr 11, 2003 at 12:07:17PM -0700, Greg KH wrote: > Problem is I don't think we can use D-BUS messages during early boot, > before init is called, so we still have to be able to handle startup > issues. But hopefully the D-BUS code can be small enough to possibly be > used in this manner, I haven't checked that out yet. I'm not sure what the threshold for small enough is, but I'll give you an analysis of D-BUS size. The current size is: # size /usr/lib/libdbus-1.so text data bss dec hex filename 138905 1548 148 140601 22539 /usr/lib/libdbus-1.so # size /usr/bin/dbus-daemon-1 text data bss dec hex filename 170756 1616 160 172532 2a1f4 /usr/bin/dbus-daemon-1 The daemon statically links in the whole library, so the 138K is in fact copied twice; the daemon itself is not that much code. I'm not sure if libtool is already doing GC on unused statically-linked-in code or if -fgc-sections would help. The library contains some dead/unused code that could be cleaned up, but there are also a few small things not yet implemented. So I expect to stay in approximately the 150K range over time. We could probably get down to 100K by not handling out of memory (just aborting on out of memory), but it seems like we need to handle that. The OOM error codepaths are a pretty substantial percentage of overall code size, surprisingly so. The other significant fraction of the library is that D-BUS contains its own little utility lib that reinvents bits of GLib/Qt - hash table, linked list, memory pools, etc. This utility lib API isn't exported from libdbus-1.so, but is used by the daemon, which is why the daemon is statically linked. Library code specific to D-BUS functionality, minus generic utility code, minus OOM handling, is probably on the order of 50K. There is one external dependency, which is an XML parser. libexpat is the smallest one I know of: # size /usr/lib/libexpat.so text data bss dec hex filename 122440 6048 4 128492 1f5ec /usr/lib/libexpat.so As this dependency is only for the daemon, -fgc-sections and static linkage could help. We could also cut-and-paste the "gmarkup" pseudo-fake-xml-subset parser from GLib, that is about this big: # size /cvs/gnome-cvs/glib/glib/gmarkup.o text data bss dec hex filename 13816 4 0 13820 35fc /cvs/gnome-cvs/glib/glib/gmarkup.o Finally, as D-BUS is meant to be a well-defined protocol, it would also be possible to create a "lite" client library perhaps, by choosing to make certain sacrifices. (e.g. by allowing only a single connection at a time, not handling OOM, and always blocking instead of having the ability to integrate into a main loop.) Obviously that would be a maintenance burden, though. Havoc ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel