From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 3 13:32:24 2009 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 5EB581065670 for ; Tue, 3 Feb 2009 13:32:24 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by mx1.freebsd.org (Postfix) with ESMTP id AECB08FC13 for ; Tue, 3 Feb 2009 13:32:23 +0000 (UTC) (envelope-from gballet@gmail.com) Received: by bwz14 with SMTP id 14so1389188bwz.19 for ; Tue, 03 Feb 2009 05:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=uywUeC13JwMscd2XFi0JwE+S7DFTGtjtFquMn0yqlWY=; b=I8dWQvCz7WB451A/AICWp+SbotfJgdTWRjZW7Rk/YYGaFtEgEo1SjluNb5suPLg3GK XIPqI+/W5EdC292ai56liBBNbRGRItHzurzzBVrf2O5buWm0759clHKntlcTIvArCsF4 5gG5EQqi+9gQSdy8oalqnpNPA8NH3WWVyYZVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Sx/9enj8eZpb7BasOj7e3XqXaZNCJ2aqLh1kKYw4hNYny+C8ZfDzrQsav+YoTppnWI T3TPRKGDDyiMTLt0g+ap2dqyrTUTC7QXv/7aVUy2XWAija7kjddOq64kcbsOEL6kvrrZ GLzgDnvWRFQsfYmuNas1fHVTS5zzVkNvUydh4= MIME-Version: 1.0 Received: by 10.181.156.12 with SMTP id i12mr2075351bko.140.1233666648039; Tue, 03 Feb 2009 05:10:48 -0800 (PST) In-Reply-To: <20090131120022.7519F10656EB@hub.freebsd.org> References: <20090131120022.7519F10656EB@hub.freebsd.org> Date: Tue, 3 Feb 2009 14:10:48 +0100 Message-ID: From: Guillaume Ballet To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: freebsd-hackers Digest, Vol 305, Issue 6 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: Tue, 03 Feb 2009 13:32:24 -0000 On Sat, Jan 31, 2009 at 1:00 PM, wrote: > > Message: 4 > Date: Fri, 30 Jan 2009 09:41:58 -0800 > From: "Matthew Fleming" > Subject: Dynamic ddb commands > To: > Message-ID: <1233337318.13748.101.camel@amaretto> > Content-Type: text/plain; charset="iso-8859-1" > > I'm working on BSD 6.x and of course the set of ddb commands is static > to whatever is in the kernel at compile. I see that BSD 7.1 has dynamic > commands using sysinits and sysuninit's to call a new > db_[un]register_cmd. > > I see this, though, only after I have spent a day or so adding a > linker_file_[un]register_ddb() that works similarly to how sysinits are > merged for the boot-time modules (malloc and copy pointers). It seems > to me that this solution (have the linker look for db_set and db_cmd_set > and, if there are any entries, malloc and save pointers to commands) is > more efficient in terms of space than adding a LIST to the command > structure and then forcing sysinits to run. This is what I proposed at first, you can find a patch doing just that following that thread: http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg65165.html But Sam and John suggested to use the sysinit facility instead. I am convinced they are right: - Sysinits are a proven system, this is the least friction path. Also, by adding functions to the linker you still have the (small but existing) risk of adding bugs to that system. - This require adding new sections. Now, on regular x86 machines that doesn't seem too much of a problem. I am however currently working on a port of FreeBSD to some ARM cortex-based board. When debugging using JTAG, the smaller amount of sections whose location in physical memory I have to care about, the simpler for me and those doing the same kind of work. - You are not "forcing" sysinits to run: they are run no matter what when loading a module. - You can still debug sysinits when inserting modules, as the core of the debugger is already running and the list has been loaded in memory. The modules command itself will of course not be available, but the base commands will still be here. Cheers, Guillaume