On Wed, 2011-01-05 at 10:45 +0100, Nikola Pajkovsky wrote:
On Tue, 04 Jan 2011 14:45:41 +0100, Denys Vlasenko dvlasenk@redhat.com wrote:
On Thu, 2010-12-16 at 15:39 +0100, Nikola Pajkovsky wrote:
Moreover, crash_data_t and dump_dir were looking as a semi-generic containers up to now.
This patch adds a new concept, "list of attachments" to the container (why to only one of them, btw?).
I think such change needs to be discussed before it can go into git. The explanation could start with "what problem does this change try to solve?".
Jiri asks me to implement machinery to add an attachment via gui/cli.
Looks like we already have it: it's the CD_FLAG_BIN bit.
Every crash dump element which has that bit is a (possibly big and/or binary) file to be attached - as opposed to "some text".
What problems do you find when you try to use that bit as an indicator that this element to be attached?
To be honest, I thought that CD_FLAG_BIN is only for a binary files.
How do we make it?
If you need to add a new CD_FLAG_BIN element to crash_data_t, do it like this:
crash_data_t *cd = new_crash_data(); ... add_to_crash_data_ext(cd, "name", "file name", CD_FLAG_BIN);
If you create a crash_data_t by loading a dump dir:
crash_data_t *cd = create_crash_data_from_dump_dir(dd);
then it decides internally which elements are binary. The logic which decides "binari-ness" may need to be improved further.
From GUI perspective there must be a function which tells what is attachment(that's why I create a file *attachment* to remember what is attachment).
I don't understand. Can you explain (maybe with C code example) what functionality you need?