From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 18 09:14:46 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1D241065679 for ; Mon, 18 Aug 2008 09:14:46 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 9C2878FC20 for ; Mon, 18 Aug 2008 09:14:46 +0000 (UTC) (envelope-from gballet@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so1242172wah.3 for ; Mon, 18 Aug 2008 02:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=joFWJ87tJmaSQKV7AyKF9oQuCR5jzvYUOcuijYnYvEw=; b=D+UAGJLm5Z7Qx2Q1vyRgrObHk2N4Um+xw5rOsHf/ct7zq0tfUwfPj7t7U0P/yq0GYO 89Nu6DuUmwsa+dZF/1mhDqzDetJcgMU/bo7QOyJtXzU9pq/vmMCuetVlQDJIy0u8Wlcp CqbvWmUVRN6HTfLG4LL1ycXzsnBnkGgnRlp5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=FG4rcPFbLlZbbZLdkpJotUD6zIQetHVveDjMN1Gh1eFGJblrUl2pfPJ9i8MdkhUg36 MnRQ/FwYHQgYy8r5/Fhy8SitqKDBLJtYibPV4k74WeL/uwJwLei2plvHTY7yZRhCULx+ LfPCKEjsPpPB0qd158UN9nu1ZeZasVSDrPEyk= Received: by 10.114.161.11 with SMTP id j11mr4740241wae.105.1219050886179; Mon, 18 Aug 2008 02:14:46 -0700 (PDT) Received: by 10.115.16.9 with HTTP; Mon, 18 Aug 2008 02:14:46 -0700 (PDT) Message-ID: Date: Mon, 18 Aug 2008 11:14:46 +0200 From: "Guillaume Ballet" To: "Sam Leffler" In-Reply-To: <48A86CA3.3040007@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48A70B37.60401@freebsd.org> <48A86CA3.3040007@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Extending the ddb command set X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2008 09:14:46 -0000 On Sun, Aug 17, 2008 at 6:23 PM, Sam Leffler 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.