This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Some notes on translation
Ulrich Drepper wrote:
Tom Zanussi wrote:
> In my experience DWARF2 is not as easy to use as it should be.
That's also what I've heard - all the more reason to start now. This
could be a tiny first step toward the much-desired dwarf2 library.
As Frank mentioned, libelf already has a DWARF library: libdw. This is
not the same as SGI's library. The latter is unusable since the memory
handling cannot be done without leaking.
The header for libdw is not yet installed since I didn't want to expose
the interface until this is needed. I can do this anytime, though. And
as far as higher-level functionality which is needed: just let me know
what is needed. Describe the problems to solve and I can add
appropriate functionality to the library.
Elena mentioned that she will get us some help with dwarf library work from
gdb team, i am hoping the library Ulrich mentioned is same as what Elena
mentioned, i hate to duplicate the work. Elena please correct me if i am
wrong.
I'm
not sure why we'd want to use /proc in place of netlink in any case -
also I thought putting new stuff in /proc was discouraged anyway.
/proc seems like the wrong place for many things. But there are a
number of other filesystems available. There are special filesystems
for high-bandwidth kernel<->userland transfer etc. And it is not hard
to write a new filesystem.
The problem with netlink is that the messages which can be read
atomically are limited in size and they are broadcasted. The latter
would basically mean no sensitive data can be transfered (unlikely) or
the system is unsafe the second you start using this functionality.
I agree with Ulrich completely that netlink is not the right solution
for our needs here. I think there are already lot of filesystems out
there that we can use with minor modifications we should try to
reuse them. Now that relayfs has gone through community
review and everyone seems to be happy with the last version we
should consider that for our needs. I understand that relayfs might
not have few api's that we need but we can add them easily than
developing a new filesystem altogether.
I just got a request for able to notify user land using our infrastructure
of some important state changes in the kernel, they might have to
do this in low memory situations as well. If i understand correctly
netlink needs memory allocation as part of the sending the data,
which doesn't meant this groups need.
One of the features customers liked in my last weeks LWE presentation
was able to have a low overhead trace buffer that gives vital information
about what are the last set of events that lead to the bad state of the
kernel.
If we use netlink we will not get this preallocated buffer without
additional
work.
--
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â