Date: Mon, 18 Aug 2008 11:14:46 +0200 From: "Guillaume Ballet" <gballet@gmail.com> To: "Sam Leffler" <sam@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Extending the ddb command set Message-ID: <fd183dc60808180214i1623e624l40832ad4403a71be@mail.gmail.com> In-Reply-To: <48A86CA3.3040007@freebsd.org> References: <fd183dc60808160203r3d90c26dq4d282d2ef153d2db@mail.gmail.com> <48A70B37.60401@freebsd.org> <fd183dc60808171017m7eabcef2xbe1845e54cda4c99@mail.gmail.com> <48A86CA3.3040007@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 17, 2008 at 6:23 PM, Sam Leffler <sam@freebsd.org> wrote:
(snip)
> Last I looked at this I was convinced it could be done using SYSINIT's and
> the existing mechanisms for adding ddb cmds. I don't think you need to
> modify the linker or ddb. Not sure if you looked sys/module.h and/or
> sys/kernel.h?
I have indeed looked at these files. That's actually what brought me
to work on the linker when I realize now that was no necessary.
Looking at them twice didn't hurt, though :)
SYSINIT is a good idea to get some "struct command"s into kernel space
and register them through come command. One can imagine creating a
DB_COMMAND_MODULE macro or something that would do exactly that.
I have however doubts on the registration part: In ddb/db_command.c,
the following table is declared:
static struct command_table db_command_table = {
db_commands,
SET_BEGIN(db_cmd_set),
SET_LIMIT(db_cmd_set)
};
which is the table that is used in db_command_loop. I am not aware of
any other mechanism to add commands to that list. That table is made
up of two parts: The first entry is a list of all the default
commands. The two next entries define the boundaries of a list of
pointers to optional commands. That list could be extended by a
module SYSCTL but:
- The table is declared as static, so at least that part must be
modified, or an accessor must be written. No big deal.
- Memory must be allocated and relevant information must be logged so
as to know what to remove when unloading a module. That is possible,
but I feel it is more risky because memory needs to be allocated and a
set of locks would not hurt in that case.
Parsing the list of modules each time has the advantage that no memory
has to be allocated and there is no concurrency problems when the
debugger is invoked (I think, please let me know if that assumption is
wrong). Also, module unloading is not a problem because once the
module goes, it is not in the list anymore and therefore commands can
not be seen nor accessed anymore.
Of course I could be wrong (or just biased?) so once again let me
know if you think otherwise. Note that I have a simpler patch in
progress that should not alter the linker since it will use
linker_file_foreach.
Either way, thanks for your comments. And sorry about the long message.
Guillaume.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd183dc60808180214i1623e624l40832ad4403a71be>