From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 3 18:05:03 2010 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 A46C71065693 for ; Fri, 3 Dec 2010 18:05:03 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 677028FC26 for ; Fri, 3 Dec 2010 18:05:03 +0000 (UTC) Received: by iwn39 with SMTP id 39so11444735iwn.13 for ; Fri, 03 Dec 2010 10:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Znt89ePPioj3Gbe9x5iHAm5bdhEFzezQ0GF/tSPT1QY=; b=w0cw+sQrHWXluxEsYLqU+1PJ1W0Zek3oT7DfrGd9uk891wL6pobPhO+OjqQKsw4ekg RHjTQO1KhfkVUrQv9WIbJCjYSBwX562VS1XUNTLusclRfR+ebIM19tbK14jQei/T3iWh YOiCEnASGcwgvFgzBgXZE7D9/pPHJxUIQ+2Ns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=k18+zcnzxbKUC7htsxJmMyBVdk/+4AsN14pcqJdmvHWXHPB4puz0ndfUDKHz971hCV eXWnIOPapOYX0ZJO8SSsj9CMLUNHCsdysC/6aPA2ExBkxi2Q8bu8qwSalLQrL/8M4ef9 g1J31CCB1KgwtvZUF3e1TPm8i1daJxWLGnbnk= MIME-Version: 1.0 Received: by 10.231.11.9 with SMTP id r9mr2166173ibr.47.1291399502775; Fri, 03 Dec 2010 10:05:02 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.21.35 with HTTP; Fri, 3 Dec 2010 10:05:02 -0800 (PST) Date: Fri, 3 Dec 2010 10:05:02 -0800 X-Google-Sender-Auth: s7xoRU3trLnPCuxho4b9xGghThU Message-ID: From: mdf@FreeBSD.org To: freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1 Subject: coretemp(4)/amdtemp(4) and sysctl nodes 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: Fri, 03 Dec 2010 18:05:03 -0000 There are very few uses in FreeBSD mainline code of sysctl_remove_oid(), and I was looking at potentially removing them. However, the use in coretemp/amdtemp has me slightly stumped. Each device provides a device_get_sysctl_ctx sysctl_ctx that is automatically cleaned up when the device goes away. Yet the sysctl nodes for both amdtemp and coretemp use the context of other devices, rather than their own. I can't quite figure out why, though the two are slightly different enough that they may have different reasons. For coretmp(4) I don't see how the parent device can be removed first, since we are a child device. So from my understanding it makes no sense to have an explicit sysctl_remove_oid() and attach in the parent's sysctl_ctx. For amdtemp, the "temperature" sysctl is added to the nexus.acpi.cpu device, which I suppose it's possible could be removed while the amdtemp sysctl was still present, causing errors. This case could be dealt with by orphaning sysctl nodes at sysctl_ctx_free if there were any not removed, presuming that whoever created them will clean them up (or leak the memory). Thoughts and explanations of the use of the parent's sysctl context? Thanks, matthew