From owner-freebsd-arch@FreeBSD.ORG Sun Jul 18 03:16:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63F8716A4CE for ; Sun, 18 Jul 2004 03:16:00 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33FAA43D31 for ; Sun, 18 Jul 2004 03:16:00 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.12.11/8.12.11) with ESMTP id i6I3FsgF035917; Sat, 17 Jul 2004 20:15:54 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i6I3FsYp035916; Sat, 17 Jul 2004 20:15:54 -0700 (PDT) (envelope-from obrien) Date: Sat, 17 Jul 2004 20:15:54 -0700 From: "David O'Brien" To: Nicolas Souchu Message-ID: <20040718031554.GF1070@dragon.nuxi.com> References: <20040716220848.A35405@armor.freesurf.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040716220848.A35405@armor.freesurf.fr> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: rmh@debian.org cc: freebsd-arch@freebsd.org Subject: Re: some PRs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2004 03:16:00 -0000 On Fri, Jul 16, 2004 at 10:08:48PM +0200, Nicolas Souchu wrote: > Patchs like: > http://www.freebsd.org/cgi/query-pr.cgi?pr=68961 What in the world is this patch (ie, /dev/full) for?? I just don't see the point in /dev/full. Could you please give some good examples of its use? Also what "Un*x OSes" besides Linux has this? -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Sun Jul 18 13:33:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0005016A4CE for ; Sun, 18 Jul 2004 13:33:27 +0000 (GMT) Received: from khazad.dyndns.org (86.Red-80-24-13.pooles.rima-tde.net [80.24.13.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 799C243D2D for ; Sun, 18 Jul 2004 13:33:27 +0000 (GMT) (envelope-from rmh@khazad.dyndns.org) Received: from rmh by khazad.dyndns.org with local (Exim 3.36 #1 (Debian)) id 1BmBnG-0005TR-00; Sun, 18 Jul 2004 15:33:30 +0200 Date: Sun, 18 Jul 2004 15:33:30 +0200 From: Robert Millan To: freebsd-arch@freebsd.org Message-ID: <20040718133330.GA21009@khazad.dyndns.org> References: <20040716220848.A35405@armor.freesurf.fr> <20040718031554.GF1070@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040718031554.GF1070@dragon.nuxi.com> Organisation: free as in freedom User-Agent: Mutt/1.5.6+20040523i Sender: cc: Nicolas Souch Subject: Re: some PRs 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, 18 Jul 2004 13:33:28 -0000 On Sat, Jul 17, 2004 at 08:15:54PM -0700, David O'Brien wrote: > On Fri, Jul 16, 2004 at 10:08:48PM +0200, Nicolas Souchu wrote: > > Patchs like: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=68961 > > What in the world is this patch (ie, /dev/full) for?? > I just don't see the point in /dev/full. Could you please give some good > examples of its use? I think it's useful for compatibility. > Also what "Un*x OSes" besides Linux has this? Asides Linux, I only know of the Hurd providing it. But there might be other kernels. -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion) From owner-freebsd-arch@FreeBSD.ORG Sun Jul 18 15:07:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEDC916A4CE for ; Sun, 18 Jul 2004 15:07:28 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07F7543D3F for ; Sun, 18 Jul 2004 15:07:28 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 0AA1A65339; Sun, 18 Jul 2004 16:07:26 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 85508-04; Sun, 18 Jul 2004 16:07:25 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 561A365218; Sun, 18 Jul 2004 16:07:25 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 3B75D61AA; Sun, 18 Jul 2004 16:07:24 +0100 (BST) Date: Sun, 18 Jul 2004 16:07:24 +0100 From: Bruce M Simpson To: Robert Millan Message-ID: <20040718150723.GC87575@empiric.dek.spc.org> References: <20040716220848.A35405@armor.freesurf.fr> <20040718031554.GF1070@dragon.nuxi.com> <20040718133330.GA21009@khazad.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040718133330.GA21009@khazad.dyndns.org> cc: Nicolas Souch cc: freebsd-arch@freebsd.org Subject: Re: some PRs 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, 18 Jul 2004 15:07:28 -0000 On Sun, Jul 18, 2004 at 03:33:30PM +0200, Robert Millan wrote: > > What in the world is this patch (ie, /dev/full) for?? > > I just don't see the point in /dev/full. Could you please give some good > > examples of its use? > > I think it's useful for compatibility. Whilst I'm grateful that you've taken time to submit a patch, you still haven't really explained which applications require this device to exist and be supported. > > Also what "Un*x OSes" besides Linux has this? > > Asides Linux, I only know of the Hurd providing it. But there might be > other kernels. It seems to me, though, that it might be better as part of the Linux emulation code eventually, as hardly anything seems to require it. Regards, BMS From owner-freebsd-arch@FreeBSD.ORG Sun Jul 18 16:31:41 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A13F16A4CE for ; Sun, 18 Jul 2004 16:31:41 +0000 (GMT) Received: from pinky.otenet.gr (pinky.otenet.gr [195.170.0.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23C8743D3F for ; Sun, 18 Jul 2004 16:31:40 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-b221.otenet.gr [212.205.244.229]) i6IGVCcK025142; Sun, 18 Jul 2004 19:31:26 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.12.11/8.12.11) with ESMTP id i6IFGpAj053707; Sun, 18 Jul 2004 18:16:51 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.12.11/8.12.11/Submit) id i6IFGoFf053706; Sun, 18 Jul 2004 18:16:50 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 18 Jul 2004 18:16:49 +0300 From: Giorgos Keramidas To: Robert Millan Message-ID: <20040718151649.GA53675@gothmog.gr> References: <20040716220848.A35405@armor.freesurf.fr> <20040718031554.GF1070@dragon.nuxi.com> <20040718133330.GA21009@khazad.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040718133330.GA21009@khazad.dyndns.org> cc: Nicolas Souch cc: freebsd-arch@freebsd.org Subject: Re: some PRs 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, 18 Jul 2004 16:31:41 -0000 On 2004-07-18 15:33, Robert Millan wrote: > On Sat, Jul 17, 2004 at 08:15:54PM -0700, David O'Brien wrote: > > On Fri, Jul 16, 2004 at 10:08:48PM +0200, Nicolas Souchu wrote: > > > Patchs like: > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=68961 > > > > What in the world is this patch (ie, /dev/full) for?? > > I just don't see the point in /dev/full. Could you please give some good > > examples of its use? > > I think it's useful for compatibility. In general, I'm not against compatibility. However, what's the end of this route? To create one special device node in /dev for every possible errno value? :-( - Giorgos From owner-freebsd-arch@FreeBSD.ORG Sun Jul 18 16:35:41 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29C8216A4CE for ; Sun, 18 Jul 2004 16:35:41 +0000 (GMT) Received: from khazad.dyndns.org (86.Red-80-24-13.pooles.rima-tde.net [80.24.13.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FA5C43D5D for ; Sun, 18 Jul 2004 16:35:40 +0000 (GMT) (envelope-from rmh@khazad.dyndns.org) Received: from rmh by khazad.dyndns.org with local (Exim 3.36 #1 (Debian)) id 1BmEdX-0002sD-00; Sun, 18 Jul 2004 18:35:39 +0200 Date: Sun, 18 Jul 2004 18:35:39 +0200 From: Robert Millan To: Bruce M Simpson Message-ID: <20040718163539.GA22126@khazad.dyndns.org> References: <20040716220848.A35405@armor.freesurf.fr> <20040718031554.GF1070@dragon.nuxi.com> <20040718133330.GA21009@khazad.dyndns.org> <20040718150723.GC87575@empiric.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040718150723.GC87575@empiric.dek.spc.org> Organisation: free as in freedom User-Agent: Mutt/1.5.6+20040523i Sender: cc: Nicolas Souch cc: freebsd-arch@freebsd.org Subject: Re: some PRs 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, 18 Jul 2004 16:35:41 -0000 On Sun, Jul 18, 2004 at 04:07:24PM +0100, Bruce M Simpson wrote: > On Sun, Jul 18, 2004 at 03:33:30PM +0200, Robert Millan wrote: > > > What in the world is this patch (ie, /dev/full) for?? > > > I just don't see the point in /dev/full. Could you please give some good > > > examples of its use? > > > > I think it's useful for compatibility. > > Whilst I'm grateful that you've taken time to submit a patch, you still > haven't really explained which applications require this device to exist > and be supported. I only could find 'bsdgames' (to be found at ftp://sunsite.unc.edu/pub/Linux/games/). The test suite for battlestar assumes /dev/full existance. However, as for each Linuxism around, people tend to reproduce it, so there might be others. (yes, it know it's ironical that bsdgames doesn't work on FreeBSD, but let's skip that ;) -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion) From owner-freebsd-arch@FreeBSD.ORG Sun Jul 18 16:51:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 472B016A4CE for ; Sun, 18 Jul 2004 16:51:43 +0000 (GMT) Received: from khazad.dyndns.org (86.Red-80-24-13.pooles.rima-tde.net [80.24.13.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC08743D31 for ; Sun, 18 Jul 2004 16:51:42 +0000 (GMT) (envelope-from rmh@khazad.dyndns.org) Received: from rmh by khazad.dyndns.org with local (Exim 3.36 #1 (Debian)) id 1BmEt4-0004SP-00; Sun, 18 Jul 2004 18:51:42 +0200 Date: Sun, 18 Jul 2004 18:51:42 +0200 From: Robert Millan To: Giorgos Keramidas Message-ID: <20040718165142.GA17142@khazad.dyndns.org> References: <20040716220848.A35405@armor.freesurf.fr> <20040718031554.GF1070@dragon.nuxi.com> <20040718133330.GA21009@khazad.dyndns.org> <20040718151649.GA53675@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040718151649.GA53675@gothmog.gr> Organisation: free as in freedom User-Agent: Mutt/1.5.6+20040523i Sender: cc: Nicolas Souch cc: freebsd-arch@freebsd.org Subject: Re: some PRs 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, 18 Jul 2004 16:51:43 -0000 On Sun, Jul 18, 2004 at 06:16:49PM +0300, Giorgos Keramidas wrote: > On 2004-07-18 15:33, Robert Millan wrote: > > > > I think it's useful for compatibility. > > In general, I'm not against compatibility. However, what's the end of > this route? To create one special device node in /dev for every > possible errno value? :-( I don't claim that /dev/full is useful just for the sake of it. Your argument (that having a device just for each errno value is silly) is something I basicaly agree with. But if some applications depend on it, it's still helpful for portability. I don't know what support for native compatibility is expected or planned for FreeBSD, but I know you have a Ports Collection with thousands of packages, and this might minimaly reduce the work of your port maintainers. IMHO, you should ask the people working in the Ports Collection for their opinion before taking a decision. (Note this patch comes from the context of the Debian GNU/kFreeBSD porting effort, in which we port Debian GNU/Linux packages, which are a bit more likely to introduce Linuxisms than the average candidate for FreeBSD Ports. Thus, our requirements might differ somewhat.) -- Robert Millan "[..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work." -- J.R.R.T., Ainulindale (Silmarillion) From owner-freebsd-arch@FreeBSD.ORG Sun Jul 18 17:51:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 578F916A4CE for ; Sun, 18 Jul 2004 17:51:19 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 199FE43D2D for ; Sun, 18 Jul 2004 17:51:19 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-75-142.dsl.lsan03.pacbell.net [67.115.75.142]) i6IHp1j2014473; Sun, 18 Jul 2004 13:51:06 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5C2B052BDC; Sun, 18 Jul 2004 10:51:00 -0700 (PDT) Date: Sun, 18 Jul 2004 10:51:00 -0700 From: Kris Kennaway To: Robert Millan Message-ID: <20040718175100.GA27990@xor.obsecurity.org> References: <20040716220848.A35405@armor.freesurf.fr> <20040718031554.GF1070@dragon.nuxi.com> <20040718133330.GA21009@khazad.dyndns.org> <20040718151649.GA53675@gothmog.gr> <20040718165142.GA17142@khazad.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <20040718165142.GA17142@khazad.dyndns.org> User-Agent: Mutt/1.4.2.1i cc: Giorgos Keramidas cc: Nicolas Souch cc: freebsd-arch@freebsd.org Subject: Re: some PRs 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, 18 Jul 2004 17:51:19 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 18, 2004 at 06:51:42PM +0200, Robert Millan wrote: > On Sun, Jul 18, 2004 at 06:16:49PM +0300, Giorgos Keramidas wrote: > > On 2004-07-18 15:33, Robert Millan wrote: > > > > > > I think it's useful for compatibility. > >=20 > > In general, I'm not against compatibility. However, what's the end of > > this route? To create one special device node in /dev for every > > possible errno value? :-( >=20 > I don't claim that /dev/full is useful just for the sake of it. Your argu= ment > (that having a device just for each errno value is silly) is something I > basicaly agree with. >=20 > But if some applications depend on it, it's still helpful for portability. > I don't know what support for native compatibility is expected or planned= for > FreeBSD, but I know you have a Ports Collection with thousands of package= s, > and this might minimaly reduce the work of your port maintainers. IMHO, y= ou > should ask the people working in the Ports Collection for their opinion b= efore > taking a decision. >=20 > (Note this patch comes from the context of the Debian GNU/kFreeBSD porting > effort, in which we port Debian GNU/Linux packages, which are a bit more > likely to introduce Linuxisms than the average candidate for FreeBSD Port= s. > Thus, our requirements might differ somewhat.) There's no mention of /dev/full in the build logs (e.g. configure script output) of any of the 11000-odd ports in the ports collection. Kris --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA+riEWry0BWjoQKURAtwaAKD/c9VAiA791uSCbAegSlIhatiYewCg0dXz 1TIldHrg41/8zUK/INE1TnA= =txr6 -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- From owner-freebsd-arch@FreeBSD.ORG Sun Jul 18 18:40:10 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9562B16A4CE for ; Sun, 18 Jul 2004 18:40:10 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B13943D2D for ; Sun, 18 Jul 2004 18:40:10 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id B119BACAE0; Sun, 18 Jul 2004 20:40:08 +0200 (CEST) Date: Sun, 18 Jul 2004 20:40:08 +0200 From: Pawel Jakub Dawidek To: Robert Millan Message-ID: <20040718184008.GC57678@darkness.comp.waw.pl> References: <20040716220848.A35405@armor.freesurf.fr> <20040718031554.GF1070@dragon.nuxi.com> <20040718133330.GA21009@khazad.dyndns.org> <20040718151649.GA53675@gothmog.gr> <20040718165142.GA17142@khazad.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline In-Reply-To: <20040718165142.GA17142@khazad.dyndns.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: Giorgos Keramidas cc: Nicolas Souch cc: freebsd-arch@freebsd.org Subject: Re: some PRs 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, 18 Jul 2004 18:40:10 -0000 --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 18, 2004 at 06:51:42PM +0200, Robert Millan wrote: +> I don't claim that /dev/full is useful just for the sake of it. Your arg= ument +> (that having a device just for each errno value is silly) is something I +> basicaly agree with. Even if it is used by some programms, I don't see it in the base system. It can be always implemented as a kernel module and maintained outside the tree. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA+sQIForvXbEpPzQRAoW5AJ4p/NaefPtQkjDX4LzFda+h6ETWnACbBdO4 mUO+Cymezcd6cxer8StaUjo= =EPt4 -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- From owner-freebsd-arch@FreeBSD.ORG Mon Jul 19 06:46:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF4F916A4CE for ; Mon, 19 Jul 2004 06:46:28 +0000 (GMT) Received: from aries3.ieee.org (fett-ext.ieee.org [140.98.210.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54B9C43D3F for ; Mon, 19 Jul 2004 06:46:28 +0000 (GMT) (envelope-from m.autoreply@ieee.org) Received: from buzz.ieee.org (localhost [127.0.0.1]) with ESMTP id i6J6kQbb022678 for ; Mon, 19 Jul 2004 02:46:26 -0400 (EDT) From: m.autoreply@ieee.org To: freebsd-arch@freebsd.org Message-ID: Date: Mon, 19 Jul 2004 02:47:45 -0400 X-MIMETrack: Serialize by Router on Buzz/US/IEEE(Release 5.0.12 |February 13, 2003) at 07/19/2004 02:46:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63-ieee_anti_spam (2004-01-11) on aries3.ieee.org Subject: X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: m.autoreply@ieee.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2004 06:46:29 -0000 Thank you for your email. IEEE Member Services has received and will respond to your email as soon as possible. Our business hours are 8:00 A.M.- 5:00 P.M., ET, Monday through Friday. PLEASE DO NOT REPLY TO THIS EMAIL. Thank you, IEEE Member Services 445 Hoes Lane Piscataway, NJ 08854 U.S.A. Telephone: +1 800 678 4333 (US and Canada), +1 732 981 0060 (Worldwide) Fax number: +1 732 562 6380 Contact us online: http://www.ieee.org/memberservices Visit the IEEE at: www.ieee.org From owner-freebsd-arch@FreeBSD.ORG Mon Jul 19 06:59:30 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90E3416A4CE; Mon, 19 Jul 2004 06:59:30 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3652A43D48; Mon, 19 Jul 2004 06:59:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i6J6wPuN021234; Mon, 19 Jul 2004 00:58:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 19 Jul 2004 00:58:25 -0600 (MDT) Message-Id: <20040719.005825.26202805.imp@bsdimp.com> To: pjd@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040718184008.GC57678@darkness.comp.waw.pl> References: <20040718151649.GA53675@gothmog.gr> <20040718165142.GA17142@khazad.dyndns.org> <20040718184008.GC57678@darkness.comp.waw.pl> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: keramida@ceid.upatras.gr cc: zeratul2@wanadoo.es cc: nsouch@free.fr cc: freebsd-arch@freebsd.org Subject: Re: some PRs 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, 19 Jul 2004 06:59:30 -0000 In message: <20040718184008.GC57678@darkness.comp.waw.pl> Pawel Jakub Dawidek writes: : On Sun, Jul 18, 2004 at 06:51:42PM +0200, Robert Millan wrote: : +> I don't claim that /dev/full is useful just for the sake of it. Your argument : +> (that having a device just for each errno value is silly) is something I : +> basicaly agree with. : : Even if it is used by some programms, I don't see it in the base system. : It can be always implemented as a kernel module and maintained outside : the tree. Given that it is implemented in this driver in about 20 lines, I think that it makes sense to have it in the base. Suggesting it be maintained outside of the tree is just plain silly. It should be brought in or abadoned. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jul 19 07:59:55 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C475A16A4CE for ; Mon, 19 Jul 2004 07:59:55 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67D0743D45 for ; Mon, 19 Jul 2004 07:59:55 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id C2C45ACADB; Mon, 19 Jul 2004 09:59:52 +0200 (CEST) Date: Mon, 19 Jul 2004 09:59:52 +0200 From: Pawel Jakub Dawidek To: "M. Warner Losh" Message-ID: <20040719075952.GG57678@darkness.comp.waw.pl> References: <20040718151649.GA53675@gothmog.gr> <20040718165142.GA17142@khazad.dyndns.org> <20040718184008.GC57678@darkness.comp.waw.pl> <20040719.005825.26202805.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VACxsDaSTfeluoxK" Content-Disposition: inline In-Reply-To: <20040719.005825.26202805.imp@bsdimp.com> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: keramida@ceid.upatras.gr cc: zeratul2@wanadoo.es cc: nsouch@free.fr cc: freebsd-arch@freebsd.org Subject: Re: some PRs 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, 19 Jul 2004 07:59:55 -0000 --VACxsDaSTfeluoxK Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 19, 2004 at 12:58:25AM -0600, M. Warner Losh wrote: +> : Even if it is used by some programms, I don't see it in the base syste= m. +> : It can be always implemented as a kernel module and maintained outside +> : the tree. +>=20 +> Given that it is implemented in this driver in about 20 lines, I think +> that it makes sense to have it in the base. Suggesting it be +> maintained outside of the tree is just plain silly. It should be +> brought in or abadoned. It isn't even used by one of our 11000 ports and you want to bring it into base system? We don't have other devices in the tree, which are actually used by some ports. I still think, that if a port which is using /dev/full will be created, device should be maintained there. EOT. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --VACxsDaSTfeluoxK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA+394ForvXbEpPzQRAmWaAKCo1rdLZDTGtjPEWYDo4wK1HFVcQACfQJ7a wKlGPcdV5Z2pzBg9MgjHt48= =K9TJ -----END PGP SIGNATURE----- --VACxsDaSTfeluoxK-- From owner-freebsd-arch@FreeBSD.ORG Mon Jul 19 14:14:46 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03DBC16A4CF; Mon, 19 Jul 2004 14:14:46 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5037443D3F; Mon, 19 Jul 2004 14:14:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i6JEDtTF028787; Mon, 19 Jul 2004 08:13:55 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 19 Jul 2004 08:13:56 -0600 (MDT) Message-Id: <20040719.081356.51946167.imp@bsdimp.com> To: pjd@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20040719075952.GG57678@darkness.comp.waw.pl> References: <20040718184008.GC57678@darkness.comp.waw.pl> <20040719.005825.26202805.imp@bsdimp.com> <20040719075952.GG57678@darkness.comp.waw.pl> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: keramida@ceid.upatras.gr cc: zeratul2@wanadoo.es cc: nsouch@free.fr cc: freebsd-arch@FreeBSD.org Subject: Re: some PRs 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, 19 Jul 2004 14:14:46 -0000 In message: <20040719075952.GG57678@darkness.comp.waw.pl> Pawel Jakub Dawidek writes: : On Mon, Jul 19, 2004 at 12:58:25AM -0600, M. Warner Losh wrote: : +> : Even if it is used by some programms, I don't see it in the base system. : +> : It can be always implemented as a kernel module and maintained outside : +> : the tree. : +> : +> Given that it is implemented in this driver in about 20 lines, I think : +> that it makes sense to have it in the base. Suggesting it be : +> maintained outside of the tree is just plain silly. It should be : +> brought in or abadoned. : : It isn't even used by one of our 11000 ports and you want to bring it : into base system? We don't have other devices in the tree, which are : actually used by some ports. I still think, that if a port which is using : /dev/full will be created, device should be maintained there. : EOT. I guess my point is that that creates so much more work that it seems like overkill. We often put things into the base system for compatibility, but rely on out of system things for higher level functionality. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jul 19 16:57:31 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80DF116A4CE; Mon, 19 Jul 2004 16:57:31 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BE9A43D39; Mon, 19 Jul 2004 16:57:31 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BmbSE-0001pf-00; Mon, 19 Jul 2004 18:57:30 +0200 Received: from [217.227.159.171] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BmbSD-0002V2-00; Mon, 19 Jul 2004 18:57:29 +0200 From: Max Laier To: freebsd-arch@freebsd.org Date: Mon, 19 Jul 2004 18:55:13 +0200 User-Agent: KMail/1.6.2 References: <20040718184008.GC57678@darkness.comp.waw.pl> <20040719075952.GG57678@darkness.comp.waw.pl> <20040719.081356.51946167.imp@bsdimp.com> In-Reply-To: <20040719.081356.51946167.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_3z/+AlCc2BpJr9+"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407191855.19885.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: keramida@ceid.upatras.gr cc: nsouch@free.fr cc: pjd@FreeBSD.org cc: zeratul2@wanadoo.es Subject: Re: some PRs 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, 19 Jul 2004 16:57:31 -0000 --Boundary-02=_3z/+AlCc2BpJr9+ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 19 July 2004 16:13, M. Warner Losh wrote: > In message: <20040719075952.GG57678@darkness.comp.waw.pl> > > Pawel Jakub Dawidek writes: > : On Mon, Jul 19, 2004 at 12:58:25AM -0600, M. Warner Losh wrote: > : +> : Even if it is used by some programms, I don't see it in the base > : system. +> : It can be always implemented as a kernel module and > : maintained outside +> : the tree. > : +> > : +> Given that it is implemented in this driver in about 20 lines, I thi= nk > : +> that it makes sense to have it in the base. Suggesting it be > : +> maintained outside of the tree is just plain silly. It should be > : +> brought in or abadoned. > : > : It isn't even used by one of our 11000 ports and you want to bring it > : into base system? We don't have other devices in the tree, which are > : actually used by some ports. I still think, that if a port which is usi= ng > : /dev/full will be created, device should be maintained there. > : EOT. > > I guess my point is that that creates so much more work that it seems > like overkill. We often put things into the base system for > compatibility, but rely on out of system things for higher level > functionality. The question to me is, do we really want to support (read fertilize) such a= =20 stupid thing? Given the chance that once we do support it people will use i= t.=20 In my opinion it is bad to integrate something into base that we agree is=20 nothing one should ever have created (at least that's my reading of the=20 thread so far). I see no user-pessure for this. I do agree however, that suggesting to maintain something that cannot be do= ne=20 in userland outside the tree is not a good solution. Still, I feel like thi= s=20 is something that belongs into the linux compat code, at best (maybe behind= =20 an "option LINUX_STUPIDITY" ....) =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_3z/+AlCc2BpJr9+ Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBA+/z3XyyEoT62BG0RAoN0AJkBZ5eZCUQi1pAbYfO9Q0aiX13FMQCfce9B ymqXsIq22Znhv5bcfO2h7PI= =XBCc -----END PGP SIGNATURE----- --Boundary-02=_3z/+AlCc2BpJr9+-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 20 18:20:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 681F816A4CE for ; Tue, 20 Jul 2004 18:20:26 +0000 (GMT) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6ABF43D31 for ; Tue, 20 Jul 2004 18:20:25 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x50a07c53.naenxx7.adsl-dhcp.tele.dk [80.160.124.83]) by pfepa.post.tele.dk (Postfix) with ESMTP id 343FF47FE2D for ; Tue, 20 Jul 2004 20:20:23 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6KIKNrT075244 for ; Tue, 20 Jul 2004 20:20:23 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Tue, 20 Jul 2004 20:20:23 +0200 Message-ID: <75243.1090347623@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: kldunload DIAGNOSTIC idea... 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, 20 Jul 2004 18:20:26 -0000 I'm pulling hair out trying to make it guaranteed safe to unload device driver modules, and the major pain here is to make sure there is no thread stuck somewhere inside the code. That gave me the idea for a simple little DIAGNOSTIC check for kldunload: run through the proc/thread table and look for any thread with an instruction counter inside the range of pages we are going to unload. Any takers ? -- 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 Tue Jul 20 18:32:15 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 69B4E16A4CE; Tue, 20 Jul 2004 18:32:15 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i6KIWELp089278; Tue, 20 Jul 2004 14:32:14 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i6KIWEoa089277; Tue, 20 Jul 2004 14:32:14 -0400 (EDT) (envelope-from green) Date: Tue, 20 Jul 2004 14:32:13 -0400 From: Brian Fundakowski Feldman To: Poul-Henning Kamp Message-ID: <20040720183213.GC1009@green.homeunix.org> References: <75243.1090347623@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75243.1090347623@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 20 Jul 2004 18:32:15 -0000 On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: > > I'm pulling hair out trying to make it guaranteed safe to unload device > driver modules, and the major pain here is to make sure there is no > thread stuck somewhere inside the code. > > That gave me the idea for a simple little DIAGNOSTIC check for kldunload: > run through the proc/thread table and look for any thread with an > instruction counter inside the range of pages we are going to unload. > > Any takers ? You mean any thread with a stack trace that includes an instruction counter inside those pages, don't you? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Tue Jul 20 18:40:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8758C16A4CE; Tue, 20 Jul 2004 18:40:00 +0000 (GMT) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25A2C43D6A; Tue, 20 Jul 2004 18:40:00 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x50a07c53.naenxx7.adsl-dhcp.tele.dk [80.160.124.83]) by pfepb.post.tele.dk (Postfix) with ESMTP id AE5C05EE072; Tue, 20 Jul 2004 20:39:58 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6KIdvgf075605; Tue, 20 Jul 2004 20:39:58 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Fundakowski Feldman From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 20 Jul 2004 14:32:13 EDT." <20040720183213.GC1009@green.homeunix.org> Date: Tue, 20 Jul 2004 20:39:57 +0200 Message-ID: <75604.1090348797@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 20 Jul 2004 18:40:00 -0000 In message <20040720183213.GC1009@green.homeunix.org>, Brian Fundakowski Feldma n writes: >On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: >> >> I'm pulling hair out trying to make it guaranteed safe to unload device >> driver modules, and the major pain here is to make sure there is no >> thread stuck somewhere inside the code. >> >> That gave me the idea for a simple little DIAGNOSTIC check for kldunload: >> run through the proc/thread table and look for any thread with an >> instruction counter inside the range of pages we are going to unload. >> >> Any takers ? > >You mean any thread with a stack trace that includes an instruction >counter inside those pages, don't you? That would require us to unwind the stack which I think is overkill for the purpose. The most likely case is that the thread is sleeping on something inside the kld so just checking the instruction pointer would be fine. Looking for sleep addresses inside the module might make sense too. -- 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 Tue Jul 20 18:52:38 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 7F80B16A4CE; Tue, 20 Jul 2004 18:52:38 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i6KIqbYH089398; Tue, 20 Jul 2004 14:52:37 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i6KIqaVn089397; Tue, 20 Jul 2004 14:52:36 -0400 (EDT) (envelope-from green) Date: Tue, 20 Jul 2004 14:52:36 -0400 From: Brian Fundakowski Feldman To: Poul-Henning Kamp Message-ID: <20040720185236.GD1009@green.homeunix.org> References: <20040720183213.GC1009@green.homeunix.org> <75604.1090348797@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75604.1090348797@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 20 Jul 2004 18:52:38 -0000 On Tue, Jul 20, 2004 at 08:39:57PM +0200, Poul-Henning Kamp wrote: > In message <20040720183213.GC1009@green.homeunix.org>, Brian Fundakowski Feldma > n writes: > >On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: > >> > >> I'm pulling hair out trying to make it guaranteed safe to unload device > >> driver modules, and the major pain here is to make sure there is no > >> thread stuck somewhere inside the code. > >> > >> That gave me the idea for a simple little DIAGNOSTIC check for kldunload: > >> run through the proc/thread table and look for any thread with an > >> instruction counter inside the range of pages we are going to unload. > >> > >> Any takers ? > > > >You mean any thread with a stack trace that includes an instruction > >counter inside those pages, don't you? > > That would require us to unwind the stack which I think is overkill > for the purpose. > > The most likely case is that the thread is sleeping on something > inside the kld so just checking the instruction pointer would be > fine. > > Looking for sleep addresses inside the module might make sense too. It's probably not overkill -- at least in my experience most of the time a driver is "doing something" it is sleeping, so the address will be in mi_switch() or somewhere way out there. Sleep addresses on dynamic data addresses are also a lot more common than sleep addresses on static/code addresses. If someone is interested in doign this, it would be very informative, especially if it could catch sleeps, pending timeouts, pending callouts, etc. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Tue Jul 20 19:07:54 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C34B516A4CE; Tue, 20 Jul 2004 19:07:54 +0000 (GMT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FF9743D60; Tue, 20 Jul 2004 19:07:51 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with SMTP id i6KJ7nsD015845; Tue, 20 Jul 2004 21:07:49 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <015b01c46e8c$d9d7eca0$471b3dd4@digiware.nl> From: "Willem Jan Withagen" To: "Brian Fundakowski Feldman" , "Poul-Henning Kamp" References: <20040720183213.GC1009@green.homeunix.org><75604.1090348797@critter.freebsd.dk> <20040720185236.GD1009@green.homeunix.org> Date: Tue, 20 Jul 2004 21:07:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 20 Jul 2004 19:07:54 -0000 > On Tue, Jul 20, 2004 at 08:39:57PM +0200, Poul-Henning Kamp wrote: > > In message <20040720183213.GC1009@green.homeunix.org>, Brian Fundakowski Feldma > > n writes: > > >On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: > > >> > > >> I'm pulling hair out trying to make it guaranteed safe to unload device > > >> driver modules, and the major pain here is to make sure there is no > > >> thread stuck somewhere inside the code. > > >> > > >> That gave me the idea for a simple little DIAGNOSTIC check for kldunload: > > >> run through the proc/thread table and look for any thread with an > > >> instruction counter inside the range of pages we are going to unload. > > >> > > >> Any takers ? Sounds like a tantalizing task, which would match with my (old) compiler knowledge. But I wonder if I know enough of the kernel internals to ever get it doing something usefull. > > > > > >You mean any thread with a stack trace that includes an instruction > > >counter inside those pages, don't you? > > > > That would require us to unwind the stack which I think is overkill > > for the purpose. > > > > The most likely case is that the thread is sleeping on something > > inside the kld so just checking the instruction pointer would be > > fine. > > > > Looking for sleep addresses inside the module might make sense too. > > It's probably not overkill -- at least in my experience most of the > time a driver is "doing something" it is sleeping, so the address > will be in mi_switch() or somewhere way out there. Sleep addresses > on dynamic data addresses are also a lot more common than sleep > addresses on static/code addresses. If someone is interested in > doign this, it would be very informative, especially if it could > catch sleeps, pending timeouts, pending callouts, etc. Ignorant, and without prejustice, I'd say: The major problem here would be to get the framework in place. Once that is available, it is glueing the principal code together, and whether it is an address, or a series of addresses from a stack-unwind. The later is only going to be more compute intensive. --WjW From owner-freebsd-arch@FreeBSD.ORG Tue Jul 20 19:09:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DAEA16A4CE; Tue, 20 Jul 2004 19:09:08 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C050543D31; Tue, 20 Jul 2004 19:09:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.200] ([192.168.0.200]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i6KJFDrf059769; Tue, 20 Jul 2004 13:15:13 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <40FD6DC6.5030907@samsco.org> Date: Tue, 20 Jul 2004 13:08:54 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7) Gecko/20040702 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Fundakowski Feldman References: <75243.1090347623@critter.freebsd.dk> <20040720183213.GC1009@green.homeunix.org> In-Reply-To: <20040720183213.GC1009@green.homeunix.org> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: kldunload DIAGNOSTIC idea... 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, 20 Jul 2004 19:09:08 -0000 Brian Fundakowski Feldman wrote: > On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: > >>I'm pulling hair out trying to make it guaranteed safe to unload device >>driver modules, and the major pain here is to make sure there is no >>thread stuck somewhere inside the code. >> >>That gave me the idea for a simple little DIAGNOSTIC check for kldunload: >>run through the proc/thread table and look for any thread with an >>instruction counter inside the range of pages we are going to unload. >> >>Any takers ? > > > You mean any thread with a stack trace that includes an instruction > counter inside those pages, don't you? > This is better than phk's suggestion since you can have module code that calls out to another part of the system and blocks. Still, it's not 100% perfect. There are all sorts of APIs out there that do async callbacks, and it really should be up to the driver to track these things. Scott From owner-freebsd-arch@FreeBSD.ORG Tue Jul 20 19:10:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EFBD16A4DF; Tue, 20 Jul 2004 19:10:43 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3AF543D46; Tue, 20 Jul 2004 19:10:42 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.200] ([192.168.0.200]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i6KJGmSg059791; Tue, 20 Jul 2004 13:16:48 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <40FD6E25.1080808@samsco.org> Date: Tue, 20 Jul 2004 13:10:29 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7) Gecko/20040702 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Fundakowski Feldman References: <20040720183213.GC1009@green.homeunix.org> <75604.1090348797@critter.freebsd.dk> <20040720185236.GD1009@green.homeunix.org> In-Reply-To: <20040720185236.GD1009@green.homeunix.org> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: kldunload DIAGNOSTIC idea... 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, 20 Jul 2004 19:10:43 -0000 Brian Fundakowski Feldman wrote: > On Tue, Jul 20, 2004 at 08:39:57PM +0200, Poul-Henning Kamp wrote: > >>In message <20040720183213.GC1009@green.homeunix.org>, Brian Fundakowski Feldma >>n writes: >> >>>On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: >>> >>>>I'm pulling hair out trying to make it guaranteed safe to unload device >>>>driver modules, and the major pain here is to make sure there is no >>>>thread stuck somewhere inside the code. >>>> >>>>That gave me the idea for a simple little DIAGNOSTIC check for kldunload: >>>>run through the proc/thread table and look for any thread with an >>>>instruction counter inside the range of pages we are going to unload. >>>> >>>>Any takers ? >>> >>>You mean any thread with a stack trace that includes an instruction >>>counter inside those pages, don't you? >> >>That would require us to unwind the stack which I think is overkill >>for the purpose. >> >>The most likely case is that the thread is sleeping on something >>inside the kld so just checking the instruction pointer would be >>fine. >> >>Looking for sleep addresses inside the module might make sense too. > > > It's probably not overkill -- at least in my experience most of the > time a driver is "doing something" it is sleeping, so the address > will be in mi_switch() or somewhere way out there. Sleep addresses > on dynamic data addresses are also a lot more common than sleep > addresses on static/code addresses. If someone is interested in > doign this, it would be very informative, especially if it could > catch sleeps, pending timeouts, pending callouts, etc. > busdma callbacks, cam callbacks, netisr callbacks, and on and on and on. Scott From owner-freebsd-arch@FreeBSD.ORG Tue Jul 20 20:39:04 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 652F816A4CE; Tue, 20 Jul 2004 20:39:04 +0000 (GMT) Received: from VARK.homeunix.com (adsl-69-107-108-225.dsl.pltn13.pacbell.net [69.107.108.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05E7943D1D; Tue, 20 Jul 2004 20:39:04 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i6KKbfim072325; Tue, 20 Jul 2004 13:37:41 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i6KKbdBO072324; Tue, 20 Jul 2004 13:37:39 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 20 Jul 2004 13:37:39 -0700 From: David Schultz To: Poul-Henning Kamp Message-ID: <20040720203739.GA72252@VARK.homeunix.com> Mail-Followup-To: Poul-Henning Kamp , Brian Fundakowski Feldman , arch@FreeBSD.ORG References: <20040720183213.GC1009@green.homeunix.org> <75604.1090348797@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75604.1090348797@critter.freebsd.dk> cc: Brian Fundakowski Feldman cc: arch@FreeBSD.ORG Subject: Re: kldunload DIAGNOSTIC idea... 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, 20 Jul 2004 20:39:04 -0000 On Tue, Jul 20, 2004, Poul-Henning Kamp wrote: > In message <20040720183213.GC1009@green.homeunix.org>, Brian Fundakowski Feldma > n writes: > >On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: > >> > >> I'm pulling hair out trying to make it guaranteed safe to unload device > >> driver modules, and the major pain here is to make sure there is no > >> thread stuck somewhere inside the code. > >> > >> That gave me the idea for a simple little DIAGNOSTIC check for kldunload: > >> run through the proc/thread table and look for any thread with an > >> instruction counter inside the range of pages we are going to unload. > >> > >> Any takers ? > > > >You mean any thread with a stack trace that includes an instruction > >counter inside those pages, don't you? > > That would require us to unwind the stack which I think is overkill > for the purpose. > > The most likely case is that the thread is sleeping on something > inside the kld so just checking the instruction pointer would be > fine. > > Looking for sleep addresses inside the module might make sense too. But this is just a heuristic that may sometimes fail. The module might be holding resources or locks, it could have callbacks, etc. If we're going to offer a forcible unload option, I think it's crucial that it be safe. That is, a system administrator must be able to use it on a production system and be confident that it will not cause anything bad to happen. Otherwise, it doesn't really buy you much. Also, doing this right (i.e. the hard way) may have other advantages. For instance, when any old module or driver fails an internal consistency check right now, or in some cases, simply fails to allocate memory, the best course of action we have right now is to panic and force a reboot of the machine. It might be worthwhile to see if some of those panics could be converted into ``forcibly reload the module and try again.'' This would require a lot of work to make sure everything gets cleaned up, but I think it would be worth it. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 20 22:15:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18D6516A4CF for ; Tue, 20 Jul 2004 22:15:47 +0000 (GMT) Received: from fidel.freesurf.fr (fidel.freesurf.fr [212.43.206.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B27F343D45 for ; Tue, 20 Jul 2004 22:15:46 +0000 (GMT) (envelope-from nsouch@smtp.freesurf.fr) Received: from smtp.freesurf.fr (62-240-249-21.adsl.freesurf.fr [62.240.249.21]) by fidel.freesurf.fr (Postfix) with SMTP id 6585D2A5B18 for ; Wed, 21 Jul 2004 00:15:45 +0200 (CEST) Received: (qmail 19395 invoked by uid 1001); 20 Jul 2004 22:15:48 -0000 Date: Wed, 21 Jul 2004 00:15:48 +0200 From: Nicolas Souchu To: freebsd-arch@freebsd.org Message-ID: <20040721001547.A19270@armor.freesurf.fr> References: <20040716220848.A35405@armor.freesurf.fr> <20040718031554.GF1070@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040718031554.GF1070@dragon.nuxi.com>; from obrien@freebsd.org on Sat, Jul 17, 2004 at 08:15:54PM -0700 cc: rmh@debian.org Subject: Re: some PRs 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, 20 Jul 2004 22:15:47 -0000 On Sat, Jul 17, 2004 at 08:15:54PM -0700, David O'Brien wrote: > On Fri, Jul 16, 2004 at 10:08:48PM +0200, Nicolas Souchu wrote: > > Patchs like: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=68961 > > What in the world is this patch (ie, /dev/full) for?? > I just don't see the point in /dev/full. Could you please give some good > examples of its use? Also what "Un*x OSes" besides Linux has this? I'll try to figure out the best alternative, given all your comments. The Linux emulation seems a good starting point. -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org http://www.freebsd.org/~nsouch/kgi4BSD From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 06:17:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F54816A4CE for ; Wed, 21 Jul 2004 06:17:32 +0000 (GMT) Received: from mid-2.inet.it (mid-2.inet.it [213.92.5.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A00843D62 for ; Wed, 21 Jul 2004 06:17:30 +0000 (GMT) (envelope-from andrea@webcom.it) Received: from 213-140-17-96.fastres.net [::ffff:213.140.17.96] by mid-2.inet.it via I-SMTP-5.1.11-51A id ::ffff:213.140.17.96+hWitoN3eLDk; Wed, 21 Jul 2004 08:17:28 +0200 Received: by brian.webcom.it (Postfix, from userid 1000) id 13C5EA7; Wed, 21 Jul 2004 08:16:56 +0200 (CEST) Date: Wed, 21 Jul 2004 08:16:56 +0200 From: Andrea Campi To: Poul-Henning Kamp Message-ID: <20040721061656.GA3636@webcom.it> References: <75243.1090347623@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75243.1090347623@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 06:17:32 -0000 On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: > I'm pulling hair out trying to make it guaranteed safe to unload device > driver modules, and the major pain here is to make sure there is no > thread stuck somewhere inside the code. > > That gave me the idea for a simple little DIAGNOSTIC check for kldunload: > run through the proc/thread table and look for any thread with an > instruction counter inside the range of pages we are going to unload. A wild idea just struck; I'm going to just expose it as I think, so bear with me. Assumption: the main reason for wanting to unload the driver is to be able to reload a new (maybe different) one. The main concern is not freeing memory. Assumption: we are talking about cases where the driver wasn't able to clean everything up in the quiesce phase. This means SOME resources failed to be cleaned up, or we couldn't even try to free them, or we don't even know them. Assumption: we are NOT talking about the case you mentioned in a previous thread, where you may have some buffer, maybe mapped in common by an expansion card and by the driver. There's not much we can do there. We're just talking of a simpler case where we (think we) know we have a thread stuck somewhere, but apart from that, we're reasonably sure we can detach. Right? Ok, under this assumptions I guess the cleanest way is to go forward and detach the driver leaving it in memory. Either the quiesce or the unload should set appropriate flags that instruct the driver to abort any further activity, so you can simply and safely do: xx_send() { if (quiesced) return; ... lengthy_function(); <<< we are sleeping somewhere down there if (gone) return; ... } Yes, this requires additional checks to be scattered around, but it's going to be opt-in. In addition, it only needs to be done in places where lenghty_function() can't be cancelled, and I guess that's not going to be an awful lot of places. But I can be wrong. In addition, this may still leak memory, unless the driver is capable of keeping track and still free data in the gone case. Thoughts? Bye, Andrea -- The best things in life are free, but the expensive ones are still worth a look. From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 06:44:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00D5516A4CE; Wed, 21 Jul 2004 06:44:37 +0000 (GMT) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BEC343D5C; Wed, 21 Jul 2004 06:44:36 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x50a07c53.naenxx7.adsl-dhcp.tele.dk [80.160.124.83]) by pfepa.post.tele.dk (Postfix) with ESMTP id 4296A47FE09; Wed, 21 Jul 2004 08:44:34 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6L6iXTd077807; Wed, 21 Jul 2004 08:44:33 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: David Schultz From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 20 Jul 2004 13:37:39 PDT." <20040720203739.GA72252@VARK.homeunix.com> Date: Wed, 21 Jul 2004 08:44:33 +0200 Message-ID: <77806.1090392273@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Brian Fundakowski Feldman cc: arch@FreeBSD.ORG Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 06:44:37 -0000 In message <20040720203739.GA72252@VARK.homeunix.com>, David Schultz writes: >> Looking for sleep addresses inside the module might make sense too. > >But this is just a heuristic that may sometimes fail. The module >might be holding resources or locks, it could have callbacks, etc. >If we're going to offer a forcible unload option, [...] This has _nothing_ to do with forcible unload. Please read the subject, again if necessary. This is an idea for a debug tool which may help people properly debug and implement unload *in general*. -- 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 Jul 21 07:06:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9221816A4CF; Wed, 21 Jul 2004 07:06:39 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49A4543D60; Wed, 21 Jul 2004 07:06:39 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-121-219-69.dsl.snfc21.pacbell.net [68.121.219.69])i6L76blM027296; Wed, 21 Jul 2004 03:06:37 -0400 Message-ID: <40FE15FD.904@elischer.org> Date: Wed, 21 Jul 2004 00:06:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Poul-Henning Kamp References: <77806.1090392273@critter.freebsd.dk> In-Reply-To: <77806.1090392273@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: David Schultz cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 07:06:39 -0000 Poul-Henning Kamp wrote: >In message <20040720203739.GA72252@VARK.homeunix.com>, David Schultz writes: > > > >>>Looking for sleep addresses inside the module might make sense too. >>> >>> >>But this is just a heuristic that may sometimes fail. The module >>might be holding resources or locks, it could have callbacks, etc. >>If we're going to offer a forcible unload option, [...] >> >> > >This has _nothing_ to do with forcible unload. > >Please read the subject, again if necessary. > >This is an idea for a debug tool which may help people properly >debug and implement unload *in general*. > as such, speed wouldnot be crucial, so having an alterred version of the stack trace code that walks all available stacks looking for matching addresses would be quite a reasonable thingto do. > > > From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 09:10:55 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C06DF16A4CF; Wed, 21 Jul 2004 09:10:55 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 883F843D4C; Wed, 21 Jul 2004 09:10:54 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i6L9ADuu077108; Wed, 21 Jul 2004 10:10:13 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-arch@freebsd.org Date: Wed, 21 Jul 2004 10:10:07 +0100 User-Agent: KMail/1.6.1 References: <20040720183213.GC1009@green.homeunix.org> <20040720185236.GD1009@green.homeunix.org> <40FD6E25.1080808@samsco.org> In-Reply-To: <40FD6E25.1080808@samsco.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407211010.08159.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean cc: Poul-Henning Kamp cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 09:10:55 -0000 On Tuesday 20 July 2004 20:10, Scott Long wrote: > Brian Fundakowski Feldman wrote: > > On Tue, Jul 20, 2004 at 08:39:57PM +0200, Poul-Henning Kamp wrote: > >>In message <20040720183213.GC1009@green.homeunix.org>, Brian > >> Fundakowski Feldma > >> > >>n writes: > >>>On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: > >>>>I'm pulling hair out trying to make it guaranteed safe to unload > >>>> device driver modules, and the major pain here is to make sure > >>>> there is no thread stuck somewhere inside the code. > >>>> > >>>>That gave me the idea for a simple little DIAGNOSTIC check for > >>>> kldunload: run through the proc/thread table and look for any > >>>> thread with an instruction counter inside the range of pages we > >>>> are going to unload. > >>>> > >>>>Any takers ? > >>> > >>>You mean any thread with a stack trace that includes an > >>> instruction counter inside those pages, don't you? > >> > >>That would require us to unwind the stack which I think is overkill > >>for the purpose. > >> > >>The most likely case is that the thread is sleeping on something > >>inside the kld so just checking the instruction pointer would be > >>fine. > >> > >>Looking for sleep addresses inside the module might make sense too. > > > > It's probably not overkill -- at least in my experience most of the > > time a driver is "doing something" it is sleeping, so the address > > will be in mi_switch() or somewhere way out there. Sleep addresses > > on dynamic data addresses are also a lot more common than sleep > > addresses on static/code addresses. If someone is interested in > > doign this, it would be very informative, especially if it could > > catch sleeps, pending timeouts, pending callouts, etc. > > busdma callbacks, cam callbacks, netisr callbacks, and on and on and > on. The original intention was that drivers use the device_busy()/device_unbusy() counter to handle these things. In some cases, just calling device_busy() from fooopen() and device_unbusy() from fooclose() is sufficient. From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 09:10:55 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C06DF16A4CF; Wed, 21 Jul 2004 09:10:55 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 883F843D4C; Wed, 21 Jul 2004 09:10:54 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i6L9ADuu077108; Wed, 21 Jul 2004 10:10:13 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-arch@freebsd.org Date: Wed, 21 Jul 2004 10:10:07 +0100 User-Agent: KMail/1.6.1 References: <20040720183213.GC1009@green.homeunix.org> <20040720185236.GD1009@green.homeunix.org> <40FD6E25.1080808@samsco.org> In-Reply-To: <40FD6E25.1080808@samsco.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407211010.08159.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean cc: Poul-Henning Kamp cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 09:10:55 -0000 On Tuesday 20 July 2004 20:10, Scott Long wrote: > Brian Fundakowski Feldman wrote: > > On Tue, Jul 20, 2004 at 08:39:57PM +0200, Poul-Henning Kamp wrote: > >>In message <20040720183213.GC1009@green.homeunix.org>, Brian > >> Fundakowski Feldma > >> > >>n writes: > >>>On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: > >>>>I'm pulling hair out trying to make it guaranteed safe to unload > >>>> device driver modules, and the major pain here is to make sure > >>>> there is no thread stuck somewhere inside the code. > >>>> > >>>>That gave me the idea for a simple little DIAGNOSTIC check for > >>>> kldunload: run through the proc/thread table and look for any > >>>> thread with an instruction counter inside the range of pages we > >>>> are going to unload. > >>>> > >>>>Any takers ? > >>> > >>>You mean any thread with a stack trace that includes an > >>> instruction counter inside those pages, don't you? > >> > >>That would require us to unwind the stack which I think is overkill > >>for the purpose. > >> > >>The most likely case is that the thread is sleeping on something > >>inside the kld so just checking the instruction pointer would be > >>fine. > >> > >>Looking for sleep addresses inside the module might make sense too. > > > > It's probably not overkill -- at least in my experience most of the > > time a driver is "doing something" it is sleeping, so the address > > will be in mi_switch() or somewhere way out there. Sleep addresses > > on dynamic data addresses are also a lot more common than sleep > > addresses on static/code addresses. If someone is interested in > > doign this, it would be very informative, especially if it could > > catch sleeps, pending timeouts, pending callouts, etc. > > busdma callbacks, cam callbacks, netisr callbacks, and on and on and > on. The original intention was that drivers use the device_busy()/device_unbusy() counter to handle these things. In some cases, just calling device_busy() from fooopen() and device_unbusy() from fooclose() is sufficient. From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 09:22:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00FE016A4CE; Wed, 21 Jul 2004 09:22:13 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 613F343D1D; Wed, 21 Jul 2004 09:22:13 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6L9Ldwj079981; Wed, 21 Jul 2004 11:21:44 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug Rabson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 10:10:07 BST." <200407211010.08159.dfr@nlsystems.com> Date: Wed, 21 Jul 2004 11:21:39 +0200 Message-ID: <79980.1090401699@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 09:22:14 -0000 In message <200407211010.08159.dfr@nlsystems.com>, Doug Rabson writes: >The original intention was that drivers use the >device_busy()/device_unbusy() counter to handle these things. In some >cases, just calling device_busy() from fooopen() and device_unbusy() >from fooclose() is sufficient. That is not enough. All methods in cdevsw, and things not in cdevsw (clone handlers, call backs, etc etc) needs to refcount. I have a lot of this working in a tree here, and will commit it once I have gone over it a few more times. -- 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 Jul 21 09:22:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00FE016A4CE; Wed, 21 Jul 2004 09:22:13 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 613F343D1D; Wed, 21 Jul 2004 09:22:13 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6L9Ldwj079981; Wed, 21 Jul 2004 11:21:44 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug Rabson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 10:10:07 BST." <200407211010.08159.dfr@nlsystems.com> Date: Wed, 21 Jul 2004 11:21:39 +0200 Message-ID: <79980.1090401699@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 09:22:14 -0000 In message <200407211010.08159.dfr@nlsystems.com>, Doug Rabson writes: >The original intention was that drivers use the >device_busy()/device_unbusy() counter to handle these things. In some >cases, just calling device_busy() from fooopen() and device_unbusy() >from fooclose() is sufficient. That is not enough. All methods in cdevsw, and things not in cdevsw (clone handlers, call backs, etc etc) needs to refcount. I have a lot of this working in a tree here, and will commit it once I have gone over it a few more times. -- 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 Jul 21 10:37:54 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70A8716A4CE; Wed, 21 Jul 2004 10:37:54 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id B58B743D66; Wed, 21 Jul 2004 10:37:53 +0000 (GMT) (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 i6LAbqkM070546; Wed, 21 Jul 2004 11:37:52 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i6LAbpON067331; Wed, 21 Jul 2004 11:37:51 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Poul-Henning Kamp In-Reply-To: <79980.1090401699@critter.freebsd.dk> References: <79980.1090401699@critter.freebsd.dk> Content-Type: text/plain Message-Id: <1090406270.7114.2.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 11:37:50 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 10:37:54 -0000 On Wed, 2004-07-21 at 10:21, Poul-Henning Kamp wrote: > In message <200407211010.08159.dfr@nlsystems.com>, Doug Rabson writes: > > >The original intention was that drivers use the > >device_busy()/device_unbusy() counter to handle these things. In some > >cases, just calling device_busy() from fooopen() and device_unbusy() > >from fooclose() is sufficient. > > That is not enough. All methods in cdevsw, and things not in cdevsw > (clone handlers, call backs, etc etc) needs to refcount. > > I have a lot of this working in a tree here, and will commit it once > I have gone over it a few more times. Methods in cdevsw which can't be called unless the device is opened can rely on a single counter managed by open/close in most cases. Other callbacks may or may not need extra handling depending on whether or not the callback can persist past close. Will you use the existing device_busy() counter or will each driver use its own counter? From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 10:37:54 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70A8716A4CE; Wed, 21 Jul 2004 10:37:54 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id B58B743D66; Wed, 21 Jul 2004 10:37:53 +0000 (GMT) (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 i6LAbqkM070546; Wed, 21 Jul 2004 11:37:52 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i6LAbpON067331; Wed, 21 Jul 2004 11:37:51 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Poul-Henning Kamp In-Reply-To: <79980.1090401699@critter.freebsd.dk> References: <79980.1090401699@critter.freebsd.dk> Content-Type: text/plain Message-Id: <1090406270.7114.2.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 11:37:50 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 10:37:54 -0000 On Wed, 2004-07-21 at 10:21, Poul-Henning Kamp wrote: > In message <200407211010.08159.dfr@nlsystems.com>, Doug Rabson writes: > > >The original intention was that drivers use the > >device_busy()/device_unbusy() counter to handle these things. In some > >cases, just calling device_busy() from fooopen() and device_unbusy() > >from fooclose() is sufficient. > > That is not enough. All methods in cdevsw, and things not in cdevsw > (clone handlers, call backs, etc etc) needs to refcount. > > I have a lot of this working in a tree here, and will commit it once > I have gone over it a few more times. Methods in cdevsw which can't be called unless the device is opened can rely on a single counter managed by open/close in most cases. Other callbacks may or may not need extra handling depending on whether or not the callback can persist past close. Will you use the existing device_busy() counter or will each driver use its own counter? From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 11:02:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB10816A4CE; Wed, 21 Jul 2004 11:02:43 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5769C43D3F; Wed, 21 Jul 2004 11:02:43 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6LB2fon081663; Wed, 21 Jul 2004 13:02:41 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug Rabson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 11:37:50 BST." <1090406270.7114.2.camel@builder02.qubesoft.com> Date: Wed, 21 Jul 2004 13:02:41 +0200 Message-ID: <81662.1090407761@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 11:02:44 -0000 In message <1090406270.7114.2.camel@builder02.qubesoft.com>, Doug Rabson writes : >On Wed, 2004-07-21 at 10:21, Poul-Henning Kamp wrote: >> In message <200407211010.08159.dfr@nlsystems.com>, Doug Rabson writes: >> >> >The original intention was that drivers use the >> >device_busy()/device_unbusy() counter to handle these things. In some >> >cases, just calling device_busy() from fooopen() and device_unbusy() >> >from fooclose() is sufficient. >> >> That is not enough. All methods in cdevsw, and things not in cdevsw >> (clone handlers, call backs, etc etc) needs to refcount. >> >> I have a lot of this working in a tree here, and will commit it once >> I have gone over it a few more times. > >Methods in cdevsw which can't be called unless the device is opened can >rely on a single counter managed by open/close in most cases. Other >callbacks may or may not need extra handling depending on whether or not >the callback can persist past close. The problem is that if you are sleeping in for instance a read, you need to wake up the thread, and you can still only hope that it will at some point in the future do a close. That is why the devsw/cdev code is designed so that you can forego your close (and do it yourself) by destroying the cdev. You still need to evict all threads of course, but you don't need to wait (potentially for ever) for them to come back and call close. >Will you use the existing device_busy() counter or will each driver use >its own counter? device_busy doesn't work well because it cannot happen until I am already inside the driver and because there is no known relationship between cdevs and device_t's. There are three parts to it, a refcount on cdevsw which tells us if any thread is inside the driver using that route, a refcount on the individual cdev and a linkage between the two. -- 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 Jul 21 11:02:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB10816A4CE; Wed, 21 Jul 2004 11:02:43 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5769C43D3F; Wed, 21 Jul 2004 11:02:43 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6LB2fon081663; Wed, 21 Jul 2004 13:02:41 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug Rabson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 11:37:50 BST." <1090406270.7114.2.camel@builder02.qubesoft.com> Date: Wed, 21 Jul 2004 13:02:41 +0200 Message-ID: <81662.1090407761@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 11:02:44 -0000 In message <1090406270.7114.2.camel@builder02.qubesoft.com>, Doug Rabson writes : >On Wed, 2004-07-21 at 10:21, Poul-Henning Kamp wrote: >> In message <200407211010.08159.dfr@nlsystems.com>, Doug Rabson writes: >> >> >The original intention was that drivers use the >> >device_busy()/device_unbusy() counter to handle these things. In some >> >cases, just calling device_busy() from fooopen() and device_unbusy() >> >from fooclose() is sufficient. >> >> That is not enough. All methods in cdevsw, and things not in cdevsw >> (clone handlers, call backs, etc etc) needs to refcount. >> >> I have a lot of this working in a tree here, and will commit it once >> I have gone over it a few more times. > >Methods in cdevsw which can't be called unless the device is opened can >rely on a single counter managed by open/close in most cases. Other >callbacks may or may not need extra handling depending on whether or not >the callback can persist past close. The problem is that if you are sleeping in for instance a read, you need to wake up the thread, and you can still only hope that it will at some point in the future do a close. That is why the devsw/cdev code is designed so that you can forego your close (and do it yourself) by destroying the cdev. You still need to evict all threads of course, but you don't need to wait (potentially for ever) for them to come back and call close. >Will you use the existing device_busy() counter or will each driver use >its own counter? device_busy doesn't work well because it cannot happen until I am already inside the driver and because there is no known relationship between cdevs and device_t's. There are three parts to it, a refcount on cdevsw which tells us if any thread is inside the driver using that route, a refcount on the individual cdev and a linkage between the two. -- 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 Jul 21 11:21:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCD1216A4CE; Wed, 21 Jul 2004 11:21:00 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FBFD43D2F; Wed, 21 Jul 2004 11:21:00 +0000 (GMT) (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 i6LBKtkM072154; Wed, 21 Jul 2004 12:20:55 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i6LBKsON068266; Wed, 21 Jul 2004 12:20:54 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Poul-Henning Kamp In-Reply-To: <81662.1090407761@critter.freebsd.dk> References: <81662.1090407761@critter.freebsd.dk> Content-Type: text/plain Message-Id: <1090408854.7114.8.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 12:20:54 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 11:21:00 -0000 On Wed, 2004-07-21 at 12:02, Poul-Henning Kamp wrote: > In message <1090406270.7114.2.camel@builder02.qubesoft.com>, Doug Rabson writes > : > >On Wed, 2004-07-21 at 10:21, Poul-Henning Kamp wrote: > >> In message <200407211010.08159.dfr@nlsystems.com>, Doug Rabson writes: > >> > >> >The original intention was that drivers use the > >> >device_busy()/device_unbusy() counter to handle these things. In some > >> >cases, just calling device_busy() from fooopen() and device_unbusy() > >> >from fooclose() is sufficient. > >> > >> That is not enough. All methods in cdevsw, and things not in cdevsw > >> (clone handlers, call backs, etc etc) needs to refcount. > >> > >> I have a lot of this working in a tree here, and will commit it once > >> I have gone over it a few more times. > > > >Methods in cdevsw which can't be called unless the device is opened can > >rely on a single counter managed by open/close in most cases. Other > >callbacks may or may not need extra handling depending on whether or not > >the callback can persist past close. > > The problem is that if you are sleeping in for instance a read, you > need to wake up the thread, and you can still only hope that it > will at some point in the future do a close. > > That is why the devsw/cdev code is designed so that you can forego > your close (and do it yourself) by destroying the cdev. You still > need to evict all threads of course, but you don't need to wait > (potentially for ever) for them to come back and call close. > > >Will you use the existing device_busy() counter or will each driver use > >its own counter? > > device_busy doesn't work well because it cannot happen until I am > already inside the driver and because there is no known relationship > between cdevs and device_t's. > > There are three parts to it, a refcount on cdevsw which tells us if > any thread is inside the driver using that route, a refcount on the > individual cdev and a linkage between the two. The device_busy() counter is still simplest (as long as there is a device_t at all). The implementation of devclass_delete_driver() will automatically veto the unload (when its called from driver_module_handler()). From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 11:21:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCD1216A4CE; Wed, 21 Jul 2004 11:21:00 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FBFD43D2F; Wed, 21 Jul 2004 11:21:00 +0000 (GMT) (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 i6LBKtkM072154; Wed, 21 Jul 2004 12:20:55 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i6LBKsON068266; Wed, 21 Jul 2004 12:20:54 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Poul-Henning Kamp In-Reply-To: <81662.1090407761@critter.freebsd.dk> References: <81662.1090407761@critter.freebsd.dk> Content-Type: text/plain Message-Id: <1090408854.7114.8.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 12:20:54 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 11:21:00 -0000 On Wed, 2004-07-21 at 12:02, Poul-Henning Kamp wrote: > In message <1090406270.7114.2.camel@builder02.qubesoft.com>, Doug Rabson writes > : > >On Wed, 2004-07-21 at 10:21, Poul-Henning Kamp wrote: > >> In message <200407211010.08159.dfr@nlsystems.com>, Doug Rabson writes: > >> > >> >The original intention was that drivers use the > >> >device_busy()/device_unbusy() counter to handle these things. In some > >> >cases, just calling device_busy() from fooopen() and device_unbusy() > >> >from fooclose() is sufficient. > >> > >> That is not enough. All methods in cdevsw, and things not in cdevsw > >> (clone handlers, call backs, etc etc) needs to refcount. > >> > >> I have a lot of this working in a tree here, and will commit it once > >> I have gone over it a few more times. > > > >Methods in cdevsw which can't be called unless the device is opened can > >rely on a single counter managed by open/close in most cases. Other > >callbacks may or may not need extra handling depending on whether or not > >the callback can persist past close. > > The problem is that if you are sleeping in for instance a read, you > need to wake up the thread, and you can still only hope that it > will at some point in the future do a close. > > That is why the devsw/cdev code is designed so that you can forego > your close (and do it yourself) by destroying the cdev. You still > need to evict all threads of course, but you don't need to wait > (potentially for ever) for them to come back and call close. > > >Will you use the existing device_busy() counter or will each driver use > >its own counter? > > device_busy doesn't work well because it cannot happen until I am > already inside the driver and because there is no known relationship > between cdevs and device_t's. > > There are three parts to it, a refcount on cdevsw which tells us if > any thread is inside the driver using that route, a refcount on the > individual cdev and a linkage between the two. The device_busy() counter is still simplest (as long as there is a device_t at all). The implementation of devclass_delete_driver() will automatically veto the unload (when its called from driver_module_handler()). From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 11:37:51 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA43F16A4CF; Wed, 21 Jul 2004 11:37:51 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 098CD43D48; Wed, 21 Jul 2004 11:37:51 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6LBbok9082179; Wed, 21 Jul 2004 13:37:50 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug Rabson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 12:20:54 BST." <1090408854.7114.8.camel@builder02.qubesoft.com> Date: Wed, 21 Jul 2004 13:37:50 +0200 Message-ID: <82178.1090409870@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 11:37:51 -0000 In message <1090408854.7114.8.camel@builder02.qubesoft.com>, Doug Rabson writes : >> There are three parts to it, a refcount on cdevsw which tells us if >> any thread is inside the driver using that route, a refcount on the >> individual cdev and a linkage between the two. > >The device_busy() counter is still simplest (as long as there is a >device_t at all). The implementation of devclass_delete_driver() will >automatically veto the unload (when its called from >driver_module_handler()). The problem is that I cannot find the device_t without dereferencing the struct cdev (either for si_driver[12] or the dev_t) and by then it is too late. There is no way we can avoid refcounting on the cdev. -- 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 Jul 21 11:37:51 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA43F16A4CF; Wed, 21 Jul 2004 11:37:51 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 098CD43D48; Wed, 21 Jul 2004 11:37:51 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6LBbok9082179; Wed, 21 Jul 2004 13:37:50 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug Rabson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 12:20:54 BST." <1090408854.7114.8.camel@builder02.qubesoft.com> Date: Wed, 21 Jul 2004 13:37:50 +0200 Message-ID: <82178.1090409870@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 11:37:51 -0000 In message <1090408854.7114.8.camel@builder02.qubesoft.com>, Doug Rabson writes : >> There are three parts to it, a refcount on cdevsw which tells us if >> any thread is inside the driver using that route, a refcount on the >> individual cdev and a linkage between the two. > >The device_busy() counter is still simplest (as long as there is a >device_t at all). The implementation of devclass_delete_driver() will >automatically veto the unload (when its called from >driver_module_handler()). The problem is that I cannot find the device_t without dereferencing the struct cdev (either for si_driver[12] or the dev_t) and by then it is too late. There is no way we can avoid refcounting on the cdev. -- 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 Jul 21 12:20:36 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07F7616A4CE; Wed, 21 Jul 2004 12:20:36 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CCCB43D31; Wed, 21 Jul 2004 12:20:33 +0000 (GMT) (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 i6LCKWkM074167; Wed, 21 Jul 2004 13:20:32 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i6LCKVON069164; Wed, 21 Jul 2004 13:20:31 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Poul-Henning Kamp In-Reply-To: <82178.1090409870@critter.freebsd.dk> References: <82178.1090409870@critter.freebsd.dk> Content-Type: text/plain Message-Id: <1090412431.7114.13.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 13:20:31 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 12:20:36 -0000 On Wed, 2004-07-21 at 12:37, Poul-Henning Kamp wrote: > In message <1090408854.7114.8.camel@builder02.qubesoft.com>, Doug Rabson writes > : > > >> There are three parts to it, a refcount on cdevsw which tells us if > >> any thread is inside the driver using that route, a refcount on the > >> individual cdev and a linkage between the two. > > > >The device_busy() counter is still simplest (as long as there is a > >device_t at all). The implementation of devclass_delete_driver() will > >automatically veto the unload (when its called from > >driver_module_handler()). > > The problem is that I cannot find the device_t without dereferencing > the struct cdev (either for si_driver[12] or the dev_t) and by then > it is too late. There is no way we can avoid refcounting on the cdev. Ok, so you are going to handle this in specfs (or whatever replaces specfs)? That makes sense. Any ideas on how network interfaces should work in this? From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 12:20:36 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07F7616A4CE; Wed, 21 Jul 2004 12:20:36 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CCCB43D31; Wed, 21 Jul 2004 12:20:33 +0000 (GMT) (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 i6LCKWkM074167; Wed, 21 Jul 2004 13:20:32 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i6LCKVON069164; Wed, 21 Jul 2004 13:20:31 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Poul-Henning Kamp In-Reply-To: <82178.1090409870@critter.freebsd.dk> References: <82178.1090409870@critter.freebsd.dk> Content-Type: text/plain Message-Id: <1090412431.7114.13.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Jul 2004 13:20:31 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 12:20:36 -0000 On Wed, 2004-07-21 at 12:37, Poul-Henning Kamp wrote: > In message <1090408854.7114.8.camel@builder02.qubesoft.com>, Doug Rabson writes > : > > >> There are three parts to it, a refcount on cdevsw which tells us if > >> any thread is inside the driver using that route, a refcount on the > >> individual cdev and a linkage between the two. > > > >The device_busy() counter is still simplest (as long as there is a > >device_t at all). The implementation of devclass_delete_driver() will > >automatically veto the unload (when its called from > >driver_module_handler()). > > The problem is that I cannot find the device_t without dereferencing > the struct cdev (either for si_driver[12] or the dev_t) and by then > it is too late. There is no way we can avoid refcounting on the cdev. Ok, so you are going to handle this in specfs (or whatever replaces specfs)? That makes sense. Any ideas on how network interfaces should work in this? From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 12:29:23 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 765A616A4CE; Wed, 21 Jul 2004 12:29:23 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C16C143D46; Wed, 21 Jul 2004 12:29:22 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6LCTLZh083183; Wed, 21 Jul 2004 14:29:21 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug Rabson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 13:20:31 BST." <1090412431.7114.13.camel@builder02.qubesoft.com> Date: Wed, 21 Jul 2004 14:29:21 +0200 Message-ID: <83182.1090412961@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 12:29:23 -0000 In message <1090412431.7114.13.camel@builder02.qubesoft.com>, Doug Rabson write s: >> The problem is that I cannot find the device_t without dereferencing >> the struct cdev (either for si_driver[12] or the dev_t) and by then >> it is too late. There is no way we can avoid refcounting on the cdev. > >Ok, so you are going to handle this in specfs (or whatever replaces >specfs)? That makes sense. That's the only way I can see to avoid tons of copy&paste code all over the drivers, because it's all the same for them. >Any ideas on how network interfaces should >work in this? I talked with Robert briefly about this yesterday, and the problem there is that struct ifnet is embedded in the softc. If the softc had a pointer to the ifnet, then we could do something similar, but as long as it's embedded we're stuck. -- 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 Jul 21 12:29:23 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 765A616A4CE; Wed, 21 Jul 2004 12:29:23 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C16C143D46; Wed, 21 Jul 2004 12:29:22 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6LCTLZh083183; Wed, 21 Jul 2004 14:29:21 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Doug Rabson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 13:20:31 BST." <1090412431.7114.13.camel@builder02.qubesoft.com> Date: Wed, 21 Jul 2004 14:29:21 +0200 Message-ID: <83182.1090412961@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 12:29:23 -0000 In message <1090412431.7114.13.camel@builder02.qubesoft.com>, Doug Rabson write s: >> The problem is that I cannot find the device_t without dereferencing >> the struct cdev (either for si_driver[12] or the dev_t) and by then >> it is too late. There is no way we can avoid refcounting on the cdev. > >Ok, so you are going to handle this in specfs (or whatever replaces >specfs)? That makes sense. That's the only way I can see to avoid tons of copy&paste code all over the drivers, because it's all the same for them. >Any ideas on how network interfaces should >work in this? I talked with Robert briefly about this yesterday, and the problem there is that struct ifnet is embedded in the softc. If the softc had a pointer to the ifnet, then we could do something similar, but as long as it's embedded we're stuck. -- 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 Jul 21 14:51:21 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E146C16A4CE for ; Wed, 21 Jul 2004 14:51:21 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D4A343D46 for ; Wed, 21 Jul 2004 14:51:21 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i6LEnMIN059539; Wed, 21 Jul 2004 08:49:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jul 2004 08:49:26 -0600 (MDT) Message-Id: <20040721.084926.84362543.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <83182.1090412961@critter.freebsd.dk> References: <1090412431.7114.13.camel@builder02.qubesoft.com> <83182.1090412961@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 14:51:22 -0000 [[ only cc'd arch@ ]] In message: <83182.1090412961@critter.freebsd.dk> "Poul-Henning Kamp" writes: : >Any ideas on how network interfaces should : >work in this? : : I talked with Robert briefly about this yesterday, and the problem : there is that struct ifnet is embedded in the softc. If the softc : had a pointer to the ifnet, then we could do something similar, but : as long as it's embedded we're stuck. Why is that the case? We don't detach the ifnet stuff after deleting the softc. Why would a pointer to ifnet in the softc make this easier? I mean, I understand that having a pointer would insulate the size of ifnet from the driver, but there's so many offsets in ifnet that are encoded in the driver that doesn't seem that big a win. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 15:08:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9CFCF16A4CE; Wed, 21 Jul 2004 15:08:35 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i6LF8ZND096616; Wed, 21 Jul 2004 11:08:35 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i6LF8YKK096615; Wed, 21 Jul 2004 11:08:34 -0400 (EDT) (envelope-from green) Date: Wed, 21 Jul 2004 11:08:33 -0400 From: Brian Fundakowski Feldman To: Poul-Henning Kamp Message-ID: <20040721150833.GG1009@green.homeunix.org> References: <1090412431.7114.13.camel@builder02.qubesoft.com> <83182.1090412961@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83182.1090412961@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 15:08:36 -0000 On Wed, Jul 21, 2004 at 02:29:21PM +0200, Poul-Henning Kamp wrote: > In message <1090412431.7114.13.camel@builder02.qubesoft.com>, Doug Rabson write > s: > > >> The problem is that I cannot find the device_t without dereferencing > >> the struct cdev (either for si_driver[12] or the dev_t) and by then > >> it is too late. There is no way we can avoid refcounting on the cdev. > > > >Ok, so you are going to handle this in specfs (or whatever replaces > >specfs)? That makes sense. > > That's the only way I can see to avoid tons of copy&paste code all over > the drivers, because it's all the same for them. > > >Any ideas on how network interfaces should > >work in this? > > I talked with Robert briefly about this yesterday, and the problem > there is that struct ifnet is embedded in the softc. If the softc > had a pointer to the ifnet, then we could do something similar, but > as long as it's embedded we're stuck. What's the difference, when in the normal case (every case?) there is a poor-man's-OO implemented by making the softc's first member ifnet (or something containing ifnet like arpcom or ieee80211com), so a pointer to an ifnet or softc or whatever is almost always castable? I believe that this is a very traditional behavior. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 15:08:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9CFCF16A4CE; Wed, 21 Jul 2004 15:08:35 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i6LF8ZND096616; Wed, 21 Jul 2004 11:08:35 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i6LF8YKK096615; Wed, 21 Jul 2004 11:08:34 -0400 (EDT) (envelope-from green) Date: Wed, 21 Jul 2004 11:08:33 -0400 From: Brian Fundakowski Feldman To: Poul-Henning Kamp Message-ID: <20040721150833.GG1009@green.homeunix.org> References: <1090412431.7114.13.camel@builder02.qubesoft.com> <83182.1090412961@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83182.1090412961@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 15:08:36 -0000 On Wed, Jul 21, 2004 at 02:29:21PM +0200, Poul-Henning Kamp wrote: > In message <1090412431.7114.13.camel@builder02.qubesoft.com>, Doug Rabson write > s: > > >> The problem is that I cannot find the device_t without dereferencing > >> the struct cdev (either for si_driver[12] or the dev_t) and by then > >> it is too late. There is no way we can avoid refcounting on the cdev. > > > >Ok, so you are going to handle this in specfs (or whatever replaces > >specfs)? That makes sense. > > That's the only way I can see to avoid tons of copy&paste code all over > the drivers, because it's all the same for them. > > >Any ideas on how network interfaces should > >work in this? > > I talked with Robert briefly about this yesterday, and the problem > there is that struct ifnet is embedded in the softc. If the softc > had a pointer to the ifnet, then we could do something similar, but > as long as it's embedded we're stuck. What's the difference, when in the normal case (every case?) there is a poor-man's-OO implemented by making the softc's first member ifnet (or something containing ifnet like arpcom or ieee80211com), so a pointer to an ifnet or softc or whatever is almost always castable? I believe that this is a very traditional behavior. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 16:38:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA67616A4CE for ; Wed, 21 Jul 2004 16:38:50 +0000 (GMT) Received: from pfepc.post.tele.dk (pfepc.post.tele.dk [195.41.46.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85DB343D45 for ; Wed, 21 Jul 2004 16:38:50 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x50a07c53.naenxx7.adsl-dhcp.tele.dk [80.160.124.83]) by pfepc.post.tele.dk (Postfix) with ESMTP id D01E7262831; Wed, 21 Jul 2004 18:38:48 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6LGcldd084656; Wed, 21 Jul 2004 18:38:47 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 08:49:26 MDT." <20040721.084926.84362543.imp@bsdimp.com> Date: Wed, 21 Jul 2004 18:38:47 +0200 Message-ID: <84655.1090427927@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 16:38:50 -0000 In message <20040721.084926.84362543.imp@bsdimp.com>, "M. Warner Losh" writes: >[[ only cc'd arch@ ]] > >In message: <83182.1090412961@critter.freebsd.dk> > "Poul-Henning Kamp" writes: >: >Any ideas on how network interfaces should >: >work in this? >: >: I talked with Robert briefly about this yesterday, and the problem >: there is that struct ifnet is embedded in the softc. If the softc >: had a pointer to the ifnet, then we could do something similar, but >: as long as it's embedded we're stuck. > >Why is that the case? We don't detach the ifnet stuff after deleting >the softc. Why would a pointer to ifnet in the softc make this >easier? Because it would allow the softc could be freed before the ifnet structure. >I mean, I understand that having a pointer would insulate the size of >ifnet from the driver, but there's so many offsets in ifnet that are >encoded in the driver that doesn't seem that big a win. That's not the point here. The problem here is that we cannot unload the driver until we have hunted down and exterminated all references to the ifnet structure. If softc only pointed to the ifnet, we could neuter the ifnet (like we do for cdev and vnodes with a set of dead_* functions) wait for all threads to drain out of the module and unload it. The ifnet cleanup will happen "when convenient". It is less of an issue in networks than in cdevsw{} context, but dismantling things from above is easier than the opposite. -- 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 Jul 21 17:12:21 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9C9816A4CE for ; Wed, 21 Jul 2004 17:12:21 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 569A143D39 for ; Wed, 21 Jul 2004 17:12:21 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i6LHAgX7061719; Wed, 21 Jul 2004 11:10:43 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jul 2004 11:10:45 -0600 (MDT) Message-Id: <20040721.111045.88466992.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <84655.1090427927@critter.freebsd.dk> References: <20040721.084926.84362543.imp@bsdimp.com> <84655.1090427927@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 17:12:21 -0000 In message: <84655.1090427927@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20040721.084926.84362543.imp@bsdimp.com>, "M. Warner Losh" writes: : >[[ only cc'd arch@ ]] : > : >In message: <83182.1090412961@critter.freebsd.dk> : > "Poul-Henning Kamp" writes: : >: >Any ideas on how network interfaces should : >: >work in this? : >: : >: I talked with Robert briefly about this yesterday, and the problem : >: there is that struct ifnet is embedded in the softc. If the softc : >: had a pointer to the ifnet, then we could do something similar, but : >: as long as it's embedded we're stuck. : > : >Why is that the case? We don't detach the ifnet stuff after deleting : >the softc. Why would a pointer to ifnet in the softc make this : >easier? : : Because it would allow the softc could be freed before the ifnet : structure. But the ifnet structure has a back pointer to the softc. What would this accomplish? struct ifnet { void *if_softc; /* pointer to driver state */ so you'd have to zero this out, and then change all the places that dereference this to check for NULL. :-( : >I mean, I understand that having a pointer would insulate the size of : >ifnet from the driver, but there's so many offsets in ifnet that are : >encoded in the driver that doesn't seem that big a win. : : That's not the point here. The problem here is that we cannot unload : the driver until we have hunted down and exterminated all references : to the ifnet structure. We can't unload the driver until we've exterminated all references to softc too. : If softc only pointed to the ifnet, we could neuter the ifnet (like : we do for cdev and vnodes with a set of dead_* functions) wait for : all threads to drain out of the module and unload it. The ifnet : cleanup will happen "when convenient". We still ahve to wait for all threads with references to softc to drain out before we unload the module. I see a small benefit to that, but it seems that the requirements for softc are stronger than ifnet and already cover it. The detach routine of the driver could easily wait for the ifnet reference count to drop before returning for network drivers (heck the if_detach call could wait all references are gone, so that it isn't actually in the driver). Where it is stored seems not to matter so much. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 17:15:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF84A16A4CE for ; Wed, 21 Jul 2004 17:15:11 +0000 (GMT) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AC8A43D45 for ; Wed, 21 Jul 2004 17:15:11 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x50a07c53.naenxx7.adsl-dhcp.tele.dk [80.160.124.83]) by pfepb.post.tele.dk (Postfix) with ESMTP id DFB895EE093; Wed, 21 Jul 2004 19:15:09 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6LHF5gC087518; Wed, 21 Jul 2004 19:15:05 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 11:10:45 MDT." <20040721.111045.88466992.imp@bsdimp.com> Date: Wed, 21 Jul 2004 19:15:05 +0200 Message-ID: <87517.1090430105@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@FreeBSD.org Subject: Re: kldunload DIAGNOSTIC idea... 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, 21 Jul 2004 17:15:12 -0000 In message <20040721.111045.88466992.imp@bsdimp.com>, "M. Warner Losh" writes: >We still ahve to wait for all threads with references to softc to >drain out before we unload the module. I see a small benefit to that, >but it seems that the requirements for softc are stronger than ifnet >and already cover it. The detach routine of the driver could easily >wait for the ifnet reference count to drop before returning for >network drivers (heck the if_detach call could wait all references are >gone, so that it isn't actually in the driver). Where it is stored >seems not to matter so much. I have not studied the ifnet scenario in details, so I won't argue about it. -- 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 Jul 21 20:03:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC5ED16A4CE for ; Wed, 21 Jul 2004 20:03:50 +0000 (GMT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70CD243D49 for ; Wed, 21 Jul 2004 20:03:50 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.11/8.12.11) with ESMTP id i6LK3mB4060419 for ; Wed, 21 Jul 2004 21:03:49 +0100 (BST) (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)i6LK3m3E060418 for arch@freebsd.org; Wed, 21 Jul 2004 21:03:48 +0100 (BST) (envelope-from mark@grondar.org) X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])i6LJquJ3010111 for ; Wed, 21 Jul 2004 20:52:56 +0100 (BST) (envelope-from mark@grondar.org) Message-Id: <200407211952.i6LJquJ3010111@grimreaper.grondar.org> To: arch@freebsd.org From: Mark Murray Date: Wed, 21 Jul 2004 20:52:55 +0100 Sender: mark@grondar.org Subject: [PATCH] Big cleanup job on memory device 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, 21 Jul 2004 20:03:51 -0000 Hey all Please have a look at http://people.freebsd.org/~markm/mem.diff It is a big cleanup of sys/${ARCH}/${ARCH}/mem.c, and it turns multiple copies of MD code into MI code with the MD bits broken out. Lots of garbage is retired. It also turns the memory and io devices into loadable modules, but going this route is probably for the braver folks amongst us. I wrote 99% of this code more than a year ago, and over time, its been tested on i386, alpha and sparc64. M -- Mark Murray iumop ap!sdn w,I idlaH From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 20:11:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19B6016A4CE; Wed, 21 Jul 2004 20:11:37 +0000 (GMT) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E81B43D49; Wed, 21 Jul 2004 20:11:36 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x50a07c53.naenxx7.adsl-dhcp.tele.dk [80.160.124.83]) by pfepa.post.tele.dk (Postfix) with ESMTP id 7E27E47FE33; Wed, 21 Jul 2004 22:11:35 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i6LKBXPr092053; Wed, 21 Jul 2004 22:11:34 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Mark Murray From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Jul 2004 20:52:55 BST." <200407211952.i6LJquJ3010111@grimreaper.grondar.org> Date: Wed, 21 Jul 2004 22:11:33 +0200 Message-ID: <92052.1090440693@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [PATCH] Big cleanup job on memory device 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, 21 Jul 2004 20:11:37 -0000 In message <200407211952.i6LJquJ3010111@grimreaper.grondar.org>, Mark Murray wr ites: >Hey all > >Please have a look at http://people.freebsd.org/~markm/mem.diff > >It is a big cleanup of sys/${ARCH}/${ARCH}/mem.c, and it turns >multiple copies of MD code into MI code with the MD bits broken >out. Lots of garbage is retired. > >It also turns the memory and io devices into loadable modules, >but going this route is probably for the braver folks amongst us. > >I wrote 99% of this code more than a year ago, and over time, its >been tested on i386, alpha and sparc64. This looks like a good thing to me. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jul 22 13:02:22 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ABC416A4CE for ; Thu, 22 Jul 2004 13:02:22 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 5B39E43D53 for ; Thu, 22 Jul 2004 13:02:21 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 10422 invoked from network); 22 Jul 2004 12:57:32 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 22 Jul 2004 12:57:32 -0000 Received: (qmail 17782 invoked by uid 1000); 22 Jul 2004 13:02:18 -0000 Date: Thu, 22 Jul 2004 16:02:18 +0300 From: Peter Pentchev To: Mark Murray Message-ID: <20040722130218.GA17391@straylight.m.ringlet.net> Mail-Followup-To: Mark Murray , arch@freebsd.org References: <200407211952.i6LJquJ3010111@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LKTjZJSUETSlgu2t" Content-Disposition: inline In-Reply-To: <200407211952.i6LJquJ3010111@grimreaper.grondar.org> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org Subject: Re: [PATCH] Big cleanup job on memory device 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, 22 Jul 2004 13:02:22 -0000 --LKTjZJSUETSlgu2t Content-Type: multipart/mixed; boundary="MnLPg7ZWsaic7Fhd" Content-Disposition: inline --MnLPg7ZWsaic7Fhd Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 21, 2004 at 08:52:55PM +0100, Mark Murray wrote: > Hey all >=20 > Please have a look at http://people.freebsd.org/~markm/mem.diff >=20 > It is a big cleanup of sys/${ARCH}/${ARCH}/mem.c, and it turns > multiple copies of MD code into MI code with the MD bits broken > out. Lots of garbage is retired. >=20 > It also turns the memory and io devices into loadable modules, > but going this route is probably for the braver folks amongst us. >=20 > I wrote 99% of this code more than a year ago, and over time, its > been tested on i386, alpha and sparc64. Works for me; it just survived a buildworld on my somewhat loaded workstation (MySQL, PostgreSQL, X and all). It seems that you would need something like the attached patch to actually build LINT, though. And of course, a very strongly-worded UPDATING entry about including the 'null' and 'mem' devices in the kernel config, but I guess that's already on your list :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. --MnLPg7ZWsaic7Fhd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mem-NOTES.patch" Content-Transfer-Encoding: quoted-printable Index: sys/conf/NOTES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/conf/NOTES,v retrieving revision 1.1249 diff -u -r1.1249 NOTES --- sys/conf/NOTES 20 Jul 2004 12:42:54 -0000 1.1249 +++ sys/conf/NOTES 22 Jul 2004 12:45:04 -0000 @@ -831,6 +831,12 @@ # Cryptographically secure random number generator; /dev/[u]random device random =20 +# The bit-bucket; /dev/null +device null + +# The system memory device; /dev/mem +device mem + # Optional character code conversion support with LIBICONV. # Each option requires their base file system and LIBICONV. options CD9660_ICONV Index: sys/amd64/conf/NOTES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/amd64/conf/NOTES,v retrieving revision 1.14 diff -u -r1.14 NOTES --- sys/amd64/conf/NOTES 17 May 2004 22:13:14 -0000 1.14 +++ sys/amd64/conf/NOTES 22 Jul 2004 12:45:43 -0000 @@ -517,3 +517,7 @@ options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX options VM_KMEM_SIZE_SCALE + +=0C +# The I/O device +device io Index: sys/i386/conf/NOTES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/i386/conf/NOTES,v retrieving revision 1.1166 diff -u -r1.1166 NOTES --- sys/i386/conf/NOTES 21 Jul 2004 14:47:54 -0000 1.1166 +++ sys/i386/conf/NOTES 22 Jul 2004 12:45:25 -0000 @@ -1053,3 +1053,7 @@ options VM_KMEM_SIZE options VM_KMEM_SIZE_MAX options VM_KMEM_SIZE_SCALE + +=0C +# The I/O device +device io --MnLPg7ZWsaic7Fhd-- --LKTjZJSUETSlgu2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA/7ra7Ri2jRYZRVMRAv6+AKCRXUtW+ytDt1mB9YupvgaLsxQPCACfR0RK b7+dh/ir80un3+7JjnDnn04= =ePNB -----END PGP SIGNATURE----- --LKTjZJSUETSlgu2t-- From owner-freebsd-arch@FreeBSD.ORG Thu Jul 22 15:02:34 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB83D16A4CE for ; Thu, 22 Jul 2004 15:02:34 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B41AC43D60 for ; Thu, 22 Jul 2004 15:02:34 +0000 (GMT) (envelope-from phk@FreeBSD.org) Received: from freefall.freebsd.org (phk@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i6MF2YDK039033 for ; Thu, 22 Jul 2004 15:02:34 GMT (envelope-from phk@freefall.freebsd.org) Received: (from phk@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i6MF2Yqg039032 for arch@freebsd.org; Thu, 22 Jul 2004 15:02:34 GMT (envelope-from phk) Date: Thu, 22 Jul 2004 15:02:34 GMT From: Poul-Henning Kamp Message-Id: <200407221502.i6MF2Yqg039032@freefall.freebsd.org> To: arch@freebsd.org Subject: [REVIEW] unit number allocation API 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, 22 Jul 2004 15:02:34 -0000 We need to allocate unit numbers for (pseudo)devices, and a few places we need to allocate inode numbers for synthetic filesystems (for instance DEVFS). For these applications the overhead of rman(9) can be totally unacceptable (60 bytes per allocation ?) and something more memory frugal is called for. This is a small API I just wrote, targeted specifically for allocating unit numbers and similar spaces. Currently the allocation policy is "lowest free number", but it would be possible to add support for allocating a specific number as well. It uses a mixed run-length/bitmap strategy with fixed size memory chunks (so it can use uma(9) in the kernel). Worst case memory usage is two bits per managed unit-number (worst case is "allocate all units, free all the odd numbered ones"). For the typical case where we never free any unit numbers, it will use 52 bytes in total on i386. Please review. (It can be run in userland) Poul-Henning /*- * Copyright (c) 2004 Poul-Henning Kamp * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $FreeBSD$ * * Unit number allocation functions. * * These functions implement a mixed run-length/bitmap management of unit * number spaces. * * Allocation is always lowest free number first. * * Worst case memory usage (disregarding boundary effects in the low end) * is two bits for each slot in the unit number space. * * The typical case where no unit numbers are freed is managed in a * constant sized memory footprint of: * sizeof(struct unithdr) + 2 * sizeof (struct unit) * (== 52 bytes on i386) * * A small userland driver program is included. * */ #ifndef _KERNEL #include #include #endif #include #include #include #ifndef _KERNEL #define KASSERT(cond, arg) \ do { \ if (!(cond)) { \ printf arg; \ exit (1); \ } \ } while (0) #endif /* * This is our basic building block. * * It can be used in three different ways depending on the value of the ptr * element. If ptr is NULL, it represents a run of free units. If ptr points * to the head, it represents a run of busy units. Otherwise it points to * an bitstring where a set bit means busy. * * When a run is represented, the len field is the length of the run. * When a bitmap is represented the len field represents the number of busy * units in the bitmap. * * The bitmap is the same size as struct unit to optimize memory management. */ struct unit { TAILQ_ENTRY(unit) list; u_int len; void *ptr; }; /* Number of bits in the bitmap */ #define NBITS (sizeof(struct unit) * 8) /* Header element for a unit number space. */ struct unithdr { TAILQ_HEAD(unithd,unit) head; u_int low; u_int high; u_int busy; }; #ifndef _KERNEL /* * Userland memory management. Just use calloc and keep track of how * many elements we have allocated for check_unithdr(). */ static u_int nalloc; static void * new_unit(void) { nalloc++; return (calloc(1, sizeof(struct unit))); } static void delete_unit(void *ptr) { nalloc--; free(ptr); } #endif #if defined(DIAGNOSTIC) || !defined(_KERNEL) /* * Consistency check */ static void check_unithdr(struct unithdr *uh) { struct unit *up; u_int x, y, z, w; y = 0; z = 0; TAILQ_FOREACH(up, &uh->head, list) { if (up->ptr != uh && up->ptr != NULL) { w = 0; for (x = 0; x < NBITS; x++) if (bit_test((bitstr_t *)up->ptr, x)) w++; KASSERT (w == up->len, ("up->len = %d should be %d\n", up->len, w)); } if (up->ptr != NULL) y += up->len; z++; if (up->ptr != NULL && up->ptr != uh) z++; } KASSERT (y == uh->busy, ("Wrong result, busy %u y %u\n", uh->busy, y)); KASSERT (z == nalloc, ("found %u alloc %u\n", z, nalloc)); } #define CHECK_UNITHDR(uh) check_unithdr(uh) #else #define CHECK_UNITHDR(uh) #endif /* * Allocate a new unit management set. * * Highest and lowest valid values given as paramters. */ struct unithdr * new_unithdr(u_int low, u_int high) { struct unithdr *uh; struct unit *up; KASSERT(low <= high, ("new_unithdr(%u, %u) makes no sense", low, high)); uh = calloc(1, sizeof *uh); TAILQ_INIT(&uh->head); uh->low = low; uh->high = high; up = new_unit(); up->len = 1 + high - low; up->ptr = NULL; TAILQ_INSERT_HEAD(&uh->head, up, list); return (uh); } /* * See if a given unit should be collapsed with a neighbor */ static void collapse_unit(struct unithdr *uh, struct unit *up) { struct unit *upp; upp = TAILQ_PREV(up, unithd, list); if (upp != NULL && up->ptr == upp->ptr) { up->len += upp->len; TAILQ_REMOVE(&uh->head, upp, list); delete_unit(upp); } upp = TAILQ_NEXT(up, list); if (upp != NULL && up->ptr == upp->ptr) { up->len += upp->len; TAILQ_REMOVE(&uh->head, upp, list); delete_unit(upp); } } /* * Eliminate a zero length unit */ static void elim_unit(struct unithdr *uh, struct unit *up) { struct unit *upp; KASSERT(up->len == 0, ("elim_unit on %u length unit", up->len)); upp = TAILQ_PREV(up, unithd, list); if (upp == NULL) upp = TAILQ_NEXT(up, list); TAILQ_REMOVE(&uh->head, up, list); delete_unit(up); if (upp != NULL) collapse_unit(uh, upp); } /* * Allocate a free unit. */ u_int alloc_unit(struct unithdr *uh) { struct unit *up, *upp; u_int x; int y; CHECK_UNITHDR(uh); x = uh->low; TAILQ_FOREACH(up, &uh->head, list) { if (up->ptr == uh) { /* Skip busy entries */ x += up->len; continue; } if (up->ptr != NULL) { /* Bitmap unit */ bit_ffc((bitstr_t *)up->ptr, NBITS, &y); KASSERT(y != -1, ("No clear bit in bitmap page")); bit_set((bitstr_t *)up->ptr, y); up->len++; if (up->len == NBITS) { /* The unit is all busy, drop bitmap */ delete_unit(up->ptr); up->ptr = uh; collapse_unit(uh, up); } uh->busy++; CHECK_UNITHDR(uh); return (x + y); } if (up->len == 1) { /* Single free unit, grab it */ up->ptr = uh; collapse_unit(uh, up); uh->busy++; CHECK_UNITHDR(uh); return (x); } /* Slice off first free unit */ upp = TAILQ_PREV(up, unithd, list); if (upp == NULL || upp->ptr != uh) { upp = new_unit(); upp->len = 0; upp->ptr = uh; TAILQ_INSERT_BEFORE(up, upp, list); } upp->len++; up->len--; uh->busy++; CHECK_UNITHDR(uh); return (x); } KASSERT(0 == 1, ("Unit table full")); } /* * Free a unit. * * If we can save units by using a bitmap, do so. */ void free_unit(struct unithdr *uh, u_int unit) { struct unit *up, *upp, *upn, *ul; u_int x, l, xl, n, pl; KASSERT(unit >= uh->low && unit <= uh->high, ("free_unit(%u) out of range [%u...%u]", unit, uh->low, uh->high)); CHECK_UNITHDR(uh); unit -= uh->low; x = 0; l = unit - unit % NBITS; ul = 0; TAILQ_FOREACH(up, &uh->head, list) { /* Keep track of which unit we'll split if we do */ if (x <= l) { ul = up; xl = x; } if (up->ptr != NULL && up->ptr != uh) { /* Bitmap */ if (x + NBITS <= unit) { /* Skip bitmap */ x += NBITS; continue; } KASSERT(bit_test((bitstr_t *)up->ptr, unit - x) != 0, ("Freeing free unit %d %d (bitmap)\n", unit, unit - x)); bit_clear((bitstr_t *)up->ptr, unit - x); uh->busy--; up->len--; /* * XXX: up->len == 1 can possibly be collapsed to * XXX: neighboring runs. */ if (up->len > 0) return; /* We have freed all units in bitmap, drop it */ delete_unit(up->ptr); up->ptr = NULL; up->len = NBITS; collapse_unit(uh, up); CHECK_UNITHDR(uh); return; } if (x + up->len <= unit) { /* Run length unit */ /* Skip run length */ x += up->len; continue; } /* We now have our run length unit */ KASSERT(up->ptr == uh, ("Freeing free unit %d (range)\n", unit)); /* Check if we can shift a unit to the previous one */ upp = TAILQ_PREV(up, unithd, list); if (unit == x && upp != NULL && upp->ptr == NULL) { upp->len++; up->len--; uh->busy--; if (up->len == 0) elim_unit(uh, up); CHECK_UNITHDR(uh); return; } /* Check if we can shift a unit to the next one */ upn = TAILQ_NEXT(up, list); if (unit == x + up->len - 1 && upn != NULL && upn->ptr == NULL) { upn->len++; up->len--; uh->busy--; if (up->len == 0) elim_unit(uh, up); CHECK_UNITHDR(uh); return; } /* * Split the current unit in two or three * * We do this backwards to front to keel ul valid. */ pl = up->len - (1 + (unit - x)); if (pl > 0) { /* The busy tail end */ upp = new_unit(); upp->ptr = uh; upp->len = pl; TAILQ_INSERT_AFTER(&uh->head, up, upp, list); } if (unit == x) { /* We are done splitting */ up->len = 1; up->ptr = NULL; } else { /* The freed bit */ upp = new_unit(); upp->len = 1; upp->ptr = NULL; TAILQ_INSERT_AFTER(&uh->head, up, upp, list); /* Adjust current unit */ up->len = unit - x; } /* Our ul element may have shifted one later */ if (ul->len + xl <= l) { xl += ul->len; ul = TAILQ_NEXT(ul, list); } uh->busy--; CHECK_UNITHDR(uh); /* Count units entirely inside potential bitmap */ n = 0; pl = xl; unit = l + NBITS; for (up = ul; up != NULL && pl + up->len <= unit; up = TAILQ_NEXT(up, list)) { if (pl >= l) n++; pl += up->len; } /* If less than three, a bitmap does not pay off */ if (n < 3) return; /* Allocate bitmap */ upp = new_unit(); upp->ptr = new_unit(); /* Tail end of ul element */ pl = ul->len - (l - xl); if (ul->ptr != NULL) { bit_nset(upp->ptr, 0, pl - 1); upp->len = pl; } ul->len -= pl; /* * We keep around ul even if it became zero sized, we need * it as a marker for where the bitmap goes in the tailq. */ l += pl; /* Soak up run length units until we have absorbed NBITS */ while (pl != NBITS) { /* Grab first one in line */ upn = TAILQ_NEXT(ul, list); /* We may not have a multiple of NBITS totally */ if (upn == NULL) break; /* Run may extend past our new bitmap */ n = NBITS - pl; if (n > upn->len) n = upn->len; if (upn->ptr != NULL) { bit_nset(upp->ptr, pl, pl + n - 1); upp->len += n; } pl += n; if (n != upn->len) { /* We did not absorbed the entire run */ upn->len -= n; break; } TAILQ_REMOVE(&uh->head, upn, list); delete_unit(upn); } /* Insert the bitmap after ul */ TAILQ_INSERT_AFTER(&uh->head, ul, upp, list); /* Ditch ul if it got reduced to zero size */ if (ul->len == 0) { TAILQ_REMOVE(&uh->head, ul, list); delete_unit(ul); } CHECK_UNITHDR(uh); return; } KASSERT(0 != 1, ("Fell off the end in free_unit")); } #ifndef _KERNEL /* * Simple stochastic test driver for the above functions */ static void print_unit(struct unithdr *uh, struct unit *up) { u_int x; printf(" %p len = %5u ptr = %p", up, up->len, up->ptr); if (up->ptr == uh || up->ptr == NULL) { printf("\n"); return; } printf(" ["); for (x = 0; x < NBITS; x++) { if (bit_test((bitstr_t *)up->ptr, x)) putchar('#'); else putchar(' '); } printf("]\n"); } static void print_unithdr(struct unithdr *uh) { struct unit *up; u_int x; printf("%p low = %u high = %u busy %u\n", uh, uh->low, uh->high, uh->busy); x = uh->low; TAILQ_FOREACH(up, &uh->head, list) { printf(" from = %5u", x); print_unit(uh, up); if (up->ptr == NULL || up->ptr == uh) x += up->len; else x += NBITS; } } /* Number of units to test */ #define NN 10000 int main(int argc __unused, const char **argv __unused) { struct unithdr *uh; int i, x; char a[NN]; uh = new_unithdr(0, NN - 1); memset(a, 0, sizeof a); printf("sizeof(struct unit) %d\n", sizeof (struct unit)); printf("sizeof(struct unithdr) %d\n", sizeof (struct unithdr)); x = 1; for (;;) { i = random() % NN; if (a[i]) { printf("F %u\n", i); free_unit(uh, i); a[i] = 0; } else { i = alloc_unit(uh); a[i] = 1; printf("A %u\n", i); } if (1) /* XXX: change this for detailed debug printout */ print_unithdr(uh); check_unithdr(uh); } return (0); } #endif -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Jul 22 15:04:05 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEA5B16A4CE for ; Thu, 22 Jul 2004 15:04:05 +0000 (GMT) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 770DD43D45 for ; Thu, 22 Jul 2004 15:04:05 +0000 (GMT) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) i6MF44uM094593; Thu, 22 Jul 2004 16:04:04 +0100 (BST) (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)i6MF44iP094592; Thu, 22 Jul 2004 16:04:04 +0100 (BST) (envelope-from mark@grondar.org) X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])i6MF08PY003720; Thu, 22 Jul 2004 16:00:09 +0100 (BST) (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200407221500.i6MF08PY003720@grimreaper.grondar.org> To: Peter Pentchev In-Reply-To: Your message of "Thu, 22 Jul 2004 16:02:18 +0300." <20040722130218.GA17391@straylight.m.ringlet.net> Date: Thu, 22 Jul 2004 16:00:08 +0100 Sender: mark@grondar.org cc: arch@FreeBSD.ORG Subject: Re: [PATCH] Big cleanup job on memory device 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, 22 Jul 2004 15:04:06 -0000 Peter Pentchev writes: > Works for me; it just survived a buildworld on my somewhat loaded > workstation (MySQL, PostgreSQL, X and all). Excellent! Thank you. > It seems that you would need something like the attached patch to > actually build LINT, though. And of course, a very strongly-worded > UPDATING entry about including the 'null' and 'mem' devices in > the kernel config, but I guess that's already on your list :) Yup, but thanks for keeping me on my toes! M -- Mark Murray iumop ap!sdn w,I idlaH From owner-freebsd-arch@FreeBSD.ORG Thu Jul 22 17:38:45 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DB7016A4CE; Thu, 22 Jul 2004 17:38:45 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E1EA43D1F; Thu, 22 Jul 2004 17:38:45 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-121-219-69.dsl.snfc21.pacbell.net [68.121.219.69])i6MHchKn260214; Thu, 22 Jul 2004 13:38:43 -0400 Message-ID: <40FFFBA3.1030204@elischer.org> Date: Thu, 22 Jul 2004 10:38:43 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Poul-Henning Kamp References: <200407221502.i6MF2Yqg039032@freefall.freebsd.org> In-Reply-To: <200407221502.i6MF2Yqg039032@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: [REVIEW] unit number allocation API 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, 22 Jul 2004 17:38:45 -0000 Poul-Henning Kamp wrote: >We need to allocate unit numbers for (pseudo)devices, and a few >places we need to allocate inode numbers for synthetic filesystems >(for instance DEVFS). > >For these applications the overhead of rman(9) can be totally >unacceptable (60 bytes per allocation ?) and something more memory >frugal is called for. > >This is a small API I just wrote, targeted specifically for allocating >unit numbers and similar spaces. > >Currently the allocation policy is "lowest free number", but it >would be possible to add support for allocating a specific number >as well. > >It uses a mixed run-length/bitmap strategy with fixed size memory >chunks (so it can use uma(9) in the kernel). > >Worst case memory usage is two bits per managed unit-number (worst >case is "allocate all units, free all the odd numbered ones"). > >For the typical case where we never free any unit numbers, it will >use 52 bytes in total on i386. > >Please review. (It can be run in userland) > >Poul-Henning > > > please also look at the Thread_id (lwpid) allocator marcel added to kern_thread.c