From owner-freebsd-arch@FreeBSD.ORG Sun Sep 7 02:10:07 2003 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 4D6EC16A4BF; Sun, 7 Sep 2003 02:10:07 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B78F43FFD; Sun, 7 Sep 2003 02:10:05 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id TAA20214; Sun, 7 Sep 2003 19:09:58 +1000 Date: Sun, 7 Sep 2003 19:09:57 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Doug Barton In-Reply-To: <20030905140628.H90946@12-234-22-23.pyvrag.nggov.pbz> Message-ID: <20030907183531.V3442@gamplex.bde.org> References: <20030905140628.H90946@12-234-22-23.pyvrag.nggov.pbz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: RFC: NO_FOO knobs in make.conf 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: Sun, 07 Sep 2003 09:10:07 -0000 On Fri, 5 Sep 2003, Doug Barton wrote: > Seems this topic is a perennial favorite, so I'd like to establish > general agreement on a policy to deal with this going forward. I propose > the following "guidelines" for discussion: > > 1. All new knobs, in all branches, should have WORD_SEPERATORS between > distinct English words. This aids understanding of what the knob means > for English speakers, and more importantly, those for whom English is > not their first language. That, and actually having a standard are the > two main reasons I'm proposing this version. Does this rule apply to non-English words like SEPERATORS (sic) in the above, BSD in FreeBSD, DES in DES, des in des, RELENG in RELENG_*, etc.? :-> > > 2. Assuming that adequate volunteer resources can be found, all knobs in > HEAD should be converted to the WORD_SEP format, and compatibility shims > added, preferably with a suitable warning. This should happen prior to > the 6-current branch. > > 3. At some point in the future, the shims in 2. will be removed in > 6-current. > > 4. The shims from 2. should probably not be removed in the eventual > RELENG_5. (I'm open on this, I just want to be sure we get it down "on > paper.") > > 5. Conversion of the knobs should never be backported to RELENG_4 I won't complain much about the names of new variables, but changing the names of old variables and adding compatibility cruft to support 2 sets of names are wastes of time. When you change this, don't forget to enforce the change on OtherBSD for compatibility. NetBSD uses: %%% # $NetBSD: bsd.README,v 1.134 2003/08/03 09:23:15 lukem Exp $ ... NOxxx If defined, disables a feature. Not intended for users. This is to allow Makefiles to disable functionality that they don't support (such as missing man pages). NOxxx variables must be defined before is included. %%% %%% # $NetBSD: bsd.own.mk,v 1.352 2003/08/01 22:51:34 mrg Exp $ ... # # Define MKxxx variables (which are either yes or no) for users # to set in /etc/mk.conf and override in the make environment. # These should be tested with `== "no"' or `!= "no"'. # The NOxxx variables should only be set by Makefiles. # # # Supported NO* options (if defined, MK* will be forced to "no", # regardless of user's mk.conf setting). # .for var in CRYPTO DOC HTML LINKLIB LINT MAN NLS OBJ PIC PICINSTALL PROFILE \ SHARE .if defined(NO${var}) MK${var}:= no .endif .endfor %%% Perhaps the real point here is that the mostly-implementation-detail names for the build system leaked out to user-visible names. Bruce From owner-freebsd-arch@FreeBSD.ORG Sun Sep 7 04:02:22 2003 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 37A7716A4C0; Sun, 7 Sep 2003 04:02:22 -0700 (PDT) Received: from amsfep12-int.chello.nl (amsfep12-int.chello.nl [213.46.243.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C923D43FA3; Sun, 7 Sep 2003 04:02:20 -0700 (PDT) (envelope-from dodell@sitetronics.com) Received: from sitetronics.com ([213.46.142.207]) by amsfep12-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with ESMTP id <20030907110219.DVAM2869.amsfep12-int.chello.nl@sitetronics.com>; Sun, 7 Sep 2003 13:02:19 +0200 Message-ID: <3F5B1008.4010007@sitetronics.com> Date: Sun, 07 Sep 2003 13:01:28 +0200 From: "Devon H. O'Dell" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <20030905140628.H90946@12-234-22-23.pyvrag.nggov.pbz> <20030907183531.V3442@gamplex.bde.org> In-Reply-To: <20030907183531.V3442@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Doug Barton cc: freebsd-arch@freebsd.org Subject: Re: RFC: NO_FOO knobs in make.conf 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: Sun, 07 Sep 2003 11:02:22 -0000 Regarding point 1: To me, the following would make sense: FREEBSD_IS_GOOD (in place of FREE_BSD_IS_GOOD -- FreeBSD qualifies as a word; it's a proper noun) DES_IS_OLD/3DES_IS_NEWER/RIJNDAEL_256_IS_BETTER I also don't see the point in backwards compatibility for something like this. Also, there are a few things in rc.conf that also could be separated (defaultrouter, for instance). I think if we're going to be anal about being consistent, we should be consistent through all the config files. My $0.02. --Devon Bruce Evans wrote: >On Fri, 5 Sep 2003, Doug Barton wrote: > > > >>Seems this topic is a perennial favorite, so I'd like to establish >>general agreement on a policy to deal with this going forward. I propose >>the following "guidelines" for discussion: >> >>1. All new knobs, in all branches, should have WORD_SEPERATORS between >>distinct English words. This aids understanding of what the knob means >>for English speakers, and more importantly, those for whom English is >>not their first language. That, and actually having a standard are the >>two main reasons I'm proposing this version. >> >> > >Does this rule apply to non-English words like SEPERATORS (sic) in the >above, BSD in FreeBSD, DES in DES, des in des, RELENG in RELENG_*, etc.? >:-> > > > >>2. Assuming that adequate volunteer resources can be found, all knobs in >>HEAD should be converted to the WORD_SEP format, and compatibility shims >>added, preferably with a suitable warning. This should happen prior to >>the 6-current branch. >> >>3. At some point in the future, the shims in 2. will be removed in >>6-current. >> >>4. The shims from 2. should probably not be removed in the eventual >>RELENG_5. (I'm open on this, I just want to be sure we get it down "on >>paper.") >> >>5. Conversion of the knobs should never be backported to RELENG_4 >> >> > >I won't complain much about the names of new variables, but >changing the names of old variables and adding compatibility cruft >to support 2 sets of names are wastes of time. > >When you change this, don't forget to enforce the change on OtherBSD for >compatibility. NetBSD uses: > >%%% ># $NetBSD: bsd.README,v 1.134 2003/08/03 09:23:15 lukem Exp $ >... >NOxxx If defined, disables a feature. > Not intended for users. > This is to allow Makefiles to disable functionality > that they don't support (such as missing man pages). > NOxxx variables must be defined before > is included. >%%% > >%%% ># $NetBSD: bsd.own.mk,v 1.352 2003/08/01 22:51:34 mrg Exp $ >... ># ># Define MKxxx variables (which are either yes or no) for users ># to set in /etc/mk.conf and override in the make environment. ># These should be tested with `== "no"' or `!= "no"'. ># The NOxxx variables should only be set by Makefiles. ># > ># ># Supported NO* options (if defined, MK* will be forced to "no", ># regardless of user's mk.conf setting). ># >.for var in CRYPTO DOC HTML LINKLIB LINT MAN NLS OBJ PIC PICINSTALL PROFILE \ > SHARE >.if defined(NO${var}) >MK${var}:= no >.endif >.endfor >%%% > >Perhaps the real point here is that the mostly-implementation-detail names >for the build system leaked out to user-visible names. > >Bruce >_______________________________________________ >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" > > > > From owner-freebsd-arch@FreeBSD.ORG Mon Sep 8 07:37:49 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 683) id E00DB16A4C0; Mon, 8 Sep 2003 07:37:49 -0700 (PDT) Date: Mon, 8 Sep 2003 07:37:49 -0700 From: Eivind Eklund To: "Adam C. Migus" Message-ID: <20030908073749.A71336@FreeBSD.org> References: <49222.192.168.4.2.1062744486.squirrel@mail.migus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <49222.192.168.4.2.1062744486.squirrel@mail.migus.org> cc: freebsd-arch@FreeBSD.org cc: Kris Kennaway Subject: Re: config files in packages (Re: (proposal) new flag forpkg_delete) 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, 08 Sep 2003 14:37:50 -0000 On Fri, Sep 05, 2003 at 02:48:06AM -0400, Adam C. Migus wrote: > I agree with the something like the Debian approach but perhaps with > more emphasis on comparison and automation than user interaction. > It takes the worry out of the hands of the port maintainers, it > keeps users from screwing up their installations, it's been done and > shown to work it can be improved by offering a diff feature. See ports/sysutils/etcmerge for an implementation of 3-way merges of /etc I did a little while ago. It handle conflicts reasonably (or what I think is reasonable, at least), including the case where a config file is deleted. Usually, it will completely automate upgrades. In order to do this, etcmerge requires a copy of the initial ("sample") configuration files as distributed by the vendor (FreeBSD, for the present). For the present case, the easy way to get this is to run mergemaster and copy the tree it creates in /var/tmp. It is not possible to use a copy of the /etc just after install, as sysinstall writes modifications to /etc before the user gets access to it, and these modifications would be lost if it was copied as "base". It should be fairly simple to extend the technique to also cover ports. If we choose to do this, we should also make sysinstall store a copy of the initial /etc, to remove the need to run mergemaster to get a copy. Eivind. From owner-freebsd-arch@FreeBSD.ORG Mon Sep 8 11:26:33 2003 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 EA52916A4BF; Mon, 8 Sep 2003 11:26:32 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D53E43FBF; Mon, 8 Sep 2003 11:26:31 -0700 (PDT) (envelope-from adam@migus.org) Received: from garple.migus.org ([68.55.83.100]) by comcast.net (sccrmhc13) with ESMTP id <2003090818262901600g6vhje>; Mon, 8 Sep 2003 18:26:29 +0000 Received: from garple.migus.org (localhost [127.0.0.1]) by garple.migus.org (8.12.9/8.12.9) with ESMTP id h88IQSui009995; Mon, 8 Sep 2003 14:26:28 -0400 (EDT) (envelope-from adam@migus.org) Received: (from www@localhost) by garple.migus.org (8.12.9/8.12.9/Submit) id h88IQRw6009994; Mon, 8 Sep 2003 14:26:27 -0400 (EDT) X-Authentication-Warning: garple.migus.org: www set sender to adam@migus.org using -f Received: from 204.254.155.35 (SquirrelMail authenticated user adam) by mail.migus.org with HTTP; Mon, 8 Sep 2003 14:26:27 -0400 (EDT) Message-ID: <57827.204.254.155.35.1063045587.squirrel@mail.migus.org> In-Reply-To: <20030908073749.A71336@FreeBSD.org> References: <49222.192.168.4.2.1062744486.squirrel@mail.migus.org> <20030908073749.A71336@FreeBSD.org> Date: Mon, 8 Sep 2003 14:26:27 -0400 (EDT) From: "Adam C. Migus" To: "Eivind Eklund" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PRIORITY_NO_NAME, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT, X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-arch@FreeBSD.ORG cc: Kris Kennaway Subject: Re: config files in packages (Re: (proposal) new flag forpkg_delete) 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, 08 Sep 2003 18:26:33 -0000 Eivind Eklund said: > On Fri, Sep 05, 2003 at 02:48:06AM -0400, Adam C. Migus wrote: >> I agree with the something like the Debian approach but perhaps >> with >> more emphasis on comparison and automation than user interaction. >> It takes the worry out of the hands of the port maintainers, it >> keeps users from screwing up their installations, it's been done >> and >> shown to work it can be improved by offering a diff feature. > > See ports/sysutils/etcmerge for an implementation of 3-way merges of > /etc I did a little while ago. It handle conflicts reasonably (or > what > I think is reasonable, at least), including the case where a config > file > is deleted. Usually, it will completely automate upgrades. > > In order to do this, etcmerge requires a copy of the initial > ("sample") > configuration files as distributed by the vendor (FreeBSD, for the > present). For the present case, the easy way to get this is to run > mergemaster and copy the tree it creates in /var/tmp. It is not > possible to use a copy of the /etc just after install, as sysinstall > writes modifications to /etc before the user gets access to it, and > these modifications would be lost if it was copied as "base". > > It should be fairly simple to extend the technique to also cover > ports. > If we choose to do this, we should also make sysinstall store a copy > of > the initial /etc, to remove the need to run mergemaster to get a > copy. > > Eivind. > Eivind, I have been playing with your package for a little while now. I like it so far and was waiting to see if you had anything else in the way of enhancements for it prior to commenting (as you've only released 0.2 thus far). You're point about the base install didn't bother me as I was using it for diskless installations. I like both of your ideas, adapting it for ports and for sysinstall. Have you received any feedback? Are there any known bugs or limitations in the current revision that might preclude experimentation with doing this now? -- Adam - (http://people.migus.org/~amigus/) Migus Dot Org - (http://www.migus.org/) From owner-freebsd-arch@FreeBSD.ORG Mon Sep 8 18:02:27 2003 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 049C216A4BF for ; Mon, 8 Sep 2003 18:02:27 -0700 (PDT) Received: from mail.yadt.co.uk (yadt.demon.co.uk [158.152.4.134]) by mx1.FreeBSD.org (Postfix) with SMTP id A8FC543F75 for ; Mon, 8 Sep 2003 18:02:21 -0700 (PDT) (envelope-from davidt@yadt.co.uk) Received: (qmail 51209 invoked from network); 9 Sep 2003 01:02:19 -0000 Received: from unknown (HELO mail.gattaca.yadt.co.uk) (@10.0.0.2) by yadt.demon.co.uk with SMTP; 9 Sep 2003 01:02:19 -0000 Received: (qmail 97087 invoked by uid 1000); 9 Sep 2003 01:02:17 -0000 Date: Tue, 9 Sep 2003 02:02:17 +0100 From: David Taylor To: freebsd-arch@FreeBSD.ORG Message-ID: <20030909010217.GA82266@gattaca.yadt.co.uk> Mail-Followup-To: freebsd-arch@FreeBSD.ORG References: <49222.192.168.4.2.1062744486.squirrel@mail.migus.org> <20030908073749.A71336@FreeBSD.org> <57827.204.254.155.35.1063045587.squirrel@mail.migus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <57827.204.254.155.35.1063045587.squirrel@mail.migus.org> User-Agent: Mutt/1.4.1i Subject: Re: config files in packages (Re: (proposal) new flag forpkg_delete) 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, 09 Sep 2003 01:02:27 -0000 On Mon, 08 Sep 2003, Adam C. Migus wrote: [snip] > > I have been playing with your package for a little while now. I > like it so far and was waiting to see if you had anything else in > the way of enhancements for it prior to commenting (as you've only > released 0.2 thus far). You're point about the base install didn't > bother me as I was using it for diskless installations. > > I like both of your ideas, adapting it for ports and for sysinstall. > Have you received any feedback? Are there any known bugs or > limitations in the current revision that might preclude > experimentation with doing this now? I'm currently (very slowly) working on an idea (as I posted somewhat hastily earlier this thread). The basic idea for merging is the same as Eivind's, but I took a different approach to getting the 'reference' config files. Basically, port Makefiles would list config files in a format something like: CONFIG_FILES= foo.cfg:etc/foo/foo.cfg \ bar_foo.cfg:etc/foo/bar/foo.cfg (It's too late to be inventive with filenames, sorry :) I need to work out exactly how the ports/package system can find the file, but my current idea is to have the ports/package system install etc/foo/foo.cfg.dist and etc/foo/bar/foo.cfg.dist (with a CONFIG_SUFFIX defaulting to .dist), then have the ports .mk files and a plist @config command handle the rest. That is, the ports/package system would install the default config file if no other config file existed, or the last user-created config file if one existed. It would also store the installed version in an RCS file (e.g. /var/db/pkg//cfg/bar_foo.cfg,v). The installed/merged versions would then be stored on a branch off of the 'reference' file it was last merged up to. On uninstallation, pkg_delete would, as currently, delete the .dist file, store the latest user file in the RCS file, and remove the config file. I've just realised that storing the RCS files in /var/pkg/db/ would result in them being deleted after an upgrade, so perhaps they need to be stored elsewhere. They'd also need to use /usr/ports/MOVED or similar to handle changing package names. However, I have (I think) worked out a way of doing this that would be backwards compatible. The pkgcfg_merge script could be set to use simple mergemaster style merging (ignore the 'reference' file and merge the new vs installed files), or a smarter diff3 style merging. The only change required to ports would be: Config files should be listed in CONFIG_FILES= (or whatever it gets called) Distributed config files _must_ be installed with CONFIG_SUFFIX (or whatever) as a suffix, to avoid overwriting stuff. The base system could either be handled as a special case (with a seperate db dir), or as a 'fake' package of some form. Hopefully, this makes more sense than my last mail about this. (I am still planning on creating/submitting a pkg_delete patch, but this was more interesting, so bumped it down my todo list a bit) -- David Taylor davidt@yadt.co.uk "The future just ain't what it used to be" From owner-freebsd-arch@FreeBSD.ORG Tue Sep 9 04:23:12 2003 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 3D58916A4BF for ; Tue, 9 Sep 2003 04:23:12 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3C6143FBD for ; Tue, 9 Sep 2003 04:23:10 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id h89BN9SO046342 for ; Tue, 9 Sep 2003 12:23:09 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h89BN8Tj094141 for ; Tue, 9 Sep 2003 12:23:09 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: arch@freebsd.org Content-Type: text/plain Message-Id: <1063106587.25817.23.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 09 Sep 2003 12:23:08 +0100 Content-Transfer-Encoding: 7bit Subject: When to burn those bridges 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, 09 Sep 2003 11:23:12 -0000 I haven't been paying much attention recently on release engineering issues so probably I have missed something. When do people think is the right time to branch off the 5.x line of development and set fire to the bridges? I have been working recently on some stuff which probably isn't appropriate for 5.x. I started trying to simplify the smbus driver so that you don't need three devices for each smbus and also to support kernel drivers for smbus-attached devices (e.g. sensors). This is possible using the current api but gets a bit clumsy in places. This led me back to the idea of multiple inheritance in kobj/newbus. Using multiple inheritance for the smbus re-work makes the chip drivers much simpler since they don't have to explicitly list the 'parent' methods in their method tables. The same thing goes for cardbus too. On these lines, I went back and read through Justin's old inheritance patches. These patches supported single inheritance for multiple interfaces at the cost of changing the driver API considerably. I've been tinkering with an alternative approach which supports multiple inheritance at the class level, almost preserving the driver API while changing the ABI slightly. The only part of the API which is not preserved is the driver 'priv' field which is only used for evil compatibility shim drivers. These shims are currently stacked up on the post 5.x bonfire, hence the question about when to light the fire. I would like to have a place to commit my work-in-progress when it gets a little further - would it be a useful idea to run a 6.x P4 tree for a while until the CVS tree branches? It would also be nice to have some kind of inheritance tree for device classes. Currently, drivers are grouped by devclass and the driver matching election is done by iterating through the drivers listed in the parent device's devclass. This means that many drivers have several attachment declarations for different alternatives, e.g.: DRIVER_MODULE(fxp, pci, fxp_driver, fxp_devclass, 0, 0); DRIVER_MODULE(fxp, cardbus, fxp_driver, fxp_devclass, 0, 0); If there was a way, for instance, of stating that a cardbus was a kind of pci, then the individual drivers can be simplified. The driver searching system could easily be extended to search for drivers in base classes of the bus driver. The same technique could be used to reduce the number of 'converter' devices. Right now, every network device has a child miibus device that manages the attached phys. Using multiple inheritance, the network drivers would be able to derive from the miibus device instead, giving a simpler device structure which more closely matches the real hardware, e.g.: fxp0: port 0x18c0-0x18df mem 0xe8000000-0xe80fffff,0xe8105000-0xe8105fff irq 10 at device 9.0 on pci0 fxp0: Ethernet address 1:2:3:4:5:6 nsphy0: on fxp0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto From owner-freebsd-arch@FreeBSD.ORG Tue Sep 9 08:30:43 2003 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 B9B4016A4BF; Tue, 9 Sep 2003 08:30:43 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-169-107-253.dsl.lsan03.pacbell.net [64.169.107.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8736743FD7; Tue, 9 Sep 2003 08:30:40 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 3893E66B04; Tue, 9 Sep 2003 08:30:40 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 19A98A94; Tue, 9 Sep 2003 08:30:40 -0700 (PDT) Date: Tue, 9 Sep 2003 08:30:40 -0700 From: Kris Kennaway To: deischen@freebsd.org Message-ID: <20030909153039.GA942@rot13.obsecurity.org> References: <20030905.183837.116096286.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: DougB@freebsd.org cc: "M. Warner Losh" cc: freebsd-arch@freebsd.org Subject: Re: RFC: NO_FOO knobs in make.conf 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, 09 Sep 2003 15:30:43 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 06, 2003 at 04:42:12AM -0400, Daniel Eischen wrote: > On Fri, 5 Sep 2003, M. Warner Losh wrote: >=20 > > In message: <20030905140628.H90946@12-234-22-23.pyvrag.nggov.pbz> > > Doug Barton writes: > > : Once we get general consensus (not universal agreement :) on this, I'= ll > > : take responsibility for marshaling the aforementioned volunteer > > : resources. > >=20 > > I'd just do it. we've already talked this to death. Lots of people > > want it, some don't. Every time we talk about it, that's the > > outcome. Let's just do it and get on with our lives. >=20 > Or change all the NO*, NO_* to WANT_* and default them to yes. That would be inconsistent with the ports tree. Kris --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/XfIfWry0BWjoQKURApXeAKDWx1DRqnbGXLQDDFx3BQdFHcluiQCfXl/I UYSHRWU7WJ3LnBjmJfP1P+g= =0yup -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 9 08:34:28 2003 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 580F316A4BF; Tue, 9 Sep 2003 08:34:28 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A0DB43FE3; Tue, 9 Sep 2003 08:34:26 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h89FYPTX011950; Tue, 9 Sep 2003 09:34:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 09 Sep 2003 09:34:16 -0600 (MDT) Message-Id: <20030909.093416.91314918.imp@bsdimp.com> To: kris@obsecurity.org From: "M. Warner Losh" In-Reply-To: <20030909153039.GA942@rot13.obsecurity.org> References: <20030905.183837.116096286.imp@bsdimp.com> <20030909153039.GA942@rot13.obsecurity.org> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: deischen@freebsd.org cc: DougB@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: RFC: NO_FOO knobs in make.conf 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, 09 Sep 2003 15:34:28 -0000 In message: <20030909153039.GA942@rot13.obsecurity.org> Kris Kennaway writes: : On Sat, Sep 06, 2003 at 04:42:12AM -0400, Daniel Eischen wrote: : > On Fri, 5 Sep 2003, M. Warner Losh wrote: : > : > > In message: <20030905140628.H90946@12-234-22-23.pyvrag.nggov.pbz> : > > Doug Barton writes: : > > : Once we get general consensus (not universal agreement :) on this, I'll : > > : take responsibility for marshaling the aforementioned volunteer : > > : resources. : > > : > > I'd just do it. we've already talked this to death. Lots of people : > > want it, some don't. Every time we talk about it, that's the : > > outcome. Let's just do it and get on with our lives. : > : > Or change all the NO*, NO_* to WANT_* and default them to yes. : : That would be inconsistent with the ports tree. I liked the NetBSD approach, once Bruce mentioned it, but thought I'd wait to see what people came up with before getting into things too much at length. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Sep 9 08:48:15 2003 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 3A38716A4BF; Tue, 9 Sep 2003 08:48:15 -0700 (PDT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AB3243FBF; Tue, 9 Sep 2003 08:48:11 -0700 (PDT) (envelope-from danfe@regency.nsu.ru) Received: from mail by mx.nsu.ru with drweb-scanned (Exim 3.35 #1 (Debian)) id 19wkmB-000265-00; Tue, 09 Sep 2003 22:51:31 +0700 Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 3.35 #1 (Debian)) id 19wkm7-00022x-00; Tue, 09 Sep 2003 22:51:27 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.9/8.12.9) with ESMTP id h89Fnovt028249; Tue, 9 Sep 2003 22:49:50 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.9/8.12.9/Submit) id h89FnnrO028243; Tue, 9 Sep 2003 22:49:49 +0700 (NOVST) Date: Tue, 9 Sep 2003 22:49:49 +0700 From: Alexey Dokuchaev To: Kris Kennaway Message-ID: <20030909154949.GA26883@regency.nsu.ru> References: <20030905.183837.116096286.imp@bsdimp.com> <20030909153039.GA942@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030909153039.GA942@rot13.obsecurity.org> User-Agent: Mutt/1.4.1i X-Envelope-To: kris@obsecurity.org, deischen@freebsd.org, DougB@freebsd.org, imp@bsdimp.com, freebsd-arch@freebsd.org cc: deischen@freebsd.org cc: DougB@freebsd.org cc: "M. Warner Losh" cc: freebsd-arch@freebsd.org Subject: Re: RFC: NO_FOO knobs in make.conf 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, 09 Sep 2003 15:48:15 -0000 On Tue, Sep 09, 2003 at 08:30:40AM -0700, Kris Kennaway wrote: > On Sat, Sep 06, 2003 at 04:42:12AM -0400, Daniel Eischen wrote: > > On Fri, 5 Sep 2003, M. Warner Losh wrote: > > > > > In message: <20030905140628.H90946@12-234-22-23.pyvrag.nggov.pbz> > > > Doug Barton writes: > > > : Once we get general consensus (not universal agreement :) on this, I'll > > > : take responsibility for marshaling the aforementioned volunteer > > > : resources. > > > > > > I'd just do it. we've already talked this to death. Lots of people > > > want it, some don't. Every time we talk about it, that's the > > > outcome. Let's just do it and get on with our lives. > > > > Or change all the NO*, NO_* to WANT_* and default them to yes. WANT_FOO is bpm's internally used vars; practice of using names like these should be avoided, FWIW. ./danfe From owner-freebsd-arch@FreeBSD.ORG Tue Sep 9 11:36:51 2003 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 8480816A4BF; Tue, 9 Sep 2003 11:36:51 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32BB543FE0; Tue, 9 Sep 2003 11:36:50 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h89IaejR035181; Tue, 9 Sep 2003 11:36:40 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.9/8.12.9/Submit) id h89Iadtl035180; Tue, 9 Sep 2003 11:36:39 -0700 (PDT) (envelope-from marcel) Date: Tue, 9 Sep 2003 11:36:39 -0700 From: Marcel Moolenaar To: Kris Kennaway Message-ID: <20030909183639.GA35128@ns1.xcllnt.net> References: <20030905.183837.116096286.imp@bsdimp.com> <20030909153039.GA942@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030909153039.GA942@rot13.obsecurity.org> User-Agent: Mutt/1.5.1i cc: deischen@freebsd.org cc: DougB@freebsd.org cc: "M. Warner Losh" cc: freebsd-arch@freebsd.org Subject: Re: RFC: NO_FOO knobs in make.conf 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, 09 Sep 2003 18:36:51 -0000 On Tue, Sep 09, 2003 at 08:30:40AM -0700, Kris Kennaway wrote: > On Sat, Sep 06, 2003 at 04:42:12AM -0400, Daniel Eischen wrote: > > On Fri, 5 Sep 2003, M. Warner Losh wrote: > > > > > In message: <20030905140628.H90946@12-234-22-23.pyvrag.nggov.pbz> > > > Doug Barton writes: > > > : Once we get general consensus (not universal agreement :) on this, I'll > > > : take responsibility for marshaling the aforementioned volunteer > > > : resources. > > > > > > I'd just do it. we've already talked this to death. Lots of people > > > want it, some don't. Every time we talk about it, that's the > > > outcome. Let's just do it and get on with our lives. > > > > Or change all the NO*, NO_* to WANT_* and default them to yes. > > That would be inconsistent with the ports tree. Except xemacs, which uses WANT_GTK as a user knob :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Tue Sep 9 18:03:32 2003 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 8E7B116A4BF for ; Tue, 9 Sep 2003 18:03:32 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFF6C43FBF for ; Tue, 9 Sep 2003 18:03:31 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from 12-234-22-23.client.attbi.com ([12.234.22.23]) by comcast.net (sccrmhc13) with SMTP id <2003091001033001600n28vue>; Wed, 10 Sep 2003 01:03:30 +0000 Date: Tue, 9 Sep 2003 18:03:29 -0700 (PDT) From: Doug Barton To: "M. Warner Losh" In-Reply-To: <20030909.093416.91314918.imp@bsdimp.com> Message-ID: <20030909174756.M42161@12-234-22-23.pyvrag.nggov.pbz> References: <20030905.183837.116096286.imp@bsdimp.com> <20030909.093416.91314918.imp@bsdimp.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: RFC: NO_FOO knobs in make.conf 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: Wed, 10 Sep 2003 01:03:32 -0000 On Tue, 9 Sep 2003, M. Warner Losh wrote: > I liked the NetBSD approach, once Bruce mentioned it, but thought I'd > wait to see what people came up with before getting into things too > much at length. Yeah, I had exactly the same feeling. I didn't want to stifle anyone's creativity. :) But since his is the best suggestion I've seen so far, and because it increases our compatibility with netbsd, I'd like to refine step one of my plan as follows: 1. All new Makefile knobs, in all branches, should have WORD_SEPARATORS between distinct English words. Internal variables should be in the form NO_FOO. In HEAD, and the eventual RELENG_5, knobs that are intended to be exposed to users should be in the form MK_FOO. Anything that isn't defined as "no" is assumed to be "yes." This gives us a lot more flexibility in terms of how we use the knobs, and how we define defaults going down the road. So for example, I'd like to have more fine grained control over what BIND bits we build, so I plan to introduce a MK_BIND_NAMED knob that controls the build of named itself, and friends like ndc. Initially I'll default this to on, but eventually I forsee switching it to off. Thoughts? Doug PS, I'll be at the tech sessions Wed-Fri if anyone wants to discuss this in person. -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Tue Sep 9 18:03:46 2003 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 0C8DA16A4BF for ; Tue, 9 Sep 2003 18:03:46 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4BE543F3F for ; Tue, 9 Sep 2003 18:03:43 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h8A13aTX016833; Tue, 9 Sep 2003 19:03:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 09 Sep 2003 19:03:35 -0600 (MDT) Message-Id: <20030909.190335.130622954.imp@bsdimp.com> To: dfr@nlsystems.com From: "M. Warner Losh" In-Reply-To: <1063106587.25817.23.camel@builder02.qubesoft.com> References: <1063106587.25817.23.camel@builder02.qubesoft.com> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: When to burn those bridges 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: Wed, 10 Sep 2003 01:03:46 -0000 In message: <1063106587.25817.23.camel@builder02.qubesoft.com> Doug Rabson writes: : I haven't been paying much attention recently on release engineering : issues so probably I have missed something. When do people think is the : right time to branch off the 5.x line of development and set fire to the : bridges? The plan was to remove them immediately after the branch to remove the support code. If nothing get fixed as we enter the "glide path" to 6.0-R, stuff that depened on the burned bridges gets killed. : This led me back to the idea of multiple inheritance in kobj/newbus. : Using multiple inheritance for the smbus re-work makes the chip drivers : much simpler since they don't have to explicitly list the 'parent' : methods in their method tables. The same thing goes for cardbus too. On : these lines, I went back and read through Justin's old inheritance : patches. These patches supported single inheritance for multiple : interfaces at the cost of changing the driver API considerably. I've : been tinkering with an alternative approach which supports multiple : inheritance at the class level, almost preserving the driver API while : changing the ABI slightly. I like this idea. : The only part of the API which is not preserved is the driver 'priv' : field which is only used for evil compatibility shim drivers. These : shims are currently stacked up on the post 5.x bonfire, hence the : question about when to light the fire. I would like to have a place to : commit my work-in-progress when it gets a little further - would it be a : useful idea to run a 6.x P4 tree for a while until the CVS tree : branches? You can do development of changes that depend on bridges burning in the 6.x tree. I'm sure that sledding will be really tough in current after the branch. The really big changes should be done in P4 and integrated into 6 when they are mature. If there's a really compelling reason (and this would be it), we can burn some bridges early. I wouldn't hold up your development based on these bridges being in harm's way. Others in the BSDcon terminal room are saying "do it now, screw waiting for 6". If you can get it done and solid, I'd do it before the branch. The drivers in harm's way either have out of tree replacements, or aren't that important, or need to be redone and this is a good excuse. : It would also be nice to have some kind of inheritance tree for device : classes. Currently, drivers are grouped by devclass and the driver : matching election is done by iterating through the drivers listed in the : parent device's devclass. This means that many drivers have several : attachment declarations for different alternatives, e.g.: : : DRIVER_MODULE(fxp, pci, fxp_driver, fxp_devclass, 0, 0); : DRIVER_MODULE(fxp, cardbus, fxp_driver, fxp_devclass, 0, 0); Many cardbus drivers do nothing different. There are a few that do, but so long as it is possible to override things if they want it. : The same technique could be used to reduce the number of 'converter' : devices. I like this. pcic/cbb have similar issues, but the size of the problem is small. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Sep 9 18:08:28 2003 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 424B816A4BF for ; Tue, 9 Sep 2003 18:08:28 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B0AB43FDD for ; Tue, 9 Sep 2003 18:08:27 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from 12-234-22-23.client.attbi.com ([12.234.22.23]) by comcast.net (sccrmhc12) with SMTP id <2003091001082601200p4010e>; Wed, 10 Sep 2003 01:08:26 +0000 Date: Tue, 9 Sep 2003 18:08:25 -0700 (PDT) From: Doug Barton To: Bruce Evans In-Reply-To: <20030907183531.V3442@gamplex.bde.org> Message-ID: <20030909180341.T42161@12-234-22-23.pyvrag.nggov.pbz> References: <20030905140628.H90946@12-234-22-23.pyvrag.nggov.pbz> <20030907183531.V3442@gamplex.bde.org> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: RFC: NO_FOO knobs in make.conf 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: Wed, 10 Sep 2003 01:08:28 -0000 On Sun, 7 Sep 2003, Bruce Evans wrote: > On Fri, 5 Sep 2003, Doug Barton wrote: > > > Seems this topic is a perennial favorite, so I'd like to establish > > general agreement on a policy to deal with this going forward. I propose > > the following "guidelines" for discussion: > > > > 1. All new knobs, in all branches, should have WORD_SEPERATORS between > > distinct English words. This aids understanding of what the knob means > > for English speakers, and more importantly, those for whom English is > > not their first language. That, and actually having a standard are the > > two main reasons I'm proposing this version. > > Does this rule apply to non-English words like SEPERATORS (sic) Ooooo.... gettin' nasty with the spelling barbs, eh? Don't get me started. :) > in the above, BSD in FreeBSD, DES in DES, des in des, RELENG in > RELENG_*, etc.? :-> Hey, one thing at a time. > I won't complain much about the names of new variables, but > changing the names of old variables and adding compatibility cruft > to support 2 sets of names are wastes of time. I disagree... I think if we're going to rev the interface, we ought to do a clean sweep. Part of the reason that this topic comes up again and again is that we're massively inconistent atm. > When you change this, don't forget to enforce the change on OtherBSD for > compatibility. Heh.... just one small step in my plan for total DougBSD domination. > NetBSD uses: As commented on in the mail I just sent, I like this concept a lot, thanks for bringing it up. > Perhaps the real point here is that the mostly-implementation-detail names > for the build system leaked out to user-visible names. *nod nod* I really like the idea of having two distinct name spaces. Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Tue Sep 9 23:20:47 2003 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 DFE9816A4BF for ; Tue, 9 Sep 2003 23:20:47 -0700 (PDT) Received: from critter.freebsd.dk (p26.n-sfpop02.stsn.com [199.107.153.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73B6743FD7 for ; Tue, 9 Sep 2003 23:20:47 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h8A6KlIP005149 for ; Wed, 10 Sep 2003 08:20:47 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Wed, 10 Sep 2003 08:20:47 +0200 Message-ID: <5148.1063174847@critter.freebsd.dk> Subject: The struct buf junta met... 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: Wed, 10 Sep 2003 06:20:48 -0000 The struct buf junta met at an undisclosed location, and this is what we found out: With the 5-stable branch (still) being 3-4 in the future, we want to get as much as the API changes into the stable branch as possible, in order to not do another "3.x mistake". The things you can expect to see appearing (provided we can make it work) is: 1. Move floppies & CD's under GEOM. 2. Move the vcount() to the dev_t for VCHR. This removes one icky problem from vnode locking. 3. Vnode bypass for userland device access. This is the stuff I posted a prototype of some time ago: Go directly from the filedesc switch to SPECFS thus bypassing vnodes and vnode locking intirely and going Giant-free for drivers that support this. 4. Scatter/Gather mapped/unmapped struct bio. This allows an I/O request to be composed of a number of pages spread out in physical memory. 5. Shoot pbufs In swap_pager.c, vfs_cluster, spec_getpages, AIO, O_DIRECT... We have a lot of ideas going forward from that point, but they are not concrete enough to actually formulate as a plan yet. We will try to explain this coherently at the devsummit this weekend and in email subsequent to that. Secretary for the Buf Junta Poul-Henning -- 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 Wed Sep 10 00:14:49 2003 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 141AD16A4C0 for ; Wed, 10 Sep 2003 00:14:49 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EDE443FBD for ; Wed, 10 Sep 2003 00:14:48 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 17773 invoked from network); 10 Sep 2003 07:14:47 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 10 Sep 2003 07:14:47 -0000 Received: from laptop.baldwin.cx (p26.n-sfpop02.stsn.com [199.107.153.26]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8A7Ei6Y038435; Wed, 10 Sep 2003 03:14:45 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <1063106587.25817.23.camel@builder02.qubesoft.com> Date: Wed, 10 Sep 2003 03:15:06 -0400 (EDT) From: John Baldwin To: Doug Rabson X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: RE: When to burn those bridges 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: Wed, 10 Sep 2003 07:14:49 -0000 On 09-Sep-2003 Doug Rabson wrote: > I haven't been paying much attention recently on release engineering > issues so probably I have missed something. When do people think is the > right time to branch off the 5.x line of development and set fire to the > bridges? Go ahead and kill the ISA compat drivers if you need to. I do think that you can probably do this work in a p4 branch until it is ready and delay the killing of compat shims until then maybe. > This led me back to the idea of multiple inheritance in kobj/newbus. > Using multiple inheritance for the smbus re-work makes the chip drivers > much simpler since they don't have to explicitly list the 'parent' > methods in their method tables. The same thing goes for cardbus too. On > these lines, I went back and read through Justin's old inheritance > patches. These patches supported single inheritance for multiple > interfaces at the cost of changing the driver API considerably. I've > been tinkering with an alternative approach which supports multiple > inheritance at the class level, almost preserving the driver API while > changing the ABI slightly. Yes, please. There is the same problem with agp(4) and the hostb(4) driver and agp(4) for Intel motherboards with onboard graphics and the drm(4) driver for the same graphics chip. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 00:53:46 2003 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 1316D16A4BF; Wed, 10 Sep 2003 00:53:46 -0700 (PDT) Received: from lewis.lclark.edu (www.ncvli.org [149.175.1.5]) by mx1.FreeBSD.org (Postfix) with SMTP id 6385B43FDF; Wed, 10 Sep 2003 00:53:44 -0700 (PDT) (envelope-from eta@lclark.edu) Received: from [149.175.34.86] ([149.175.34.86]) by lewis.lclark.edu (SAVSMTP 3.1.1.32) with SMTP id M2003091000534313783 ; Wed, 10 Sep 2003 00:53:43 -0700 From: Eric Anholt To: John Baldwin In-Reply-To: References: Content-Type: text/plain Message-Id: <1063180423.634.31.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 10 Sep 2003 00:53:43 -0700 Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: RE: When to burn those bridges 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: Wed, 10 Sep 2003 07:53:46 -0000 On Wed, 2003-09-10 at 00:15, John Baldwin wrote: > On 09-Sep-2003 Doug Rabson wrote: > > I haven't been paying much attention recently on release engineering > > issues so probably I have missed something. When do people think is the > > right time to branch off the 5.x line of development and set fire to the > > bridges? > > Go ahead and kill the ISA compat drivers if you need to. I do think > that you can probably do this work in a p4 branch until it is ready > and delay the killing of compat shims until then maybe. > > > This led me back to the idea of multiple inheritance in kobj/newbus. > > Using multiple inheritance for the smbus re-work makes the chip drivers > > much simpler since they don't have to explicitly list the 'parent' > > methods in their method tables. The same thing goes for cardbus too. On > > these lines, I went back and read through Justin's old inheritance > > patches. These patches supported single inheritance for multiple > > interfaces at the cost of changing the driver API considerably. I've > > been tinkering with an alternative approach which supports multiple > > inheritance at the class level, almost preserving the driver API while > > changing the ABI slightly. > > Yes, please. There is the same problem with agp(4) and the hostb(4) > driver and agp(4) for Intel motherboards with onboard graphics and > the drm(4) driver for the same graphics chip. I thought we wanted agp(4) to replace hostb(4) when agp would attach. It's not the same problem for intel onboard graphics and the drm driver, then, since we need both drivers for the DRM to work. I think keithw solved this by making the agp driver provide a "drmsub" child device which the i8x0 DRM attaches to. Would there be any problems with putting that in CVS? -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 01:07:25 2003 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 D7B4416A4BF; Wed, 10 Sep 2003 01:07:25 -0700 (PDT) Received: from axe-inc.co.jp (axegw.axe-inc.co.jp [61.199.217.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2919243FBF; Wed, 10 Sep 2003 01:07:24 -0700 (PDT) (envelope-from takawata@axe-inc.co.jp) Received: from axe-inc.co.jp ([192.47.224.47]) by axe-inc.co.jp (8.9.3+3.2W/3.7W) with ESMTP id RAA24609; Wed, 10 Sep 2003 17:07:22 +0900 (JST) Message-Id: <200309100807.RAA24609@axe-inc.co.jp> To: John Baldwin In-reply-to: Your message of "Wed, 10 Sep 2003 03:15:06 -0400." Date: Wed, 10 Sep 2003 17:08:44 +0900 From: User Takawata cc: arch@freebsd.org Subject: Re: When to burn those bridges 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: Wed, 10 Sep 2003 08:07:26 -0000 In message , John Baldwin wrote: > >Yes, please. There is the same problem with agp(4) and the hostb(4) >driver and agp(4) for Intel motherboards with onboard graphics and >the drm(4) driver for the same graphics chip. ,and ACPI VGA extension driver to add display controling feature. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 01:08:14 2003 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 72BFB16A4BF for ; Wed, 10 Sep 2003 01:08:14 -0700 (PDT) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id F040C43FB1 for ; Wed, 10 Sep 2003 01:08:12 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.12.9/8.12.8) with ESMTP id h8A87igs047168; Wed, 10 Sep 2003 09:07:44 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: "M. Warner Losh" In-Reply-To: <20030909.190335.130622954.imp@bsdimp.com> References: <1063106587.25817.23.camel@builder02.qubesoft.com> <20030909.190335.130622954.imp@bsdimp.com> Content-Type: text/plain Message-Id: <1063181264.43759.6.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 10 Sep 2003 09:07:44 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: Re: When to burn those bridges 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: Wed, 10 Sep 2003 08:08:14 -0000 On Wed, 2003-09-10 at 02:03, M. Warner Losh wrote: > If there's a really compelling reason (and this would be it), we can > burn some bridges early. I wouldn't hold up your development based on > these bridges being in harm's way. Others in the BSDcon terminal room > are saying "do it now, screw waiting for 6". If you can get it done > and solid, I'd do it before the branch. The drivers in harm's way > either have out of tree replacements, or aren't that important, or > need to be redone and this is a good excuse. If I commit this work to -current now, it will break ABI compatibility with 5.1-RELEASE. When is the ABI for 5.x suppose to be frozen? Does it matter if I break the 5.1 ABI in current? For what its worth, this change will also make the kobj method dispatch SMP safe (without locks). > > : It would also be nice to have some kind of inheritance tree for device > : classes. Currently, drivers are grouped by devclass and the driver > : matching election is done by iterating through the drivers listed in the > : parent device's devclass. This means that many drivers have several > : attachment declarations for different alternatives, e.g.: > : > : DRIVER_MODULE(fxp, pci, fxp_driver, fxp_devclass, 0, 0); > : DRIVER_MODULE(fxp, cardbus, fxp_driver, fxp_devclass, 0, 0); > > Many cardbus drivers do nothing different. There are a few that do, > but so long as it is possible to override things if they want it. Drivers which really need something special for cardbus will be able to override things by defining a subclass of their pci driver which is listed in the cardbus devclass. > > : The same technique could be used to reduce the number of 'converter' > : devices. > > I like this. pcic/cbb have similar issues, but the size of the > problem is small. Its mainly a cosmetic thing but it has always been an irritation to me to have these little clusters of devices where there is only one piece of hardware, e.g.: hostb0 pci0 pcib1 pci1 amdpm0 smbus0 smb0 should become: pci0 pci1 amdpm0 From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 01:32:45 2003 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 D2E7116A4BF for ; Wed, 10 Sep 2003 01:32:45 -0700 (PDT) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id DEFB343FBD for ; Wed, 10 Sep 2003 01:32:44 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: (qmail 72336 invoked by uid 1002); 10 Sep 2003 08:32:44 -0000 Received: from unknown (HELO ?10.4.1.5?) (64.58.1.252) by smtp.mho.net with SMTP; 10 Sep 2003 08:32:44 -0000 Date: Wed, 10 Sep 2003 02:33:59 -0600 (MDT) From: Scott Long X-X-Sender: scottl@pooker.samsco.home To: Doug Rabson In-Reply-To: <1063181264.43759.6.camel@herring.nlsystems.com> Message-ID: <20030910022914.F80075@pooker.samsco.home> References: <1063106587.25817.23.camel@builder02.qubesoft.com> <1063181264.43759.6.camel@herring.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: "M. Warner Losh" Subject: Re: When to burn those bridges 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: Wed, 10 Sep 2003 08:32:45 -0000 On Wed, 10 Sep 2003, Doug Rabson wrote: > On Wed, 2003-09-10 at 02:03, M. Warner Losh wrote: > > If there's a really compelling reason (and this would be it), we can > > burn some bridges early. I wouldn't hold up your development based on > > these bridges being in harm's way. Others in the BSDcon terminal room > > are saying "do it now, screw waiting for 6". If you can get it done > > and solid, I'd do it before the branch. The drivers in harm's way > > either have out of tree replacements, or aren't that important, or > > need to be redone and this is a good excuse. > > If I commit this work to -current now, it will break ABI compatibility > with 5.1-RELEASE. When is the ABI for 5.x suppose to be frozen? Does it > matter if I break the 5.1 ABI in current? For what its worth, this > change will also make the kobj method dispatch SMP safe (without locks). The 5.x ABI and API will not be stable until 5.3. This work looks very encouraging; please go ahead and do what you need to do to implement it. I'm not sure if Justin has any thoughts on your approach or if he cares to revive his newbus work, but you might want to check with him just to be sure. Scott From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 01:47:58 2003 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 0751C16A4BF; Wed, 10 Sep 2003 01:47:58 -0700 (PDT) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEC7943F75; Wed, 10 Sep 2003 01:47:56 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.12.9/8.12.8) with ESMTP id h8A8lZgs047343; Wed, 10 Sep 2003 09:47:35 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Eric Anholt In-Reply-To: <1063180423.634.31.camel@leguin> References: <1063180423.634.31.camel@leguin> Content-Type: text/plain Message-Id: <1063183655.43759.10.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 10 Sep 2003 09:47:35 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@FreeBSD.org cc: John Baldwin Subject: RE: When to burn those bridges 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: Wed, 10 Sep 2003 08:47:58 -0000 On Wed, 2003-09-10 at 08:53, Eric Anholt wrote: > On Wed, 2003-09-10 at 00:15, John Baldwin wrote: > > On 09-Sep-2003 Doug Rabson wrote: > > > I haven't been paying much attention recently on release engineering > > > issues so probably I have missed something. When do people think is the > > > right time to branch off the 5.x line of development and set fire to the > > > bridges? > > > > Go ahead and kill the ISA compat drivers if you need to. I do think > > that you can probably do this work in a p4 branch until it is ready > > and delay the killing of compat shims until then maybe. > > > > > This led me back to the idea of multiple inheritance in kobj/newbus. > > > Using multiple inheritance for the smbus re-work makes the chip drivers > > > much simpler since they don't have to explicitly list the 'parent' > > > methods in their method tables. The same thing goes for cardbus too. On > > > these lines, I went back and read through Justin's old inheritance > > > patches. These patches supported single inheritance for multiple > > > interfaces at the cost of changing the driver API considerably. I've > > > been tinkering with an alternative approach which supports multiple > > > inheritance at the class level, almost preserving the driver API while > > > changing the ABI slightly. > > > > Yes, please. There is the same problem with agp(4) and the hostb(4) > > driver and agp(4) for Intel motherboards with onboard graphics and > > the drm(4) driver for the same graphics chip. > > I thought we wanted agp(4) to replace hostb(4) when agp would attach. > It's not the same problem for intel onboard graphics and the drm driver, > then, since we need both drivers for the DRM to work. I think keithw > solved this by making the agp driver provide a "drmsub" child device > which the i8x0 DRM attaches to. Would there be any problems with > putting that in CVS? That is exactly what Keith did for the i830. I have his patches for it and I was supposed to review and commit them but they kind of got pushed to the bottom of the pile due to my recent house move. Would you like to do the honours? As far as I'm concerned, the patches are commit-ready apart from some minor violations of style(9) which I don't really care about but others might. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 03:14:19 2003 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 0BFEA16A4BF for ; Wed, 10 Sep 2003 03:14:19 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c211-28-27-130.belrs2.nsw.optusnet.com.au [211.28.27.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31D2643FBF for ; Wed, 10 Sep 2003 03:14:17 -0700 (PDT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h8AAEEgh004980; Wed, 10 Sep 2003 20:14:14 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h8AAEAOX004979; Wed, 10 Sep 2003 20:14:10 +1000 (EST) Date: Wed, 10 Sep 2003 20:14:10 +1000 From: Peter Jeremy To: Poul-Henning Kamp Message-ID: <20030910101410.GA4964@cirb503493.alcatel.com.au> References: <5148.1063174847@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5148.1063174847@critter.freebsd.dk> User-Agent: Mutt/1.4.1i cc: arch@freebsd.org Subject: Re: The struct buf junta met... 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: Wed, 10 Sep 2003 10:14:19 -0000 On Wed, Sep 10, 2003 at 08:20:47AM +0200, Poul-Henning Kamp wrote: >With the 5-stable branch (still) being 3-4 in the future, we want ^^ days, months, years? >to get as much as the API changes into the stable branch as possible, >in order to not do another "3.x mistake". Sounds reasonable but how much will all these new features further delay 5-stable whilst the bugs are ironed out? I agree that 3.x caused heartache but having an "almost -stable" 5.x branch doesn't help either. Peter From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 08:31:38 2003 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 EEF0D16A4BF for ; Wed, 10 Sep 2003 08:31:38 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2CDB43FEC for ; Wed, 10 Sep 2003 08:31:36 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h8AFVYTX022798; Wed, 10 Sep 2003 09:31:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 10 Sep 2003 09:31:34 -0600 (MDT) Message-Id: <20030910.093134.112624676.imp@bsdimp.com> To: dfr@nlsystems.com From: "M. Warner Losh" In-Reply-To: <1063181264.43759.6.camel@herring.nlsystems.com> References: <1063106587.25817.23.camel@builder02.qubesoft.com> <20030909.190335.130622954.imp@bsdimp.com> <1063181264.43759.6.camel@herring.nlsystems.com> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: When to burn those bridges 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: Wed, 10 Sep 2003 15:31:39 -0000 In message: <1063181264.43759.6.camel@herring.nlsystems.com> Doug Rabson writes: : On Wed, 2003-09-10 at 02:03, M. Warner Losh wrote: : > If there's a really compelling reason (and this would be it), we can : > burn some bridges early. I wouldn't hold up your development based on : > these bridges being in harm's way. Others in the BSDcon terminal room : > are saying "do it now, screw waiting for 6". If you can get it done : > and solid, I'd do it before the branch. The drivers in harm's way : > either have out of tree replacements, or aren't that important, or : > need to be redone and this is a good excuse. : : If I commit this work to -current now, it will break ABI compatibility : with 5.1-RELEASE. When is the ABI for 5.x suppose to be frozen? Does it : matter if I break the 5.1 ABI in current? For what its worth, this : change will also make the kobj method dispatch SMP safe (without locks). We can still break ABI with 5.1 if there's a good reason. Making things MP stafe is a good reason. : > : The same technique could be used to reduce the number of 'converter' : > : devices. : > : > I like this. pcic/cbb have similar issues, but the size of the : > problem is small. : : Its mainly a cosmetic thing but it has always been an irritation to me : to have these little clusters of devices where there is only one piece : of hardware, e.g.: : : hostb0 : pci0 : pcib1 : pci1 : amdpm0 : smbus0 : smb0 : : should become: : : pci0 : pci1 : amdpm0 Actually, the bridges do add value, so at least pcib would need to remain. I think it would be hard to get rid of them, but there could easily be something that I'm missing. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 09:30:33 2003 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 92E8D16A4BF for ; Wed, 10 Sep 2003 09:30:33 -0700 (PDT) Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3E3343FCB for ; Wed, 10 Sep 2003 09:30:32 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 10762 invoked from network); 10 Sep 2003 16:30:32 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 10 Sep 2003 16:30:32 -0000 Received: from laptop.baldwin.cx (p26.n-sfpop02.stsn.com [199.107.153.26]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8AGUR6Y040389; Wed, 10 Sep 2003 12:30:28 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <1063183655.43759.10.camel@herring.nlsystems.com> Date: Wed, 10 Sep 2003 12:30:49 -0400 (EDT) From: John Baldwin To: Doug Rabson X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@FreeBSD.org Subject: RE: When to burn those bridges 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: Wed, 10 Sep 2003 16:30:33 -0000 On 10-Sep-2003 Doug Rabson wrote: > On Wed, 2003-09-10 at 08:53, Eric Anholt wrote: >> On Wed, 2003-09-10 at 00:15, John Baldwin wrote: >> > On 09-Sep-2003 Doug Rabson wrote: >> > > I haven't been paying much attention recently on release engineering >> > > issues so probably I have missed something. When do people think is the >> > > right time to branch off the 5.x line of development and set fire to the >> > > bridges? >> > >> > Go ahead and kill the ISA compat drivers if you need to. I do think >> > that you can probably do this work in a p4 branch until it is ready >> > and delay the killing of compat shims until then maybe. >> > >> > > This led me back to the idea of multiple inheritance in kobj/newbus. >> > > Using multiple inheritance for the smbus re-work makes the chip drivers >> > > much simpler since they don't have to explicitly list the 'parent' >> > > methods in their method tables. The same thing goes for cardbus too. On >> > > these lines, I went back and read through Justin's old inheritance >> > > patches. These patches supported single inheritance for multiple >> > > interfaces at the cost of changing the driver API considerably. I've >> > > been tinkering with an alternative approach which supports multiple >> > > inheritance at the class level, almost preserving the driver API while >> > > changing the ABI slightly. >> > >> > Yes, please. There is the same problem with agp(4) and the hostb(4) >> > driver and agp(4) for Intel motherboards with onboard graphics and >> > the drm(4) driver for the same graphics chip. >> >> I thought we wanted agp(4) to replace hostb(4) when agp would attach. >> It's not the same problem for intel onboard graphics and the drm driver, >> then, since we need both drivers for the DRM to work. I think keithw >> solved this by making the agp driver provide a "drmsub" child device >> which the i8x0 DRM attaches to. Would there be any problems with >> putting that in CVS? > > That is exactly what Keith did for the i830. I have his patches for it > and I was supposed to review and commit them but they kind of got pushed > to the bottom of the pile due to my recent house move. Would you like to > do the honours? As far as I'm concerned, the patches are commit-ready > apart from some minor violations of style(9) which I don't really care > about but others might. We still get texture corruption on the i830 that we are tracking down. We also have several other problems with missed interrupts due to lack of spl() usage in DRM. I also have the patches and can try to clean them up and commit them once Keith signs off on them. Back to the hostb problem: notice that agp can't be kldloaded because it can't attach to hostb because hostb is attached to it. If agp were a separate device instance from teh hostb device, then you could kldload agp. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 09:59:21 2003 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 BC06016A4BF; Wed, 10 Sep 2003 09:59:21 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ED3043FF5; Wed, 10 Sep 2003 09:59:20 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id h8AGxESO091634; Wed, 10 Sep 2003 17:59:18 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h8AGx8Tj026519; Wed, 10 Sep 2003 17:59:08 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: John Baldwin In-Reply-To: References: Content-Type: text/plain Message-Id: <1063213147.26798.1.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 10 Sep 2003 17:59:08 +0100 Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.org Subject: RE: When to burn those bridges 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: Wed, 10 Sep 2003 16:59:22 -0000 On Wed, 2003-09-10 at 17:30, John Baldwin wrote: > On 10-Sep-2003 Doug Rabson wrote: > > On Wed, 2003-09-10 at 08:53, Eric Anholt wrote: > >> On Wed, 2003-09-10 at 00:15, John Baldwin wrote: > >> > On 09-Sep-2003 Doug Rabson wrote: > >> > > I haven't been paying much attention recently on release engineering > >> > > issues so probably I have missed something. When do people think is the > >> > > right time to branch off the 5.x line of development and set fire to the > >> > > bridges? > >> > > >> > Go ahead and kill the ISA compat drivers if you need to. I do think > >> > that you can probably do this work in a p4 branch until it is ready > >> > and delay the killing of compat shims until then maybe. > >> > > >> > > This led me back to the idea of multiple inheritance in kobj/newbus. > >> > > Using multiple inheritance for the smbus re-work makes the chip drivers > >> > > much simpler since they don't have to explicitly list the 'parent' > >> > > methods in their method tables. The same thing goes for cardbus too. On > >> > > these lines, I went back and read through Justin's old inheritance > >> > > patches. These patches supported single inheritance for multiple > >> > > interfaces at the cost of changing the driver API considerably. I've > >> > > been tinkering with an alternative approach which supports multiple > >> > > inheritance at the class level, almost preserving the driver API while > >> > > changing the ABI slightly. > >> > > >> > Yes, please. There is the same problem with agp(4) and the hostb(4) > >> > driver and agp(4) for Intel motherboards with onboard graphics and > >> > the drm(4) driver for the same graphics chip. > >> > >> I thought we wanted agp(4) to replace hostb(4) when agp would attach. > >> It's not the same problem for intel onboard graphics and the drm driver, > >> then, since we need both drivers for the DRM to work. I think keithw > >> solved this by making the agp driver provide a "drmsub" child device > >> which the i8x0 DRM attaches to. Would there be any problems with > >> putting that in CVS? > > > > That is exactly what Keith did for the i830. I have his patches for it > > and I was supposed to review and commit them but they kind of got pushed > > to the bottom of the pile due to my recent house move. Would you like to > > do the honours? As far as I'm concerned, the patches are commit-ready > > apart from some minor violations of style(9) which I don't really care > > about but others might. > > We still get texture corruption on the i830 that we are tracking down. > We also have several other problems with missed interrupts due to > lack of spl() usage in DRM. I also have the patches and can try > to clean them up and commit them once Keith signs off on them. > Back to the hostb problem: notice that agp can't be kldloaded because > it can't attach to hostb because hostb is attached to it. If agp > were a separate device instance from teh hostb device, then you could > kldload agp. My feeling about that was always that the hostb driver provides absolutely no added value in the system. When I was developing agp originally, I just nuked it and kldloading agp.ko worked just fine. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 10:00:46 2003 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 206AB16A4BF for ; Wed, 10 Sep 2003 10:00:46 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28C1A43FB1 for ; Wed, 10 Sep 2003 10:00:44 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br (dcs@[10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h8AH0Kj05451; Wed, 10 Sep 2003 14:00:20 -0300 Message-ID: <3F5F58A3.5030003@tcoip.com.br> Date: Wed, 10 Sep 2003 14:00:19 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030702 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: Peter Jeremy References: <5148.1063174847@critter.freebsd.dk> <20030910101410.GA4964@cirb503493.alcatel.com.au> In-Reply-To: <20030910101410.GA4964@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: The struct buf junta met... 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: Wed, 10 Sep 2003 17:00:46 -0000 Peter Jeremy wrote: > On Wed, Sep 10, 2003 at 08:20:47AM +0200, Poul-Henning Kamp wrote: > >>With the 5-stable branch (still) being 3-4 in the future, we want > > ^^ days, months, years? Releases, I assume. :-) > >>to get as much as the API changes into the stable branch as possible, >>in order to not do another "3.x mistake". > > > Sounds reasonable but how much will all these new features further > delay 5-stable whilst the bugs are ironed out? I agree that 3.x > caused heartache but having an "almost -stable" 5.x branch doesn't > help either. > > Peter > _______________________________________________ > 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" -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Now there's three things you can do in a baseball game: you can win or you can lose or it can rain. -- Casey Stengel From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 10:01:50 2003 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 B05ED16A4BF for ; Wed, 10 Sep 2003 10:01:50 -0700 (PDT) Received: from critter.freebsd.dk (p26.n-sfpop02.stsn.com [199.107.153.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABF8443FE1 for ; Wed, 10 Sep 2003 10:01:49 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h8AH1lEG007884; Wed, 10 Sep 2003 19:01:48 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: "Daniel C. Sobral" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 10 Sep 2003 14:00:19 -0300." <3F5F58A3.5030003@tcoip.com.br> Date: Wed, 10 Sep 2003 19:01:47 +0200 Message-ID: <7883.1063213307@critter.freebsd.dk> cc: Peter Jeremy cc: arch@freebsd.org Subject: Re: The struct buf junta met... 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: Wed, 10 Sep 2003 17:01:50 -0000 In message <3F5F58A3.5030003@tcoip.com.br>, "Daniel C. Sobral" writes: >Peter Jeremy wrote: >> On Wed, Sep 10, 2003 at 08:20:47AM +0200, Poul-Henning Kamp wrote: >> >>>With the 5-stable branch (still) being 3-4 in the future, we want >> >> ^^ days, months, years? > >Releases, I assume. :-) months actually. -- 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 Wed Sep 10 15:39:18 2003 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 B12C716A4BF for ; Wed, 10 Sep 2003 15:39:18 -0700 (PDT) Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7353943FE5 for ; Wed, 10 Sep 2003 15:39:17 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 20020 invoked from network); 10 Sep 2003 22:39:16 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 10 Sep 2003 22:39:16 -0000 Received: from laptop.baldwin.cx (p26.n-sfpop02.stsn.com [199.107.153.26]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8AMdB6Y043331; Wed, 10 Sep 2003 18:39:12 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <1063213147.26798.1.camel@builder02.qubesoft.com> Date: Wed, 10 Sep 2003 18:39:27 -0400 (EDT) From: John Baldwin To: Doug Rabson X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@FreeBSD.org Subject: RE: When to burn those bridges 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: Wed, 10 Sep 2003 22:39:18 -0000 On 10-Sep-2003 Doug Rabson wrote: > On Wed, 2003-09-10 at 17:30, John Baldwin wrote: >> On 10-Sep-2003 Doug Rabson wrote: >> > On Wed, 2003-09-10 at 08:53, Eric Anholt wrote: >> >> On Wed, 2003-09-10 at 00:15, John Baldwin wrote: >> >> > On 09-Sep-2003 Doug Rabson wrote: >> >> > > I haven't been paying much attention recently on release engineering >> >> > > issues so probably I have missed something. When do people think is the >> >> > > right time to branch off the 5.x line of development and set fire to the >> >> > > bridges? >> >> > >> >> > Go ahead and kill the ISA compat drivers if you need to. I do think >> >> > that you can probably do this work in a p4 branch until it is ready >> >> > and delay the killing of compat shims until then maybe. >> >> > >> >> > > This led me back to the idea of multiple inheritance in kobj/newbus. >> >> > > Using multiple inheritance for the smbus re-work makes the chip drivers >> >> > > much simpler since they don't have to explicitly list the 'parent' >> >> > > methods in their method tables. The same thing goes for cardbus too. On >> >> > > these lines, I went back and read through Justin's old inheritance >> >> > > patches. These patches supported single inheritance for multiple >> >> > > interfaces at the cost of changing the driver API considerably. I've >> >> > > been tinkering with an alternative approach which supports multiple >> >> > > inheritance at the class level, almost preserving the driver API while >> >> > > changing the ABI slightly. >> >> > >> >> > Yes, please. There is the same problem with agp(4) and the hostb(4) >> >> > driver and agp(4) for Intel motherboards with onboard graphics and >> >> > the drm(4) driver for the same graphics chip. >> >> >> >> I thought we wanted agp(4) to replace hostb(4) when agp would attach. >> >> It's not the same problem for intel onboard graphics and the drm driver, >> >> then, since we need both drivers for the DRM to work. I think keithw >> >> solved this by making the agp driver provide a "drmsub" child device >> >> which the i8x0 DRM attaches to. Would there be any problems with >> >> putting that in CVS? >> > >> > That is exactly what Keith did for the i830. I have his patches for it >> > and I was supposed to review and commit them but they kind of got pushed >> > to the bottom of the pile due to my recent house move. Would you like to >> > do the honours? As far as I'm concerned, the patches are commit-ready >> > apart from some minor violations of style(9) which I don't really care >> > about but others might. >> >> We still get texture corruption on the i830 that we are tracking down. >> We also have several other problems with missed interrupts due to >> lack of spl() usage in DRM. I also have the patches and can try >> to clean them up and commit them once Keith signs off on them. >> Back to the hostb problem: notice that agp can't be kldloaded because >> it can't attach to hostb because hostb is attached to it. If agp >> were a separate device instance from teh hostb device, then you could >> kldload agp. > > My feeling about that was always that the hostb driver provides > absolutely no added value in the system. When I was developing agp > originally, I just nuked it and kldloading agp.ko worked just fine. I don't mind if hostb were to die, but it does serve somewhat of a purpose. A dummy vga driver might also be useful with Warner's PCI power management stuff as well. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Thu Sep 11 01:46:06 2003 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 4191116A4BF; Thu, 11 Sep 2003 01:46:06 -0700 (PDT) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 288AD43FF7; Thu, 11 Sep 2003 01:46:00 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.12.9/8.12.8) with ESMTP id h8B8Tfgs059465; Thu, 11 Sep 2003 09:29:41 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: John Baldwin In-Reply-To: References: Content-Type: text/plain Message-Id: <1063268981.55877.9.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 11 Sep 2003 09:29:41 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@FreeBSD.org Subject: RE: When to burn those bridges 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, 11 Sep 2003 08:46:06 -0000 On Wed, 2003-09-10 at 23:39, John Baldwin wrote: > On 10-Sep-2003 Doug Rabson wrote: > > > > My feeling about that was always that the hostb driver provides > > absolutely no added value in the system. When I was developing agp > > originally, I just nuked it and kldloading agp.ko worked just fine. > > I don't mind if hostb were to die, but it does serve somewhat of a > purpose. A dummy vga driver might also be useful with Warner's PCI > power management stuff as well. A long time ago, I was thinking about a scheme where newbus would detach a driver which had attached to a device at a very low priority if a new driver was added via kldload. The way it might work is that a 'placeholder' driver like hostb would mark the device with a flag, e.g. device_set_placeholder. When a new driver is loaded, devices set as placeholders would be re-probed in bus_generic_driver_added as well as devices with no drivers at all. If the new driver probed with a higher value than the current placeholder driver, in device_probe_and_attach, the old driver would be detached and the new one attached. From owner-freebsd-arch@FreeBSD.ORG Thu Sep 11 07:06:17 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 683) id 6D7DB16A4C0; Thu, 11 Sep 2003 07:06:17 -0700 (PDT) Date: Thu, 11 Sep 2003 07:06:17 -0700 From: Eivind Eklund To: "Adam C. Migus" Message-ID: <20030911070617.A86202@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <57827.204.254.155.35.1063045587.squirrel@mail.migus.org> cc: Kris Kennaway cc: freebsd-arch@FreeBSD.org Subject: Re: config files in packages (Re: (proposal) new flag forpkg_delete) 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, 11 Sep 2003 14:06:17 -0000 On Mon, Sep 08, 2003 at 02:26:27PM -0400, Adam C. Migus wrote: [about ports/sysutils/etcmerge, 3-way merge for /etc] > I have been playing with your package for a little while now. I > like it so far and was waiting to see if you had anything else in > the way of enhancements for it prior to commenting (as you've only > released 0.2 thus far). You're point about the base install didn't > bother me as I was using it for diskless installations. > > I like both of your ideas, adapting it for ports and for sysinstall. > Have you received any feedback? Are there any known bugs or > limitations in the current revision that might preclude > experimentation with doing this now? I've not received any feedback beyond a single mail saying that it was not possible to run (because I'd tested a different version than I committed due to a problem with a PATH setting here), and that some people loved the program based on the description. There isn't any specific limitations that should block playing with it - the main thing I miss for it is that I haven't taken the time to compile a complete testsuite for it yet. The only known "bugs" is that the documentation isn't perfect (I know a number of things I'd like to fix in it, including documenting the options available), and that the options are specific for some commands instead of being general. Eivind. From owner-freebsd-arch@FreeBSD.ORG Thu Sep 11 07:51:01 2003 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 D360216A4BF for ; Thu, 11 Sep 2003 07:51:01 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9CD843FE3 for ; Thu, 11 Sep 2003 07:50:58 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4839 invoked from network); 11 Sep 2003 14:50:58 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 11 Sep 2003 14:50:58 -0000 Received: from laptop.baldwin.cx (p26.n-sfpop02.stsn.com [199.107.153.26]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8BEos6Y047929; Thu, 11 Sep 2003 10:50:54 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <1063268981.55877.9.camel@herring.nlsystems.com> Date: Thu, 11 Sep 2003 10:50:53 -0400 (EDT) From: John Baldwin To: Doug Rabson X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@FreeBSD.org Subject: RE: When to burn those bridges 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, 11 Sep 2003 14:51:01 -0000 On 11-Sep-2003 Doug Rabson wrote: > On Wed, 2003-09-10 at 23:39, John Baldwin wrote: >> On 10-Sep-2003 Doug Rabson wrote: >> > >> > My feeling about that was always that the hostb driver provides >> > absolutely no added value in the system. When I was developing agp >> > originally, I just nuked it and kldloading agp.ko worked just fine. >> >> I don't mind if hostb were to die, but it does serve somewhat of a >> purpose. A dummy vga driver might also be useful with Warner's PCI >> power management stuff as well. > > A long time ago, I was thinking about a scheme where newbus would detach > a driver which had attached to a device at a very low priority if a new > driver was added via kldload. > > The way it might work is that a 'placeholder' driver like hostb would > mark the device with a flag, e.g. device_set_placeholder. When a new > driver is loaded, devices set as placeholders would be re-probed in > bus_generic_driver_added as well as devices with no drivers at all. If > the new driver probed with a higher value than the current placeholder > driver, in device_probe_and_attach, the old driver would be detached and > the new one attached. I have thought about this as well, but instead of a placeholder flag, just doing this for any driver that returned a probe value != 0. This relies on very simple probes however, since ideally you would want to execute the new driver's probe and if it matches better, then you detach the old driver and attach the new one. This requires that the new driver's probe not try to alloc resources or dink with the hardware though. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Thu Sep 11 12:53:10 2003 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 29BAF16A4BF for ; Thu, 11 Sep 2003 12:53:10 -0700 (PDT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E1D443FD7 for ; Thu, 11 Sep 2003 12:53:09 -0700 (PDT) (envelope-from nsouch@perso.free.fr) Received: from armor.fastether (nas-cbv-8-62-147-156-37.dial.proxad.net [62.147.156.37]) by postfix4-1.free.fr (Postfix) with SMTP id 466AB4B2A9 for ; Thu, 11 Sep 2003 21:53:06 +0200 (CEST) Received: (qmail 5553 invoked by uid 1001); 11 Sep 2003 22:08:07 -0000 Date: Thu, 11 Sep 2003 22:08:07 +0000 From: Nicolas Souchu To: freebsd-arch@freebsd.org Message-ID: <20030911220807.A5528@armor.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i cc: Marcel Moolenaar Subject: kgi4BSD progress report 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, 11 Sep 2003 19:53:10 -0000 Hi folks, Just to keep you informed about my console project. The project URL is now http://www.freebsd.org/~nsouch/kgi4BSD kgi4BSD comes to the point where the console messages are printed in 640x400x8 graphic mode using the gfb boot font. There is still no virtual terminal handling because I'm not sure about it in the kernel. Regarding this I'd be glad to have opinions about having the VTs managed outside the kernel. You'll find the current design picted at http://www.freebsd.org/~nsouch/kgi4BSD/design-notes.html for the text version. Concerning graphic mode, one should replace the ISO renderer and the TEXT16 resource by a called GFB renderer with a KGI fb resource. Blocks in the diagram interact through a flexible kobj API. Now comes the point where we all want better modes and portability. Better modes should be provided by KGI native driver which currently can only be probed during bus enumeration. Currently, the KGI drivers rely on a PCI API looking like this: #if KGI_SYS_NEED_i64 typedef __kgi_u64_t pcicfg_vaddr_t; /* the virtual address type */ #define PCICFG_64_NULL ((pcicfg_vaddr_t) 0xFFFFFFFFFFFFFFFF) #define PCICFG_NULL PCICFG_64_NULL #else typedef __kgi_u32_t pcicfg_vaddr_t; /* the virtual address type */ #define PCICFG_32_NULL ((pcicfg_vaddr_t) 0xFFFF0000) /* an invalid virtual address */ #define PCICFG_NULL PCICFG_32_NULL #endif #define PCICFG_VADDR(bus, slot, fn) \ !((bus+1 > 0) || (slot+1 > 0) || (fn+1 > 0)) \ ? PCICFG_NULL \ : ( (pcicfg_vaddr_t) \ ((((bus) & 0xFF) << 24) | (PCI_DEVFN((slot),(fn)) << 16)) ) #define PCICFG_BUS(vaddr) (((vaddr) >> 24) & 0xFF) #define PCICFG_DEV(vaddr) PCI_SLOT(((vaddr) >> 16) & 0xFF) #define PCICFG_FN(vaddr) PCI_FUNC(((vaddr) >> 16) & 0xFF) #define PCICFG_REG(vaddr) ((vaddr) & 0xFFFF) #define PCICFG_SIGNATURE(vendor, device) ((vendor << 16) | device) /* * FreeBSD specific stuff */ extern pcicfg_vaddr_t pcicfg_dev2cfg(device_t dev); extern struct pcicfg_dev *pcicfg_lookup_device(pcicfg_vaddr_t pcidev); extern device_t pcicfg_get_device(pcicfg_vaddr_t pcidev); extern int pcicfg_add_device(device_t dev); extern int pcicfg_remove_device(device_t dev); extern void pcicfg_claim_device(pcicfg_vaddr_t addr); extern void pcicfg_free_device(pcicfg_vaddr_t addr); extern int pcicfg_find_device(pcicfg_vaddr_t *addr, const __kgi_u32_t *signatures); extern int pcicfg_find_subsystem(pcicfg_vaddr_t *addr, const __kgi_u32_t *signatures); extern int pcicfg_find_class(pcicfg_vaddr_t *addr, const __kgi_u32_t *signatures); extern __kgi_u8_t pcicfg_in8 (const pcicfg_vaddr_t vaddr); extern __kgi_u16_t pcicfg_in16(const pcicfg_vaddr_t vaddr); extern __kgi_u32_t pcicfg_in32(const pcicfg_vaddr_t vaddr); extern void pcicfg_out8 (const __kgi_u8_t val, const pcicfg_vaddr_t vaddr); extern void pcicfg_out16(const __kgi_u16_t val, const pcicfg_vaddr_t vaddr); extern void pcicfg_out32(const __kgi_u32_t val, const pcicfg_vaddr_t vaddr); Currently, this API is only a wrapper to the FreeBSD pci newbus/buspace API. But, for the boot, this API could be simply implemented with arch specific code for accessing the PCI space. Then the bus enumeration could take the pcicfg structures to reserve the resources already acquired by the graphic driver during boot. Another approach could be to unload the driver after boot and reload it with the more appropriate pcicfg API then based on newbus/buspace. This second solution would enforce to use kobj for the pcicfg to enable ABI compatibility between the 2 pcicfg implementations (avoiding relinking). We have to provide a convenient way to fully use the KGI drivers even with arch specific code at boot. All ideas/remarks are welcome. Nicholas -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Sep 11 14:34:33 2003 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 D6A6A16A4BF; Thu, 11 Sep 2003 14:34:33 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9D2D43FB1; Thu, 11 Sep 2003 14:34:32 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h8BLYUTX036667; Thu, 11 Sep 2003 15:34:31 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 11 Sep 2003 15:34:30 -0600 (MDT) Message-Id: <20030911.153430.91755961.imp@bsdimp.com> To: dfr@nlsystems.com From: "M. Warner Losh" In-Reply-To: <1063213147.26798.1.camel@builder02.qubesoft.com> References: <1063213147.26798.1.camel@builder02.qubesoft.com> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: When to burn those bridges 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, 11 Sep 2003 21:34:34 -0000 In message: <1063213147.26798.1.camel@builder02.qubesoft.com> Doug Rabson writes: : My feeling about that was always that the hostb driver provides : absolutely no added value in the system. When I was developing agp : originally, I just nuked it and kldloading agp.ko worked just fine. is that true even on systems with multiple host bridges? Warner From owner-freebsd-arch@FreeBSD.ORG Thu Sep 11 14:39:31 2003 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 7074816A4BF; Thu, 11 Sep 2003 14:39:31 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 569C243FEA; Thu, 11 Sep 2003 14:39:30 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h8BLdSTX036713; Thu, 11 Sep 2003 15:39:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 11 Sep 2003 15:39:29 -0600 (MDT) Message-Id: <20030911.153929.44983352.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <1063268981.55877.9.camel@herring.nlsystems.com> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: When to burn those bridges 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, 11 Sep 2003 21:39:31 -0000 In message: John Baldwin writes: : I have thought about this as well, but instead of a placeholder flag, : just doing this for any driver that returned a probe value != 0. : This relies on very simple probes however, since ideally you would : want to execute the new driver's probe and if it matches better, then : you detach the old driver and attach the new one. This requires : that the new driver's probe not try to alloc resources or dink with : the hardware though. I've thought seriously about just detatching the older driver, if possible. If that succeeds, we reprobe. This has the advantage of being easy to implement, but does cause a fair amount of churn. Besides, proble routines on self enumerating devices should look at the IDs that anybody can look at at any time. However, there are some issues with some drivers that have old/new versions or that need to ask the hardware what kind of thing it really is before making the call. These drivers are rare, thankfully, and even rarer are those that have different levels. owi/wi is the only one I know of that fits this bill, and the only reason owi is there is to help fix wi, so I don't think we should necessarily design to make this sort of thing too easy.... Warner From owner-freebsd-arch@FreeBSD.ORG Thu Sep 11 22:30:17 2003 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 A092A16A4BF for ; Thu, 11 Sep 2003 22:30:17 -0700 (PDT) Received: from mail.speakeasy.net (mail10.speakeasy.net [216.254.0.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5115A44001 for ; Thu, 11 Sep 2003 22:30:11 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9182 invoked from network); 12 Sep 2003 05:30:10 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 12 Sep 2003 05:30:10 -0000 Received: from laptop.baldwin.cx (p26.n-sfpop02.stsn.com [199.107.153.26]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8C5U66Y051468; Fri, 12 Sep 2003 01:30:07 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030911.153430.91755961.imp@bsdimp.com> Date: Fri, 12 Sep 2003 01:30:06 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: Re: When to burn those bridges 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, 12 Sep 2003 05:30:17 -0000 On 11-Sep-2003 M. Warner Losh wrote: > In message: <1063213147.26798.1.camel@builder02.qubesoft.com> > Doug Rabson writes: >: My feeling about that was always that the hostb driver provides >: absolutely no added value in the system. When I was developing agp >: originally, I just nuked it and kldloading agp.ko worked just fine. > > is that true even on systems with multiple host bridges? hostb exists to implement device_quiet(). :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Thu Sep 11 22:30:33 2003 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 16E7A16A4BF for ; Thu, 11 Sep 2003 22:30:33 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C8C44400E for ; Thu, 11 Sep 2003 22:30:32 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 823 invoked from network); 12 Sep 2003 05:30:31 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 12 Sep 2003 05:30:31 -0000 Received: from laptop.baldwin.cx (p26.n-sfpop02.stsn.com [199.107.153.26]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8C5UR6Y051473; Fri, 12 Sep 2003 01:30:28 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030911.153929.44983352.imp@bsdimp.com> Date: Fri, 12 Sep 2003 01:30:27 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: Re: When to burn those bridges 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, 12 Sep 2003 05:30:33 -0000 On 11-Sep-2003 M. Warner Losh wrote: > In message: > John Baldwin writes: >: I have thought about this as well, but instead of a placeholder flag, >: just doing this for any driver that returned a probe value != 0. >: This relies on very simple probes however, since ideally you would >: want to execute the new driver's probe and if it matches better, then >: you detach the old driver and attach the new one. This requires >: that the new driver's probe not try to alloc resources or dink with >: the hardware though. > > I've thought seriously about just detatching the older driver, if > possible. If that succeeds, we reprobe. This has the advantage of > being easy to implement, but does cause a fair amount of churn. How do you know which drivers to detach? Are you going to detach the generic PCI ATA driver on every kldload? Are you going to detach the generic PCI-PCI bridge driver for PCI-PCI bridges on add-on cards for every kldload of a PCI driver? That would be freaking insane. The problem is that you don't know what devices a new driver might be more suitable for than existing drivers. > Besides, proble routines on self enumerating devices should look at > the IDs that anybody can look at at any time. However, there are some > issues with some drivers that have old/new versions or that need to > ask the hardware what kind of thing it really is before making the > call. These drivers are rare, thankfully, and even rarer are those > that have different levels. owi/wi is the only one I know of that > fits this bill, and the only reason owi is there is to help fix wi, so > I don't think we should necessarily design to make this sort of thing > too easy.... rl(4) and re(4)? Several drivers still allocate resources in probe(), which would break things. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Fri Sep 12 00:39:18 2003 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 AB09F16A4BF; Fri, 12 Sep 2003 00:39:18 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A59C43FE3; Fri, 12 Sep 2003 00:39:17 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h8C7dFTX039915; Fri, 12 Sep 2003 01:39:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 12 Sep 2003 01:39:11 -0600 (MDT) Message-Id: <20030912.013911.13774129.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20030911.153929.44983352.imp@bsdimp.com> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: When to burn those bridges 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, 12 Sep 2003 07:39:18 -0000 In message: John Baldwin writes: : How do you know which drivers to detach? Are you going to detach : the generic PCI ATA driver on every kldload? Are you going to : detach the generic PCI-PCI bridge driver for PCI-PCI bridges on : add-on cards for every kldload of a PCI driver? That would be : freaking insane. The problem is that you don't know what devices : a new driver might be more suitable for than existing drivers. This does suck. : > Besides, proble routines on self enumerating devices should look at : > the IDs that anybody can look at at any time. However, there are some : > issues with some drivers that have old/new versions or that need to : > ask the hardware what kind of thing it really is before making the : > call. These drivers are rare, thankfully, and even rarer are those : > that have different levels. owi/wi is the only one I know of that : > fits this bill, and the only reason owi is there is to help fix wi, so : > I don't think we should necessarily design to make this sort of thing : > too easy.... : : rl(4) and re(4)? Several drivers still allocate resources in probe(), : which would break things. yea, but that's a bit of a pathological case. first, rl/re attach to a specific driver, and not override. So maybe we could mandate that drivers that are generic and return negative return values should be constrained to only look at the plug and play info and are not allowed to look at resources. owi/wi is the only pair that does this evilness. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Sep 12 01:05:20 2003 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 96A3416A4BF; Fri, 12 Sep 2003 01:05:20 -0700 (PDT) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 185AA43FF2; Fri, 12 Sep 2003 01:05:19 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.12.9/8.12.8) with ESMTP id h8C84egs008780; Fri, 12 Sep 2003 09:04:40 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: "M. Warner Losh" In-Reply-To: <20030912.013911.13774129.imp@bsdimp.com> References: <20030911.153929.44983352.imp@bsdimp.com> <20030912.013911.13774129.imp@bsdimp.com> Content-Type: text/plain Message-Id: <1063353880.5536.6.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 12 Sep 2003 09:04:40 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: Re: When to burn those bridges 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, 12 Sep 2003 08:05:20 -0000 On Fri, 2003-09-12 at 08:39, M. Warner Losh wrote: > In message: > John Baldwin writes: > : How do you know which drivers to detach? Are you going to detach > : the generic PCI ATA driver on every kldload? Are you going to > : detach the generic PCI-PCI bridge driver for PCI-PCI bridges on > : add-on cards for every kldload of a PCI driver? That would be > : freaking insane. The problem is that you don't know what devices > : a new driver might be more suitable for than existing drivers. > > This does suck. > > : > Besides, proble routines on self enumerating devices should look at > : > the IDs that anybody can look at at any time. However, there are some > : > issues with some drivers that have old/new versions or that need to > : > ask the hardware what kind of thing it really is before making the > : > call. These drivers are rare, thankfully, and even rarer are those > : > that have different levels. owi/wi is the only one I know of that > : > fits this bill, and the only reason owi is there is to help fix wi, so > : > I don't think we should necessarily design to make this sort of thing > : > too easy.... > : > : rl(4) and re(4)? Several drivers still allocate resources in probe(), > : which would break things. > > yea, but that's a bit of a pathological case. first, rl/re attach to > a specific driver, and not override. So maybe we could mandate that > drivers that are generic and return negative return values should be > constrained to only look at the plug and play info and are not allowed > to look at resources. owi/wi is the only pair that does this > evilness. This is why I was thinking about a device flag which a driver would set if it is just a placeholder which can be pre-empted safely. From owner-freebsd-arch@FreeBSD.ORG Fri Sep 12 01:08:06 2003 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 03D0116A4BF; Fri, 12 Sep 2003 01:08:06 -0700 (PDT) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBDBF43F93; Fri, 12 Sep 2003 01:08:04 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.12.9/8.12.8) with ESMTP id h8C87hgs008802; Fri, 12 Sep 2003 09:07:43 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: "M. Warner Losh" In-Reply-To: <20030911.153430.91755961.imp@bsdimp.com> References: <1063213147.26798.1.camel@builder02.qubesoft.com> <20030911.153430.91755961.imp@bsdimp.com> Content-Type: text/plain Message-Id: <1063354063.5536.10.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 12 Sep 2003 09:07:43 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: Re: When to burn those bridges 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, 12 Sep 2003 08:08:06 -0000 On Thu, 2003-09-11 at 22:34, M. Warner Losh wrote: > In message: <1063213147.26798.1.camel@builder02.qubesoft.com> > Doug Rabson writes: > : My feeling about that was always that the hostb driver provides > : absolutely no added value in the system. When I was developing agp > : originally, I just nuked it and kldloading agp.ko worked just fine. > > is that true even on systems with multiple host bridges? Yes. The host bridges are normally either attached as pcib devices to the nexus or handled by acpi. The hostb driver just matches against the pci devices during the toplevel pci scan and then quietens the attach so that the user doesn't appear to see the device twice. From owner-freebsd-arch@FreeBSD.ORG Fri Sep 12 08:17:09 2003 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 0A19916A4BF; Fri, 12 Sep 2003 08:17:09 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 584D143FDF; Fri, 12 Sep 2003 08:17:08 -0700 (PDT) (envelope-from sam@errno.com) Received: from [10.0.3.253] (p26.n-sfpop02.stsn.com [199.107.153.26]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h8CFH017099004 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 12 Sep 2003 08:17:03 -0700 (PDT) (envelope-from sam@errno.com) Date: Fri, 12 Sep 2003 08:23:01 -0700 From: Sam Leffler To: "M. Warner Losh" , jhb@freebsd.org Message-ID: <979999.1063354981@[10.0.3.253]> In-Reply-To: <20030912.013911.13774129.imp@bsdimp.com> References: <20030911.153929.44983352.imp@bsdimp.com> <20030912.013911.13774129.imp@bsdimp.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-DCC-Servercave-Metrics: ebb.errno.com 1183; Body=3 Fuz1=3 Fuz2=3 cc: arch@freebsd.org Subject: Re: When to burn those bridges 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, 12 Sep 2003 15:17:09 -0000 > yea, but that's a bit of a pathological case. first, rl/re attach to > a specific driver, and not override. So maybe we could mandate that > drivers that are generic and return negative return values should be > constrained to only look at the plug and play info and are not allowed > to look at resources. owi/wi is the only pair that does this > evilness. Magic return values are evil; better to use longer-lasting state like flags associated with the driver. Sam From owner-freebsd-arch@FreeBSD.ORG Fri Sep 12 11:26:37 2003 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 C762B16A4D6 for ; Fri, 12 Sep 2003 11:26:37 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id E39EC43FE0 for ; Fri, 12 Sep 2003 11:26:36 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24706 invoked from network); 12 Sep 2003 18:26:36 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 12 Sep 2003 18:26:36 -0000 Received: from laptop.baldwin.cx (p26.n-sfpop02.stsn.com [199.107.153.26]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8CIQV6Y055420; Fri, 12 Sep 2003 14:26:31 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <1063353880.5536.6.camel@herring.nlsystems.com> Date: Fri, 12 Sep 2003 14:26:30 -0400 (EDT) From: John Baldwin To: Doug Rabson X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org cc: "M. Warner Losh" Subject: Re: When to burn those bridges 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, 12 Sep 2003 18:26:37 -0000 On 12-Sep-2003 Doug Rabson wrote: > On Fri, 2003-09-12 at 08:39, M. Warner Losh wrote: >> In message: >> John Baldwin writes: >> : How do you know which drivers to detach? Are you going to detach >> : the generic PCI ATA driver on every kldload? Are you going to >> : detach the generic PCI-PCI bridge driver for PCI-PCI bridges on >> : add-on cards for every kldload of a PCI driver? That would be >> : freaking insane. The problem is that you don't know what devices >> : a new driver might be more suitable for than existing drivers. >> >> This does suck. >> >> : > Besides, proble routines on self enumerating devices should look at >> : > the IDs that anybody can look at at any time. However, there are some >> : > issues with some drivers that have old/new versions or that need to >> : > ask the hardware what kind of thing it really is before making the >> : > call. These drivers are rare, thankfully, and even rarer are those >> : > that have different levels. owi/wi is the only one I know of that >> : > fits this bill, and the only reason owi is there is to help fix wi, so >> : > I don't think we should necessarily design to make this sort of thing >> : > too easy.... >> : >> : rl(4) and re(4)? Several drivers still allocate resources in probe(), >> : which would break things. >> >> yea, but that's a bit of a pathological case. first, rl/re attach to >> a specific driver, and not override. So maybe we could mandate that >> drivers that are generic and return negative return values should be >> constrained to only look at the plug and play info and are not allowed >> to look at resources. owi/wi is the only pair that does this >> evilness. > > This is why I was thinking about a device flag which a driver would set > if it is just a placeholder which can be pre-empted safely. Yes, I wish we had better drivers so we didn't have to do that, but that might be the best for now. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/