lkml.org 
[lkml]   [2003]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] udev 0.1 release
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.201 / U:6.340 seconds]
©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site