From owner-freebsd-arch@FreeBSD.ORG Mon Feb 23 00:42:31 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0143616A4CE for ; Mon, 23 Feb 2004 00:42:31 -0800 (PST) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id B474243D1D for ; Mon, 23 Feb 2004 00:42:14 -0800 (PST) (envelope-from mtm@identd.net) Received: from [213.55.66.102] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 37360355 for freebsd-arch@freebsd.org; Mon, 23 Feb 2004 11:36:22 +0300 Received: from mobile.acs-et.com (localhost [127.0.0.1]) ESMTP id i1N8fpMe013412 for ; Mon, 23 Feb 2004 11:41:53 +0300 (EAT) (envelope-from mtm@mobile.acs-et.com) Received: (from mtm@localhost) by mobile.acs-et.com (8.12.10/8.12.10/Submit) id i1N8foV0013411 for freebsd-arch@freebsd.org; Mon, 23 Feb 2004 11:41:50 +0300 (EAT) (envelope-from mtm) Date: Mon, 23 Feb 2004 11:41:46 +0300 From: Mike Makonnen To: freebsd-arch@freebsd.org Message-ID: <20040223084146.GA4202@mobile.acs-et.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) Subject: rc.d and ports X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 08:42:31 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, A lot of people have been calling to have ports startup scripts integrated into rc.d. I have finally gotten arround to doing it. Attached are the rc.d patches to make it work, but I will need some cooperation from the ports folks. Essentialy the rc.d patches will recognize a ports script and source the appropriate configuration files. From the user's point of view there will be two major differences: 1. No more fooport.sh-sample files that must be renamed to enable the port 2. Ports can be configured from /etc/rc.conf (or /usr/local/etc/rc.conf). To make this work here's what's needed from the ports makefiles. This is just a general sketch of what needs to be done. The ports folks can do this however they deem appropriate. The makefile for the port should define a variable: RCVAR_NAME="fooport_enable" Then, logic similar to this should be inserted in the appropriate bsd.port* makefile: if ! grep 1>/dev/null "\$${RCVAR_NAME}=" ${PREFIX}/etc/defaults/rc.conf ; then echo "${RCVAR_NAME}=NO" >> ${PREFIX}/etc/defaults/rc.conf fi The only difference between a ports and a base system startup script will be that the ports script will have to call an additional routine: init_ports_config(). For example: init_ports_config load_rc_config $name run_rc_command "$1" I know from cursory glances at -current mail that people are divided on whether to have /usr/local/etc/{rc.conf,rc.conf.d} or to support only /etc/rc.conf. Both will be supported. It's the user's choice whether he wants every thing in /etc/rc.conf or /usr/local/etc/rc.conf. However, a /usr/local/etc/defaults/rc.conf is needed because that is where the default values for ports config knobs will be kept and because they should be kept separately from base system knobs. Comments/Corrections solicited. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diff Index: etc/rc.subr =================================================================== RCS file: /home/ncvs/src/etc/rc.subr,v retrieving revision 1.19 diff -u -r1.19 rc.subr --- etc/rc.subr 22 Jan 2004 08:46:03 -0000 1.19 +++ etc/rc.subr 22 Feb 2004 08:14:05 -0000 @@ -844,17 +844,29 @@ if [ -r /etc/defaults/rc.conf ]; then debug "Sourcing /etc/defaults/rc.conf" . /etc/defaults/rc.conf - source_rc_confs + source_rc_confs "$rc_conf_files" elif [ -r /etc/rc.conf ]; then debug "Sourcing /etc/rc.conf (/etc/defaults/rc.conf doesn't exist)." . /etc/rc.conf fi _rc_conf_loaded=YES fi + if checkyesno freebsd_ports ; then + if [ -z "$_rc_ports_conf_loaded ]; then + source_rc_confs "$rc_ports_conf_files" + fi + _rc_ports_conf_loaded=YES + fi if [ -f /etc/rc.conf.d/"$_command" ]; then debug "Sourcing /etc/rc.conf.d/${_command}" . /etc/rc.conf.d/"$_command" fi + if checkyesno freebsd_ports ; then + if [ -f "${rc_ports_conf_dir}/${_command}" ]; then + debug "Sourcing ${rc_ports_conf_dir}/${_command}" + . "${rc_ports_conf_dir}/${_command}" + fi + fi # XXX - Deprecated variable name support # @@ -872,6 +884,40 @@ ;; esac +} + +# +# source_rc_confs list +# The mechanism used by /etc/rc.* scripts to source rc_conf_files +# overrides safely. If the files in list exist and are readable +# they will be sourced by this routine. +# +source_rc_confs () +{ + local i sourced_files file_list + file_list="$1" + + for i in ${file_list}; do + case ${sourced_files} in + *:$i:*) + ;; + *) + sourced_files="${sourced_files}:$i:" + if [ -r $i ]; then + . $i + fi + ;; + esac + done +} + +# +# init_ports_config +# Initialization routine for FreeBSD ports scripts. +# +init_ports_config() +{ + freebsd_ports="YES" } # Index: etc/defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.198 diff -u -r1.198 rc.conf --- etc/defaults/rc.conf 3 Feb 2004 11:26:08 -0000 1.198 +++ etc/defaults/rc.conf 22 Feb 2004 08:19:42 -0000 @@ -41,6 +41,8 @@ local_startup="/usr/local/etc/rc.d /usr/X11R6/etc/rc.d" # startup script dirs. script_name_sep=" " # Change if your startup scripts' names contain spaces rc_conf_files="/etc/rc.conf /etc/rc.conf.local" +rc_ports_conf_files="/usr/local/etc/defaults/rc.conf /usr/local/etc/rc.conf" +rc_ports_conf_dir="/usr/local/etc/rc.conf.d" # Experimental - test before enabling gbde_autoattach_all="NO" # YES automatically mounts gbde devices from fstab @@ -471,27 +473,3 @@ #jail_example_fdescfs_enable="NO" # mount fdescfs in the jail #jail_example_procfs_enable="NO" # mount procfs in jail #jail_example_devfs_ruleset="ruleset_name" # devfs ruleset to apply to jail - -############################################################## -### Define source_rc_confs, the mechanism used by /etc/rc.* ## -### scripts to source rc_conf_files overrides safely. ## -############################################################## - -if [ -z "${source_rc_confs_defined}" ]; then - source_rc_confs_defined=yes - source_rc_confs () { - local i sourced_files - for i in ${rc_conf_files}; do - case ${sourced_files} in - *:$i:*) - ;; - *) - sourced_files="${sourced_files}:$i:" - if [ -r $i ]; then - . $i - fi - ;; - esac - done - } -fi Index: etc/mtree/BSD.local.dist =================================================================== RCS file: /home/ncvs/src/etc/mtree/BSD.local.dist,v retrieving revision 1.107 diff -u -r1.107 BSD.local.dist --- etc/mtree/BSD.local.dist 29 Jan 2004 16:17:25 -0000 1.107 +++ etc/mtree/BSD.local.dist 22 Feb 2004 08:15:07 -0000 @@ -8,6 +8,8 @@ bin .. etc + defaults + .. pam.d .. rc.d --J/dobhs11T7y2rNN-- From owner-freebsd-arch@FreeBSD.ORG Mon Feb 23 02:46:27 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 153DC16A4CE for ; Mon, 23 Feb 2004 02:46:27 -0800 (PST) Received: from postman.arcor.de (postman4.arcor-online.net [151.189.0.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A09A43D2D for ; Mon, 23 Feb 2004 02:46:26 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i1NAkNUa002140 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 Feb 2004 11:46:24 +0100 (MET) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1AvDbR-000EU5-Q7; Mon, 23 Feb 2004 11:46:21 +0100 Message-ID: <4039D9FF.40208@fillmore-labs.com> Date: Mon, 23 Feb 2004 11:46:23 +0100 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: Mike Makonnen References: <20040223084146.GA4202@mobile.acs-et.com> In-Reply-To: <20040223084146.GA4202@mobile.acs-et.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-arch@freebsd.org Subject: Re: rc.d and ports X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 10:46:27 -0000 Mike Makonnen wrote: > Hi, > > A lot of people have been calling to have ports startup scripts > integrated into rc.d. I have finally gotten arround to doing it. > Attached are the rc.d patches to make it work, but > I will need some cooperation from the ports folks. See PR 56736, there since Sep 2003: If you don't like it, please provide feedback what you think can be improved. > Essentialy the rc.d patches will recognize a ports script and source > the appropriate configuration files. From the user's point of view > there will be two major differences: > 1. No more fooport.sh-sample files that must be renamed to enable the port > 2. Ports can be configured from /etc/rc.conf (or /usr/local/etc/rc.conf). Except the /usr/local/etc/rc.conf this is what a lot of ports already do. > To make this work here's what's needed from the ports makefiles. > This is just a general sketch of what needs to be done. The > ports folks can do this however they deem appropriate. > > The makefile for the port should define a variable: > > RCVAR_NAME="fooport_enable" > > Then, logic similar to this should be inserted in the appropriate > bsd.port* makefile: > > if ! grep 1>/dev/null "\$${RCVAR_NAME}=" ${PREFIX}/etc/defaults/rc.conf ; then > echo "${RCVAR_NAME}=NO" >> ${PREFIX}/etc/defaults/rc.conf > fi I guess we don't need this (and shouldn't do it, since ${PREFIX}/etc/defaults/rc.conf might be read-only). Defaulting xxx_enable to "NO" seems to be sufficient, with [ -z "$xxx_enable" ] && xxx_enable="NO" or xxx_enable=${xxx_enable:-"NO"} before calling load_rc_config $name > [...] > > I know from cursory glances at -current mail that people are divided > on whether to have /usr/local/etc/{rc.conf,rc.conf.d} or to support > only /etc/rc.conf. Both will be supported. It's the user's choice > whether he wants every thing in /etc/rc.conf or /usr/local/etc/rc.conf. > However, a /usr/local/etc/defaults/rc.conf is needed because that is where > the default values for ports config knobs will be kept and because they > should be kept separately from base system knobs. Adding /usr/local/etc/rc.conf maybe a good idea, but I don't see the need for a /usr/local/etc/defaults/rc.conf. > Comments/Corrections solicited. See above. If I get feedback I well incorporate /usr/local/etc/defaults/rc.conf support in PR 56736. Regards Oliver From owner-freebsd-arch@FreeBSD.ORG Sun Feb 22 18:58:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 151FA16A4CE; Sun, 22 Feb 2004 18:58:48 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBAD043D1D; Sun, 22 Feb 2004 18:58:47 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i1N2wjnI014632; Sun, 22 Feb 2004 21:58:46 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Sun, 22 Feb 2004 21:58:45 -0500 To: current@FreeBSD.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) X-Mailman-Approved-At: Mon, 23 Feb 2004 04:59:42 -0800 cc: Bruce Evans Subject: HEADSUP: Commits Planned for 64-bit time_t on sparc64 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 02:58:48 -0000 [this is being BCC'ed to -arch and -hackers just to make sure that everyone is aware of this before changes are committed, but I expect all of the discussion to happen on -current] Sparc64 users (including me) have said that we'd like the sparc64 port to be running with a 64-bit time_t before we make a "stable" branch for the 5.x-series. I have been working on a procedure that can be used to safely perform this very incompatible change. I think I finally have that pretty much ready-to-go. I will therefore make the bold claim that I plan to take the files you can find at: http://people.freebsd.org/~gad/time-64/UPDATING.64BTT http://people.freebsd.org/~gad/time-64/installworld_oldk http://people.freebsd.org/~gad/time-64/installworld_newk and I plan to commit them to /usr/src, on Wed March 3rd. This does not actually change anything, but it tells adventurous sparc64 users that we're officially on the way to making this change, so they can try upgrades to 64-bTT (64-bit time_t). These files are only going to be in the base system long enough to help sparc64 users through the transition. I am very interested in any "show-stopper" problems in what I have written. My hope is that these files will disappear shortly after 5.3-release, though, so I don't want to spend much time polishing the scripts up when it comes to style issues. I'm still interested in hearing about them, but I may not be in a rush to do anything about style issues. Assuming that no one runs into a show-stopper problem, I plan to commit the change to /usr/src/sys/sparc64/include/_types.h that switches to 64-bTT for sparc. /usr/src/UPDATING will also need to have an entry added, but that entry will just point to the /usr/src/UPDATING.64bTT file. I plan to commit this (or have Warner commit the change to UPDATING?) on Wednesday March 10th. All of these changes will cause zero changes for people who are running on other hardware platforms. Only sparc64 users have to lay awake in terror of what this change might do to them. I should note that it *has* been working fine for me... :-) Also, about a dozen other sparc64 users have used these files to make a successful transition, with very few problems reported. As for me, I expect that my real-work job is going to get much busier by March 15th. If this 64-bTT change is not committed at that point, then some other developer will have to lead the charge for making the change. And, personally, I think we are already awfully close to the time for 5.3-release, and we can not afford to get much closer to it before making this change. So if we can not make this change by March 15th (at the latest), then I think we will have to put it off until 6.0. In fact, if I had a fix for the dhclient issue I would prefer to move both of the planned commits up by a week. I know this could be improved upon if I had more time to work on it, but this is basically the best I could do with the time I had. If my main job had something to do with FreeBSD, then I would have some way to justify spending more time working on issues like this... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Mon Feb 23 23:24:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB8BD16A4CE for ; Mon, 23 Feb 2004 23:24:39 -0800 (PST) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA42143D1F for ; Mon, 23 Feb 2004 23:24:35 -0800 (PST) (envelope-from mtm@identd.net) Received: from [213.55.67.126] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 37426633; Tue, 24 Feb 2004 10:18:42 +0300 Received: from mobile.acs-et.com (localhost [127.0.0.1]) ESMTP id i1O7OCQk001331; Tue, 24 Feb 2004 10:24:16 +0300 (EAT) (envelope-from mtm@mobile.acs-et.com) Received: (from mtm@localhost) by mobile.acs-et.com (8.12.10/8.12.10/Submit) id i1O7OBfA001330; Tue, 24 Feb 2004 10:24:11 +0300 (EAT) (envelope-from mtm) Date: Tue, 24 Feb 2004 10:24:01 +0300 From: Mike Makonnen To: Oliver Eikemeier Message-ID: <20040224072401.GB1125@mobile.acs-et.com> References: <20040223084146.GA4202@mobile.acs-et.com> <4039D9FF.40208@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4039D9FF.40208@fillmore-labs.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: freebsd-arch@FreeBSD.org Subject: Re: rc.d and ports X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 07:24:40 -0000 On Mon, Feb 23, 2004 at 11:46:23AM +0100, Oliver Eikemeier wrote: > Mike Makonnen wrote: > > >Hi, > > > >A lot of people have been calling to have ports startup scripts > >integrated into rc.d. I have finally gotten arround to doing it. > >Attached are the rc.d patches to make it work, but > >I will need some cooperation from the ports folks. > See PR 56736, there since Sep 2003: > > > If you don't like it, please provide feedback what you think can be > improved. It looks like you put some effort into it and I appreciate it, but I'm sorry to say I don't like it at all. It really isn't any better than the current situation. Basically your patches special case the ports scripts and hack around rc.d mechanisms to make it work with ports. This is wrong. If anything the ports should be modified to fit in the already present rc.d mechanism. > > > >The makefile for the port should define a variable: > > > >RCVAR_NAME="fooport_enable" > > > >Then, logic similar to this should be inserted in the appropriate > >bsd.port* makefile: > > > >if ! grep 1>/dev/null "\$${RCVAR_NAME}=" ${PREFIX}/etc/defaults/rc.conf ; > >then > > echo "${RCVAR_NAME}=NO" >> ${PREFIX}/etc/defaults/rc.conf > >fi > I guess we don't need this (and shouldn't do it, since > ${PREFIX}/etc/defaults/rc.conf > might be read-only). Defaulting xxx_enable to "NO" seems to be sufficient, > with > > [ -z "$xxx_enable" ] && xxx_enable="NO" > or > xxx_enable=${xxx_enable:-"NO"} > before calling load_rc_config $name Again, why special-case ports scripts ? If the only thing people want is an xxx_enable, then the current scheme is fine: Install the port script with xxx.sh-sample and when you want to enable it just rename the file. But if the ports want to be able to use the whole range of rc.d functionality, then ${PREFIX}/etc/defaults/rc.conf is needed for all the other knobs that need to be defined. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 01:59:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E13216A4CE for ; Tue, 24 Feb 2004 01:59:13 -0800 (PST) Received: from postman.arcor.de (postman2.arcor-online.net [151.189.0.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA94343D1F for ; Tue, 24 Feb 2004 01:59:12 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i1O9xAf5017624 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Feb 2004 10:59:11 +0100 (MET) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1AvZLI-0002xg-HZ; Tue, 24 Feb 2004 10:59:08 +0100 Message-ID: <403B206B.7000101@fillmore-labs.com> Date: Tue, 24 Feb 2004 10:59:07 +0100 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: Mike Makonnen References: <20040223084146.GA4202@mobile.acs-et.com> <4039D9FF.40208@fillmore-labs.com> <20040224072401.GB1125@mobile.acs-et.com> In-Reply-To: <20040224072401.GB1125@mobile.acs-et.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-arch@FreeBSD.org Subject: Re: rc.d and ports X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 09:59:13 -0000 Mike Makonnen wrote: > On Mon, Feb 23, 2004 at 11:46:23AM +0100, Oliver Eikemeier wrote: > >>Mike Makonnen wrote: >> >>>Hi, >>> >>>A lot of people have been calling to have ports startup scripts >>>integrated into rc.d. I have finally gotten arround to doing it. >>>Attached are the rc.d patches to make it work, but >>>I will need some cooperation from the ports folks. >> >>See PR 56736, there since Sep 2003: >> >> >>If you don't like it, please provide feedback what you think can be >>improved. > > It looks like you put some effort into it and I appreciate it, but > I'm sorry to say I don't like it at all. It really isn't any better than > the current situation. Basically your patches special case the ports > scripts and hack around rc.d mechanisms to make it > work with ports. This is wrong. If anything the ports should > be modified to fit in the already present rc.d mechanism. I guess I don't fully understand what modifications you suggest for the ports. What is needed to fit into rc.d? >>>The makefile for the port should define a variable: >>> >>>RCVAR_NAME="fooport_enable" >>> >>>Then, logic similar to this should be inserted in the appropriate >>>bsd.port* makefile: >>> >>>if ! grep 1>/dev/null "\$${RCVAR_NAME}=" ${PREFIX}/etc/defaults/rc.conf ; >>>then >>> echo "${RCVAR_NAME}=NO" >> ${PREFIX}/etc/defaults/rc.conf >>>fi >> >>I guess we don't need this (and shouldn't do it, since >>${PREFIX}/etc/defaults/rc.conf >>might be read-only). Defaulting xxx_enable to "NO" seems to be sufficient, >>with >> >> [ -z "$xxx_enable" ] && xxx_enable="NO" >>or >> xxx_enable=${xxx_enable:-"NO"} >>before calling load_rc_config $name > > Again, why special-case ports scripts ? Because the defaults belong to the port, not to the base system. I want them to go away with the port. Nobody (and especially not ports) should edit whatever/defaults/rc.conf, and how would I otherwise cope with the situation that default flags may change? > If the only thing people want is an xxx_enable, then the current scheme > is fine: Install the port script with xxx.sh-sample and when you want > to enable it just rename the file. But if the ports want to be able to > use the whole range of rc.d functionality, then ${PREFIX}/etc/defaults/rc.conf > is needed for all the other knobs that need to be defined. I guess I incorporate ${PREFIX}/etc/defaults/rc.conf and another change in PR 56736, the main point there was that I wanted them to participate in rcorder, which I believe is a good thing, especially when you consider the possibility to move sendmail or other parts of the base system to ports. So I understand that sourcing ${PREFIX}/etc/defaults/rc.conf is the main reservation that you have against this patch? Regards Oliver From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 02:39:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA43516A4CF for ; Tue, 24 Feb 2004 02:39:58 -0800 (PST) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0694643D1F for ; Tue, 24 Feb 2004 02:39:55 -0800 (PST) (envelope-from mtm@identd.net) Received: from [213.55.65.39] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 37438375; Tue, 24 Feb 2004 13:34:03 +0300 Received: from mobile.acs-et.com (localhost [127.0.0.1]) ESMTP id i1OAdaQk020530; Tue, 24 Feb 2004 13:39:39 +0300 (EAT) (envelope-from mtm@mobile.acs-et.com) Received: (from mtm@localhost) by mobile.acs-et.com (8.12.10/8.12.10/Submit) id i1OAdaPA020529; Tue, 24 Feb 2004 13:39:36 +0300 (EAT) (envelope-from mtm) Date: Tue, 24 Feb 2004 13:39:32 +0300 From: Mike Makonnen To: Oliver Eikemeier Message-ID: <20040224103932.GA20467@mobile.acs-et.com> References: <20040223084146.GA4202@mobile.acs-et.com> <4039D9FF.40208@fillmore-labs.com> <20040224072401.GB1125@mobile.acs-et.com> <403B206B.7000101@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403B206B.7000101@fillmore-labs.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: freebsd-arch@FreeBSD.org Subject: Re: rc.d and ports X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 10:39:58 -0000 On Tue, Feb 24, 2004 at 10:59:07AM +0100, Oliver Eikemeier wrote: > > I guess I don't fully understand what modifications you suggest for the > ports. What is needed to fit into rc.d? The modification I ask for in my initial email :-) If ports want to be a part of rc.d then they must use appropriate rc.d mechanisms. My rc.d modification to support /usr/local/etc/{rc.conf,defaults/rc.conf,rc.conf.d} are necessary so that ports configuration knobs don't pollute the enviroment for base system scripts. But other than that, it should be up to the ports to fit into the rc.d scheme. The problem with your patch is that it is a bunch of hacks to rc.d to semi-incorporate ports into the rc.d mechanism. My point is: don't hack rc.d to semi-incorporate ports. Instead, we should fully incorporate ports into rc.d. > >> > >>I guess we don't need this (and shouldn't do it, since > >>${PREFIX}/etc/defaults/rc.conf > >>might be read-only). Defaulting xxx_enable to "NO" seems to be > >>sufficient, with > >> > >>[ -z "$xxx_enable" ] && xxx_enable="NO" > >>or > >>xxx_enable=${xxx_enable:-"NO"} > >>before calling load_rc_config $name > > > >Again, why special-case ports scripts ? > > Because the defaults belong to the port, not to the base system. I want them > to go away with the port. Nobody (and especially not ports) should edit > whatever/defaults/rc.conf, and how would I otherwise cope with the situation > that default flags may change? Then the ports can use /usr/local/etc/rc.conf.d. When the port is deleted it can just delete the appropriate conf file in that directory without the need to edit any files. > > I guess I incorporate ${PREFIX}/etc/defaults/rc.conf and another change in > PR 56736, the main point there was that I wanted them to participate in > rcorder, > which I believe is a good thing, especially when you consider the > possibility > to move sendmail or other parts of the base system to ports. > > So I understand that sourcing ${PREFIX}/etc/defaults/rc.conf is the main > reservation that you have against this patch? No. As I have tried to state already I don't like it because it is an unnecesary hack. As for participating in rcorder(8), first the ports have to support all the rc.d mechanisms. Your patch simply hacks rc.d to allow those ports that choose to use some of the rc.subr functionality to participate in rcorder(8)ing. What should happen is that our ports infrastructure should fully support rc.d and all ports scripts should be modified to work with rc.d. Otherwise, we will have lots of confused users wondering why some ports are ordered with the base system scripts and others are not. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 04:14:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B25916A4CE for ; Tue, 24 Feb 2004 04:14:58 -0800 (PST) Received: from postman.arcor.de (postman2.arcor-online.net [151.189.0.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5988143D2D for ; Tue, 24 Feb 2004 04:14:57 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i1OCEtf5000792 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Feb 2004 13:14:56 +0100 (MET) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1AvbSf-0003Ge-6O; Tue, 24 Feb 2004 13:14:53 +0100 Message-ID: <403B403C.7040701@fillmore-labs.com> Date: Tue, 24 Feb 2004 13:14:52 +0100 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: Mike Makonnen References: <20040223084146.GA4202@mobile.acs-et.com> <4039D9FF.40208@fillmore-labs.com> <20040224072401.GB1125@mobile.acs-et.com> <403B206B.7000101@fillmore-labs.com> <20040224103932.GA20467@mobile.acs-et.com> In-Reply-To: <20040224103932.GA20467@mobile.acs-et.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-arch@FreeBSD.org Subject: Re: rc.d and ports X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 12:14:58 -0000 Mike Makonnen wrote: > On Tue, Feb 24, 2004 at 10:59:07AM +0100, Oliver Eikemeier wrote: > >>I guess I don't fully understand what modifications you suggest for the >>ports. What is needed to fit into rc.d? > > The modification I ask for in my initial email :-) > If ports want to be a part of rc.d then they must use appropriate rc.d > mechanisms. My rc.d modification to support > /usr/local/etc/{rc.conf,defaults/rc.conf,rc.conf.d} are necessary > so that ports configuration knobs don't pollute the enviroment for > base system scripts. But other than that, it should be up to the > ports to fit into the rc.d scheme. I guess we agree here. I'll post a follow-up with uses ${PREFIX}/etc/{rc.conf,defaults/rc.conf,rc.conf.d} too. The problem here is that you'll have to support different prefixes, like /usr/X11R6. > The problem with your patch is that it is a bunch of hacks to > rc.d to semi-incorporate ports into the rc.d mechanism. My point > is: don't hack rc.d to semi-incorporate ports. Instead, we should > fully incorporate ports into rc.d. ... which this patch tries do. >>>>I guess we don't need this (and shouldn't do it, since >>>>${PREFIX}/etc/defaults/rc.conf >>>>might be read-only). Defaulting xxx_enable to "NO" seems to be >>>>sufficient, with >>>> >>>>[ -z "$xxx_enable" ] && xxx_enable="NO" >>>>or >>>>xxx_enable=${xxx_enable:-"NO"} >>>>before calling load_rc_config $name >>> >>>Again, why special-case ports scripts ? >> >>Because the defaults belong to the port, not to the base system. I want them >>to go away with the port. Nobody (and especially not ports) should edit >>whatever/defaults/rc.conf, and how would I otherwise cope with the situation >>that default flags may change? > > Then the ports can use /usr/local/etc/rc.conf.d. When the port is deleted > it can just delete the appropriate conf file in that directory without the > need to edit any files. ${PREFIX}/etc/rc.conf.d files may be edited by the user, so you can't simply delete them. >>I guess I incorporate ${PREFIX}/etc/defaults/rc.conf and another change in >>PR 56736, the main point there was that I wanted them to participate in >>rcorder, >>which I believe is a good thing, especially when you consider the >>possibility >>to move sendmail or other parts of the base system to ports. >> >>So I understand that sourcing ${PREFIX}/etc/defaults/rc.conf is the main >>reservation that you have against this patch? > > No. As I have tried to state already I don't like it because it is an > unnecesary hack. As for participating in rcorder(8), first the ports > have to support all the rc.d mechanisms. Your patch simply hacks rc.d > to allow those ports that choose to use some of the rc.subr functionality > to participate in rcorder(8)ing. What should happen is that our ports > infrastructure should fully support rc.d and all ports scripts should > be modified to work with rc.d. Otherwise, we will have lots of confused > users wondering why some ports are ordered with the base system scripts and > others are not. I get your point, but currently there is no way to convert *all* ports, we don't have the manpower to convert and test them all. So we need a transition path, where we may deprecate older scripts at some point. I guess we agree that ${PREFIX}/etc/rc.conf should be sourced by ports rc.d scripts, but this is not enough to integrate ports in rc.d without breaking the existing ports base. The patch, supplemented by ${PREFIX}/etc/{rc.conf,defaults/rc.conf,rc.conf.d} *is* a step forward in that direction. -Oliver From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 07:25:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E132716A4CE for ; Tue, 24 Feb 2004 07:25:25 -0800 (PST) Received: from srv01.sparkit.no (srv01.sparkit.no [193.69.116.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B34A43D1F for ; Tue, 24 Feb 2004 07:25:25 -0800 (PST) (envelope-from eivind@FreeBSD.org) Received: from ws ([193.69.114.88]) by srv01.sparkit.no (8.12.10/8.12.10) with ESMTP id i1OFPEJO097122; Tue, 24 Feb 2004 16:25:14 +0100 (CET) (envelope-from eivind@FreeBSD.org) Received: from ws (localhost [127.0.0.1]) by ws (8.12.9/8.12.10) with ESMTP id i1OFOImd004098; Tue, 24 Feb 2004 15:24:18 GMT (envelope-from eivind@ws) Received: (from eivind@localhost) by ws (8.12.9/8.12.10/Submit) id i1OFOHdq004097; Tue, 24 Feb 2004 15:24:17 GMT (envelope-from eivind) Date: Tue, 24 Feb 2004 15:23:16 +0000 From: Eivind Eklund To: Oliver Eikemeier Message-ID: <20040224152316.GB3364@FreeBSD.org> References: <20040223084146.GA4202@mobile.acs-et.com> <4039D9FF.40208@fillmore-labs.com> <20040224072401.GB1125@mobile.acs-et.com> <403B206B.7000101@fillmore-labs.com> <20040224103932.GA20467@mobile.acs-et.com> <403B403C.7040701@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403B403C.7040701@fillmore-labs.com> User-Agent: Mutt/1.5.4i cc: freebsd-arch@FreeBSD.org Subject: Re: rc.d and ports X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 15:25:26 -0000 On Tue, Feb 24, 2004 at 01:14:52PM +0100, Oliver Eikemeier wrote: > Mike Makonnen wrote: > >>them > >>to go away with the port. Nobody (and especially not ports) should edit > >>whatever/defaults/rc.conf, and how would I otherwise cope with the > >>situation > >>that default flags may change? > > > >Then the ports can use /usr/local/etc/rc.conf.d. When the port is deleted > >it can just delete the appropriate conf file in that directory without the > >need to edit any files. > > ${PREFIX}/etc/rc.conf.d files may be edited by the user, so you can't simply > delete them. Yes, we can. These are defaults *as supplied from FreeBSD*, and editing them is an error. I think that we might want a more telling name (${PREFIX}/etc/defaults/rc.conf.d/ or ${PREFIX}/etc/rc.conf.defaults/ - I prefer the former). If we want to be really friendly, we might also want to allow per-port override files, make sure the defaults are suitably labelled inside each file, and set them schg so the user have to work really hard to shoot himself in the foot. But if we use default files, we definately can and should delete them when we wipe the port. The other alternative is to use a full merge system for port config files. I've put up a draft of a design for extending etcmerge to support this at http://people.freebsd.org/~eivind/etcmerge.ports However, having parts of the system come and go at will is a really hard job for any config file manager. Eivind. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 10:10:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4892916A4CE for ; Tue, 24 Feb 2004 10:10:50 -0800 (PST) Received: from postman.arcor.de (postman2.arcor-online.net [151.189.0.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E00943D1F for ; Tue, 24 Feb 2004 10:10:49 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-51-138.reverse.qsc.de [212.202.51.138]) (authenticated bits=0)i1OIAdf5003948 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Feb 2004 19:10:44 +0100 (MET) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1Avh0t-0004t1-Lw; Tue, 24 Feb 2004 19:10:35 +0100 Message-ID: <403B9396.8020404@fillmore-labs.com> Date: Tue, 24 Feb 2004 19:10:30 +0100 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: Mike Makonnen , freebsd-arch@FreeBSD.org References: <20040223084146.GA4202@mobile.acs-et.com> <4039D9FF.40208@fillmore-labs.com> <20040224072401.GB1125@mobile.acs-et.com> <403B206B.7000101@fillmore-labs.com> <20040224103932.GA20467@mobile.acs-et.com> <403B403C.7040701@fillmore-labs.com> In-Reply-To: <403B403C.7040701@fillmore-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 Subject: Re: rc.d and ports X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 18:10:50 -0000 Oliver Eikemeier wrote: > [...] > > I guess we agree here. I'll post a follow-up with uses > ${PREFIX}/etc/{rc.conf,defaults/rc.conf,rc.conf.d} too. The problem here > is that you'll have to support different prefixes, like /usr/X11R6. Ok, before I send my next patch we should agree on the following: If we assume the following rules: i) defaults are overwritten by user editable files ii) configuration in base overwrites configuration in prefix iii) individual command configuration overwrites common configuration where i) breaks ii) breaks iii), we get the following load order for a port with name $_command and prefix $_prefix: 1. "$_prefix"/etc/defaults/rc.conf (read only, but unsure who may provide it) 2. /etc/defaults/rc.conf (read only, base system) 3. "$_prefix"/etc/defaults/rc.conf.d/"$_command" (read only, may be installed by the port) 4. "$_prefix"/etc/rc.conf (user editable) 5. "$_prefix"/etc/rc.conf.d/"$_command" (user editable) 6. /etc/rc.conf ( + /etc/rc.conf.local, both user editable) 7. /etc/rc.conf.d/"$_command" (user editable) where we have to source /etc/defaults/rc.conf and /etc/rc.conf *every* time, since we don't know whether other config files overwrite parts of them. I suggest the syntax load_rc_config "$_command" "$_prefix" since the port knows where it lives, omitting the second argument for base scripts. Does everybody agree, or is a different load order more appropriate? -Oliver From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 17:11:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0BF3016A4CE for ; Tue, 24 Feb 2004 17:11:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: owner-freebsd-www@freebsd.org To: freebsd-arch@freebsd.org Message-ID: Date: Tue, 24 Feb 2004 17:10:59 -0800 Precedence: bulk X-BeenThere: freebsd-www@freebsd.org X-Mailman-Version: 2.1.1 X-List-Administrivia: yes Sender: owner-freebsd-www@freebsd.org Errors-To: owner-freebsd-www@freebsd.org Subject: Your message to freebsd-www awaits moderator approval X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 01:11:01 -0000 Your mail to 'freebsd-www' with the subject information Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.freebsd.org/mailman/confirm/freebsd-www/3470ceceb786954c607eb6345c6067dcedd557cc PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 22:23:21 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CAD9D16A4CE for ; Tue, 24 Feb 2004 22:23:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: owner-freebsd-newbies@freebsd.org To: freebsd-arch@freebsd.org Message-ID: Date: Tue, 24 Feb 2004 22:23:21 -0800 Precedence: bulk X-BeenThere: freebsd-newbies@freebsd.org X-Mailman-Version: 2.1.1 X-List-Administrivia: yes Sender: owner-freebsd-newbies@freebsd.org Errors-To: owner-freebsd-newbies@freebsd.org Subject: Your message to freebsd-newbies awaits moderator approval X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 06:23:21 -0000 Your mail to 'freebsd-newbies' with the subject information Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.freebsd.org/mailman/confirm/freebsd-newbies/297e73784dfc46b5240155e640d1897c3da8d679 PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 22:26:30 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 8279E16A4CE for ; Tue, 24 Feb 2004 22:26:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: owner-freebsd-sparc64@freebsd.org To: freebsd-arch@freebsd.org Message-ID: Date: Tue, 24 Feb 2004 22:26:29 -0800 Precedence: bulk X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 X-List-Administrivia: yes Sender: owner-freebsd-sparc64@freebsd.org Errors-To: owner-freebsd-sparc64@freebsd.org Subject: Your message to freebsd-sparc64 awaits moderator approval X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 06:26:30 -0000 Your mail to 'freebsd-sparc64' with the subject stolen Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.freebsd.org/mailman/confirm/freebsd-sparc64/7718948c8820333f5cceca4c945cd41b29415aab PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 24 22:27:36 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D7D7B16A4CE for ; Tue, 24 Feb 2004 22:27:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: owner-freebsd-test@freebsd.org To: freebsd-arch@freebsd.org Message-ID: Date: Tue, 24 Feb 2004 22:27:35 -0800 Precedence: bulk X-BeenThere: freebsd-test@freebsd.org X-Mailman-Version: 2.1.1 X-List-Administrivia: yes Sender: owner-freebsd-test@freebsd.org Errors-To: owner-freebsd-test@freebsd.org Subject: Your message to freebsd-test awaits moderator approval X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 06:27:37 -0000 Your mail to 'freebsd-test' with the subject something for you Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.freebsd.org/mailman/confirm/freebsd-test/4971e0456f503a7e0a9d10c7e216470145ae9ede PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. From owner-freebsd-arch@FreeBSD.ORG Wed Feb 25 00:04:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1C98516A4D0 for ; Wed, 25 Feb 2004 00:04:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: owner-freebsd-security@freebsd.org To: freebsd-arch@freebsd.org Message-ID: Date: Wed, 25 Feb 2004 00:04:42 -0800 Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 X-List-Administrivia: yes Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Subject: Your message to freebsd-security awaits moderator approval X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 08:04:44 -0000 Your mail to 'freebsd-security' with the subject something for you Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.freebsd.org/mailman/confirm/freebsd-security/a82f24f6e1224ee114ff270f0c8767031da25af6 PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. From owner-freebsd-arch@FreeBSD.ORG Wed Feb 25 08:35:02 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A4F6716A4CE for ; Wed, 25 Feb 2004 08:35:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: owner-freebsd-security@freebsd.org To: freebsd-arch@freebsd.org Message-ID: Date: Wed, 25 Feb 2004 08:35:00 -0800 Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 X-List-Administrivia: yes Sender: owner-freebsd-security@freebsd.org Errors-To: owner-freebsd-security@freebsd.org Subject: Your message to freebsd-security awaits moderator approval X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 16:35:02 -0000 Your mail to 'freebsd-security' with the subject stolen Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.freebsd.org/mailman/confirm/freebsd-security/5af51001efdfaf43e73146ccce66a9681eb0d0a6 PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. From owner-freebsd-arch@FreeBSD.ORG Wed Feb 25 11:42:16 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39C6916A50F for ; Wed, 25 Feb 2004 11:42:16 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9D4F43D1D for ; Wed, 25 Feb 2004 11:42:15 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.10) with ESMTP id i1PJftOJ068250; Wed, 25 Feb 2004 11:41:55 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i1PJfsW4068249; Wed, 25 Feb 2004 11:41:54 -0800 (PST) (envelope-from obrien) Date: Wed, 25 Feb 2004 11:41:54 -0800 From: "David O'Brien" To: Oliver Eikemeier Message-ID: <20040225194154.GN7567@dragon.nuxi.com> References: <20040223084146.GA4202@mobile.acs-et.com> <4039D9FF.40208@fillmore-labs.com> <20040224072401.GB1125@mobile.acs-et.com> <403B206B.7000101@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403B206B.7000101@fillmore-labs.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-arch@FreeBSD.org Subject: Re: rc.d and ports X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 19:42:16 -0000 On Tue, Feb 24, 2004 at 10:59:07AM +0100, Oliver Eikemeier wrote: > I guess I incorporate ${PREFIX}/etc/defaults/rc.conf and another change in > PR 56736, the main point there was that I wanted them to participate in ... > So I understand that sourcing ${PREFIX}/etc/defaults/rc.conf is the main > reservation that you have against this patch? So lets just use /etc/rc.conf.d/ with "_enable=yes" in it. That keeps ports from trying to edit a critical file (/etc/rc.conf) on install and deinstall. It also recognizes that daemon startup is an individual system thing, not common across all mounters of $PREFIX. From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 06:53:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0CF016A4CE for ; Thu, 26 Feb 2004 06:53:28 -0800 (PST) Received: from hotmail.com (law11-f13.law11.hotmail.com [64.4.17.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5A5C43D3F for ; Thu, 26 Feb 2004 06:53:28 -0800 (PST) (envelope-from tester192@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Feb 2004 06:53:28 -0800 Received: from 129.70.15.229 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 26 Feb 2004 14:53:28 GMT X-Originating-IP: [129.70.15.229] X-Originating-Email: [tester192@hotmail.com] X-Sender: tester192@hotmail.com From: "Math Comp" To: freebsd-arch@freebsd.org Date: Thu, 26 Feb 2004 14:53:28 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Feb 2004 14:53:28.0533 (UTC) FILETIME=[4B40F850:01C3FC78] Subject: Keyboard Hook X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 14:53:29 -0000 Hallo. I need to install a keyboard hook procedure. Please, tell me some key words and say whether it's possible at all. It is also assumed that I don't have any root privileges. Thanks a lot. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:06:40 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F27B416A4CE for ; Thu, 26 Feb 2004 10:06:39 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 517F643D2D for ; Thu, 26 Feb 2004 10:06:39 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 441485309; Thu, 26 Feb 2004 19:06:38 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 072205308 for ; Thu, 26 Feb 2004 19:06:24 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 9375033C71; Thu, 26 Feb 2004 19:06:24 +0100 (CET) To: arch@freebsd.org From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 19:06:24 +0100 Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Subject: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:06:40 -0000 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The first of the attached patches creates a sysctl context and node for every device in the system named for its nameunit. Each device's sysctl node is a child of the parent device's sysctl node, so the resulting sysctl tree resembles the "show devices by attachment" mode of Windows's device manager. Standard entries in each device's tree include %class, %desc and %driver (device class, device description and driver name). I also plan to add entries for device IDs, irq / drq lines etc., but this will require additional bus-specific code and is not yet implemented. Note that root0 is not created through the usual means and therefore does not get its own sysctl node; its children (nexus0 on i386) are placed directly in dev. I haven't yet decided whether this is a feature or a bug. The second patch modifies the NDISulator to use the per-device context and tree rather than create its own. There are several other drivers that do this; I chose the NDISulator because I can actually test it. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=dev.diff Index: sys/kern/subr_bus.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_bus.c,v retrieving revision 1.140 diff -u -r1.140 subr_bus.c --- sys/kern/subr_bus.c 24 Feb 2004 19:31:30 -0000 1.140 +++ sys/kern/subr_bus.c 26 Feb 2004 16:11:13 -0000 @@ -56,6 +56,7 @@ #include SYSCTL_NODE(_hw, OID_AUTO, bus, CTLFLAG_RW, NULL, NULL); +SYSCTL_NODE(, OID_AUTO, dev, CTLFLAG_RW, NULL, NULL); /* * Used to attach drivers to devclasses. @@ -123,6 +124,9 @@ u_char pad; void *ivars; void *softc; + + struct sysctl_ctx_list sysctl_ctx; + struct sysctl_oid *sysctl_tree; }; struct device_op_desc { @@ -252,6 +256,8 @@ static dev_t devctl_dev; +static struct sysctl_ctx_list device_sysctl_ctx; + static void devinit(void) { @@ -260,6 +266,7 @@ mtx_init(&devsoftc.mtx, "dev mtx", "devd", MTX_DEF); cv_init(&devsoftc.cv, "dev cv"); TAILQ_INIT(&devsoftc.devq); + sysctl_ctx_init(&device_sysctl_ctx); } static int @@ -381,6 +388,8 @@ struct dev_event_info *n1 = NULL; struct proc *p; + if (*data != '?') + printf("devctl: %s", data); n1 = malloc(sizeof(*n1), M_BUS, M_NOWAIT); if (n1 == NULL) return; @@ -1256,6 +1265,18 @@ return (dev->devflags); } +struct sysctl_ctx_list * +device_get_sysctl_ctx(device_t dev) +{ + return (&dev->sysctl_ctx); +} + +struct sysctl_oid * +device_get_sysctl_tree(device_t dev) +{ + return (dev->sysctl_tree); +} + int device_print_prettyname(device_t dev) { @@ -1509,7 +1530,7 @@ if (!error) { if (!device_is_quiet(dev)) device_print_child(bus, dev); - error = DEVICE_ATTACH(dev); + error = device_attach(dev); if (!error) { dev->state = DS_ATTACHED; devadded(dev); @@ -1539,6 +1560,71 @@ return (error); } +enum { + DEVICE_SYSCTL_CLASS, + DEVICE_SYSCTL_DESC, + DEVICE_SYSCTL_DRIVER, +}; + +static int +device_sysctl_handler(SYSCTL_HANDLER_ARGS) +{ + device_t dev = (device_t)arg1; + const char *value; + size_t len; + + switch (arg2) { + case DEVICE_SYSCTL_CLASS: + value = dev->devclass->name; + break; + case DEVICE_SYSCTL_DESC: + value = dev->desc; + break; + case DEVICE_SYSCTL_DRIVER: + value = dev->driver->name; + break; + default: + return (EINVAL); + } + if (value == NULL) + return (ENODEV); + len = strlen(value); + return (SYSCTL_OUT(req, value, strlen(value))); +} + +int +device_attach(device_t dev) +{ + struct sysctl_oid_list *parent_node; + int error; + + sysctl_ctx_init(&dev->sysctl_ctx); + if (dev->parent && dev->parent->sysctl_tree) + parent_node = SYSCTL_CHILDREN(dev->parent->sysctl_tree); + else + parent_node = SYSCTL_STATIC_CHILDREN(_dev); + dev->sysctl_tree = SYSCTL_ADD_NODE(&dev->sysctl_ctx, parent_node, + OID_AUTO, dev->nameunit, CTLFLAG_RD, 0, ""); + if ((error = DEVICE_ATTACH(dev)) != 0) { + sysctl_ctx_free(&dev->sysctl_ctx); + dev->sysctl_tree = NULL; + return (error); + } + SYSCTL_ADD_PROC(&dev->sysctl_ctx, SYSCTL_CHILDREN(dev->sysctl_tree), + OID_AUTO, "%class", CTLFLAG_RD, + dev, DEVICE_SYSCTL_CLASS, device_sysctl_handler, "A", + "device class name"); + SYSCTL_ADD_PROC(&dev->sysctl_ctx, SYSCTL_CHILDREN(dev->sysctl_tree), + OID_AUTO, "%desc", CTLFLAG_RD, + dev, DEVICE_SYSCTL_DESC, device_sysctl_handler, "A", + "device description"); + SYSCTL_ADD_PROC(&dev->sysctl_ctx, SYSCTL_CHILDREN(dev->sysctl_tree), + OID_AUTO, "%driver", CTLFLAG_RD, + dev, DEVICE_SYSCTL_DRIVER, device_sysctl_handler, "A", + "device driver name"); + return (0); +} + int device_detach(device_t dev) { @@ -1552,6 +1638,10 @@ if ((error = DEVICE_DETACH(dev)) != 0) return (error); + if (dev->sysctl_tree != NULL) { + sysctl_ctx_free(&dev->sysctl_ctx); + dev->sysctl_tree = NULL; + } devremoved(dev); device_printf(dev, "detached\n"); if (dev->parent) Index: sys/sys/bus.h =================================================================== RCS file: /home/ncvs/src/sys/sys/bus.h,v retrieving revision 1.57 diff -u -r1.57 bus.h --- sys/sys/bus.h 24 Oct 2003 22:41:54 -0000 1.57 +++ sys/sys/bus.h 26 Feb 2004 15:51:43 -0000 @@ -317,6 +317,7 @@ const char *name, int unit); void device_busy(device_t dev); int device_delete_child(device_t dev, device_t child); +int device_attach(device_t dev); int device_detach(device_t dev); void device_disable(device_t dev); void device_enable(device_t dev); @@ -335,6 +336,8 @@ void *device_get_softc(device_t dev); device_state_t device_get_state(device_t dev); int device_get_unit(device_t dev); +struct sysctl_ctx_list *device_get_sysctl_ctx(device_t dev); +struct sysctl_oid *device_get_sysctl_tree(device_t dev); int device_is_alive(device_t dev); /* did probe succeed? */ int device_is_attached(device_t dev); /* did attach succeed? */ int device_is_enabled(device_t dev); Index: sys/sys/sysctl.h =================================================================== RCS file: /home/ncvs/src/sys/sys/sysctl.h,v retrieving revision 1.124 diff -u -r1.124 sysctl.h --- sys/sys/sysctl.h 26 Feb 2004 00:27:03 -0000 1.124 +++ sys/sys/sysctl.h 26 Feb 2004 13:30:25 -0000 @@ -52,7 +52,7 @@ * respective subsystem header files. */ -#define CTL_MAXNAME 12 /* largest number of components supported */ +#define CTL_MAXNAME 24 /* largest number of components supported */ /* * Each subsystem defined by sysctl defines a list of variables --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=ndis.diff Index: sys/compat/ndis/kern_ndis.c =================================================================== RCS file: /home/ncvs/src/sys/compat/ndis/kern_ndis.c,v retrieving revision 1.39 diff -u -r1.39 kern_ndis.c --- sys/compat/ndis/kern_ndis.c 14 Feb 2004 20:57:32 -0000 1.39 +++ sys/compat/ndis/kern_ndis.c 26 Feb 2004 16:05:07 -0000 @@ -585,6 +585,8 @@ ndis_create_sysctls(arg) void *arg; { + struct sysctl_ctx_list *sysctl_ctx; + struct sysctl_oid *sysctl_tree; struct ndis_softc *sc; ndis_cfg *vals; char buf[256]; @@ -597,12 +599,8 @@ TAILQ_INIT(&sc->ndis_cfglist_head); - /* Create the sysctl tree. */ - - sc->ndis_tree = SYSCTL_ADD_NODE(&sc->ndis_ctx, - SYSCTL_STATIC_CHILDREN(_hw), OID_AUTO, - device_get_nameunit(sc->ndis_dev), CTLFLAG_RD, 0, - device_get_desc(sc->ndis_dev)); + sysctl_ctx = device_get_sysctl_ctx(sc->ndis_dev); + sysctl_tree = device_get_sysctl_tree(sc->ndis_dev); /* Add the driver-specific registry keys. */ @@ -614,8 +612,8 @@ vals++; continue; } - SYSCTL_ADD_STRING(&sc->ndis_ctx, - SYSCTL_CHILDREN(sc->ndis_tree), + SYSCTL_ADD_STRING(sysctl_ctx, + SYSCTL_CHILDREN(sysctl_tree), OID_AUTO, vals->nc_cfgkey, CTLFLAG_RW, vals->nc_val, sizeof(vals->nc_val), @@ -684,7 +682,8 @@ TAILQ_INSERT_TAIL(&sc->ndis_cfglist_head, cfg, link); - SYSCTL_ADD_STRING(&sc->ndis_ctx, SYSCTL_CHILDREN(sc->ndis_tree), + SYSCTL_ADD_STRING(device_get_sysctl_ctx(sc->ndis_dev), + SYSCTL_CHILDREN(device_get_sysctl_tree(sc->ndis_dev)), OID_AUTO, cfg->ndis_cfg.nc_cfgkey, flag, cfg->ndis_cfg.nc_val, sizeof(cfg->ndis_cfg.nc_val), cfg->ndis_cfg.nc_cfgdesc); Index: sys/compat/ndis/subr_ndis.c =================================================================== RCS file: /home/ncvs/src/sys/compat/ndis/subr_ndis.c,v retrieving revision 1.48 diff -u -r1.48 subr_ndis.c --- sys/compat/ndis/subr_ndis.c 16 Feb 2004 02:50:03 -0000 1.48 +++ sys/compat/ndis/subr_ndis.c 26 Feb 2004 15:49:19 -0000 @@ -582,7 +582,7 @@ * See if registry key is already in a list of known keys * included with the driver. */ - TAILQ_FOREACH(e, &sc->ndis_ctx, link) { + TAILQ_FOREACH(e, device_get_sysctl_ctx(sc->ndis_dev), link) { oidp = e->entry; if (strcmp(oidp->oid_name, keystr) == 0) { if (strcmp((char *)oidp->oid_arg1, "UNSET") == 0) { @@ -678,7 +678,7 @@ /* See if the key already exists. */ - TAILQ_FOREACH(e, &sc->ndis_ctx, link) { + TAILQ_FOREACH(e, device_get_sysctl_ctx(sc->ndis_dev), link) { oidp = e->entry; if (strcmp(oidp->oid_name, keystr) == 0) { /* Found it, set the value. */ Index: sys/dev/if_ndis/if_ndis.c =================================================================== RCS file: /home/ncvs/src/sys/dev/if_ndis/if_ndis.c,v retrieving revision 1.42 diff -u -r1.42 if_ndis.c --- sys/dev/if_ndis/if_ndis.c 11 Feb 2004 21:53:40 -0000 1.42 +++ sys/dev/if_ndis/if_ndis.c 26 Feb 2004 15:44:52 -0000 @@ -43,7 +43,6 @@ #include #include #include -#include #include #include @@ -586,8 +585,6 @@ else sc->ndis_devidx = devidx; - sysctl_ctx_init(&sc->ndis_ctx); - /* Create sysctl registry nodes */ ndis_create_sysctls(sc); @@ -948,8 +945,6 @@ ndis_unload_driver((void *)ifp); bus_dma_tag_destroy(sc->ndis_parent_tag); - - sysctl_ctx_free(&sc->ndis_ctx); return(0); } Index: sys/dev/if_ndis/if_ndisvar.h =================================================================== RCS file: /home/ncvs/src/sys/dev/if_ndis/if_ndisvar.h,v retrieving revision 1.10 diff -u -r1.10 if_ndisvar.h --- sys/dev/if_ndis/if_ndisvar.h 27 Jan 2004 09:08:12 -0000 1.10 +++ sys/dev/if_ndis/if_ndisvar.h 26 Feb 2004 15:44:46 -0000 @@ -104,8 +104,6 @@ int ndis_if_flags; int ndis_skip; - struct sysctl_ctx_list ndis_ctx; - struct sysctl_oid *ndis_tree; int ndis_devidx; interface_type ndis_iftype; --=-=-=-- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:10:53 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7785416A4CE for ; Thu, 26 Feb 2004 10:10:53 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C69B43D1F for ; Thu, 26 Feb 2004 10:10:52 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id AE03C5309; Thu, 26 Feb 2004 19:10:51 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 704BB5308 for ; Thu, 26 Feb 2004 19:10:37 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 59CC733C71; Thu, 26 Feb 2004 19:10:37 +0100 (CET) To: arch@freebsd.org References: From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 19:10:37 +0100 In-Reply-To: (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav's?= message of "Thu, 26 Feb 2004 19:06:24 +0100") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:10:53 -0000 BTW, the dev tree on my laptop looks like this: des@des ~% sysctl dev dev.nexus0.npx0.%class: npx dev.nexus0.npx0.%desc: math processor dev.nexus0.npx0.%driver: npx dev.nexus0.acpi0.acpi_timer0.%class: acpi_timer dev.nexus0.acpi0.acpi_timer0.%desc: 24-bit timer at 3.579545MHz dev.nexus0.acpi0.acpi_timer0.%driver: acpi_timer dev.nexus0.acpi0.acpi_cpu0.%class: acpi_cpu dev.nexus0.acpi0.acpi_cpu0.%desc: CPU dev.nexus0.acpi0.acpi_cpu0.%driver: acpi_cpu dev.nexus0.acpi0.acpi_tz0.%class: acpi_tz dev.nexus0.acpi0.acpi_tz0.%desc: Thermal Zone dev.nexus0.acpi0.acpi_tz0.%driver: acpi_tz dev.nexus0.acpi0.acpi_acad0.%class: acpi_acad dev.nexus0.acpi0.acpi_acad0.%desc: AC Adapter dev.nexus0.acpi0.acpi_acad0.%driver: acpi_acad dev.nexus0.acpi0.acpi_cmbat0.%class: acpi_cmbat dev.nexus0.acpi0.acpi_cmbat0.%desc: Control Method Battery dev.nexus0.acpi0.acpi_cmbat0.%driver: acpi_cmbat dev.nexus0.acpi0.acpi_cmbat1.%class: acpi_cmbat dev.nexus0.acpi0.acpi_cmbat1.%desc: Control Method Battery dev.nexus0.acpi0.acpi_cmbat1.%driver: acpi_cmbat dev.nexus0.acpi0.acpi_lid0.%class: acpi_lid dev.nexus0.acpi0.acpi_lid0.%desc: Control Method Lid Switch dev.nexus0.acpi0.acpi_lid0.%driver: acpi_lid dev.nexus0.acpi0.acpi_button0.%class: acpi_button dev.nexus0.acpi0.acpi_button0.%desc: Power Button dev.nexus0.acpi0.acpi_button0.%driver: acpi_button dev.nexus0.acpi0.acpi_button1.%class: acpi_button dev.nexus0.acpi0.acpi_button1.%desc: Sleep Button dev.nexus0.acpi0.acpi_button1.%driver: acpi_button dev.nexus0.acpi0.pcib0.pci0.agp0.%class: agp dev.nexus0.acpi0.pcib0.pci0.agp0.%desc: Intel 82855 host to AGP bridge dev.nexus0.acpi0.pcib0.pci0.agp0.%driver: agp dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.%class: pci dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.%desc: ACPI PCI bus dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.%driver: pci dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.drm0.%class: drm dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.drm0.%desc: ATI Radeon Lf R250 Mobil= ity 9000 M9 dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.drm0.%driver: drm dev.nexus0.acpi0.pcib0.pci0.pcib1.%class: pcib dev.nexus0.acpi0.pcib0.pci0.pcib1.%desc: ACPI PCI-PCI bridge dev.nexus0.acpi0.pcib0.pci0.pcib1.%driver: pcib dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.%class: uhub dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.%desc: Intel UHCI root hub, cl= ass 9/0, rev 1.00/1.00, addr 1 dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.%driver: uhub dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ums0.%class: ums dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ums0.%desc: Logitech USB Mouse= , rev 1.10/6.20, addr 2 dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ums0.%driver: ums dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ugen0.%class: ugen dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ugen0.%desc: vendor 0x413c pro= duct 0x8000, rev 1.10/5.65, addr 3 dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ugen0.%driver: ugen dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.%class: usb dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.%desc: Intel 82801DB (ICH4) USB cont= roller USB-A dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.%driver: usb dev.nexus0.acpi0.pcib0.pci0.uhci0.%class: uhci dev.nexus0.acpi0.pcib0.pci0.uhci0.%desc: Intel 82801DB (ICH4) USB controlle= r USB-A dev.nexus0.acpi0.pcib0.pci0.uhci0.%driver: uhci dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.uhub1.%class: uhub dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.uhub1.%desc: Intel UHCI root hub, cl= ass 9/0, rev 1.00/1.00, addr 1 dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.uhub1.%driver: uhub dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.%class: usb dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.%desc: Intel 82801DB (ICH4) USB cont= roller USB-B dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.%driver: usb dev.nexus0.acpi0.pcib0.pci0.uhci1.%class: uhci dev.nexus0.acpi0.pcib0.pci0.uhci1.%desc: Intel 82801DB (ICH4) USB controlle= r USB-B dev.nexus0.acpi0.pcib0.pci0.uhci1.%driver: uhci dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.uhub2.%class: uhub dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.uhub2.%desc: Intel UHCI root hub, cl= ass 9/0, rev 1.00/1.00, addr 1 dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.uhub2.%driver: uhub dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.%class: usb dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.%desc: Intel 82801DB (ICH4) USB cont= roller USB-C dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.%driver: usb dev.nexus0.acpi0.pcib0.pci0.uhci2.%class: uhci dev.nexus0.acpi0.pcib0.pci0.uhci2.%desc: Intel 82801DB (ICH4) USB controlle= r USB-C dev.nexus0.acpi0.pcib0.pci0.uhci2.%driver: uhci dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.cardbus0.%class: cardbus dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.cardbus0.%desc: CardBus bus dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.cardbus0.%driver: cardbus dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.pccard0.%class: pccard dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.pccard0.%desc: 16-bit PCCard bus dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.pccard0.%driver: pccard dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.%class: cbb dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.%desc: O2Micro OZ711E1 PCI-Card= Bus Bridge dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.%driver: cbb dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.cardbus1.%class: cardbus dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.cardbus1.%desc: CardBus bus dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.cardbus1.%driver: cardbus dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.pccard1.%class: pccard dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.pccard1.%desc: 16-bit PCCard bus dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.pccard1.%driver: pccard dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.%class: cbb dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.%desc: O2Micro OZ711E1 PCI-Card= Bus Bridge dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.%driver: cbb dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.%class: pci dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.%desc: ACPI PCI bus dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.%driver: pci dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.RadioState: 0 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.PowerSaveMode: 0 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.PLCPHeader: 0 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.frag: 2346 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.rts: 2347 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.NetworkAddress: dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.antdiv: 3 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.BTCoexist: 1 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Channel: 11 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.EnableLEAP: 1 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Interference_Mode: -1 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.IBSSGMode: 0 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.LegacyMode: 0 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.band: 0 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.AssocPref: 0 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.RoamPref: 0 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Rate: 0 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.10280001: Dell TrueMobile 1400 = Adapter dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Environment: 1 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.NdisVersion: 0x00050001 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.BusType: 5 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.InterruptNumber: 11 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.ForcePIO: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.NoRadio: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.AdapterDesc: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.DriverDesc: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.WPA: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Buffers: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Locale: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.PwrOut: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.IBSSGProtection: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.RoamTrigger: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.FrameBursting: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.gpio0: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.gpio1: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.gpio2: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.gpio3: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.BadFramePreempt: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.scan_channel_time: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.scan_unassoc_time: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.scan_home_time: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.scan_passes: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.EnableAutoConnect: UNSET dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.%class: bwe dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.%desc: Dell TrueMobile 1400 Dua= l Band WLAN Mini-PCI Card dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.%driver: bwe dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.%class: bge dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.%desc: Broadcom BCM5702 Gigabit= Ethernet, ASIC rev. 0x1002 dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.%driver: bge dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.brgphy0.%class: brgphy dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.brgphy0.%desc: BCM5703 = 10/100/1000baseTX PHY dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.brgphy0.%driver: brgphy dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.%class: miibus dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.%desc: MII bus dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.%driver: miibus dev.nexus0.acpi0.pcib0.pci0.pcib2.%class: pcib dev.nexus0.acpi0.pcib0.pci0.pcib2.%desc: ACPI PCI-PCI bridge dev.nexus0.acpi0.pcib0.pci0.pcib2.%driver: pcib dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.%class: isa dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.%desc: ISA bus dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.%driver: isa dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.pmtimer0.%class: pmtimer dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.pmtimer0.%driver: pmtimer dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.orm0.%class: orm dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.orm0.%desc: Option ROM dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.orm0.%driver: orm dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.sc0.%class: sc dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.sc0.%desc: System console dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.sc0.%driver: sc dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.vga0.%class: vga dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.vga0.%desc: Generic ISA VGA dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.vga0.%driver: vga dev.nexus0.acpi0.pcib0.pci0.isab0.%class: isab dev.nexus0.acpi0.pcib0.pci0.isab0.%desc: PCI-ISA bridge dev.nexus0.acpi0.pcib0.pci0.isab0.%driver: isab dev.nexus0.acpi0.pcib0.pci0.atapci0.ata0.%class: ata dev.nexus0.acpi0.pcib0.pci0.atapci0.ata0.%driver: ata dev.nexus0.acpi0.pcib0.pci0.atapci0.ata1.%class: ata dev.nexus0.acpi0.pcib0.pci0.atapci0.ata1.%driver: ata dev.nexus0.acpi0.pcib0.pci0.atapci0.%class: atapci dev.nexus0.acpi0.pcib0.pci0.atapci0.%desc: Intel ICH4 UDMA100 controller dev.nexus0.acpi0.pcib0.pci0.atapci0.%driver: atapci dev.nexus0.acpi0.pcib0.pci0.pcm0.%class: pcm dev.nexus0.acpi0.pcib0.pci0.pcm0.%desc: Intel ICH4 (82801DB) dev.nexus0.acpi0.pcib0.pci0.pcm0.%driver: pcm dev.nexus0.acpi0.pcib0.pci0.%class: pci dev.nexus0.acpi0.pcib0.pci0.%desc: ACPI PCI bus dev.nexus0.acpi0.pcib0.pci0.%driver: pci dev.nexus0.acpi0.pcib0.%class: pcib dev.nexus0.acpi0.pcib0.%desc: ACPI Host-PCI bridge dev.nexus0.acpi0.pcib0.%driver: pcib dev.nexus0.acpi0.psmcpnp0.%class: psmcpnp dev.nexus0.acpi0.psmcpnp0.%driver: psmcpnp dev.nexus0.acpi0.atkbdc0.atkbd0.%class: atkbd dev.nexus0.acpi0.atkbdc0.atkbd0.%desc: AT Keyboard dev.nexus0.acpi0.atkbdc0.atkbd0.%driver: atkbd dev.nexus0.acpi0.atkbdc0.psm0.%class: psm dev.nexus0.acpi0.atkbdc0.psm0.%desc: PS/2 Mouse dev.nexus0.acpi0.atkbdc0.psm0.%driver: psm dev.nexus0.acpi0.atkbdc0.%class: atkbdc dev.nexus0.acpi0.atkbdc0.%desc: Keyboard controller (i8042) dev.nexus0.acpi0.atkbdc0.%driver: atkbdc dev.nexus0.acpi0.attimer0.%class: attimer dev.nexus0.acpi0.attimer0.%driver: attimer dev.nexus0.acpi0.attimer1.%class: attimer dev.nexus0.acpi0.attimer1.%driver: attimer dev.nexus0.acpi0.atpic0.%class: atpic dev.nexus0.acpi0.atpic0.%driver: atpic dev.nexus0.acpi0.atdma0.%class: atdma dev.nexus0.acpi0.atdma0.%driver: atdma dev.nexus0.acpi0.npxisa0.%class: npxisa dev.nexus0.acpi0.npxisa0.%driver: npxisa dev.nexus0.acpi0.sio0.%class: sio dev.nexus0.acpi0.sio0.%driver: sio dev.nexus0.acpi0.ppc0.ppbus0.lpt0.%class: lpt dev.nexus0.acpi0.ppc0.ppbus0.lpt0.%desc: Printer dev.nexus0.acpi0.ppc0.ppbus0.lpt0.%driver: lpt dev.nexus0.acpi0.ppc0.ppbus0.ppi0.%class: ppi dev.nexus0.acpi0.ppc0.ppbus0.ppi0.%desc: Parallel I/O dev.nexus0.acpi0.ppc0.ppbus0.ppi0.%driver: ppi dev.nexus0.acpi0.ppc0.ppbus0.%class: ppbus dev.nexus0.acpi0.ppc0.ppbus0.%desc: Parallel port bus dev.nexus0.acpi0.ppc0.ppbus0.%driver: ppbus dev.nexus0.acpi0.ppc0.%class: ppc dev.nexus0.acpi0.ppc0.%driver: ppc dev.nexus0.acpi0.%class: acpi dev.nexus0.acpi0.%desc: DELL CPi R dev.nexus0.acpi0.%driver: acpi dev.nexus0.%class: nexus dev.nexus0.%driver: nexus DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:21:27 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2CD516A4CE for ; Thu, 26 Feb 2004 10:21:27 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EF8243D1F for ; Thu, 26 Feb 2004 10:21:27 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QILMkj080040; Thu, 26 Feb 2004 11:21:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 11:20:45 -0700 (MST) Message-Id: <20040226.112045.82374099.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:21:28 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : The first of the attached patches creates a sysctl context and node : for every device in the system named for its nameunit. Each device's= : sysctl node is a child of the parent device's sysctl node, so the : resulting sysctl tree resembles the "show devices by attachment" mode= : of Windows's device manager. Standard entries in each device's tree : include %class, %desc and %driver (device class, device description : and driver name). I also plan to add entries for device IDs, irq / : drq lines etc., but this will require additional bus-specific code an= d : is not yet implemented. How is this different than the sysctl stuff that already exsists for this and is accessed by devinfo? Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:23:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F31F716A4CF for ; Thu, 26 Feb 2004 10:23:11 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F1D543D2F for ; Thu, 26 Feb 2004 10:23:11 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QIN8kj080073; Thu, 26 Feb 2004 11:23:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 11:22:31 -0700 (MST) Message-Id: <20040226.112231.68042660.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:23:12 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : @@ -381,6 +388,8 @@ : struct dev_event_info *n1 =3D NULL; : struct proc *p; : = : + if (*data !=3D '?') : + printf("devctl: %s", data); This is bogus. Also, there's no provision for devices that are in the tree, but have no drivers attached. These devices also can consume resources and are interested from that point of view. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:23:54 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66C6E16A4CE for ; Thu, 26 Feb 2004 10:23:54 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6222843D1D for ; Thu, 26 Feb 2004 10:23:53 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QINnkj080094; Thu, 26 Feb 2004 11:23:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 11:23:12 -0700 (MST) Message-Id: <20040226.112312.01048309.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:23:54 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : BTW, the dev tree on my laptop looks like this: : = : des@des ~% sysctl dev : dev.nexus0.npx0.%class: npx : dev.nexus0.npx0.%desc: math processor : dev.nexus0.npx0.%driver: npx : dev.nexus0.acpi0.acpi_timer0.%class: acpi_timer : dev.nexus0.acpi0.acpi_timer0.%desc: 24-bit timer at 3.579545MHz : dev.nexus0.acpi0.acpi_timer0.%driver: acpi_timer : dev.nexus0.acpi0.acpi_cpu0.%class: acpi_cpu : dev.nexus0.acpi0.acpi_cpu0.%desc: CPU : dev.nexus0.acpi0.acpi_cpu0.%driver: acpi_cpu : dev.nexus0.acpi0.acpi_tz0.%class: acpi_tz : dev.nexus0.acpi0.acpi_tz0.%desc: Thermal Zone : dev.nexus0.acpi0.acpi_tz0.%driver: acpi_tz : dev.nexus0.acpi0.acpi_acad0.%class: acpi_acad : dev.nexus0.acpi0.acpi_acad0.%desc: AC Adapter : dev.nexus0.acpi0.acpi_acad0.%driver: acpi_acad : dev.nexus0.acpi0.acpi_cmbat0.%class: acpi_cmbat : dev.nexus0.acpi0.acpi_cmbat0.%desc: Control Method Battery : dev.nexus0.acpi0.acpi_cmbat0.%driver: acpi_cmbat : dev.nexus0.acpi0.acpi_cmbat1.%class: acpi_cmbat : dev.nexus0.acpi0.acpi_cmbat1.%desc: Control Method Battery : dev.nexus0.acpi0.acpi_cmbat1.%driver: acpi_cmbat : dev.nexus0.acpi0.acpi_lid0.%class: acpi_lid : dev.nexus0.acpi0.acpi_lid0.%desc: Control Method Lid Switch : dev.nexus0.acpi0.acpi_lid0.%driver: acpi_lid : dev.nexus0.acpi0.acpi_button0.%class: acpi_button : dev.nexus0.acpi0.acpi_button0.%desc: Power Button : dev.nexus0.acpi0.acpi_button0.%driver: acpi_button : dev.nexus0.acpi0.acpi_button1.%class: acpi_button : dev.nexus0.acpi0.acpi_button1.%desc: Sleep Button : dev.nexus0.acpi0.acpi_button1.%driver: acpi_button : dev.nexus0.acpi0.pcib0.pci0.agp0.%class: agp : dev.nexus0.acpi0.pcib0.pci0.agp0.%desc: Intel 82855 host to AGP bridg= e : dev.nexus0.acpi0.pcib0.pci0.agp0.%driver: agp : dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.%class: pci : dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.%desc: ACPI PCI bus : dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.%driver: pci : dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.drm0.%class: drm : dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.drm0.%desc: ATI Radeon Lf R250= Mobility 9000 M9 : dev.nexus0.acpi0.pcib0.pci0.pcib1.pci1.drm0.%driver: drm : dev.nexus0.acpi0.pcib0.pci0.pcib1.%class: pcib : dev.nexus0.acpi0.pcib0.pci0.pcib1.%desc: ACPI PCI-PCI bridge : dev.nexus0.acpi0.pcib0.pci0.pcib1.%driver: pcib : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.%class: uhub : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.%desc: Intel UHCI root h= ub, class 9/0, rev 1.00/1.00, addr 1 : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.%driver: uhub : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ums0.%class: ums : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ums0.%desc: Logitech USB= Mouse, rev 1.10/6.20, addr 2 : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ums0.%driver: ums : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ugen0.%class: ugen : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ugen0.%desc: vendor 0x41= 3c product 0x8000, rev 1.10/5.65, addr 3 : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.uhub0.ugen0.%driver: ugen : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.%class: usb : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.%desc: Intel 82801DB (ICH4) US= B controller USB-A : dev.nexus0.acpi0.pcib0.pci0.uhci0.usb0.%driver: usb : dev.nexus0.acpi0.pcib0.pci0.uhci0.%class: uhci : dev.nexus0.acpi0.pcib0.pci0.uhci0.%desc: Intel 82801DB (ICH4) USB con= troller USB-A : dev.nexus0.acpi0.pcib0.pci0.uhci0.%driver: uhci : dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.uhub1.%class: uhub : dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.uhub1.%desc: Intel UHCI root h= ub, class 9/0, rev 1.00/1.00, addr 1 : dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.uhub1.%driver: uhub : dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.%class: usb : dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.%desc: Intel 82801DB (ICH4) US= B controller USB-B : dev.nexus0.acpi0.pcib0.pci0.uhci1.usb1.%driver: usb : dev.nexus0.acpi0.pcib0.pci0.uhci1.%class: uhci : dev.nexus0.acpi0.pcib0.pci0.uhci1.%desc: Intel 82801DB (ICH4) USB con= troller USB-B : dev.nexus0.acpi0.pcib0.pci0.uhci1.%driver: uhci : dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.uhub2.%class: uhub : dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.uhub2.%desc: Intel UHCI root h= ub, class 9/0, rev 1.00/1.00, addr 1 : dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.uhub2.%driver: uhub : dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.%class: usb : dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.%desc: Intel 82801DB (ICH4) US= B controller USB-C : dev.nexus0.acpi0.pcib0.pci0.uhci2.usb2.%driver: usb : dev.nexus0.acpi0.pcib0.pci0.uhci2.%class: uhci : dev.nexus0.acpi0.pcib0.pci0.uhci2.%desc: Intel 82801DB (ICH4) USB con= troller USB-C : dev.nexus0.acpi0.pcib0.pci0.uhci2.%driver: uhci : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.cardbus0.%class: cardbus : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.cardbus0.%desc: CardBus b= us : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.cardbus0.%driver: cardbus= : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.pccard0.%class: pccard : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.pccard0.%desc: 16-bit PCC= ard bus : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.pccard0.%driver: pccard : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.%class: cbb : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.%desc: O2Micro OZ711E1 PC= I-CardBus Bridge : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb0.%driver: cbb : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.cardbus1.%class: cardbus : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.cardbus1.%desc: CardBus b= us : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.cardbus1.%driver: cardbus= : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.pccard1.%class: pccard : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.pccard1.%desc: 16-bit PCC= ard bus : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.pccard1.%driver: pccard : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.%class: cbb : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.%desc: O2Micro OZ711E1 PC= I-CardBus Bridge : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.cbb1.%driver: cbb : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.%class: pci : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.%desc: ACPI PCI bus : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.%driver: pci : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.RadioState: 0 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.PowerSaveMode: 0 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.PLCPHeader: 0 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.frag: 2346 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.rts: 2347 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.NetworkAddress: : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.antdiv: 3 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.BTCoexist: 1 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Channel: 11 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.EnableLEAP: 1 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Interference_Mode: -1 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.IBSSGMode: 0 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.LegacyMode: 0 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.band: 0 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.AssocPref: 0 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.RoamPref: 0 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Rate: 0 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.10280001: Dell TrueMobile= 1400 Adapter : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Environment: 1 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.NdisVersion: 0x00050001 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.BusType: 5 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.InterruptNumber: 11 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.ForcePIO: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.NoRadio: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.AdapterDesc: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.DriverDesc: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.WPA: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Buffers: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.Locale: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.PwrOut: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.IBSSGProtection: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.RoamTrigger: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.FrameBursting: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.gpio0: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.gpio1: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.gpio2: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.gpio3: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.BadFramePreempt: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.scan_channel_time: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.scan_unassoc_time: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.scan_home_time: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.scan_passes: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.EnableAutoConnect: UNSET : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.%class: bwe : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.%desc: Dell TrueMobile 14= 00 Dual Band WLAN Mini-PCI Card : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bwe0.%driver: bwe : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.%class: bge : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.%desc: Broadcom BCM5702 G= igabit Ethernet, ASIC rev. 0x1002 : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.%driver: bge : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.brgphy0.%class: b= rgphy : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.brgphy0.%desc: BC= M5703 10/100/1000baseTX PHY : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.brgphy0.%driver: = brgphy : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.%class: miibus : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.%desc: MII bus : dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2.bge0.miibus0.%driver: miibus : dev.nexus0.acpi0.pcib0.pci0.pcib2.%class: pcib : dev.nexus0.acpi0.pcib0.pci0.pcib2.%desc: ACPI PCI-PCI bridge : dev.nexus0.acpi0.pcib0.pci0.pcib2.%driver: pcib : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.%class: isa : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.%desc: ISA bus : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.%driver: isa : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.pmtimer0.%class: pmtimer : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.pmtimer0.%driver: pmtimer : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.orm0.%class: orm : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.orm0.%desc: Option ROM : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.orm0.%driver: orm : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.sc0.%class: sc : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.sc0.%desc: System console : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.sc0.%driver: sc : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.vga0.%class: vga : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.vga0.%desc: Generic ISA VGA : dev.nexus0.acpi0.pcib0.pci0.isab0.isa0.vga0.%driver: vga : dev.nexus0.acpi0.pcib0.pci0.isab0.%class: isab : dev.nexus0.acpi0.pcib0.pci0.isab0.%desc: PCI-ISA bridge : dev.nexus0.acpi0.pcib0.pci0.isab0.%driver: isab : dev.nexus0.acpi0.pcib0.pci0.atapci0.ata0.%class: ata : dev.nexus0.acpi0.pcib0.pci0.atapci0.ata0.%driver: ata : dev.nexus0.acpi0.pcib0.pci0.atapci0.ata1.%class: ata : dev.nexus0.acpi0.pcib0.pci0.atapci0.ata1.%driver: ata : dev.nexus0.acpi0.pcib0.pci0.atapci0.%class: atapci : dev.nexus0.acpi0.pcib0.pci0.atapci0.%desc: Intel ICH4 UDMA100 control= ler : dev.nexus0.acpi0.pcib0.pci0.atapci0.%driver: atapci : dev.nexus0.acpi0.pcib0.pci0.pcm0.%class: pcm : dev.nexus0.acpi0.pcib0.pci0.pcm0.%desc: Intel ICH4 (82801DB) : dev.nexus0.acpi0.pcib0.pci0.pcm0.%driver: pcm : dev.nexus0.acpi0.pcib0.pci0.%class: pci : dev.nexus0.acpi0.pcib0.pci0.%desc: ACPI PCI bus : dev.nexus0.acpi0.pcib0.pci0.%driver: pci : dev.nexus0.acpi0.pcib0.%class: pcib : dev.nexus0.acpi0.pcib0.%desc: ACPI Host-PCI bridge : dev.nexus0.acpi0.pcib0.%driver: pcib : dev.nexus0.acpi0.psmcpnp0.%class: psmcpnp : dev.nexus0.acpi0.psmcpnp0.%driver: psmcpnp : dev.nexus0.acpi0.atkbdc0.atkbd0.%class: atkbd : dev.nexus0.acpi0.atkbdc0.atkbd0.%desc: AT Keyboard : dev.nexus0.acpi0.atkbdc0.atkbd0.%driver: atkbd : dev.nexus0.acpi0.atkbdc0.psm0.%class: psm : dev.nexus0.acpi0.atkbdc0.psm0.%desc: PS/2 Mouse : dev.nexus0.acpi0.atkbdc0.psm0.%driver: psm : dev.nexus0.acpi0.atkbdc0.%class: atkbdc : dev.nexus0.acpi0.atkbdc0.%desc: Keyboard controller (i8042) : dev.nexus0.acpi0.atkbdc0.%driver: atkbdc : dev.nexus0.acpi0.attimer0.%class: attimer : dev.nexus0.acpi0.attimer0.%driver: attimer : dev.nexus0.acpi0.attimer1.%class: attimer : dev.nexus0.acpi0.attimer1.%driver: attimer : dev.nexus0.acpi0.atpic0.%class: atpic : dev.nexus0.acpi0.atpic0.%driver: atpic : dev.nexus0.acpi0.atdma0.%class: atdma : dev.nexus0.acpi0.atdma0.%driver: atdma : dev.nexus0.acpi0.npxisa0.%class: npxisa : dev.nexus0.acpi0.npxisa0.%driver: npxisa : dev.nexus0.acpi0.sio0.%class: sio : dev.nexus0.acpi0.sio0.%driver: sio : dev.nexus0.acpi0.ppc0.ppbus0.lpt0.%class: lpt : dev.nexus0.acpi0.ppc0.ppbus0.lpt0.%desc: Printer : dev.nexus0.acpi0.ppc0.ppbus0.lpt0.%driver: lpt : dev.nexus0.acpi0.ppc0.ppbus0.ppi0.%class: ppi : dev.nexus0.acpi0.ppc0.ppbus0.ppi0.%desc: Parallel I/O : dev.nexus0.acpi0.ppc0.ppbus0.ppi0.%driver: ppi : dev.nexus0.acpi0.ppc0.ppbus0.%class: ppbus : dev.nexus0.acpi0.ppc0.ppbus0.%desc: Parallel port bus : dev.nexus0.acpi0.ppc0.ppbus0.%driver: ppbus : dev.nexus0.acpi0.ppc0.%class: ppc : dev.nexus0.acpi0.ppc0.%driver: ppc : dev.nexus0.acpi0.%class: acpi : dev.nexus0.acpi0.%desc: DELL CPi R : dev.nexus0.acpi0.%driver: acpi : dev.nexus0.%class: nexus : dev.nexus0.%driver: nexus devinfo -v on my laptop: nexus0 legacy0 npx0 acpi0 acpi_timer0 acpi_cpu0 acpi_tz0 acpi_acad0 acpi_cmbat0 acpi_cmbat1 acpi_lid0 acpi_button0 acpi_button1 unknown pcib0 pci0 agp0 pnpinfo vendor=3D0x8086 device=3D0x1130 subvendor=3D0x0000= subdevice=3D0x0000 class=3D0x060000 at slot=3D0 function=3D0 pcib1 pnpinfo vendor=3D0x8086 device=3D0x1131 subvendor=3D0x000= 0 subdevice=3D0x0000 class=3D0x060400 at slot=3D1 function=3D0 pci1 drm0 pnpinfo vendor=3D0x1002 device=3D0x4d46 subvendor=3D0x= 1028 subdevice=3D0x00a4 class=3D0x030000 at slot=3D0 function=3D0 pcib2 pnpinfo vendor=3D0x8086 device=3D0x2448 subvendor=3D0x000= 0 subdevice=3D0x0000 class=3D0x060400 at slot=3D30 function=3D0 pci2 pcm0 pnpinfo vendor=3D0x125d device=3D0x1998 subvendor=3D0x= 1028 subdevice=3D0x00a4 class=3D0x040100 at slot=3D3 function=3D0 cbb0 pnpinfo vendor=3D0x104c device=3D0xac42 subvendor=3D0x= 1028 subdevice=3D0x00a4 class=3D0x060700 at slot=3D15 function=3D0 cardbus0 pccard0 cbb1 pnpinfo vendor=3D0x104c device=3D0xac42 subvendor=3D0x= 1028 subdevice=3D0x00a4 class=3D0x060700 at slot=3D15 function=3D1 cardbus1 pccard1 ep0 pnpinfo manufacturer=3D0x0101 product=3D0x0589 cisv= endor=3D"3Com Corporation" cisproduct=3D"3C589" function_type=3D6 at fu= nction=3D0 fwohci0 pnpinfo vendor=3D0x104c device=3D0x8027 subvendor=3D= 0x1028 subdevice=3D0x00a4 class=3D0x0c0010 at slot=3D15 function=3D2 firewire0 isab0 pnpinfo vendor=3D0x8086 device=3D0x244c subvendor=3D0x000= 0 subdevice=3D0x0000 class=3D0x060100 at slot=3D31 function=3D0 isa0 pmtimer0 sc0 vga0 adv0 aha0 aic0 bt0 cs0 ed0 fe0 ie0 le0 lnc0 pcic0 pcic1 ppc0 sio0 sio1 sio2 sio3 sn0 vt0 orm0 atapci0 pnpinfo vendor=3D0x8086 device=3D0x244a subvendor=3D0x8= 086 subdevice=3D0x4541 class=3D0x010180 at slot=3D31 function=3D1 ata0 ata1 uhci0 pnpinfo vendor=3D0x8086 device=3D0x2442 subvendor=3D0x808= 6 subdevice=3D0x4541 class=3D0x0c0300 at slot=3D31 function=3D2 usb0 uhub0 unknown unknown unknown unknown psmcpnp0 atkbdc0 atkbd0 psm0 attimer0 attimer1 unknown unknown atpic0 atdma0 npxisa0 fdc0 fd0 fd1 unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown unknown From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:27:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5329B16A4CE for ; Thu, 26 Feb 2004 10:27:12 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D673943D3F for ; Thu, 26 Feb 2004 10:27:11 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QIR9kj080206; Thu, 26 Feb 2004 11:27:09 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 11:26:31 -0700 (MST) Message-Id: <20040226.112631.45877306.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:27:12 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : I also plan to add entries for device IDs, irq / : drq lines etc., but this will require additional bus-specific code an= d : is not yet implemented. You don't need bus specific code for any of these things, per se. There's already two routines that busses can (and mostly do) implement. The irq/drq/resource stuff is already recorded elsewhere and can be dug out, just like devinfo does. The existing interface to get location and pnpinfo from the bus are: # # Returns the pnp info for this device. Return it as a string. If the= # string is insufficient for the storage, then return EOVERFLOW. # METHOD int child_pnpinfo_str { device_t _dev; device_t _child; char *_buf; size_t _buflen; }; # # Returns the location for this device. Return it as a string. If the= # string is insufficient for the storage, then return EOVERFLOW. # METHOD int child_location_str { device_t _dev; device_t _child; char *_buf; size_t _buflen; }; Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:29:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECEE216A4CE for ; Thu, 26 Feb 2004 10:29:47 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA23443D1F for ; Thu, 26 Feb 2004 10:29:47 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 87DA95309; Thu, 26 Feb 2004 19:29:46 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 6F0A05308; Thu, 26 Feb 2004 19:29:41 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id E30D433C71; Thu, 26 Feb 2004 19:29:40 +0100 (CET) To: "M. Warner Losh" References: <20040226.112045.82374099.imp@bsdimp.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 19:29:40 +0100 In-Reply-To: <20040226.112045.82374099.imp@bsdimp.com> (M. Warner Losh's message of "Thu, 26 Feb 2004 11:20:45 -0700 (MST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:29:48 -0000 "M. Warner Losh" writes: > How is this different than the sysctl stuff that already exsists for > this and is accessed by devinfo? 1) it is immensely easier to access 2) it gives drivers a well-defined place to put their per-device sysctl variables - devinfo doesn't address that issue at all DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:30:27 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8422016A4CE for ; Thu, 26 Feb 2004 10:30:27 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52AE543D31 for ; Thu, 26 Feb 2004 10:30:27 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 8228E5309; Thu, 26 Feb 2004 19:30:26 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id E612D5308; Thu, 26 Feb 2004 19:30:21 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id C83EC33C71; Thu, 26 Feb 2004 19:30:21 +0100 (CET) To: "M. Warner Losh" References: <20040226.112231.68042660.imp@bsdimp.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 19:30:21 +0100 In-Reply-To: <20040226.112231.68042660.imp@bsdimp.com> (M. Warner Losh's message of "Thu, 26 Feb 2004 11:22:31 -0700 (MST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:30:27 -0000 "M. Warner Losh" writes: > des@des.no (Dag-Erling Sm=F8rgrav) writes: > : + if (*data !=3D '?') > : + printf("devctl: %s", data); > > This is bogus. Sorry, unrelated debugging printf. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:35:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0290F16A4CE for ; Thu, 26 Feb 2004 10:35:26 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EFEE43D1D for ; Thu, 26 Feb 2004 10:35:25 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QIZEkj080373; Thu, 26 Feb 2004 11:35:15 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 11:35:14 -0700 (MST) Message-Id: <20040226.113514.94846192.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: <20040226.112045.82374099.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:35:26 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : "M. Warner Losh" writes: : > How is this different than the sysctl stuff that already exsists fo= r : > this and is accessed by devinfo? : = : 1) it is immensely easier to access From=20whose point of view. devinfo is easier to type than sysctl dev by one character :-). However, : 2) it gives drivers a well-defined place to put their per-device : sysctl variables - devinfo doesn't address that issue at all That is a good reason to transitioning to this, so long as we can come up with a good way to represent detached nodes. This also gives us a good place to hang other actions we may want to send to device drivers like power down, etc. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:41:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E37C16A4CE for ; Thu, 26 Feb 2004 10:41:43 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B221843D2F for ; Thu, 26 Feb 2004 10:41:42 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QIfdkj080517; Thu, 26 Feb 2004 11:41:40 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 11:41:39 -0700 (MST) Message-Id: <20040226.114139.74817352.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: <20040226.112045.82374099.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:41:43 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : 2) it gives drivers a well-defined place to put their per-device : sysctl variables - devinfo doesn't address that issue at all I guess if you are going to reinvent devinfo, some mechanism to replace it should be included. It just looked like a 95% duplication of devinfo when I first saw things. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:47:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4050F16A4CE for ; Thu, 26 Feb 2004 10:47:14 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id C094A43D39 for ; Thu, 26 Feb 2004 10:47:13 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 40782530F; Thu, 26 Feb 2004 19:47:12 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 904EC5309; Thu, 26 Feb 2004 19:47:01 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 63C2333C71; Thu, 26 Feb 2004 19:47:01 +0100 (CET) To: "M. Warner Losh" References: <20040226.112045.82374099.imp@bsdimp.com> <20040226.113514.94846192.imp@bsdimp.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 19:47:01 +0100 In-Reply-To: <20040226.113514.94846192.imp@bsdimp.com> (M. Warner Losh's message of "Thu, 26 Feb 2004 11:35:14 -0700 (MST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:47:14 -0000 "M. Warner Losh" writes: > des@des.no (Dag-Erling Sm=F8rgrav) writes: > : 1) it is immensely easier to access > From whose point of view. Programmatically. The in-kernel implementation is much simpler, and the userland code required to access it will also be simpler. Accessing individual devices (once you know where they are) should also be much simpler since devinfo only gives you "all or nothing". > : 2) it gives drivers a well-defined place to put their per-device > : sysctl variables - devinfo doesn't address that issue at all > That is a good reason to transitioning to this, so long as we can come > up with a good way to represent detached nodes. As long as they have a device_t, it should be a piece of cake. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:48:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 441AD16A4CF for ; Thu, 26 Feb 2004 10:48:26 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id EECFC43D2D for ; Thu, 26 Feb 2004 10:48:25 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 3455B5309; Thu, 26 Feb 2004 19:48:25 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 4FE565308; Thu, 26 Feb 2004 19:48:17 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 2E9DC33C71; Thu, 26 Feb 2004 19:48:17 +0100 (CET) To: "M. Warner Losh" References: <20040226.112045.82374099.imp@bsdimp.com> <20040226.114139.74817352.imp@bsdimp.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 19:48:17 +0100 In-Reply-To: <20040226.114139.74817352.imp@bsdimp.com> (M. Warner Losh's message of "Thu, 26 Feb 2004 11:41:39 -0700 (MST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:48:26 -0000 "M. Warner Losh" writes: > I guess if you are going to reinvent devinfo, some mechanism to > replace it should be included. It just looked like a 95% duplication > of devinfo when I first saw things. It should be a simple matter to reimplement devinfo(8) to use the dev sysctl tree. Does anything else than devinfo(8) use devinfo(3)? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:50:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D627816A4CE for ; Thu, 26 Feb 2004 10:50:58 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50DFA43D1F for ; Thu, 26 Feb 2004 10:50:58 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QIotkj080647; Thu, 26 Feb 2004 11:50:55 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 11:50:49 -0700 (MST) Message-Id: <20040226.115049.97364862.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: <20040226.114139.74817352.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:50:58 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : "M. Warner Losh" writes: : > I guess if you are going to reinvent devinfo, some mechanism to : > replace it should be included. It just looked like a 95% duplicati= on : > of devinfo when I first saw things. : = : It should be a simple matter to reimplement devinfo(8) to use the dev= : sysctl tree. Does anything else than devinfo(8) use devinfo(3)? I don't think that anything else does use it. However, devctl is closely related and is used by devd. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:56:45 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56C5116A4CE for ; Thu, 26 Feb 2004 10:56:45 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30AFE43D1F for ; Thu, 26 Feb 2004 10:56:42 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004022618564101400kl774e>; Thu, 26 Feb 2004 18:56:41 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA07209; Thu, 26 Feb 2004 10:56:39 -0800 (PST) Date: Thu, 26 Feb 2004 10:56:37 -0800 (PST) From: Julian Elischer To: "M. Warner Losh" In-Reply-To: <20040226.113514.94846192.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: des@des.no cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:56:45 -0000 On Thu, 26 Feb 2004, M. Warner Losh wrote: > In message: > des@des.no (Dag-Erling Sm=F8rgrav) writes: > : "M. Warner Losh" writes: > : > How is this different than the sysctl stuff that already exsists for > : > this and is accessed by devinfo? > :=20 > : 1) it is immensely easier to access >=20 > From whose point of view. devinfo is easier to type than sysctl dev > by one character :-). However, it is easier to check a specific thing.. e.g. What's on pcibus 2? sysctl dev.nexus0.acpi0.pcib0.pci0.pcib2.pci2 a bit of a mouthfull, but at least unambiguous :-) it might be possible to also produce some "more succinct" versions. i would like to be able to say sysctl dev.nexus0.acpi0.pcib0.pci0.pcib2.slot2 to see what is there.. This is very close to the device-tree filesystem, (I forget the actual name) that linux has. The advantage of that approach is that you can have symlinks.. e.g. /devtree/nexus0/acpi0/pcib0/pci0/pcib2/pci2/slot2 --> /devtree/nexus0/acpi0/pcib0/pci0/pcib2/pci2/bwe0 of course in human terms the above would be easier read as: /devtree/pcib0/pcib2/slot2 or=20 dev.pcib0.pcib2.slot2 is there a way of getting rid of the "fluff" entries? ( a flag on teh dev_attach saying "I am a fluff entry, do not show me"?) >=20 > : 2) it gives drivers a well-defined place to put their per-device > : sysctl variables - devinfo doesn't address that issue at all >=20 > That is a good reason to transitioning to this, so long as we can come > up with a good way to represent detached nodes. This also gives us a > good place to hang other actions we may want to send to device drivers > like power down, etc. I agree this lays the groundwork for unifying a number of things.. what about 'virtual' devices? dev.virtual.mem dev.virtual.mem.size dev.virtual.kmem >=20 > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >=20 From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 10:58:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90DFA16A4D4 for ; Thu, 26 Feb 2004 10:58:39 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1775C43D1D for ; Thu, 26 Feb 2004 10:58:39 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i1QIvdDL095451; Thu, 26 Feb 2004 13:57:39 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i1QIvdDW095448; Thu, 26 Feb 2004 13:57:39 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 26 Feb 2004 13:57:38 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 18:58:39 -0000 On Thu, 26 Feb 2004, Dag-Erling Sm=F8rgrav wrote: > "M. Warner Losh" writes: > > I guess if you are going to reinvent devinfo, some mechanism to > > replace it should be included. It just looked like a 95% duplication > > of devinfo when I first saw things. >=20 > It should be a simple matter to reimplement devinfo(8) to use the dev > sysctl tree. Does anything else than devinfo(8) use devinfo(3)?=20 devinfo(8) is arguably one of the most useful additions to FreeBSD in a long time :-). Since you have your hands in there, could you take a look at the issue involving devices that share resources: specifically, devinfo(8) (possibly due to defficiences in the sysctls supporting it) does not render things like shared IRQ's well (or at all). For example, I have several devices that appear to share IRQ 11:=20 pcib0: slot 7 INTD is routed to irq 11 pcib0: slot 16 INTA is routed to irq 11 pcib0: slot 16 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 pcib0: slot 3 INTA is routed to irq 11 pcib0: slot 3 INTA is routed to irq 11 uhci0: port 0xdce0-0xdcff irq 11 at device 7.2 on pci0 xl0: <3Com 3c556 Fast Etherlink XL> port 0xd400-0xd4ff mem 0xf3ffd800-0xf3ffd87f,0xf3ffdc00-0xf3ffdc7f irq 11 at device 16.0 on pci0 wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 drm0: port 0xec00-0xecff mem 0xfdffc000-0xfdffffff,0xf8000000-0xfbffffff irq 11 at device 0.0 on pci1 (This probably explains extreme suffering when running with apic and drm, but that's beside the point :-). Devinfo renders this as follows: Interrupt request lines: 0x0 (root0) 0x1 (atkbd0) 0x2-0x3 (root0) 0x4 (sio0) 0x5 (root0) 0x6 (fdc0) 0x7 (ppc0) 0x8 (root0) 0x9 (acpi0) 0xa (root0) 0xb (cbb0) 0xc (psmcpnp0) 0xd (root0) 0xe (ata0) 0xf (ata1) Having a unified and managed namespace for device sysctls sounds like a generally good idea to me, as more and more devices require some of another tweaking. Have you had any thoughts on how to name sysctls and kernel environment variables on a per-driver basis, rather than a per-device basis? I.e., fxp and some other device drivers have configuration settings that affect all instances of devices, rather than specific instances. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 11:06:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B90516A4CE for ; Thu, 26 Feb 2004 11:06:32 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A5A043D2D for ; Thu, 26 Feb 2004 11:06:32 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id F21115309; Thu, 26 Feb 2004 20:06:30 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 491FA5308; Thu, 26 Feb 2004 20:06:24 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 9AD2333C71; Thu, 26 Feb 2004 20:06:23 +0100 (CET) To: "M. Warner Losh" References: <20040226.114139.74817352.imp@bsdimp.com> <20040226.115049.97364862.imp@bsdimp.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 20:06:23 +0100 In-Reply-To: <20040226.115049.97364862.imp@bsdimp.com> (M. Warner Losh's message of "Thu, 26 Feb 2004 11:50:49 -0700 (MST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 19:06:32 -0000 "M. Warner Losh" writes: > des@des.no (Dag-Erling Sm=F8rgrav) writes: > : It should be a simple matter to reimplement devinfo(8) to use the dev > : sysctl tree. Does anything else than devinfo(8) use devinfo(3)? > I don't think that anything else does use it. However, devctl is > closely related and is used by devd. I don't see any reason to modify or remove devctl.... DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 11:09:27 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CF2216A4CE; Thu, 26 Feb 2004 11:09:27 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29CC043D2D; Thu, 26 Feb 2004 11:09:27 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 497355309; Thu, 26 Feb 2004 20:09:26 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 3A84D5308; Thu, 26 Feb 2004 20:09:16 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id CA10F33C71; Thu, 26 Feb 2004 20:09:15 +0100 (CET) To: Robert Watson References: From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 20:09:15 +0100 In-Reply-To: (Robert Watson's message of "Thu, 26 Feb 2004 13:57:38 -0500 (EST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 19:09:27 -0000 Robert Watson writes: > Having a unified and managed namespace for device sysctls sounds like a > generally good idea to me, as more and more devices require some of > another tweaking. Have you had any thoughts on how to name sysctls and > kernel environment variables on a per-driver basis, rather than a > per-device basis? I.e., fxp and some other device drivers have > configuration settings that affect all instances of devices, rather than > specific instances. It should be easy to add a per-devclass_t or per-driver_t sysctl context and tree. These things are disgustingly easy to create; the only hard part is figuring out when and where to create them. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 11:17:42 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9F8F16A4CE for ; Thu, 26 Feb 2004 11:17:42 -0800 (PST) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CBFD43D1F for ; Thu, 26 Feb 2004 11:17:38 -0800 (PST) (envelope-from john@baldwin.cx) Received: (qmail 4268 invoked from network); 26 Feb 2004 19:17:36 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 26 Feb 2004 19:17:36 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i1QJHV28051411; Thu, 26 Feb 2004 14:17:31 -0500 (EST) (envelope-from john@baldwin.cx) From: John Baldwin To: arch@FreeBSD.org Date: Thu, 26 Feb 2004 14:18:56 -0500 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402261418.56290.john@baldwin.cx> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: des@des.no cc: Julian Elischer Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 19:17:43 -0000 On Thursday 26 February 2004 01:56 pm, Julian Elischer wrote: > is there a way of getting rid of the "fluff" entries? > ( a flag on teh dev_attach saying "I am a fluff entry, do not show me"?) What is a "fluff" entry? Above you threw out the PCI busses and left the foo-PCI bridges. By the way, I think that the sysctl should be a program interface. Humans should use devinfo(8). -- John Baldwin <>< http://www.baldwin.cx/~john/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 11:17:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D787B16A4CE; Thu, 26 Feb 2004 11:17:48 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77D8843D39; Thu, 26 Feb 2004 11:17:48 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <2004022619172101200adbf2e>; Thu, 26 Feb 2004 19:17:23 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA07509; Thu, 26 Feb 2004 11:17:20 -0800 (PST) Date: Thu, 26 Feb 2004 11:17:19 -0800 (PST) From: Julian Elischer To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: arch@freebsd.org cc: Robert Watson Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 19:17:49 -0000 On Thu, 26 Feb 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Robert Watson writes: > > Having a unified and managed namespace for device sysctls sounds like a > > generally good idea to me, as more and more devices require some of > > another tweaking. Have you had any thoughts on how to name sysctls and > > kernel environment variables on a per-driver basis, rather than a > > per-device basis? I.e., fxp and some other device drivers have > > configuration settings that affect all instances of devices, rather tha= n > > specific instances. >=20 > It should be easy to add a per-devclass_t or per-driver_t sysctl > context and tree. These things are disgustingly easy to create; the > only hard part is figuring out when and where to create them. and delete them. >=20 > DES > --=20 > Dag-Erling Sm=F8rgrav - des@des.no > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >=20 From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 11:44:15 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4473F16A4CE for ; Thu, 26 Feb 2004 11:44:14 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A86B343D39 for ; Thu, 26 Feb 2004 11:44:13 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i1QJhm75002325; Thu, 26 Feb 2004 20:43:53 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 26 Feb 2004 19:47:01 +0100." Date: Thu, 26 Feb 2004 20:43:48 +0100 Message-ID: <2324.1077824628@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 19:44:16 -0000 In message , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= writes: >"M. Warner Losh" writes: >> des@des.no (Dag-Erling Smørgrav) writes: >> : 1) it is immensely easier to access >> From whose point of view. > >Programmatically. The in-kernel implementation is much simpler, and >the userland code required to access it will also be simpler. >Accessing individual devices (once you know where they are) should >also be much simpler since devinfo only gives you "all or nothing". > > >> : 2) it gives drivers a well-defined place to put their per-device >> : sysctl variables - devinfo doesn't address that issue at all >> That is a good reason to transitioning to this, so long as we can come >> up with a good way to represent detached nodes. > >As long as they have a device_t, it should be a piece of cake. Having a device_t is a property of having hardware, not of being a device driver. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 11:48:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 305D816A4CE for ; Thu, 26 Feb 2004 11:48:12 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0D8843D41 for ; Thu, 26 Feb 2004 11:48:11 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 2D1FC5309; Thu, 26 Feb 2004 20:48:10 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 451835308; Thu, 26 Feb 2004 20:47:59 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id BAEB833C71; Thu, 26 Feb 2004 20:47:58 +0100 (CET) To: "Poul-Henning Kamp" References: <2324.1077824628@critter.freebsd.dk> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 20:47:58 +0100 In-Reply-To: <2324.1077824628@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 26 Feb 2004 20:43:48 +0100") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 19:48:12 -0000 "Poul-Henning Kamp" writes: > Dag-Erling =3D?iso-8859-1?q?Sm=3DF8rgrav?=3D writes: > > "M. Warner Losh" writes: > > > That is a good reason to transitioning to this, so long as we can come > > > up with a good way to represent detached nodes. > > As long as they have a device_t, it should be a piece of cake. > Having a device_t is a property of having hardware, not of being a > device driver. I believe that by "detached nodes", Warner means hardware that does not have a driver. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 11:51:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8377116A4CE for ; Thu, 26 Feb 2004 11:51:11 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E426E43D1F for ; Thu, 26 Feb 2004 11:51:10 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i1QJp9Ds002469; Thu, 26 Feb 2004 20:51:09 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 26 Feb 2004 19:10:37 +0100." Date: Thu, 26 Feb 2004 20:51:09 +0100 Message-ID: <2468.1077825069@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 19:51:11 -0000 In message , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= writes: >BTW, the dev tree on my laptop looks like this: > >des@des ~% sysctl dev >dev.nexus0.npx0.%class: npx >dev.nexus0.npx0.%desc: math processor >dev.nexus0.npx0.%driver: npx >dev.nexus0.acpi0.acpi_timer0.%class: acpi_timer >dev.nexus0.acpi0.acpi_timer0.%desc: 24-bit timer at 3.579545MHz >dev.nexus0.acpi0.acpi_timer0.%driver: acpi_timer Just for the record: Having based this on newbus it only documents hardware-anchored device drivers. I don't know if this is going to be a limitation we will have to address or not, but I think you should reserve the toplevel name "pseudo" or "sw" or similar as a placeholder for non-hardware device drivers, just in case. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 11:55:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EF0116A4CE; Thu, 26 Feb 2004 11:55:08 -0800 (PST) Received: from sirius.firepipe.net (sirius.firepipe.net [69.13.116.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61D8243D1F; Thu, 26 Feb 2004 11:55:08 -0800 (PST) (envelope-from will@csociety.org) Received: by sirius.firepipe.net (Postfix, from userid 1000) id E872C18FE7; Thu, 26 Feb 2004 14:55:07 -0500 (EST) Date: Thu, 26 Feb 2004 14:55:07 -0500 From: Will Andrews To: Robert Watson Message-ID: <20040226195507.GQ7466@sirius.firepipe.net> Mail-Followup-To: Robert Watson , Dag-Erling Sm?rgrav , arch@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ejxBj3YzjByOPzh0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: Dag-Erling Sm?rgrav cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 19:55:08 -0000 --ejxBj3YzjByOPzh0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 26, 2004 at 01:57:38PM -0500, Robert Watson wrote: > devinfo(8) is arguably one of the most useful additions to FreeBSD in a > long time :-). Since you have your hands in there, could you take a look How about adding a standard interface for an English description of the device? It would be useful for e.g. user programs to access such information easily within the device tree. Regards, --=20 wca --ejxBj3YzjByOPzh0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAPk8WF47idPgWcsURAg1/AJ0T2ypRnhDNbuP2rwL5jp3MPTfThgCeN/pE kpIAen9kyh/eccLkYm84B8w= =SdHU -----END PGP SIGNATURE----- --ejxBj3YzjByOPzh0-- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 11:56:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1478516A4CE; Thu, 26 Feb 2004 11:56:59 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id D62B843D1D; Thu, 26 Feb 2004 11:56:58 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 060245309; Thu, 26 Feb 2004 20:56:57 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 95E975308; Thu, 26 Feb 2004 20:56:51 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 97A4433C68; Thu, 26 Feb 2004 20:56:50 +0100 (CET) To: Robert Watson References: <20040226195507.GQ7466@sirius.firepipe.net> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 20:56:50 +0100 In-Reply-To: <20040226195507.GQ7466@sirius.firepipe.net> (Will Andrews's message of "Thu, 26 Feb 2004 14:55:07 -0500") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 19:56:59 -0000 Will Andrews writes: > How about adding a standard interface for an English description > of the device? It would be useful for e.g. user programs to > access such information easily within the device tree. Already done. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 11:57:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C496116A4CE for ; Thu, 26 Feb 2004 11:57:39 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5113843D2F for ; Thu, 26 Feb 2004 11:57:39 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QJvakj081401; Thu, 26 Feb 2004 12:57:36 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 12:57:19 -0700 (MST) Message-Id: <20040226.125719.01017771.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: <20040226.115049.97364862.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 19:57:39 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : "M. Warner Losh" writes: : > des@des.no (Dag-Erling Sm=F8rgrav) writes: : > : It should be a simple matter to reimplement devinfo(8) to use the= dev : > : sysctl tree. Does anything else than devinfo(8) use devinfo(3)? : > I don't think that anything else does use it. However, devctl is : > closely related and is used by devd. : = : I don't see any reason to modify or remove devctl.... I don't see any reason to have two almost similar things in the tree when one will do. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 11:59:24 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94C1216A4CE for ; Thu, 26 Feb 2004 11:59:24 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E321F43D3F for ; Thu, 26 Feb 2004 11:59:23 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QJxLkj081437; Thu, 26 Feb 2004 12:59:21 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 12:59:04 -0700 (MST) Message-Id: <20040226.125904.08946359.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: <2324.1077824628@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org cc: phk@phk.freebsd.dk Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 19:59:24 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : "Poul-Henning Kamp" writes: : > Dag-Erling =3D?iso-8859-1?q?Sm=3DF8rgrav?=3D writes: : > > "M. Warner Losh" writes: : > > > That is a good reason to transitioning to this, so long as we c= an come : > > > up with a good way to represent detached nodes. : > > As long as they have a device_t, it should be a piece of cake. : > Having a device_t is a property of having hardware, not of being a : > device driver. : = : I believe that by "detached nodes", Warner means hardware that does : not have a driver. They have a device_t, however. All nodes in the tree have a device_t (kind of by definition). Not all nodes in the tree have a devclass associated with their device_t (eg, not all devices are attached). this is why you'll see lots of 'unknown' nodes in the devinfo output. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 12:02:20 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71F9016A4CE; Thu, 26 Feb 2004 12:02:20 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9DB943D1D; Thu, 26 Feb 2004 12:02:19 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QK2Hkj081515; Thu, 26 Feb 2004 13:02:17 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 13:02:00 -0700 (MST) Message-Id: <20040226.130200.112722727.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org cc: rwatson@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:02:20 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : Robert Watson writes: : > Having a unified and managed namespace for device sysctls sounds li= ke a : > generally good idea to me, as more and more devices require some of= : > another tweaking. Have you had any thoughts on how to name sysctls= and : > kernel environment variables on a per-driver basis, rather than a : > per-device basis? I.e., fxp and some other device drivers have : > configuration settings that affect all instances of devices, rather= than : > specific instances. : = : It should be easy to add a per-devclass_t or per-driver_t sysctl : context and tree. These things are disgustingly easy to create; the : only hard part is figuring out when and where to create them. You'd need to have devclass as well as dev trees, but that's easy to do. We have hw.tsc.. sysctls for all the drivers at work, and it would be nice to have a more general framework to put stuff like that into. It would be nice if there was some kind of tie-in to tunables as well, since many drivers have tunables that are global, but might want to be less global. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 12:02:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF41D16A4CF; Thu, 26 Feb 2004 12:02:39 -0800 (PST) Received: from sirius.firepipe.net (sirius.firepipe.net [69.13.116.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99C3243D39; Thu, 26 Feb 2004 12:02:39 -0800 (PST) (envelope-from will@csociety.org) Received: by sirius.firepipe.net (Postfix, from userid 1000) id 59ADC18FEC; Thu, 26 Feb 2004 15:02:39 -0500 (EST) Date: Thu, 26 Feb 2004 15:02:39 -0500 From: Will Andrews To: Dag-Erling Sm?rgrav Message-ID: <20040226200239.GS7466@sirius.firepipe.net> Mail-Followup-To: Dag-Erling Sm?rgrav , Robert Watson , arch@freebsd.org References: <20040226195507.GQ7466@sirius.firepipe.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u+M3zPFM/+rkulSy" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: arch@freebsd.org cc: Robert Watson Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:02:40 -0000 --u+M3zPFM/+rkulSy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 26, 2004 at 08:56:50PM +0100, Dag-Erling Sm?rgrav wrote: > Already done. My apologies, I didn't look at your sysctl dev printout very closely, obviously. Thanks! :-) regards, --=20 wca --u+M3zPFM/+rkulSy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAPlDfF47idPgWcsURAhGzAJwJRPjNZDy+hpsU4jUTw+qXkCb0NQCcC03V GHMJDkhbtmNurVErkYOyv1w= =TVO+ -----END PGP SIGNATURE----- --u+M3zPFM/+rkulSy-- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 12:03:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C275516A4CE for ; Thu, 26 Feb 2004 12:03:50 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C8C743D1D for ; Thu, 26 Feb 2004 12:03:50 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QK3lkj081561; Thu, 26 Feb 2004 13:03:47 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 13:03:30 -0700 (MST) Message-Id: <20040226.130330.54448406.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <2468.1077825069@critter.freebsd.dk> References: <2468.1077825069@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: des@des.no cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:03:50 -0000 In message: <2468.1077825069@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= : writes: : : >BTW, the dev tree on my laptop looks like this: : > : >des@des ~% sysctl dev : >dev.nexus0.npx0.%class: npx : >dev.nexus0.npx0.%desc: math processor : >dev.nexus0.npx0.%driver: npx : >dev.nexus0.acpi0.acpi_timer0.%class: acpi_timer : >dev.nexus0.acpi0.acpi_timer0.%desc: 24-bit timer at 3.579545MHz : >dev.nexus0.acpi0.acpi_timer0.%driver: acpi_timer : : Just for the record: Having based this on newbus it only documents : hardware-anchored device drivers. I don't know if this is going to : be a limitation we will have to address or not, but I think you should : reserve the toplevel name "pseudo" or "sw" or similar as a placeholder : for non-hardware device drivers, just in case. There's not really a tree for pseudo devices right now. They just are kludged into the system any old way that they can be at the moment. They aren't part of the hardware device hierarchy. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 12:08:10 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C39AE16A4CE for ; Thu, 26 Feb 2004 12:08:10 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50D3F43D2D for ; Thu, 26 Feb 2004 12:08:10 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QK86kj081677; Thu, 26 Feb 2004 13:08:06 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 13:07:49 -0700 (MST) Message-Id: <20040226.130749.96599763.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <20040226.130330.54448406.imp@bsdimp.com> References: <2468.1077825069@critter.freebsd.dk> <20040226.130330.54448406.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: des@des.no cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:08:10 -0000 In message: <20040226.130330.54448406.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <2468.1077825069@critter.freebsd.dk> : "Poul-Henning Kamp" writes: : : In message , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= : : writes: : : : : >BTW, the dev tree on my laptop looks like this: : : > : : >des@des ~% sysctl dev : : >dev.nexus0.npx0.%class: npx : : >dev.nexus0.npx0.%desc: math processor : : >dev.nexus0.npx0.%driver: npx : : >dev.nexus0.acpi0.acpi_timer0.%class: acpi_timer : : >dev.nexus0.acpi0.acpi_timer0.%desc: 24-bit timer at 3.579545MHz : : >dev.nexus0.acpi0.acpi_timer0.%driver: acpi_timer : : : : Just for the record: Having based this on newbus it only documents : : hardware-anchored device drivers. I don't know if this is going to : : be a limitation we will have to address or not, but I think you should : : reserve the toplevel name "pseudo" or "sw" or similar as a placeholder : : for non-hardware device drivers, just in case. : : There's not really a tree for pseudo devices right now. They just are : kludged into the system any old way that they can be at the moment. : They aren't part of the hardware device hierarchy. Hate to reply to myself.... By impliciation we shouldn't kludge this mechanism to include them, but consider having a pseudo0 attached to nexus0 that accumulates them so they are less of a kludge to the whole system. Also gives a more uniform way of controlling them. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 12:37:55 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E47316A4CE for ; Thu, 26 Feb 2004 12:37:55 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 684DB43D31 for ; Thu, 26 Feb 2004 12:37:54 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i1QKbnpY003046; Thu, 26 Feb 2004 21:37:49 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 26 Feb 2004 12:59:04 MST." <20040226.125904.08946359.imp@bsdimp.com> Date: Thu, 26 Feb 2004 21:37:49 +0100 Message-ID: <3045.1077827869@critter.freebsd.dk> cc: des@des.no cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:37:55 -0000 In message <20040226.125904.08946359.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: > des@des.no (Dag-Erling Smørgrav) writes: >: "Poul-Henning Kamp" writes: >: > Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= writes: >: > > "M. Warner Losh" writes: >: > > > That is a good reason to transitioning to this, so long as we can come >: > > > up with a good way to represent detached nodes. >: > > As long as they have a device_t, it should be a piece of cake. >: > Having a device_t is a property of having hardware, not of being a >: > device driver. >: >: I believe that by "detached nodes", Warner means hardware that does >: not have a driver. > >They have a device_t, however. All nodes in the tree have a device_t >(kind of by definition). Not all nodes in the tree have a devclass >associated with their device_t (eg, not all devices are attached). >this is why you'll see lots of 'unknown' nodes in the devinfo output. GEOM, NETGRAPH pty, tun, tap, nmdm and similar have no newbus infestation and there would have to really good reasons to infest them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 12:39:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D93B16A4D0 for ; Thu, 26 Feb 2004 12:39:26 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 640C043D31 for ; Thu, 26 Feb 2004 12:39:25 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i1QKdMfH003063; Thu, 26 Feb 2004 21:39:22 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 26 Feb 2004 13:03:30 MST." <20040226.130330.54448406.imp@bsdimp.com> Date: Thu, 26 Feb 2004 21:39:22 +0100 Message-ID: <3062.1077827962@critter.freebsd.dk> cc: des@des.no cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:39:26 -0000 In message <20040226.130330.54448406.imp@bsdimp.com>, "M. Warner Losh" writes: >: Just for the record: Having based this on newbus it only documents >: hardware-anchored device drivers. I don't know if this is going to >: be a limitation we will have to address or not, but I think you should >: reserve the toplevel name "pseudo" or "sw" or similar as a placeholder >: for non-hardware device drivers, just in case. > >There's not really a tree for pseudo devices right now. They just are >kludged into the system any old way that they can be at the moment. >They aren't part of the hardware device hierarchy. As long as we agree that this is for hardware only and limited to that, then I have no problems. I still think it prudent to nail down "pseudo" or "sw" or something should we change our mind. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 12:41:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FBC416A4CE for ; Thu, 26 Feb 2004 12:41:43 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB79343D2F for ; Thu, 26 Feb 2004 12:41:42 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QKfdkj082140; Thu, 26 Feb 2004 13:41:39 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 13:41:20 -0700 (MST) Message-Id: <20040226.134120.71093962.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <3045.1077827869@critter.freebsd.dk> References: <20040226.125904.08946359.imp@bsdimp.com> <3045.1077827869@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: des@des.no cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:41:43 -0000 In message: <3045.1077827869@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20040226.125904.08946359.imp@bsdimp.com>, "M. Warner Losh= " writes: : >In message: : > des@des.no (Dag-Erling Sm=F8rgrav) writes: : >: "Poul-Henning Kamp" writes: : >: > Dag-Erling =3D?iso-8859-1?q?Sm=3DF8rgrav?=3D writes: : >: > > "M. Warner Losh" writes: : >: > > > That is a good reason to transitioning to this, so long as w= e can come : >: > > > up with a good way to represent detached nodes. : >: > > As long as they have a device_t, it should be a piece of cake.= : >: > Having a device_t is a property of having hardware, not of being= a : >: > device driver. : >: = : >: I believe that by "detached nodes", Warner means hardware that doe= s : >: not have a driver. : > : >They have a device_t, however. All nodes in the tree have a device_= t : >(kind of by definition). Not all nodes in the tree have a devclass : >associated with their device_t (eg, not all devices are attached). : >this is why you'll see lots of 'unknown' nodes in the devinfo output= .= : = : GEOM, NETGRAPH pty, tun, tap, nmdm and similar have no newbus : infestation and there would have to really good reasons to infest the= m. If they want to use this mechanism, they need to use the mechanism. I'm cool with them not using this mechanism, but I don't think we should kludge it to allow for them to use it. That's what I'm saying... This is a newbus only mechanism and let's not get bogged down in accomidatnig non-newbus things until we have the newbus parts of it working. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 12:42:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C71A116A4CE for ; Thu, 26 Feb 2004 12:42:14 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62CAE43D1D for ; Thu, 26 Feb 2004 12:42:14 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QKgBkj082149; Thu, 26 Feb 2004 13:42:11 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 13:41:54 -0700 (MST) Message-Id: <20040226.134154.18582197.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <3062.1077827962@critter.freebsd.dk> References: <20040226.130330.54448406.imp@bsdimp.com> <3062.1077827962@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: des@des.no cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:42:14 -0000 In message: <3062.1077827962@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20040226.130330.54448406.imp@bsdimp.com>, "M. Warner Losh" writes: : : >: Just for the record: Having based this on newbus it only documents : >: hardware-anchored device drivers. I don't know if this is going to : >: be a limitation we will have to address or not, but I think you should : >: reserve the toplevel name "pseudo" or "sw" or similar as a placeholder : >: for non-hardware device drivers, just in case. : > : >There's not really a tree for pseudo devices right now. They just are : >kludged into the system any old way that they can be at the moment. : >They aren't part of the hardware device hierarchy. : : As long as we agree that this is for hardware only and limited to : that, then I have no problems. : : I still think it prudent to nail down "pseudo" or "sw" or something : should we change our mind. We should nail that down when we decide on the mechanism for dealing. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 12:45:41 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 957EA16A4CE for ; Thu, 26 Feb 2004 12:45:41 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55CB643D1F for ; Thu, 26 Feb 2004 12:45:41 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 2D1D35309; Thu, 26 Feb 2004 21:45:40 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id DDD745308; Thu, 26 Feb 2004 21:45:33 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 793B533C68; Thu, 26 Feb 2004 21:45:33 +0100 (CET) To: "M. Warner Losh" References: <20040226.115049.97364862.imp@bsdimp.com> <20040226.125719.01017771.imp@bsdimp.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 26 Feb 2004 21:45:33 +0100 In-Reply-To: <20040226.125719.01017771.imp@bsdimp.com> (M. Warner Losh's message of "Thu, 26 Feb 2004 12:57:19 -0700 (MST)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:45:41 -0000 "M. Warner Losh" writes: > des@des.no (Dag-Erling Sm=F8rgrav) writes: > : I don't see any reason to modify or remove devctl.... > I don't see any reason to have two almost similar things in the tree > when one will do. I don't see how devctl and the dev sysctl tree are the same thing. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 12:46:18 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A05FB16A4CE for ; Thu, 26 Feb 2004 12:46:18 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 951CD43D31 for ; Thu, 26 Feb 2004 12:46:18 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004022620461701400k8vsre>; Thu, 26 Feb 2004 20:46:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA08709; Thu, 26 Feb 2004 12:46:17 -0800 (PST) Date: Thu, 26 Feb 2004 12:46:15 -0800 (PST) From: Julian Elischer To: "M. Warner Losh" In-Reply-To: <20040226.134120.71093962.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: des@des.no cc: phk@phk.freebsd.dk cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:46:18 -0000 On Thu, 26 Feb 2004, M. Warner Losh wrote: > In message: <3045.1077827869@critter.freebsd.dk> > "Poul-Henning Kamp" writes: > : In message <20040226.125904.08946359.imp@bsdimp.com>, "M. Warner Losh" = writes: > : >In message: > : > des@des.no (Dag-Erling Sm=F8rgrav) writes: > : >: "Poul-Henning Kamp" writes: > : >: > Dag-Erling =3D?iso-8859-1?q?Sm=3DF8rgrav?=3D writes: > : >: > > "M. Warner Losh" writes: > : >: > > > That is a good reason to transitioning to this, so long as we = can come > : >: > > > up with a good way to represent detached nodes. > : >: > > As long as they have a device_t, it should be a piece of cake. > : >: > Having a device_t is a property of having hardware, not of being a > : >: > device driver. > : >:=20 > : >: I believe that by "detached nodes", Warner means hardware that does > : >: not have a driver. > : > > : >They have a device_t, however. All nodes in the tree have a device_t > : >(kind of by definition). Not all nodes in the tree have a devclass > : >associated with their device_t (eg, not all devices are attached). > : >this is why you'll see lots of 'unknown' nodes in the devinfo output. > :=20 > : GEOM, NETGRAPH pty, tun, tap, nmdm and similar have no newbus > : infestation and there would have to really good reasons to infest them. Well netgraph has been using net.graph for a while but it would be nice to have at least a convention as to where things like this might go..=20 >=20 > If they want to use this mechanism, they need to use the mechanism. > I'm cool with them not using this mechanism, but I don't think we > should kludge it to allow for them to use it. That's what I'm > saying... This is a newbus only mechanism and let's not get bogged > down in accomidatnig non-newbus things until we have the newbus parts > of it working. >=20 > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >=20 From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 12:47:57 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCED616A4CE for ; Thu, 26 Feb 2004 12:47:57 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A9CD43D1F for ; Thu, 26 Feb 2004 12:47:57 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1QKlskj082293; Thu, 26 Feb 2004 13:47:54 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 26 Feb 2004 13:47:37 -0700 (MST) Message-Id: <20040226.134737.123677005.imp@bsdimp.com> To: des@des.no From: "M. Warner Losh" In-Reply-To: References: <20040226.125719.01017771.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 20:47:57 -0000 In message: des@des.no (Dag-Erling Sm=F8rgrav) writes: : "M. Warner Losh" writes: : > des@des.no (Dag-Erling Sm=F8rgrav) writes: : > : I don't see any reason to modify or remove devctl.... : > I don't see any reason to have two almost similar things in the tre= e : > when one will do. : = : I don't see how devctl and the dev sysctl tree are the same thing. ah, I misread 'devctl' as 'devinfo' Warner From owner-freebsd-arch@FreeBSD.ORG Thu Feb 26 14:21:33 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6123C16A4CE for ; Thu, 26 Feb 2004 14:21:33 -0800 (PST) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 294DB43D1F for ; Thu, 26 Feb 2004 14:21:33 -0800 (PST) (envelope-from john@baldwin.cx) Received: (qmail 1963 invoked from network); 26 Feb 2004 22:21:32 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 26 Feb 2004 22:21:32 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i1QMLI28052274; Thu, 26 Feb 2004 17:21:18 -0500 (EST) (envelope-from john@baldwin.cx) From: John Baldwin To: arch@FreeBSD.org Date: Thu, 26 Feb 2004 17:22:42 -0500 User-Agent: KMail/1.6 References: <20040226.130200.112722727.imp@bsdimp.com> In-Reply-To: <20040226.130200.112722727.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200402261722.42523.john@baldwin.cx> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: des@des.no cc: rwatson@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 22:21:33 -0000 On Thursday 26 February 2004 03:02 pm, M. Warner Losh wrote: > In message: > > des@des.no (Dag-Erling Sm=F8rgrav) writes: > : Robert Watson writes: > : > Having a unified and managed namespace for device sysctls sounds like= a > : > generally good idea to me, as more and more devices require some of > : > another tweaking. Have you had any thoughts on how to name sysctls a= nd > : > kernel environment variables on a per-driver basis, rather than a > : > per-device basis? I.e., fxp and some other device drivers have > : > configuration settings that affect all instances of devices, rather > : > than specific instances. > : > : It should be easy to add a per-devclass_t or per-driver_t sysctl > : context and tree. These things are disgustingly easy to create; the > : only hard part is figuring out when and where to create them. > > You'd need to have devclass as well as dev trees, but that's easy to > do. We have hw.tsc.. sysctls for all the drivers at > work, and it would be nice to have a more general framework to put > stuff like that into. > > It would be nice if there was some kind of tie-in to tunables as well, > since many drivers have tunables that are global, but might want to be > less global. Maybe 'dev.foo0.bar0' for devices, and 'driver.foo' are things specific to = the=20 foo driver, though really that would have to be devclass.foo. Drivers can= =20 have the same names, so that gets harder. E.g., we have multiple pci(4)=20 drivers and multiple pcib(4) drivers. So you couldn't just have a=20 'driver.pci'. You could have a 'devclass.acpi/pci' and a 'devclass.pci/pci= '=20 though for class-wide things perhaps. Drivers are a much harder nut to cra= ck=20 given that they don't really have a sensible uniquifier. =2D-=20 John Baldwin <>< http://www.baldwin.cx/~john/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Feb 27 04:16:31 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0EBF16A4CE for ; Fri, 27 Feb 2004 04:16:31 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 229E843D1F for ; Fri, 27 Feb 2004 04:16:29 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i1RCGD5O001290; Fri, 27 Feb 2004 23:16:13 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i1RCG9ch022782; Fri, 27 Feb 2004 23:16:11 +1100 Date: Fri, 27 Feb 2004 23:16:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= In-Reply-To: Message-ID: <20040227230124.D2469@gamplex.bde.org> References: <20040226.112045.82374099.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 12:16:32 -0000 On Thu, 26 Feb 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > "M. Warner Losh" writes: > > How is this different than the sysctl stuff that already exsists for > > this and is accessed by devinfo? > > 1) it is immensely easier to access > > 2) it gives drivers a well-defined place to put their per-device > sysctl variables - devinfo doesn't address that issue at all Only broken drivers use sysctl variables. ioctl(3) is a much better interface that sysctl(3) for accessing per-device info. sysctl(8) is a better interface than ioctl(8) for handling the few device control things that can be done in a generic way, but this is only because there are so few such things that ioctl(8) doesn't exist. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Feb 27 05:35:45 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E813916A4CE for ; Fri, 27 Feb 2004 05:35:45 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEC1B43D1F for ; Fri, 27 Feb 2004 05:35:44 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i1RDZYQh011617; Fri, 27 Feb 2004 14:35:39 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Feb 2004 23:16:09 +1100." <20040227230124.D2469@gamplex.bde.org> Date: Fri, 27 Feb 2004 14:35:33 +0100 Message-ID: <11616.1077888933@critter.freebsd.dk> cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 13:35:46 -0000 In message <20040227230124.D2469@gamplex.bde.org>, Bruce Evans writes: >On Thu, 26 Feb 2004, Dag-Erling [iso-8859-1] Smørgrav wrote: > >> "M. Warner Losh" writes: >> > How is this different than the sysctl stuff that already exsists for >> > this and is accessed by devinfo? >> >> 1) it is immensely easier to access >> >> 2) it gives drivers a well-defined place to put their per-device >> sysctl variables - devinfo doesn't address that issue at all > >Only broken drivers use sysctl variables. ioctl(3) is a much better >interface that sysctl(3) for accessing per-device info. sysctl(8) is >a better interface than ioctl(8) for handling the few device control >things that can be done in a generic way, but this is only because >there are so few such things that ioctl(8) doesn't exist. sysctl is superior for properties that should not be vulnerable to any user who happens to be able to open the device. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Feb 27 07:06:20 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7B3616A4D0 for ; Fri, 27 Feb 2004 07:06:20 -0800 (PST) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB57543D2D for ; Fri, 27 Feb 2004 07:06:20 -0800 (PST) (envelope-from john@baldwin.cx) Received: (qmail 11404 invoked from network); 27 Feb 2004 15:06:20 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 27 Feb 2004 15:06:20 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i1RF6G28056405; Fri, 27 Feb 2004 10:06:16 -0500 (EST) (envelope-from john@baldwin.cx) From: John Baldwin To: arch@FreeBSD.org Date: Fri, 27 Feb 2004 10:07:43 -0500 User-Agent: KMail/1.6 References: <20040227230124.D2469@gamplex.bde.org> In-Reply-To: <20040227230124.D2469@gamplex.bde.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200402271007.43299.john@baldwin.cx> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 15:06:21 -0000 On Friday 27 February 2004 07:16 am, Bruce Evans wrote: > On Thu, 26 Feb 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > > "M. Warner Losh" writes: > > > How is this different than the sysctl stuff that already exsists for > > > this and is accessed by devinfo? > > > > 1) it is immensely easier to access > > > > 2) it gives drivers a well-defined place to put their per-device > > sysctl variables - devinfo doesn't address that issue at all > > Only broken drivers use sysctl variables. ioctl(3) is a much better > interface that sysctl(3) for accessing per-device info. sysctl(8) is > a better interface than ioctl(8) for handling the few device control > things that can be done in a generic way, but this is only because > there are so few such things that ioctl(8) doesn't exist. Note that ioctl's act on dev_t devices, not on device_t devices. We have t= wo=20 distinct notions of a device right now: physical hardware devices (new-bus)= =20 and UNIX file devices (entries in /dev). You can ioctl the latter, but not= =20 necessarily the former. =2D-=20 John Baldwin <>< http://www.baldwin.cx/~john/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Feb 27 07:27:42 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D3E716A4CF for ; Fri, 27 Feb 2004 07:27:42 -0800 (PST) Received: from darkness.comp.waw.pl (unknown [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE87543D3F for ; Fri, 27 Feb 2004 07:27:41 -0800 (PST) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 08B2EACE1F; Fri, 27 Feb 2004 16:27:40 +0100 (CET) Date: Fri, 27 Feb 2004 16:27:40 +0100 From: Pawel Jakub Dawidek To: freebsd-arch@freebsd.org Message-ID: <20040227152739.GG5720@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sl5MdczEF/OU2Miu" Content-Disposition: inline User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 Subject: rcNG and jail. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 15:27:42 -0000 --sl5MdczEF/OU2Miu Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello. I've some proof-of-concept patch to teach rcNG about jail. This will allow using starting scripts without any hacks. It works in this way: We're able now to check if we are in jail or not by getting value of sysctl security.jail.jailed. By default scripts are available inside jail, if script does not make sens in jail it should be marked by setting "injail" variable to "no" inside it. Script can still be started when prefix 'force' is used. I'm not sure if this is "the right way", maybe we should provide some sort of script flags to define things like this? http://people.freebsd.org/~pjd/patches/rc_jail.patch --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --sl5MdczEF/OU2Miu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAP2HrForvXbEpPzQRAqNVAKCGPjZBY6tXndmtk4Ds8gza9TDyBgCgqzfK Mvm/Q5TbYFe1IO9L1kxbnPE= =xDfr -----END PGP SIGNATURE----- --sl5MdczEF/OU2Miu-- From owner-freebsd-arch@FreeBSD.ORG Fri Feb 27 09:20:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08DA916A4CE for ; Fri, 27 Feb 2004 09:20:37 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3025543D1D for ; Fri, 27 Feb 2004 09:20:36 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 1CFE15309; Fri, 27 Feb 2004 18:20:35 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id BBD755308 for ; Fri, 27 Feb 2004 18:20:24 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 42D8033C71; Fri, 27 Feb 2004 18:20:24 +0100 (CET) To: arch@freebsd.org From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Fri, 27 Feb 2004 18:20:24 +0100 Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 Subject: 'sysctl dev', round two X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 17:20:37 -0000 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable New patch attached; it should be considerably cleaner than the previous one. A couple of surprises, though: - unattached devices still aren't picked up, which they should if they have a device_t. For instance, I don't see a sysctl entry for the following: none0@pci0:31:3: class=3D0x0c0500 card=3D0x24c21458 chip=3D0x24c3808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82801DB/DBM (ICH4/M) SMBus Controller' class =3D serial bus subclass =3D SMBus - USB devices don't seem to report their location or pnpinfo. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=dev.diff Index: sys/kern/subr_bus.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_bus.c,v retrieving revision 1.140 diff -u -r1.140 subr_bus.c --- sys/kern/subr_bus.c 24 Feb 2004 19:31:30 -0000 1.140 +++ sys/kern/subr_bus.c 27 Feb 2004 16:53:57 -0000 @@ -56,6 +56,7 @@ #include SYSCTL_NODE(_hw, OID_AUTO, bus, CTLFLAG_RW, NULL, NULL); +SYSCTL_NODE(, OID_AUTO, dev, CTLFLAG_RW, NULL, NULL); /* * Used to attach drivers to devclasses. @@ -123,6 +124,9 @@ u_char pad; void *ivars; void *softc; + + struct sysctl_ctx_list sysctl_ctx; + struct sysctl_oid *sysctl_tree; }; struct device_op_desc { @@ -185,6 +189,106 @@ #endif /* + * dev sysctl tree + */ + +enum { + DEVICE_SYSCTL_CLASS, + DEVICE_SYSCTL_DESC, + DEVICE_SYSCTL_DRIVER, + DEVICE_SYSCTL_LOCATION, + DEVICE_SYSCTL_PNPINFO, +}; + +static int +device_sysctl_handler(SYSCTL_HANDLER_ARGS) +{ + device_t dev = (device_t)arg1; + const char *value; + char *buf; + int error; + + buf = NULL; + switch (arg2) { + case DEVICE_SYSCTL_CLASS: + value = dev->devclass ? dev->devclass->name : NULL; + break; + case DEVICE_SYSCTL_DESC: + value = dev->desc; + break; + case DEVICE_SYSCTL_DRIVER: + value = dev->driver ? dev->driver->name : NULL; + break; + case DEVICE_SYSCTL_LOCATION: + value = buf = malloc(1024, M_BUS, M_WAITOK | M_ZERO); + bus_child_location_str(dev, buf, 1024); + break; + case DEVICE_SYSCTL_PNPINFO: + value = buf = malloc(1024, M_BUS, M_WAITOK | M_ZERO); + bus_child_pnpinfo_str(dev, buf, 1024); + break; + default: + return (EINVAL); + } + if (value == NULL) + value = "?"; + error = SYSCTL_OUT(req, value, strlen(value)); + if (buf != NULL) + free(buf, M_BUS); + return (error); +} + +static void +device_sysctl_init(device_t dev) +{ + struct sysctl_oid_list *parent_node; + + if (dev->parent) { + if (dev->parent->sysctl_tree == NULL) + device_sysctl_init(dev->parent); + parent_node = SYSCTL_CHILDREN(dev->parent->sysctl_tree); + } else { + parent_node = SYSCTL_STATIC_CHILDREN(_dev); + } + if (dev->sysctl_tree != NULL) { + sysctl_move_oid(dev->sysctl_tree, parent_node); + return; + } + sysctl_ctx_init(&dev->sysctl_ctx); + dev->sysctl_tree = SYSCTL_ADD_NODE(&dev->sysctl_ctx, parent_node, + OID_AUTO, dev->nameunit, CTLFLAG_RD, 0, ""); + SYSCTL_ADD_PROC(&dev->sysctl_ctx, SYSCTL_CHILDREN(dev->sysctl_tree), + OID_AUTO, "%class", CTLFLAG_RD, + dev, DEVICE_SYSCTL_CLASS, device_sysctl_handler, "A", + "device class name"); + SYSCTL_ADD_PROC(&dev->sysctl_ctx, SYSCTL_CHILDREN(dev->sysctl_tree), + OID_AUTO, "%desc", CTLFLAG_RD, + dev, DEVICE_SYSCTL_DESC, device_sysctl_handler, "A", + "device description"); + SYSCTL_ADD_PROC(&dev->sysctl_ctx, SYSCTL_CHILDREN(dev->sysctl_tree), + OID_AUTO, "%driver", CTLFLAG_RD, + dev, DEVICE_SYSCTL_DRIVER, device_sysctl_handler, "A", + "device driver name"); + SYSCTL_ADD_PROC(&dev->sysctl_ctx, SYSCTL_CHILDREN(dev->sysctl_tree), + OID_AUTO, "%location", CTLFLAG_RD, + dev, DEVICE_SYSCTL_LOCATION, device_sysctl_handler, "A", + "device location relative to parent"); + SYSCTL_ADD_PROC(&dev->sysctl_ctx, SYSCTL_CHILDREN(dev->sysctl_tree), + OID_AUTO, "%pnpinfo", CTLFLAG_RD, + dev, DEVICE_SYSCTL_PNPINFO, device_sysctl_handler, "A", + "device identification"); +} + +static void +device_sysctl_fini(device_t dev) +{ + if (dev->sysctl_tree == NULL) + return; + sysctl_ctx_free(&dev->sysctl_ctx); + dev->sysctl_tree = NULL; +} + +/* * /dev/devctl implementation */ @@ -886,6 +990,7 @@ dc->devices[dev->unit] = dev; dev->devclass = dc; snprintf(dev->nameunit, buflen, "%s%d", dc->name, dev->unit); + device_sysctl_init(dev); return (0); } @@ -900,6 +1005,7 @@ if (dev->devclass != dc || dc->devices[dev->unit] != dev) panic("devclass_delete_device: inconsistent device class"); + device_sysctl_fini(dev); dc->devices[dev->unit] = NULL; if (dev->flags & DF_WILDCARD) dev->unit = -1; @@ -956,9 +1062,7 @@ } dev->ivars = NULL; dev->softc = NULL; - dev->state = DS_NOTPRESENT; - TAILQ_INSERT_TAIL(&bus_data_devices, dev, devlink); bus_data_generation_update(); @@ -1043,6 +1147,7 @@ TAILQ_REMOVE(&dev->children, child, link); TAILQ_REMOVE(&bus_data_devices, child, devlink); device_set_desc(child, NULL); + device_sysctl_fini(dev); kobj_delete((kobj_t) child, M_BUS); bus_data_generation_update(); @@ -1254,6 +1359,18 @@ device_get_flags(device_t dev) { return (dev->devflags); +} + +struct sysctl_ctx_list * +device_get_sysctl_ctx(device_t dev) +{ + return (&dev->sysctl_ctx); +} + +struct sysctl_oid * +device_get_sysctl_tree(device_t dev) +{ + return (dev->sysctl_tree); } int Index: sys/sys/bus.h =================================================================== RCS file: /home/ncvs/src/sys/sys/bus.h,v retrieving revision 1.57 diff -u -r1.57 bus.h --- sys/sys/bus.h 24 Oct 2003 22:41:54 -0000 1.57 +++ sys/sys/bus.h 27 Feb 2004 15:44:30 -0000 @@ -335,6 +335,8 @@ void *device_get_softc(device_t dev); device_state_t device_get_state(device_t dev); int device_get_unit(device_t dev); +struct sysctl_ctx_list *device_get_sysctl_ctx(device_t dev); +struct sysctl_oid *device_get_sysctl_tree(device_t dev); int device_is_alive(device_t dev); /* did probe succeed? */ int device_is_attached(device_t dev); /* did attach succeed? */ int device_is_enabled(device_t dev); --=-=-=-- From owner-freebsd-arch@FreeBSD.ORG Sat Feb 28 03:06:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D87616A4CE for ; Sat, 28 Feb 2004 03:06:01 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90BFE43D1F for ; Sat, 28 Feb 2004 03:05:58 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i1SB5p5O005229; Sat, 28 Feb 2004 22:05:51 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i1SB5m0I012148; Sat, 28 Feb 2004 22:05:49 +1100 Date: Sat, 28 Feb 2004 22:05:47 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Poul-Henning Kamp In-Reply-To: <11616.1077888933@critter.freebsd.dk> Message-ID: <20040228214619.S6048@gamplex.bde.org> References: <11616.1077888933@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: arch@freebsd.org Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 11:06:01 -0000 On Fri, 27 Feb 2004, Poul-Henning Kamp wrote: > In message <20040227230124.D2469@gamplex.bde.org>, Bruce Evans writes: > >Only broken drivers use sysctl variables. ioctl(3) is a much better > >interface that sysctl(3) for accessing per-device info. sysctl(8) is > >a better interface than ioctl(8) for handling the few device control > >things that can be done in a generic way, but this is only because > >there are so few such things that ioctl(8) doesn't exist. > > sysctl is superior for properties that should not be vulnerable > to any user who happens to be able to open the device. Nope. Only broken drivers would provide more features than are intended to any user who happens to be able to open the device. Many drivers require write access to do write-like operations, and some bogusly require appropriate privilege. Extra device nodes (control devices) are be required to provide access to certain features (especially when opening the normal device is required to have a side effect). There is much more support for access control on device nodes than on sysctls. Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Feb 28 03:10:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C17016A4F6 for ; Sat, 28 Feb 2004 03:10:17 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DF0A43D1F for ; Sat, 28 Feb 2004 03:10:17 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i1SBA15O005508; Sat, 28 Feb 2004 22:10:01 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i1SB9x0I012550; Sat, 28 Feb 2004 22:10:00 +1100 Date: Sat, 28 Feb 2004 22:09:58 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Baldwin In-Reply-To: <200402271007.43299.john@baldwin.cx> Message-ID: <20040228220602.K6048@gamplex.bde.org> References: <20040227230124.D2469@gamplex.bde.org> <200402271007.43299.john@baldwin.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: arch@FreeBSD.org cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= Subject: Re: per-device sysctls X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 11:10:37 -0000 On Fri, 27 Feb 2004, John Baldwin wrote: > On Friday 27 February 2004 07:16 am, Bruce Evans wrote: > > On Thu, 26 Feb 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > > > "M. Warner Losh" writes: > > > > How is this different than the sysctl stuff that already exsists fo= r > > > > this and is accessed by devinfo? > > > > > > 1) it is immensely easier to access > > > > > > 2) it gives drivers a well-defined place to put their per-device > > > sysctl variables - devinfo doesn't address that issue at all > > > > Only broken drivers use sysctl variables. ioctl(3) is a much better > > interface that sysctl(3) for accessing per-device info. sysctl(8) is > > a better interface than ioctl(8) for handling the few device control > > things that can be done in a generic way, but this is only because > > there are so few such things that ioctl(8) doesn't exist. > > Note that ioctl's act on dev_t devices, not on device_t devices. We have= two > distinct notions of a device right now: physical hardware devices (new-bu= s) > and UNIX file devices (entries in /dev). You can ioctl the latter, but n= ot > necessarily the former. I think (2) means dev_t devices. I agree that a separate mechanism (but no= t 2) is needed for device_t devices. Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Feb 28 07:47:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2731F16A4CE for ; Sat, 28 Feb 2004 07:47:26 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DBDA43D1D for ; Sat, 28 Feb 2004 07:47:25 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i1SFlN6t021850 for ; Sat, 28 Feb 2004 16:47:23 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Sat, 28 Feb 2004 16:47:23 +0100 Message-ID: <21849.1077983243@critter.freebsd.dk> Subject: EVENTHANDLER_FAST removal ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 15:47:26 -0000 Any objection to removing the unused EVENTHANDLER_FAST stuff ? Index: eventhandler.h =================================================================== RCS file: /home/ncvs/src/sys/sys/eventhandler.h,v retrieving revision 1.29 diff -u -r1.29 eventhandler.h --- eventhandler.h 24 Mar 2003 21:24:37 -0000 1.29 +++ eventhandler.h 28 Feb 2004 15:43:06 -0000 @@ -89,51 +89,6 @@ EHL_UNLOCK((list)); \ } while (0) - -/* - * Fast handler lists require the eventhandler list be present - * at link time. They don't allow addition of entries to - * unknown eventhandler lists, ie. each list must have an - * "owner". - * - * Fast handler lists must be defined once by the owner - * of the eventhandler list, and the declaration must be in - * scope at any point the list is manipulated. - */ -#define EVENTHANDLER_FAST_DECLARE(name, type) \ -extern struct eventhandler_list Xeventhandler_list_ ## name ; \ -struct eventhandler_entry_ ## name { \ - struct eventhandler_entry ee; \ - type eh_func; \ -}; \ -struct __hack - -#define EVENTHANDLER_FAST_DEFINE(name, type) \ -struct eventhandler_list Xeventhandler_list_ ## name = { #name }; \ -struct __hack - -#define EVENTHANDLER_FAST_INVOKE(name, ...) do { \ - struct eventhandler_list *_el = &Xeventhandler_list_ ## name ; \ - \ - if (_el->el_flags & EHL_INITTED) { \ - EHL_LOCK(_el); \ - _EVENTHANDLER_INVOKE(name, _el , ## __VA_ARGS__); \ - } \ -} while (0) - -#define EVENTHANDLER_FAST_REGISTER(name, func, arg, priority) \ - eventhandler_register(&Xeventhandler_list_ ## name, \ - #name, func, arg, priority) - -#define EVENTHANDLER_FAST_DEREGISTER(name, tag) do { \ - struct eventhandler_list *_el = &Xeventhandler_list_ ## name ; \ - \ - KASSERT(_el->el_flags & EHL_INITTED, \ - ("eventhandler_fast_deregister on un-inited list %s", ## name)); \ - EHL_LOCK(_el); \ - eventhandler_deregister(_el, tag); \ -} while (0) - /* * Slow handlers are entirely dynamic; lists are created * when entries are added to them, and thus have no concept of "owner", @@ -195,13 +150,6 @@ EVENTHANDLER_DECLARE(shutdown_pre_sync, shutdown_fn); /* before fs sync */ EVENTHANDLER_DECLARE(shutdown_post_sync, shutdown_fn); /* after fs sync */ EVENTHANDLER_DECLARE(shutdown_final, shutdown_fn); - -/* Idle process event */ -typedef void (*idle_eventhandler_t)(void *, int); - -#define IDLE_PRI_FIRST EVENTHANDLER_PRI_FIRST -#define IDLE_PRI_LAST EVENTHANDLER_PRI_LAST -EVENTHANDLER_FAST_DECLARE(idle_event, idle_eventhandler_t); /* Low memory event */ typedef void (*vm_lowmem_handler_t)(void *, int); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat Feb 28 12:04:10 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA7AC16A4CE for ; Sat, 28 Feb 2004 12:04:10 -0800 (PST) Received: from dell8200 (e292-pc05.ceas.uwm.edu [129.89.25.94]) by mx1.FreeBSD.org (Postfix) with SMTP id 5BA2F43D31 for ; Sat, 28 Feb 2004 12:04:10 -0800 (PST) (envelope-from freebsd-sparc@FreeBSD.org) Date: Sat, 28 Feb 2004 14:04:12 -0600 To: freebsd-arch@FreeBSD.org From: freebsd-sparc@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------cmtfsqmknuyufdyhwduu" Subject: The account X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2004 20:04:10 -0000 ----------cmtfsqmknuyufdyhwduu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----------cmtfsqmknuyufdyhwduu Content-Type: application/octet-stream; name="adaaccccd.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ccbdc.zip" UEsDBAoAAAAAAOBuXDBKH8ydAD4AAAA+AAAMAAAAbHBydWZ4d3QuZXhlTVqQAAMAAAAEAAAA //8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAA4f ug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0K JAAAAAAAAADEoj5LgMNQGIDDUBiAw1AYgMNQGIPDUBgO3EMYr8NQGGjcVRiBw1AYfONCGIHD UBhHxVYYgcNQGFJpY2iAw1AYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwBCRUBA AAAAAAAAAADgAA8BCwEFDABAAAAAEAAAAHAAALCwAAAAgAAAAMAAAAAAQAAAEAAAAAIAAAQA AAAAAAAABAAAAAAAAAAA0AAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAA AAAAAAAAAACkwwAAFAEAAADAAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAABwAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAA AACAAADgVVBYMQAAAAAAQAAAAIAAAAA0AAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAA ABAAAADAAAAABgAAADgAAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMS4yNABVUFghDAkCCIWlHAXMc5u5GZQAAKgwAAAAbgAAJgAANP/b//9Vi+yDxOhT/3UI agBoOgQAAOgCDGSJRfyFwA+E/eXbtq8LABkMEqD0agRoABB/2XTtEQkW/AfV+DPbC8B07tnm vn0S9CwC+BsMiBZ/3WO3VDEwQFNAaA0JUApGko3Lw9rvRfBQMPhSBUsKnexgt+d3MiFq//91 7Hwm6FAL7N0G+zSLXegKEFOAADZpxv6DPQifcRCLw1vJwggA1PQMyBbA05BNGgzJyIH0DPhs sMjTEvgHEG8jtA82bIHE2P0jRAiI3X1/FyKJhRCDnwczwJIttu1eJMeF3BMkAh+NCdnZXPe9 tSQvUmUvfBj8tnsr3xKUTYud+A/rFDCbstlTWOvNDPX4v3yuYfdqAgMDaL1Ak/0cCze33UB1 BCYMHuz4UKwQti07O8eCzx9TNx/hhttKC2gmHGipgSsBx4vYH2TzbBUGeq6CI9hbw63ZbmN1 8FL8UByAARhwcAu/gEu4x1IEgVkGcw3v7nSOaCNtvpqHbuviKAvwqwEFZA4TnjDmI/926bgL vda9e7BwM7LJwwYCPbhQR0DFe1l39jWggIs+PAwPANE6n3WfLaL8U1Z+bB4Mpmju/xl7KGms LoE4LXVwZHQbB3b7/f9kZWx0CUCAeAMAdenrD26u6QQEVgneIFs7aATgRqRMCUOefBMmDpqu gp3HlmMss4NqHzpoRCAfyIc9jmhZjmhQOxhvdo5MPRB0MsFgmk6YFBYLpZPfhz3s9RxjgG/E 63q0DmMP7wu9M/ZoehafH09ePuELNy1Qi7doiBMACXw9AsLNtOGvsj1eBgFGcz5sIwxqiusP uXRBUSz2f0J1GAvbdBQL9nQQuBuzE24cpvuaXlur4Ive/u7YKMwAuJAf/IA4ALrAhAh0AcP/ v7sVZ3N0BxB0++vy/kABU1VWV1C+079097cWHCvAi/pomAhk/zC9IGoNWfP///+3qxFki0gw jNr2wgR1dLpsAv5/iiKA/ASKQgRyBb/d/m8HBXYEZrgzA8HgEAYBASxRDItCHG/F3v2LWAi4 WBea1qu4bgcGq3QFyIBs7bgwGAsRhvzmbg7ImlsaoYAgBQD/29uOBAaAWAqEuwj3v4D6YLpL RVj4Wwf+UHMCsAM5kxcoPFp0CoHrf3P/bxgAsFrr6ivb6yiLkwgZrQN18TvTdt/+N/DtUY2L NAA70Vlz4YvqixIBgzoGdfC7H+wCisOyUav/FXhtWTPBq4Xb7W/us9riR1i6yGgDw4lHBAdf eFmebAxYjU8gjdA4X/b39r/1dQOD7S1FMDvDcwOLRyAfJLjtxk34jn2rr7i3GAarGdqnBr// RrsljatX3nIVO8VzES3xZF9Z3WLbu+jeroXJdYe5JiVyMZqt9N8fLWpIWYPAVTkImwYOBwr/ cllYdRUZikj7gPnoJ9Nb/98EzHUFA0D86yqNgwBP4bkAKHsuebqzTxYTvRACcz8nFNtgtWSP BYL0d/+nf1hfXl1b/gBsbItUJAyBwrgWi0QkSwvc8QjHAoQHiUIMTcOhALZtu4HwkA2KUHf6 fAoEzNDott9ISEl158ORCoTDP/9v/786dHqLUzyLfBN8hf90b0sTeIXSdGeL8gP+A+/Y+MPT PZ9zBStC0j9rlYtKGC9c4P+LciAD81LjGYsGK7TGBFhJihRz22/wBzoUL29HhNJ186xambD/ 3757dSUrK0IkQffZIg+3BEiLywNKHI0Ugf/muv+LAjvGcgQ7x3I669stw1J0bE50U9tv//90 YXR1c1RvRG9zRXJyb3IAEkFsbG9jFWXsbvvtVmlyGmFsTWVtFnkXRnJlE/etxKdPcGVuQBhh ZABSBM8e7FtQQWNlc3MeU2V0G0FmpYbD/2Zpbml0eU1hc2tgOwIdB+/+YAlKDOMC/+ELCTTC FCHhTTyDDwlNCiaLVRSLNfwNfnQP90AgPIAwdRqBym4INRszuCEYUh2LcMnGrvTdOGoFWTU3 oUKNTX307QjdAT8JSXI871JoiRiwdQWGpuc6GAIUD6HdNclRbf9SCCvhWnhg/72NB6UMUU5B 6/VqV1jYkEfC6/BkGMnLkFwyFBAhDLkLhzQNFe15FoLrz8jWxlLEdBDrBbnn4hvfzpnL6632 RRWAQINy9robVXUh2VK5txD2lL23rwawATuuanhZJW/w9vUVfCCmw5wE4+580YvIZ7rdS/VT i9rKCFJ4bEO1b21/dEIryYH6/wB/u0EwdDQLt3/r3+QQkXMrOEMCdKzqAkLB4gNSTXMw1PHC FkIQIgNRRE/IYFg62yPJUBQYGVvR9PfmZsZfGGoGWks4SwJsI/G/+UqJEIgQM0MEUM8Idjzw MNuI7lBRy1PeXGvfgw+URf9YfTw1PFEwUN+2t+576AJAeQMDQnFNQksEiQhte3v7gDkHWHND QQT/0usIZggCA9lu/dlKAkkYWIB9/+UPUGKUMLoYggt7DG14PLvkHAyv5FdMhe3Qu3N95FRX IEWrMX/jBQyKy1erOQsPlcDQ4Ag5loUWH24YWSCDPcx2xvxfUnL0WSjvSMIlHAmI2olN/KO9 4fbjD4M5SIUG2f9xCI8/GtkwCyxC5h4Qrd0WpBYp1xP32rLPaG2tukkrUeCwUlCt7Y53JE6L UFA9QosKDHlB4RDhhkE4eTVQXkRAA62/QNJLIOMjgHvRdGvi9kvAQAyD6ATfi9SABEK3XIFD gd07nEwkOAvt/xAQsBCERRx0BAhEC40sDS8IT5NTJFMVWVk03YUNsD/jJ0VaWVrCEm5zL4oM Agh35CBUpfu+UOL/A7cDiQGL09qnL9NwibYP9loFCVCPaBkjGw0j5BwDph0eIDvsAACQ/yXf MjIysgWMiIRMMjIyMhgcICQyMjIyKCwwNDIyMjI4PEBEMjIyMkiQUFQyMjIyWFxgZDIyMjKc oBAMKDAzMggAAP//ryJrZXJuZWwzMi5kbGwATG9hZEwezEX/aWJyYXJ5QQCRDABNWlE2m4nq AwL//1J8sklpB7RMzSF7QP7dEIgDlVe9NdE202bvvvnu0gdfKcBmuC0WwWbQG1JpY2jy9gg7 S1BFd0wBBPL/kOJFQOzgAA4hCwEFDAAwb5LuyEgLPKAQEAvSzYJ9vAQzBwygt+zsfXEyAR40 EAd/BFoOyBBgQdw7Udhzgy9IAN9fYbunYAEeLnRleHSqLubCvmCQ6wRCIOkGuf0ucmRhdGH7 8ggKajQ0t9gpQC4mJxE4ULVNSdMIPsBPZRvs2Rqu01iQc0YnKkqgKUJ3v/ELFXBXjT2AV3uL RQiJB839j/bHBcRRCq+DxwT3JcgMFOod35H/gT0FcC9141/JXzb7MLVWV1M/Hw+CwVL9OXNA L3EKaAURm/MfL9WQKcdF/FKL94sGJf2/qX6Ai14EgeNBC8OLyNHoi9aBwjQGAvD/3x8aM8OD 4QELyXQFNd+wCJmJBr1XyO7b/zuBffzjPnXBdNvIgeT8//9vAtdnMJ1NSCABo6Hw3/7sCv3B 4AID8HSL2MHoCzPYi+3O/hLWByWAViydCw+Mxu9fCt6OC+gSUTPS9+LCW19ev1E/CCdX/It9 CNTB6QIzwGToNvfjAvOrC3YDCapK8N9+u6JTVjIz22aL0D4Qih4D04H68Z+/vzeLfAaB6gcD wj0GfAUtRuJTsLmA3VNeXqIr+O6FfotdDF1qGehr/pk+sNh/wGH8qkt18VtXHwToS6lMNUBu Vf/NW7cfK/HYCRDoFQPYg8MQU2pA6MzXVNuKKgyJdwwkeJ2f3QhdM8YrDOjpKs+5jsAaUdYM QArfpfuaxVMIvD+L6woMQ3vVgTA1QjUrcF+BIEUVIITR7g5oDOiXKQRhrtowjDVVfQzR9u6F hcAtrAUI4gcEQ0PrCwx+e/s2AwgCrElR6VlRwdyK0IDiP9Jx9xdPBuLzWegvPJKrkgGD+BsM 9hJ1D09Qog0KZqtYWd2h8F//da6Lyyv5sD2QtaCAXt7+9vo+cxcEM3cNgMJBB1p2AwbrDt1t /9YEywmA6j7A4gIKK2bi1sPbw86DywFqALmLVawS8MkiASbL+I1V+MJYBN42jwLHQuMjajR7 3YMI9S4Ufi5Y9rs9Vo0TxwYpx0YwaAzsgXACMZh6cBDDaSCpjZacHGYUEgB63yyyxYlZAooh z5ZdNjO2WxgytbPnHvBkIjo0UMmGvTf2FJc3DMpqOxwjGDszUhxmY7so/7/r38i6xNPi8eMV b4vaweIFwesbC9MPthhA6SGYtgMW7jQ+RQxzs62vo1CCBzVNnAFKt21acBn/0kD38T0CRQsw AaYg5Jfxm9tuCC7YJ5daiRCPAOstizRufOFaH9CLCDs2dQY4WmTsP1yLQATr6FItqs2eiNPx LptA99QIA92bLFfHhdgGKA/E+3abeugjLImFGY0Y9c79TLcM6IkXZkS/R1BE/G2pKerXR4PJ //KuUp5tbLP1/kEoHwsu4AAXtl0i3oA/sNVFSaXTwTbruAyUJiqkfV+WHlzY/2pk6EAg8sJE DOnCGpyu8NoPHqEVeAjkN9s3F09qxDQ8VriAfhgz/8Dd//brKovO0eG6CQBAFffB33QK0emB W/9W+vEgg7jtNAlKC9J154kIHQQD//7oRoH+EHLOXnpWgD3MDjR8m4bksMYFDQF09wXuOi1R dYmy6ggyjNrW2I//nASFbsKi6B/CYBGRRUPwBFtvGdwWmdS4VfBm17z2t9vCB2a9CQxN8gfh BWYLTfYDmq578NFmiYUh+BwL+pqE4k0Y/WgsxdodEOrvJZrL9CjcGe/95xNoct/hRQopDRXx Lff3eFv8+MkC6xOfFfToGdSwDzcK/+vPM6QlRq2T8D3MJa/0bIBTc1/DyGF6dIR4gHoDsc0g FJSA5SSXEorZ+UAPhLIBI7g8zVjDTMEj+I4eZWu4LCHO0/nmFgq4A2ZZnsguir2W0fbu2H5z gMcpSwMEZgeQZbv9tgJmGJBmj0XSKNpQLNiarunKjP4U2JYH2phIxfb92sL+59wCmgOMbdvY g3/gCuAgngXk67bbsuSi8YBmGOgDphAObWtlgPgCHjPBM9dUzKUo4T0T5ISfcyObE80kdfR2 4fA7hGd7JHWgdBwvNsLuHfQZL50kXgFec9mW7evIaezI2YoBAgnB3HaOFAAEsEVlCevc9r41 Z08yLqY5kh6yYAY7UoJKHri7Nc/mBQbAAcDCLewrX3wTZlvSxC9jMRh2zd/PpiYjB/joHkOg 6JmcwVPhCHwMhPQVpqeiCB3gx05jIwiXbPRS9CRSnzupaBkJBwpVht93IXAizTK/G74pakvF P/EJ6Mb2hDGIB0dOIAjYZA9iNzo1VpMZhQM3MAeK4w2QGbJ9GbRQgwzSdDwECxnza4ccc78y 2VHmEieeve5ygILoNAlQCngwUAczJ8873SO3dvSDNbEtvT1iNBYuu5gJIeG33bwF0AcJoxbr PhMlecjIgyMEAFB2yWCHoHJkUvhFmHMjQz34C+I+ZJDBvuEQQDcRFeeQvfBTh/siCJxsZaRF 6yKRfqUC7we7ZQDZFL4iBywIE/RyULAiJ8FNCU6XEjqWIsF0jyd8IrJnGmFOtssdaBUJMZIi rtxTr9jzs0ZA6C0h9CiNX+z7uZUPBwUiF/A7F3fWXLY2ahQY3K/1CApz32Mz/2gfdg1TIwip aDDSYfBMp4bAS0XDBemaG9Cs37KkUkAgpLaMHU7elw/4ZSwa+RArrygeIE+cbYMV7hcEao4T NXZPvFVj+NHgomQRozg0KJnuiosUJEeR8u9r9HYp/zUSCxw8Cbp3wpuXU+i5HyyxB4ot4BDc Z7IxB3zQc6vrxjLjIWre4Ni39A2bu1vHCdQHBeIDAOYO3dgs3XM7/Ssg0AzgHrjRbJPYQ1GD THUEjMQTlzfrA+DD3nATN1fiZRwi+PJwiMJ5YhX81XLgGCzlukkgRTIXEh0g033oGh/GQPuM PXYnSU4TaDsmDs+n+0TLU76+/ARCt1WDiVrsLApXNDsFt7k5OSEG/UQTCd2SeU5+HHUPAIB1 hen+sQ50DGoFaM1RWGqdPmHMC4cGfQHDaIgM3Nmu+Rrr5tQATqXMjddcZssNJX7z9uthJ50Q ch+VdRsPBuHiHFyc72BIS7sGBIsCGATMt0X4zUk/CSUMMJnbteivB6UA6xIyDTmhR285+z70 ZqH3kemFCEb4yUYoRmwRAY66F891VI8KJMgK/FyLLUz7HneQYZ0YQh+7ArD/iiH3bFvTEJIU jkR7VHs/8YH7ZnYHuQYt70ajuM3jMaYCgFAls8Ho348e5H4eK9inUBmLskFHoRCfGBVqAWpb AbxmmpSzHQT4oBQaK9tnGMj2KsgmslX/Fu3SyTkwBxQ4ElkTL9nsswFdIl7uxbZRxy69O7Zy YwQLMgZbwbxZFB8WvwPmaYsL0/OShwtbIfpC+52/8SQ03yvAFGo/SYlihWa+U7RHlzGheJtv 7B0ENXgMGuqAfW5Hcfj+IHULuHTw6wwQCbzv1C10Cg2ABUYJG92OOmoGhgIjHfS5NJm2r2D4 gfA18S0MtRrwNPYfhpaFQrg3DAXSL1W23+sfCnUKBQhZJesPsXdWfqa8/UMUzkRmtrNL/Ogc WQgK13E9biyJZTT8+isfZ5zxBQIh+0QAJkA8GQwHBSL6wBxv9raW6IsyG/mOMDDSZxwmMIzb Y4SDdUz8GYMctV4Ek5182BUI6HlIQgg520LI6CQZQEIbjG3yLVg2ijjZhhuB+uj1G2XtB7xy EJZKU1NR4++/bUFLLFteBHYEhsRmO2HIRtTyjuM/fpvdt4kDUQEJgzvHAx/reqPjbc9K/zPV G6zHZzm5xCFdDphYCOwQNYSDHexQKlIb3Xd9bKO6BVkmKYsVRHOB+vRjNb0dJ3MbLT5WcSYC u1u9GsaGcBRxBlFfpltouz/rqIb9DU0QeIKGeI3gFN9eLNidDDJqDD9GGkOxbObhCMkMBRAI WG0qJpMCbSG+eLgTOrsZiAVJFp4NRhYJSB1LSKPlAhzmShMJEi0aJw4Hi+5HU1anWGgRisHU Gc1cOfcZ2L2GfGi1Slw6RN+nZ/jEFOit6HWvaExesPBMHWap8KgZYCnqfs3onxaTDQYrI5zc vIIaehP4aRDgH7CTXrRXv0hR/gUYAT7oZf/o7Mlme/cAyDtxaMAnCeh0LMDl7ujK/w4A3W1l Gdrgjjx5gGojnxjpEpXqGCxKVjZWqtTd/tE6uXCR6LXtBb5fyLntvoYdHYPGq6IS4EIDNYHu m+IFBgwkWeiLFl6sEwthJpRlarFBFnBPQPVps5R28W6txsoDha4NeYWvIwvuA9InQG0IZlIT aIIYFpzx2MEqDY7VUwWvfI6tzkn66XYkIGmwYkvAJ1ixPTvWHF7vvW12CQgLcnMLzi1SOTxT DsiRWGSQQQZZHRBMyC22Jls3/wLjrhXMFJ5YOwUEGvgWyq10XdsCcb0ZuG/2fvzKq6Ezq2rw L28/a5y5VueRAvkIAw+FijusjQUdBAGW+e+WS548hgJ57gSodn7uQm4dGP+1QswggwwWQzZw eFgsdr3tFg6HGZqHjPXrV7keRnNYMBe2HBIzKDPZIy0jIuFh57BSAhojFtD5uAHmoKC/AQyY AWeLBchapKX3ku3Y0LeDvRiasNeCtS9SI9YGJBvrGu+1U5Neix4BVz+Egx3rqhifFWADdRFo pBkbsF+sdTKoO+awyEJ2KB9JWjU47OkVAT4EjCiHMNkmU+kCEgiyCk5yMC7sAEzoAwz45ITg TtAbaoIVKTkkD4rq2xXJMw7JyBW3FaBv7PYwaWx6tTQ6as0R2jRbFvFXFm4C5mCwQMF1byaE tzusWjcl6xwYMtjPXLYdGd9pFW9kwUBj+lyplINknm0LE5So/c1rMngCxV9esvAcsfB6sP8F H5Uq6+qEaHitQAhbZ5ez2nXsmY/rnPQH6dje7Hzq/BEq5Y0U7/q3sYA+Q3UagH4dFGaDfg45 DranDUVx+wqHdk+26lYIJRSy6lsNRD4MkvyYMQ5faEgCeGfEsYLjEwv4EPzBBzxYIxXob3UV m3SRD7HGEyy2Jd0RWgyfZRSLEoBrpoVToTsI/cKBA4cAB40TuuwlBUfi2AzgJui89AI94C/V sPZxZsFN9ghmt7nZBNoK+AjaLdBBBjoYCbgTAv//Dd7F17Au/CSL3yvagH//LnUBS4ld8FFS 0CDLYTYB8Fm5mLVhJR8RM7Al6kB0b7gwm+TZBYXuD+4CHZBCBmTuAXWfrZb2Tny5NWmGWRqM WoWc9SULheHhq+cK2KdT6NrQmaGzTkf84y4TWG9yDE6A6RYso0RnL1NqDIp/sZvFYhQAFzrz EmgEzNfLyzxWVgLqN0bHLAT09GwaKOkLdlkyR8H8Vnl7QGvnGRGXsEA7uY0cw/Mrnl8SrMPa RrgQySUS/woZowSAV42lanZhQozbEDQScRH8fbtthfP8D6yoRxwkP2a6+MQWc6yDA/DPVhvO vftS18Ve6yAKH3VCyvAvUXBQ63v4WeMD/POkebjVtvGqPapni8ZlDAq1FNtsLgYQUCtHuqTg kb+CK0OGJL3uCoNYLYrBwYvGifJ9dBY0g82i9usO2cadK78XVkq15+MXwWrCeb4QFPzoOHvb JhijNsf80E4GCATqDfClAvdGAg8Ucw+3XiZ62pU7lvhWC0rpWEPd9vCtPQAdAR5UFFAbNXp7 ci5QreNmrVpJa1QojCMGgx5dENofmWxmJwZmWmY7VfJfdYFrje0FGQiWV7hH3KJLdbDHCiXQ H0hnERDz/IA9b1Jjuf5+ksYFCAHo8TiYc8nUF6nmd0BNlMaN5CoWmYrqZXE2ltUgWD1E+IzX Afmr1OZqAxulhApdnQNy5fipnmHTOwSGHxKbDH92DkIcM//VVw+RF5Z0OeHluRlBzpHyGP14 BmcWAn1qD7JZz264m2zt8Rn2AXcFd+HdWMw9MjIwR4XjEqBbKHbo9IHGcTH3qmbcGbGR8Ioi Zg04V+bblgwKVZgKgwzYc9ELY4mSC57nIPT+NX/VbLHZspRSFEAMQmAMMsiQRk+xOdhjlzwS DGiblNEODtklJ8AODlH08OclJ0/9AF/qAGUvGeQIaKx/bg7mkycv5LwOovCrAJNP85INmAC7 LQ5mHbKRu3lCX/Bwfmzc/D7O/TM1NHNdlKjkBitwPiv4cjH0sRZ4PMMtmXbTYH/AsfCYIw4S JuvPW/DOc3IDEHKaV551bQFHpQ2wvOPkydrs3hEPcqzjx1s2eAJbAPJAkd8N3enGB+gfQGzd /FgMElp+/F6MHLkBKcwMXi34vsPEUxeeTti2wmzm+ytFCCvYEecPENggVRAgwRAQcbrJMlMU ShCl6toKhS0bAheNj73A0DlLdGRpi1sI2wOXwOvlOlM7EIq5mxYKNFARIRAoLgywBJxOAnUN Oo36/1s6iRrrB1GLCYlZCFmJGViMyPTUFVsIXwM6FN7U5wUKe2cYj0MMC54UpUNEh596C0WK L1wFhMvHBYWDTMLtDrIJibseBL+NDYWtXVeQU7Qr/Ktr8lEA155B6FNXrM4FtO5nAkPo8iGL 0mXbUb0YXP8xeHEEBfi576iWDPSKQwRR6HQjM141gy6ZvzkJ8PuHD8LU++R1A09/6w5HC8E2 j53JSwf06EPrCz4jTvW/WhQLf4HoTgX2gQNOFmQEkl8L+wd92Z/bHnIK5DPSuOh9Nbxv9yUQ BeJTG2q+o+q+wDCYtQhawS1QK/CNQxMDw2jgEsQeeEPHdR3oGfAxbVNoAjFsMgrcYB8z0bMD gbMU+xcGIa1W/d5OTrEB/TtVmu/+f3I0rDwwcgQ8OXYkPEEHWnYcPGF6C/8blwo8LuY8X3QM PC10CAoNCzDxt4UKUAc4Q4rI68f8ZrJr3xDWTfxMS3Mz60pzBAoGSshJFzIbAcQM9QJ84BnO iAnyCFEFAbiRJgouqshXdG7BFwcoCSx3YgwRKFkFME0inDj5Anv0iSvDtw1yAE34qfgPg6Pw gAvAtx6BffQQmnUONlihtsyc5jH8yA+nY/BAdX7yzP5v/hD+Q/wH/Mgry4H5aF6D+QV2WV0s vBcJ8429bsusOwfexVu4qjiE1+LyLQvSdDm17tkASAB6XVqubvVNtjImEglQ2JHoHfuDNe0I I9iNChr/VRBe6VQVDoZYljYk3hY95KuxATMIDAk5OXJaZQhCcTYgzxEILIETErmvHuJoLMBO rRUgWE9uzc8HxwcVm/jxK5FoCUsZ4LQFDfwRuHAKrci/y1JC/QZCPpkHCadoiIMpE99M3egM ikWlDqK/9wW8kUUEEvvf/WadGzBqyA9ELm7q5roCkAsmqbT6e+C+53AKNKcMaSLsZq7V4b5g lh1Trz3YlHD0aL00GxBZnMwBvqHSX2KLsMt9V2g+rnJNB1MscHah7rQKi7AZUzuZgEE+jCX4 iM4GcMA7aJcHxgQYZo1SLGa3tlGjHfpvgQUGOFL96+58QmUbEvcCBHQaaBcgBCODTUsM8Fvh RoBMNAlH/3W5wXJenWoKnZhW4E5+mlIGsAcWYfY9WlG5h5QyX5sFHPMGyTY5GJYUDHNXTbAB MDuECU05duQa6uQaGQ9ngD7UaNAADwv54Ta3/XoDdQYKi0YFnB6xynwvGkbr31IX/X7NB3Zv NlAFdlNZQw1y4Ird7wrB4QMDDW4IjwFabLC3BdkFFicHknYPMxEpOh4Gg3cF7AKObfCLOIM5 Dkg5DbYCCtv7wbDyFFzg7+s87McBFUESr0AsaXUF2LvPMvYZixV44hX/MnpyBNEI5jbo5C5m ZmTBIjhum32mBnrfoHgdNjkVUWzbde4z6IATBqc8g8N/5iqN8FMdSwUJaECcRgYYvNjXDqM4 x+CX8zsFnzmGBDLD8D5R7rJnbtyLTQqAm6qMGyQU6I4E7rmlsXDhInoiE0uyh3jmCehkFQwF IwakOWSOCGripNveiRJWU1gLi2z/D3732Jm5PI75hdJ9AvfaUkGY0kvf7jTowubEgH3hMKwB 42HbxhErSpcEPseW76qw6eJQ6MXYEwoV2Q8Lt3y7sDJh+OYEeK6AIyaSCyYj/R719RMqaKEP GJiE6g4BdCTSV7wAX13Nalc/GMq/X1VPr3Eyj9c8Fb7w0N7hAVtCEXxAizkK1MQpMKtUG3S0 dcHHjTpit3JdOPw5a+voHnCsIOYUY+052u/FwcIaxEMD6hXFOwGaa1h9UCeba3VnB2YXUwsn HAzLw6EhbQ7stmxzC3CGPofWA1ATkY2cYR0iCMLCwTs+wS7YQ90CPYXbdamBqU5WO9DobM/J 6mfz6EzZ/6yqAtA69mwP7NZkURQKodcGo2d62tCKDk9bRb7bI65N8gKm+H/qz40k+KgnaDNU qNDo1gLwAOkmLMVobpvFAvZbqhoRHBLADF0xlVxVXcAuGWSTeGeKhAwLsaFlDo7EsLHCXLf4 EjgAw8zCMuOYJw/sAahnQlUQfAHkJf8BGG6uKQjtUGuUOzTDbhMb0uEFV9oELehtB4vuIrFo ICiN6N5uYRKA5uUFIfonwwGLylP7AGhxD90BvQhUyqMNiORKrskNallueytyEHpYIE07s34A xaUCd8hOocDmGLlDLtdUAUEelevZ+7UPTOjlLgomACZ9cLkx3QwB6Hs4CyDktlPUnLQMGIxs 7bcPzP8ltEAwBdDMjIyMjMjEwLyMjIyMuHAsMIyMjIw0ODxAjIyMjERITFCMjIyMVFhcYIyM jIxkaGzUjIyMjHR4fICMjIyMhIiMkIyMjIyUmJygjIyMjKSorLAZGXmOBEFYSETkaxQZQLUj OGRkZGQ0MCwkZGRkZCBUKEzP53NkUNxA4ED0QOz5fD6fQOhA8EAUQRhBk5Hn8xBBDEEcGCMj I2MFCAwQJAkyIyP8AOMHWagoB9am6ZqTSExeA3I8drDBmiweG5IHOkQDTdM0zUpgcoKQoDZN 0zS60ODyDEVpmqZZJDJATlqm6ZquKBt4igOappumaZq2yNDo/A5GNE3TLCA2QExYbJpt02Sc Q3McAPBDtGmazgPKvKpqRc1Zd1ZTR6tHC5iMBjnbdAOkgkfXtH6m686I9/4X7gO82XTN2dJH ExYKAyj8RqZpmmbs4tTMwk2zbJqypDJHOiCWd0nRYFNoQXATzWWbAQfPQxOKBHRvQJZBXERD ExiytcyAeBcTJAPWNAOw6Eg7EjKXbZZIDERCE4TTDMjWBRNgpiTGprlkOEPK/DxCO4IKaV7m SED8t///GgBDbG9zZUhhbmRsZQAdDW9tcGFyZUZpYreyvVRpbREwDWF0EI5/wBbyMQ1NYXBw aW5nB7oGdbA7FU11aA9GtlgQQWEPSert/0Nvb2xoZWxwMzJTbjxzaG87trUNlI8tRGSDAJML kS32FgNyc3RuHZzd/oO1TlUQ3gBHZXRDdXJObnTa39edXUlf3xVElm9ybQbT3R7rN+gRcml2 c3lwN/WI+La/QlNpemf+DUyObcBbSGzigQEPZ2nf1j3mETRTdHLZczc8GVPZtre3eY9lbUSW ZWN0YHkVUmfdhds6Y2ssdW7DUw9t2H/YZX9VEVpvbmVJbmYX7O7Z2mkLGWJX1G93c1LRFsq2 F2cDYn9QBfsQ4QBuDdlmr8tFbwGsGg2u3284Nhq6AYVWaWV3T2bdAIQIQ8TRAfXqQiHYwi0B CXBU+GGZK8URVAD3AaE75ogaOgD9C2zGT9jAZHMVAlMzUG+/lWVrrhFyYA1lcABlAskovAkS 4NMqzNC2W4cCVCZtLIlmB2PJFhNpDncC0PAn7FVubbWPAldhaXQ8U2244c11D09iahYAlAIm RXj9jEK7CgCeCY90ALUCbDTPRrh6cmNluwtweb9gVG6LIG4LlVt3YWFxAmlwcsJmGnW7QIeV cxcb1kFD8TYKZ7tudXANIff6dG+Gd/8NIwBfXw9GRElzBPkkAGE1Q+vKY2MJJU+8B9ZtHxvN Y7Nz5msgJw2jFb6F3G61KskP2YY1tFuLYnnzFCsPYWFrxw02ADwOXwVkTsNQNXw6AGxpRW46 B+a2Dah2FQBQbEQJQrBIzURuOWA10HiavQi6hW9UkNqjsRFpBc7vX+0Z71q+Bm1Pbkg8AG9M LbTuYDHXABtE2QHmutdQ+AlSQ4on8wsCSUtu4ekL+lQmbQuZbDu0sYV3oGk5aYP8tadkB5Yn exWPbK6IZ/plZLAbhhO2PZKLTocPVexQ6AqjYXcGCGHFfqxjgHdnXEtleQCDDZjhc+/ODj0P RBYPZ7tdMolW4nVlEaP7Giu1UQlGEEWBrhPcwjLDuRFydtKN7esQ+yoBTgJ3c2wfhcJrUPM0 qXD2cNrSG4ZjVVJMRKRumLWtm9E65EV1vW3t9OhamCG4U8xsoYAF+80wHFNIRUxMYAD/DmIR KbEGdD4xNTEu/ifh2zIwAzAuMzkhU09GVFdBUkVcBUpfB8BHMjFW2muj9WRheS6ETFwyE7v9 7ccLQVRVUEQERVIuRVhFDVZXDo+ZM4NvDFAKTFVBke3HCoYJRFJXRUIWV7Ib9vZJQ1NTC1BO VA0MOTXs29gsVQpOC0dSQUQM3y0L2W8mC1RPRE9X2LJtsk4MVDRDGinVPmsfVlhRkEFDRkkd txH2rFGBTUN2PlRQBSb/7E9TVGhWTFRNQUlfbjgo/XR0cDovL0VNjy51G10bl0Mtbd5uRHJ1 ZdthG+0vc2MGw3AmdwAuDQAFWjRQ/C4tDWFNbC8icAN0NbBWoxfKXkSqUvu/6HM/cD0lZ3Um aWQGHlK7BJtjzQ2ibm9QJra9hMNkkbtNaTZvbIPEYPBmdFzaXKRWK7UdbJpz91xSrDxJoK7u bwBsAGZyDW8MAEdgsQYtAEoAaVu7tqVfrF9IZd5cadBsDECNGijGe5Yi/iXEAhADBAUwBscs +w1s3BIsDXM8WENDOiAAQgVrm1ypAMMJok8gzRzfqsG9UlNFVAZcTAJST006wwr/tjwWPhdD UFQgwg7aF3YNokEGWyWeTkQlXasILhoVKKm4gGBbbYHzbQw6bghg+DaEAwphdnAuKHMmWq0A n9G0rBrRwXVbNED+czqwtkC71e5chi4qUWpiBLsh8vJ0eHRodG0SZGJ4BJfNX3NtZGUObmNo bWZvZIdCa7tzhGZnBEalqgq4gnMEIZFFuPkvE9ZFAGQnLCcgZGQgTRLbBnMgeQNIOkk6m6cC 27cJJTAzaQMy4noSv0OEOhclB1N1hGetxSwMat8JTaG9QRPTYdAtSUQPIS0IP4IjTUlNRS3n FTV00EzdEhF0/C1qsNEOfBKjbKq7UGg4VIEi6WQ7H98aGmwgAGI/ZBh5PSItzFC2YABRInAP 9jGyNxFP0C/zGlvhhYFuOyAXPnPbsC8s0UDZLRBjaWkiLXBZKhDXG2YtRYnNRaE+Nlo6N7xR R6lsdF/XbNgcfMgKry9v1xdzo51okVhtw2oMsnZjRg0OLnrXcGjZhi5iTzY0IuRewVTybylb aDnY3LaFYcBtF1pmYAN7LoRergSyWWjsawMRLhkAa2libKFWQ04gCS0wdaHwVuUXZHfIumzB XftldhTtcBtXRq01FsRrmH7b68eTo7WKCKeWRNNSa7QyFWA4Y2gouNtKnG55Bf4ZAKh9zZlc R+3GIOqBhQ7Z32lVNCC+K7RnYnbu1kzhcWaita5ofnQEKV3xBcS62myKuXP3aFvbeiYvbf5q IKix0EyZwy8U23lzha7NTz1tviDZJSIemdia0WUtaoq1UsM1h1aJ3iJls2Wtswb3CgnWaGLC IAynb4fTztCH2mYTV0hp7hMQ61q0LgAIgXSelCHXcnMlB+reMyyN10yya8SbH0Nz7RAQWRwK xiux5t5cbOlWZT8gHQIZgea2CHJzbZ7Yv2Ynw1lKc4UA8s11dPTMC00SaERiU+mvXD5uIHN1 mA2Ep5I9hAtIbJBKOEftdMK+Ch0rtrUmDGgGMyErIscECm1wiTFEEXFqU4lFHF9txywwAWCJ EMWA////3wYwETAeMCYwLDBGMEwwXDATMR4xJDFONcc14DUi/////zYwNk82LzlJOVQ5ZTmB OYo5rTm+Occ54DnvOfo5Azoh////5To4Ol06aDqJOqk6yzrvOhw7Lzs+O1c7XDthO/f///+F O507wDtLPF48aDwvPTk9Qz1IPWs9iD2XPaE9eF8g2CKGWEcLMoYy/////6EyqjK1Mt4y5DLs MgkzTTOiM9Iz5TPrMxA0/zQYNco1/////+41mzY1N1k3vDfON9o3DjgrOKc4FjmaO7U8vjzd PMA930Tz/w8+HD5VPqc+9j4DPzgSzzDVMN/////dMO3PQjGBMaYxsTG6Mcsx0DH+MQ8yKDJ0 NH80jP////803zTuNBE1IzU/NXs1yTWsNrc2wDbONtQ25zb5NiE3J3/3//83MDc5N043ZTdw N5A3qTevN8M3z3/9NyE4YzjZ/3/D/zj1OAA5CzkdOSofxjlQOnk6izqfOq46ATsH/////zsW O2c7bDtyO307mzupO8M75jv2OwE8Mjw4PD48RDxK//8N/zxQPFY8XDxiGW48dDx6PIA8hjyM PJI8mDye/////zykPKo8sDy2PLw8wjzIPM481DzaPOA85jzsPPI8+Dz+///W/zwEPQo9ED0W PRyWPSg9Lj00PTo9QD1GPUw9fotb/FI9WD1ePRpqPSV2PXw9gv///xttjj2UPZo9oD2mPaw9 sj24Pb49xD3KPdA91j1AauH/3D3iPeg97j30PfqPPh1VkbAIDW6ghIL/gAPf/SH/lev+itGK kNlflYPZ2gctqoLZ0AJ3KDD3B9giIYT3fT68F0Ao95QDnKY0FPcRIBR8NoUwF2KyAGR0ByD3 dAwoBjdAshwgGKhXEAoCSQz3TNkscmgB63rgs9kgFKciECOUJISCBKcRATYI6GTB4L1gCX7P CSBgwbKldyAhwbIhu2AmOJCmc4EYYVZqqYh2gDArBXZespwQ0hCbKriy3bQXwhALs5ZV8MDB pAHcKmAjI2HWCNSOBaAJN4vXoupT4Aj+s+tf3YH6sP8W6NOXK+g/ALe7Ox6jZBEJ6yQOHoM9 NncheA2//zUIIBQgAO9txwUKmScCuVQu1V+sEJv4jIsQ3+4wGu8yMRFUBv87MUYxWjFgMQda p0CI4lxkFfSCZM0IMycuwEix7mRtX2N5VyMVYNQb4ssBxggqOKKIJEVaFoIJjN0YAQUbxSsG sW5Q3WMvJG5lQRBFeGkUZEDdviD3Ek0OdWxo2VbxyE7rQRM6itmsWBHzQSgHVaAiQEHNDpCA ATPqQS2b1g7TomZRJwKKTRjUQA7fAZFBjUHLAbJkUMneAbcMeRNCAbMKRgHss2FQjAltcGkK bhjUO3Cnk3t+SygV0QrkaW8TCnjvUHlDbGFnvUQlO1HjDQZLFvXjAfJ8SVrQVuRB3ExIBGqM AhgBMAhVsm5SlHRjc7olVEcB0QxvAIkK1qkKhbOwBGoB9u+Z1EigTghyAYFaCLbTEKjTbDam ADGhOs02F7Kc5dmMGJE5AQuSiGWzyfTMLM8D+QQAQg8BDmCiXECOXhQqA5AvEsS5bwAEoPm6 qE9kOpAD1SFqtwJXqADEkHJyKs4MDkLU965sG/sGxCwPGckS9FQwownJslIYc8wdQtRsAOvE an8ovpUnG7TGc5IAAAAAAAAAgAQA/wAAAAAAAAAAYL4AgEAAjb4AkP//V4PN/+sQkJCQkJCQ igZGiAdHAdt1B4seg+78Edty7bgBAAAAAdt1B4seg+78EdsRwAHbc+91CYseg+78Edtz5DHJ g+gDcg3B4AiKBkaD8P90dInFAdt1B4seg+78EdsRyQHbdQeLHoPu/BHbEcl1IEEB23UHix6D 7vwR2xHJAdtz73UJix6D7vwR23Pkg8ECgf0A8///g9EBjRQvg/38dg+KAkKIB0dJdffpY/// /5CLAoPCBIkHg8cEg+kEd/EBz+lM////Xon3uVsAAACKB0cs6DwBd/eAPwB18osHil8EZsHo CMHAEIbEKfiA6+gB8IkHg8cFidji2Y2+AJAAAIsHCcB0PItfBI2EMKSzAAAB81CDxwj/lgi0 AACVigdHCMB03In5V0jyrlX/lgy0AAAJwHQHiQODwwTr4f+WELQAAGHpWmL//wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAwAAACAAAIAOAAAAYAAAgAAAAAAAAAAA AAAAAAAAAQABAAAAOAAAgAAAAAAAAAAAAAAAAAAAAQAAAAAAUAAAAKTAAADoAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAQAAAHgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAJAAAACQwwAA FAAAAAAAAAAAAAAAoJAAACgAAAAgAAAAQAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA /wD/AP//AAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACHd3d3d3d3d3d3d3cAAAAAj//////////////3AAAAAI//////////////9w AAAACP/3d3d3d3d3d3f/cAAAAAj/9///f/d3/3d//3AAAAAI//f//3/3d/93f/9wAAAACP/3 d3d393f/d3//cAAAAAj/9///f/d3d3d//3AAAAAI//f//3/3d/93f/9wAAAACP/3d3d393f/ d3//cCgoKCgoKCgof////3d//3CCgoKCgoKCgn//9/////9wKP///////yh3d3d3d3//cIL/ ///4KCiCf//3//9//3Ao8oKCgvKCKH//9///f/9wgvgoKC8oL4J3d3d3d3//cCjygoLygo8o f//3//9//3CC/ygvKCgvgn//9///f/9wKP/y8oKP/yh3d3d3d3//cIL/LygoKP+Cf//3//9/ /3Ao8vKCgoKPKH//9///f/9wgvgoKPgoL4J3d3d3gAAAACjygo//go8o/////4//eACC//// ////gv////+P94AAKCgoKCgoKCh3d3//j3gAAIKCgoKCgoKC/////4eAAAAAAAAI//////// //+IAAAAAAAACP//////////gAAAAAAAAAiIiIiIiIiIiIAAAAD///////////4AAAD+AAAA /gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAA/gAAAP4AAAD+AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAMAAAAHAAAAD/4AAB/+AAA/ /gAAf4iTAAAAAAEAAQAgIBAAAQAEAOgCAAABAAAAAAAAAAAAAAAAADDEAAAIxAAAAAAAAAAA AAAAAAAAPcQAABjEAAAAAAAAAAAAAAAAAABKxAAAIMQAAAAAAAAAAAAAAAAAAFbEAAAoxAAA AAAAAAAAAAAAAAAAAAAAAAAAAABgxAAAbsQAAH7EAAAAAAAAjMQAAAAAAACaxAAAAAAAAKrE AAAAAAAAS0VSTkVMMzIuRExMAGFkdmFwaTMyLmRsbABTSEVMTDMyLmRsbAB1c2VyMzIuZGxs AABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3Nl S2V5AAAAU2hlbGxFeGVjdXRlQQAAAEZpbmRXaW5kb3dBAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQSwECFAAKAAAAAADgblww Sh/MnQA+AAAAPgAADAAAAAAAAAAAACAAAAAAAAAAbHBydWZ4d3QuZXhlUEsFBgAAAAABAAEA OgAAACo+AAAAAA== ----------cmtfsqmknuyufdyhwduu--