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    [from the cache]
    ©2003-2014 Jasper Spaans. Advertise on this site