From owner-freebsd-arch Sun Dec 23 0:39:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 7983D37B416; Sun, 23 Dec 2001 00:39:14 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBN8bAl61272; Sun, 23 Dec 2001 09:37:14 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: The Anarcat Cc: arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: sysctl kern.disks shouldn't have to sort its output In-Reply-To: Your message of "Sat, 22 Dec 2001 18:08:00 EST." <20011222230759.GD530@shall.anarcat.dyndns.org> Date: Sun, 23 Dec 2001 09:37:10 +0100 Message-ID: <61270.1009096630@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011222230759.GD530@shall.anarcat.dyndns.org>, The Anarcat writes: >-- snip -- >revision 1.50.2.14 >date: 2001/09/18 06:47:30; author: jkh; state: Exp; lines: +2 -2 >Temporarily disable the use of kern.disks - it returns the disk >devices in the wrong order and causes them to be displayed out of >sequence in sysinstall. >To me, the sorting belongs to libdisk at most, or to the user app. ABSOLUTELY! >Of course, one might wonder why the entries in kern.disks are not >sorted. This, I do not know. It might depend on how the disks are >detected. For example, here, sysctl kern.disks gives: > >kern.disks: cd0 ad3 ad1 ad0 md0 The reason they are not sorted is that if userland wants them sorted, it can be trivially done, whereas nothing in the kernel wants them sorted and consequently sorting them in the kernel would be waste of time&space. Not to mention agreeing on what the _right_ sorting order would be: disk before CD/DVD ? SCSI before ATA ? Fixed before removable ? BIKESHED!!!! >Anyways. If the sorting belongs to the kernel, I could do it. don't. >However, I think it belongs to libdisk, so I'll start working on a patch >there. Yes, please do. That is what Jordan should have done (and was urged to) in the first place, but he was afraid that he would b0rk sysinstall doing so. Go figure. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 23 1:36:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from titanic.uninet.kiev.ua (titanic.uninet.kiev.ua [193.125.78.35]) by hub.freebsd.org (Postfix) with ESMTP id 71E8B37B405 for ; Sun, 23 Dec 2001 01:36:53 -0800 (PST) Received: (from uucp@localhost) by titanic.uninet.kiev.ua (8.11.1/8.11.1) with UUCP id fBN9aj214703; Sun, 23 Dec 2001 11:36:45 +0200 (EET) (envelope-from ura@sphinx.univ.kiev.ua) Received: by sphinx.univ.kiev.ua (Postfix, from userid 1001) id C117C59201; Sun, 23 Dec 2001 11:35:44 +0200 (EET) Date: Sun, 23 Dec 2001 11:35:44 +0200 From: Yuri Karaban To: Peter Wemm Cc: freebsd-arch@freebsd.org Subject: Re: gnu getopt in libc Message-ID: <20011223093544.GA27632@sphinx.univ.kiev.ua> References: <20011222132030.GA19596@sphinx.univ.kiev.ua> <20011222201930.B9DEF38CC@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011222201930.B9DEF38CC@overcee.netplex.com.au> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 22, 2001 at 12:19:30PM -0800, Peter Wemm wrote: > > gnu getopt supports long options and can reorder option keys > > so i can write: > > some_program -a -b -c file1 file2 -d -e -f > > > > FreeBSD getopt in libc very simple it can recoginze only one letter > > arguments, does not support optional arguments and arguments to > > program may appear only at the beginning. > > > > so why dont replace libc/stdlib/getopt.c by gnu version ? > > 1) because it is nonstandard You mean that some programs relies on the fact that -d -e -f are files also ? There is a solution, if the NEW_GETOPT environment varaible is set, act as gnu getopt, and people who want the old behavior (or their scripts/programs require that) simply should not set this variable. > 2) it is GPL contaminated which we cannot use in libc. This is not the problem, someone (maybe me) can write it, getopt with the same functionality. PS. If I want to write a new getopt function, isn't my work futile ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 23 1:46: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from titanic.uninet.kiev.ua (titanic.uninet.kiev.ua [193.125.78.35]) by hub.freebsd.org (Postfix) with ESMTP id 09BF637B419; Sun, 23 Dec 2001 01:46:00 -0800 (PST) Received: (from uucp@localhost) by titanic.uninet.kiev.ua (8.11.1/8.11.1) with UUCP id fBN9jvl15250; Sun, 23 Dec 2001 11:45:57 +0200 (EET) (envelope-from ura@sphinx.univ.kiev.ua) Received: by sphinx.univ.kiev.ua (Postfix, from userid 1001) id D5F4159201; Sun, 23 Dec 2001 11:44:07 +0200 (EET) Date: Sun, 23 Dec 2001 11:44:07 +0200 From: Yuri Karaban To: Kris Kennaway Cc: freebsd-arch@freebsd.org Subject: Re: gnu getopt in libc Message-ID: <20011223094407.GA31337@sphinx.univ.kiev.ua> References: <20011222132030.GA19596@sphinx.univ.kiev.ua> <20011222201930.B9DEF38CC@overcee.netplex.com.au> <20011222212453.A91247@citusc17.usc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011222212453.A91247@citusc17.usc.edu> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > so why dont replace libc/stdlib/getopt.c by gnu version ? > > > > 1) because it is nonstandard > > 2) it is GPL contaminated which we cannot use in libc. > > NetBSD have a BSDL'ed getopt_long() in their libc. It's required for > GNU tar longopt support in pax(1) - I have an almost complete port of > both in my tree. Does the NetBSD getopt support the optional arguments and options reorder ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 23 5:25:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 4A7F437B419; Sun, 23 Dec 2001 05:25:22 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.6/8.11.4) id fBNDP9H99811; Sun, 23 Dec 2001 05:25:09 -0800 (PST) (envelope-from kris) Date: Sun, 23 Dec 2001 05:25:08 -0800 From: Kris Kennaway To: Yuri Karaban Cc: Kris Kennaway , freebsd-arch@FreeBSD.ORG Subject: Re: gnu getopt in libc Message-ID: <20011223052508.A99762@citusc17.usc.edu> References: <20011222132030.GA19596@sphinx.univ.kiev.ua> <20011222201930.B9DEF38CC@overcee.netplex.com.au> <20011222212453.A91247@citusc17.usc.edu> <20011223094407.GA31337@sphinx.univ.kiev.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011223094407.GA31337@sphinx.univ.kiev.ua>; from ura@sphinx.univ.kiev.ua on Sun, Dec 23, 2001 at 11:44:07AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 23, 2001 at 11:44:07AM +0200, Yuri Karaban wrote: > > > > so why dont replace libc/stdlib/getopt.c by gnu version ? > > >=20 > > > 1) because it is nonstandard > > > 2) it is GPL contaminated which we cannot use in libc. > >=20 > > NetBSD have a BSDL'ed getopt_long() in their libc. It's required for > > GNU tar longopt support in pax(1) - I have an almost complete port of > > both in my tree. > Does the NetBSD getopt support the optional arguments and options reorder= ? I don't know off-hand..I'm not even sure what you mean :) Kris --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8Jds0Wry0BWjoQKURAsFrAKCYe7ar4uldH2juRQM9dHJafj4WjwCg8yth ng74mwhrUjgWpKgsbAZtnHw= =JSPh -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 23 6: 1:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from titanic.uninet.kiev.ua (titanic.uninet.kiev.ua [193.125.78.35]) by hub.freebsd.org (Postfix) with ESMTP id 4241B37B41A; Sun, 23 Dec 2001 06:01:12 -0800 (PST) Received: (from uucp@localhost) by titanic.uninet.kiev.ua (8.11.1/8.11.1) with UUCP id fBNE18730948; Sun, 23 Dec 2001 16:01:08 +0200 (EET) (envelope-from ura@sphinx.univ.kiev.ua) Received: by sphinx.univ.kiev.ua (Postfix, from userid 1001) id 6723B59201; Sun, 23 Dec 2001 16:01:47 +0200 (EET) Date: Sun, 23 Dec 2001 16:01:47 +0200 From: Yuri Karaban To: Kris Kennaway Cc: freebsd-arch@FreeBSD.ORG Subject: Re: gnu getopt in libc Message-ID: <20011223140147.GA35333@sphinx.univ.kiev.ua> Mail-Followup-To: Kris Kennaway , freebsd-arch@FreeBSD.ORG References: <20011222132030.GA19596@sphinx.univ.kiev.ua> <20011222201930.B9DEF38CC@overcee.netplex.com.au> <20011222212453.A91247@citusc17.usc.edu> <20011223094407.GA31337@sphinx.univ.kiev.ua> <20011223052508.A99762@citusc17.usc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011223052508.A99762@citusc17.usc.edu> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 23, 2001 at 05:25:08AM -0800, Kris Kennaway wrote: > > > NetBSD have a BSDL'ed getopt_long() in their libc. It's required for > > > GNU tar longopt support in pax(1) - I have an almost complete port of > > > both in my tree. > > Does the NetBSD getopt support the optional arguments and options reorder ? > > I don't know off-hand..I'm not even sure what you mean :) optional arguments is like: %> some_prog -n 10 and %> some_prog -n are both valid and options reorder is: %> some_prog -a -b -c hello world -d -e f for getopt caller is the same as %> some_prog -a -b -c -d -e -f hello world To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 23 6:20:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id EC8EA37B417; Sun, 23 Dec 2001 06:20:39 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.6/8.11.4) id fBNEKdD00846; Sun, 23 Dec 2001 06:20:39 -0800 (PST) (envelope-from kris) Date: Sun, 23 Dec 2001 06:20:39 -0800 From: Kris Kennaway To: Kris Kennaway , freebsd-arch@FreeBSD.ORG Subject: Re: gnu getopt in libc Message-ID: <20011223062039.A827@citusc17.usc.edu> References: <20011222132030.GA19596@sphinx.univ.kiev.ua> <20011222201930.B9DEF38CC@overcee.netplex.com.au> <20011222212453.A91247@citusc17.usc.edu> <20011223094407.GA31337@sphinx.univ.kiev.ua> <20011223052508.A99762@citusc17.usc.edu> <20011223140147.GA35333@sphinx.univ.kiev.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011223140147.GA35333@sphinx.univ.kiev.ua>; from ura@sphinx.univ.kiev.ua on Sun, Dec 23, 2001 at 04:01:47PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 23, 2001 at 04:01:47PM +0200, Yuri Karaban wrote: > On Sun, Dec 23, 2001 at 05:25:08AM -0800, Kris Kennaway wrote: >=20 > > > > NetBSD have a BSDL'ed getopt_long() in their libc. It's required f= or > > > > GNU tar longopt support in pax(1) - I have an almost complete port = of > > > > both in my tree. > > > Does the NetBSD getopt support the optional arguments and options reo= rder ? > >=20 > > I don't know off-hand..I'm not even sure what you mean :) > optional arguments is like: > %> some_prog -n 10 > and > %> some_prog -n > are both valid >=20 > and options reorder is: > %> some_prog -a -b -c hello world -d -e f > for getopt caller is the same as > %> some_prog -a -b -c -d -e -f hello world Okay, now I'm sure what you mean, but I still don't know off-hand :-) Kris --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8Jeg3Wry0BWjoQKURApw7AKCwgt9CrpoxWCPQMFF12y0PVKBoVwCfV132 sjIz+iO9qsREUf2oevondWY= =kq7R -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 23 6:26:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by hub.freebsd.org (Postfix) with ESMTP id 0A1A337B405; Sun, 23 Dec 2001 06:26:25 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 16I9a3-0008CZ-0V; Sun, 23 Dec 2001 14:26:23 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id fBNEP8927725; Sun, 23 Dec 2001 14:25:08 GMT (envelope-from dfr@nlsystems.com) Date: Sun, 23 Dec 2001 14:24:35 +0000 (GMT) From: Doug Rabson To: Julian Elischer Cc: Poul-Henning Kamp , John Baldwin , , Alfred Perlstein Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: Message-ID: <20011223142258.V457-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Dec 2001, Julian Elischer wrote: > > > On Thu, 20 Dec 2001, Poul-Henning Kamp wrote: > > > > > A) We should probably implement > > int enough_stack() > > a full unoptimised but correct version would be: > > int > enough_stack(u_int needed) > { > caddr_t addr, addr2; > > if needed > KSTACK_PAGES * PAGESIZE return 0; > > /* catch stupid values */ > addr1 = &needed; > addr2 = (caddr_t)curthread->td_kstack + needed; > > return (addr1 > addr2) > } One thing to remember - ia64 has *two* stacks. One traditional stack grows from the top of the kstack region downwards and the other, the register stack, grows upwards from the base of the kstack region. Its not possible to have a truly MI implementation of enough_stack(). -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 23 8:43:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tomts16-srv.bellnexxia.net (tomts16.bellnexxia.net [209.226.175.4]) by hub.freebsd.org (Postfix) with ESMTP id E14A137B41A; Sun, 23 Dec 2001 08:43:50 -0800 (PST) Received: from khan.anarcat.dyndns.org ([65.94.189.35]) by tomts16-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011223164344.LHAX19575.tomts16-srv.bellnexxia.net@khan.anarcat.dyndns.org>; Sun, 23 Dec 2001 11:43:44 -0500 Received: from shall.anarcat.dyndns.org (shall.anarcat.dyndns.org [192.168.0.1]) by khan.anarcat.dyndns.org (Postfix) with ESMTP id 07BBA1B24; Sun, 23 Dec 2001 11:43:40 -0500 (EST) Received: by shall.anarcat.dyndns.org (Postfix, from userid 1000) id DF51220ACD; Sun, 23 Dec 2001 11:43:37 -0500 (EST) Date: Sun, 23 Dec 2001 11:43:37 -0500 From: The Anarcat To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: sysctl kern.disks shouldn't have to sort its output Message-ID: <20011223164336.GA34175@shall.anarcat.dyndns.org> References: <20011222230759.GD530@shall.anarcat.dyndns.org> <61270.1009096630@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf" Content-Disposition: inline In-Reply-To: <61270.1009096630@critter.freebsd.dk> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --wq9mPyueHGvFACwf Content-Type: multipart/mixed; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun Dec 23, 2001 at 09:37:10AM +0100, Poul-Henning Kamp wrote: > In message <20011222230759.GD530@shall.anarcat.dyndns.org>, The Anarcat w= rites: >=20 > >-- snip -- > >revision 1.50.2.14 > >date: 2001/09/18 06:47:30; author: jkh; state: Exp; lines: +2 -2 > >Temporarily disable the use of kern.disks - it returns the disk > >devices in the wrong order and causes them to be displayed out of > >sequence in sysinstall. >=20 >=20 > >To me, the sorting belongs to libdisk at most, or to the user app. >=20 > ABSOLUTELY! Yay. > >Of course, one might wonder why the entries in kern.disks are not > >sorted. This, I do not know. It might depend on how the disks are > >detected. For example, here, sysctl kern.disks gives: > > > >kern.disks: cd0 ad3 ad1 ad0 md0 >=20 > The reason they are not sorted is that if userland wants them sorted, > it can be trivially done, whereas nothing in the kernel wants them > sorted and consequently sorting them in the kernel would be waste > of time&space. Arguable, but I agree. > Not to mention agreeing on what the _right_ sorting order would be: > disk before CD/DVD ? > SCSI before ATA ? > Fixed before removable ? > BIKESHED!!!! I prefer my bikeshed to be: lexicographical order. ;) > >Anyways. If the sorting belongs to the kernel, I could do it. >=20 > don't. I did. Patch attached. :) It's simple, really. It just finds a proper place to add the disk when it is created instead of mindlessly adding it at the HEAD of the list. Oh, and if this gets committed, I suggest the removal of the printfs. :) (let the flamewar begin) > >However, I think it belongs to libdisk, so I'll start working on a patch > >there. >=20 > Yes, please do. That is what Jordan should have done (and was urged to) > in the first place, but he was afraid that he would b0rk sysinstall doing > so. Go figure. Already done. See PR bin/33070 and post on this list. Someone in his right mind, please commit libdisk or kernel changes, I don't really care. I don't think kern.disks was broken in the first place, so *please* remove that KERN_DISKS_BROKEN crap from the makefile, at least. that also needs to be MFC'd, IMHO, because it affects the way libdisk detects drives: normal users can run sysctl kern.disks but not open(/dev/ad0). So testing libh is a breeze with kern.disks because you can do everything root can do without the dangerous commit part. :) BTW: I won't be able to come up with libh boot floppies until after the vacations, sadly. But I will come up with them at some point. ETA Jan 5. :) a. --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch Content-Transfer-Encoding: quoted-printable Index: subr_disk.c =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/kern/subr_disk.c,v retrieving revision 1.20.2.6 diff -u -r1.20.2.6 subr_disk.c --- subr_disk.c 5 Oct 2001 07:14:57 -0000 1.20.2.6 +++ subr_disk.c 23 Dec 2001 07:32:45 -0000 @@ -47,6 +47,7 @@ disk_create(int unit, struct disk *dp, int flags, struct cdevsw *cdevsw, s= truct cdevsw *proto) { dev_t dev; + struct disk *n1, *n2; =20 bzero(dp, sizeof(*dp)); =20 @@ -70,7 +71,30 @@ dp->d_dev =3D dev; dp->d_dsflags =3D flags; dp->d_devsw =3D cdevsw; - LIST_INSERT_HEAD(&disklist, dp, d_list); + + /* find where we must put this device */ + n1 =3D LIST_FIRST(&disklist); + n2 =3D NULL; + /* skip lower devices */ + while ((n1 !=3D NULL) && + (strcmp(dev->si_name, n1->d_dev->si_name) > 0)) { + if (bootverbose) + printf("skipping disk %s to order %s\n", + n1->d_dev->si_name, dev->si_name); + n2 =3D n1; + n1 =3D LIST_NEXT(n1, d_list); + } + if (n2 =3D=3D NULL) { + LIST_INSERT_HEAD(&disklist, dp, d_list); + if (bootverbose) + printf("inserting disk %s at HEAD\n", dev->si_name); + } else { + LIST_INSERT_AFTER(n2, dp, d_list); + if (bootverbose) + printf("inserting disk %s after %s (n2)\n", + dev->si_name, n2->d_dev->si_name); + } +=09 return (dev); } =20 --bp/iNruPH9dso1Pn-- --wq9mPyueHGvFACwf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwmCbgACgkQttcWHAnWiGfyMACgnYmpmNBCjGSX3YO8qwHbn1bm tqYAnA1qbeqlXiz5OuqviRYZnBeAlqdp =PuNM -----END PGP SIGNATURE----- --wq9mPyueHGvFACwf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 23 12:27:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 0B1CA37B41B; Sun, 23 Dec 2001 12:27:49 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBNKPml72303; Sun, 23 Dec 2001 21:25:48 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: The Anarcat Cc: arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: sysctl kern.disks shouldn't have to sort its output In-Reply-To: Your message of "Sun, 23 Dec 2001 11:43:37 EST." <20011223164336.GA34175@shall.anarcat.dyndns.org> Date: Sun, 23 Dec 2001 21:25:48 +0100 Message-ID: <72301.1009139148@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011223164336.GA34175@shall.anarcat.dyndns.org>, The Anarcat write s: > >On Sun Dec 23, 2001 at 09:37:10AM +0100, Poul-Henning Kamp wrote: >> In message <20011222230759.GD530@shall.anarcat.dyndns.org>, The Anarcat w= >rites: >> >Anyways. If the sorting belongs to the kernel, I could do it. >> don't. > >I did. Patch attached. :) It's simple, really. It just finds a proper >place to add the disk when it is created instead of mindlessly adding it >at the HEAD of the list. > >Oh, and if this gets committed, I suggest the removal of the printfs. :) Since I think my my "MAINTAINER" status on subr_disk.c is still in good standing, consider this official notice that I object to this patch being committed. Sorting of the disks should happen in userland according to the individual applications need. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 23 12:29:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tomts6-srv.bellnexxia.net (tomts6.bellnexxia.net [209.226.175.26]) by hub.freebsd.org (Postfix) with ESMTP id B8C6537B405; Sun, 23 Dec 2001 12:29:44 -0800 (PST) Received: from khan.anarcat.dyndns.org ([65.94.189.35]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011223202943.NZRF14445.tomts6-srv.bellnexxia.net@khan.anarcat.dyndns.org>; Sun, 23 Dec 2001 15:29:43 -0500 Received: from shall.anarcat.dyndns.org (shall.anarcat.dyndns.org [192.168.0.1]) by khan.anarcat.dyndns.org (Postfix) with ESMTP id 0AC131B28; Sun, 23 Dec 2001 15:29:38 -0500 (EST) Received: by shall.anarcat.dyndns.org (Postfix, from userid 1000) id 6A1F420ACD; Sun, 23 Dec 2001 15:29:32 -0500 (EST) Date: Sun, 23 Dec 2001 15:29:32 -0500 From: The Anarcat To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: sysctl kern.disks shouldn't have to sort its output Message-ID: <20011223202931.GA34708@shall.anarcat.dyndns.org> References: <20011223164336.GA34175@shall.anarcat.dyndns.org> <72301.1009139148@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <72301.1009139148@critter.freebsd.dk> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun Dec 23, 2001 at 09:25:48PM +0100, Poul-Henning Kamp wrote: > In message <20011223164336.GA34175@shall.anarcat.dyndns.org>, The Anarcat= write > s: > > > >On Sun Dec 23, 2001 at 09:37:10AM +0100, Poul-Henning Kamp wrote: > >> In message <20011222230759.GD530@shall.anarcat.dyndns.org>, The Anarca= t w=3D > >rites: >=20 > >> >Anyways. If the sorting belongs to the kernel, I could do it. > >> don't. > > > >I did. Patch attached. :) It's simple, really. It just finds a proper > >place to add the disk when it is created instead of mindlessly adding it > >at the HEAD of the list. > > > >Oh, and if this gets committed, I suggest the removal of the printfs. :) >=20 > Since I think my my "MAINTAINER" status on subr_disk.c is still in good > standing, consider this official notice that I object to this patch > being committed. >=20 > Sorting of the disks should happen in userland according to the > individual applications need. Agreed, then. Would you then be kind enough to commit the changes to libdisk? ;) A. --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwmPqoACgkQttcWHAnWiGerBwCfX2+q8HpFAKWy+d04FChz1bPd s30AoJ26jiin1qkrowisz0lzbd+b731u =zKiG -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 24 9:49: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B6C2837B416 for ; Mon, 24 Dec 2001 09:49:04 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBOHn3D29854 for ; Mon, 24 Dec 2001 12:49:03 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 24 Dec 2001 12:49:03 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: sysctl (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Another case where sysctls need to be set for a module, but sysctl.conf is processed before the module is loaded. Makes one almost tempted to have /etc/modules/linux.conf which would look something like: before_load { }; after_load { sysctl compat.linux.osname="FreeBSD"; sysctl compat.linux.osrelease="4.4-STABLE"; }; before_unload { }; after_unload { }; Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services ---------- Forwarded message ---------- Date: 23 Dec 2001 18:21:13 -0500 From: Roger Savard To: freebsd-stable@freebsd.org Subject: sysctl Hi, I usually use /etc/sysctl.conf to modify two parameters compat.linux.osname=FreeBSD compat.linux.osrelease=4.4-Stable The reason behind this is to be accounted for FreeBSD instead of Linux ... some day will have native freebsd code... I get this result now: %sysctl -a | grep os ... pcib0: on motherboard <118>unknown oid 'compat.linux.osname' <118>unknown oid 'compat.linux.osrelease' <118> hostname <118> media: Ethernet autoselect (100baseTX ) user.posix2_version: 199212 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 jail.set_hostname_allowed: 1 compat.linux.osname: Linux compat.linux.osrelease: 2.4.2 compat.linux.oss_version: 198144 No changes !! Thanks again. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 24 11:15:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8228037B405 for ; Mon, 24 Dec 2001 11:15:13 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBOJF8D30554 for ; Mon, 24 Dec 2001 14:15:08 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 24 Dec 2001 14:15:07 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: Re: netstat -f inet broken ? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hmmm.. Talk about a weird date problem. Anyone got any thoughts on this one? Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services ---------- Forwarded message ---------- Date: Mon, 24 Dec 2001 12:03:34 -0600 (CST) From: "Stephen D. Spencer" To: Robert Watson Cc: freebsd-stable@FreeBSD.ORG Subject: Re: netstat -f inet broken ? On Mon, 24 Dec 2001, Robert Watson wrote: >> [...] > Verify that your userland and kernel are in sync, and let us know if the > problem persists. A few people ran into this, but it cleared up for all > of them when they re-sync'd userland and kernel. > Before removing the compile/name directory (which made it work dandily), I had the same netstat issue. The odd thing was that the dates on the problem kernels were quite off (system time has been verified). The second iteration reported that it had been compiled in October of 2081. This was after a build/installworld as of last night. Stephen Spencer | | "Mutton yesterday, mutton today, and blimey, | if it don't look like mutton again tomarrer" | -Bert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 25 11:13:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id F222737B419 for ; Tue, 25 Dec 2001 11:13:29 -0800 (PST) Received: (qmail 31318 invoked by uid 1000); 25 Dec 2001 18:29:25 -0000 Date: Tue, 25 Dec 2001 20:29:25 +0200 From: Peter Pentchev To: arch@FreeBSD.org Subject: make(1) enhancement - an 'environment processor' option Message-ID: <20011225202925.F304@straylight.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, As some of you may have noticed, I maintain a little utility that keeps environment variables on a per-directory basis - the sysutils/penv port. Basically, what it does is remember what variables you want set for a specific directory and then hand them in the environment of any program you want to run. This may be quite useful for ports, especially those with lots of tweakable knobs, like vpopmail or MySQL, since it won't let you miss one of those knobs the next time you rebuild the port. However, there is one little problem with penv - it only sets the environment based on the data for the current directory. If a port has dependencies, and some of them also have knobs, you either have to set them for the port you want to build, or you have to build the dependency separately. For example, I want Ghostscript to build with an A4 output format, but then I want to build Ghostscript as part of the textproc/docproj build. If I set 'A4=yes' in the print/ghostscript-gnu directory and then I do a 'make' in the textproc/docproj directory, penv and make(1) will only pick up the textproc/docproj settings, and this A4=yes will be lost. If only there was a way to let make(1) read per-directory information for every single directory it recursed into.. Here is a little patch to make make(1) do just that - invoke an external 'environment processor', read its output and modify its own environment before doing anything else. This way, I can keep the A4=yes in the penv settings for the print/ghostscript-gnu directory and rest assured that a docproj build will pick it right up. This, incidentally, removes the need for the 'penv' invocation to be visible at all. Whereas before one had to run 'penv make all install', now all one has to do is run 'make all install', and make(1) will run penv all by itself. For those worried about the overhead of a program invocation, there is the MAKEENVDIR environment variable, which, if specified, is treated as an extended regular expression for the directory names to run the environment processor in. Thus, if MAKEENVDIR is set to something like, say, "^(/usr|/home/roam/fbsd)/ports/", then the environment processor will only be run in the Ports collection and not at all during a buildworld. Comments? Flames? Instant shootdowns? :) G'luck, Peter -- .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI Index: src/usr.bin/make/main.c =================================================================== RCS file: /home/ncvs/src/usr.bin/make/main.c,v retrieving revision 1.49 diff -u -r1.49 main.c --- src/usr.bin/make/main.c 25 Apr 2001 14:44:41 -0000 1.49 +++ src/usr.bin/make/main.c 25 Dec 2001 17:37:25 -0000 @@ -88,6 +88,7 @@ #include #include #include +#include #include #include #ifdef __STDC__ @@ -139,6 +140,8 @@ static void MainParseArgs __P((int, char **)); char * chdir_verify_path __P((char *, char *)); static int ReadMakefile __P((void *, void *)); +static void ReadEnvProc __P((const char *, const char *, + const char *)); static void usage __P((void)); static char *curdir; /* startup directory */ @@ -428,6 +431,81 @@ return 0; } +/*- + * ReadEnvProc -- + * Read the output of an environment processor program and + * set or unset environment variables accordingly. + * + * Results: + * none + * + * Side effects: + * Executes the program specified by the envproc argument and + * sets or unsets environment variables according to the program output. + */ + +static void +ReadEnvProc(const char *envproc, const char *envprocdir, const char *curdir) { + regex_t regdir; + int r; + char regerr[128]; + FILE *envout; + char *s, *new; + size_t len; + + /* First check if the env processor needs to run at all here */ + if ((envprocdir != NULL) && (envprocdir[0] != '\0')) { + memset(®dir, 0, sizeof(regdir)); + r = regcomp(®dir, envprocdir, REG_EXTENDED | REG_NOSUB); + if (r != 0) { + regerror(r, ®dir, regerr, sizeof(regerr)); + errx(1, "parsing regexp %s: %s", envprocdir, regerr); + } + + /* If curdir does not match, return w/o executing anything */ + r = regexec(®dir, curdir, 0, NULL, 0); + if (r == REG_NOMATCH) + return; + if (r != 0) { + regerror(r, ®dir, regerr, sizeof(regerr)); + errx(1, "matching regexp %s against %s: %s", + envprocdir, curdir, regerr); + } + } + + if ((envout = popen(envproc, "r")) == NULL) + err(1, "invoking environment processor '%s'", envproc); + + while ((s = fgetln(envout, &len)) != NULL) { + /* Null-terminate as needed */ + if (s[len - 1] == '\n') { + s[len - 1] = '\0'; + new = NULL; + } else { + if ((new = realloc(s, len + 1)) == NULL) + err(1, "reading env processor output"); + memcpy(new, s, len); + new[len] = '\0'; + s = new; + } + + /* + * A 'var=value' specification sets the variable, while + * a mere variable name unsets it. + */ + if (strchr(s, '=') != NULL) + putenv(s); + else + unsetenv(s); + + if (new != NULL) + free(new); + } + if (ferror(envout)) + err(1, "reading env processor output"); + + pclose(envout); +} /*- * main -- @@ -465,6 +543,8 @@ char *cp = NULL, *start; /* avoid faults on read-only strings */ static char syspath[] = _PATH_DEFSYSPATH; + char *envproc = getenv("MAKEENVPROC"); + char *envprocdir = getenv("MAKEENVDIR"); #if DEFSHELL == 2 /* @@ -497,6 +577,12 @@ if (stat(curdir, &sa) == -1) err(2, "%s", curdir); + + /* + * Look for an environment processor as early as possible + */ + if ((envproc != NULL) && (envproc[0] != '\0')) + ReadEnvProc(envproc, envprocdir, curdir); #if defined(__i386__) && defined(__FreeBSD_version) && \ __FreeBSD_version > 300003 Index: src/usr.bin/make/make.1 =================================================================== RCS file: /home/ncvs/src/usr.bin/make/make.1,v retrieving revision 1.48 diff -u -r1.48 make.1 --- src/usr.bin/make/make.1 10 Aug 2001 13:45:27 -0000 1.48 +++ src/usr.bin/make/make.1 25 Dec 2001 17:40:39 -0000 @@ -32,7 +32,7 @@ .\" from: @(#)make.1 8.4 (Berkeley) 3/19/94 .\" $FreeBSD$ .\" -.Dd March 19, 1994 +.Dd December 25, 2001 .Dt MAKE 1 .Os .Sh NAME @@ -373,7 +373,9 @@ .It Environment variables Variables defined as part of .Nm Ns 's -environment. +environment or in the output of the +.Ev MAKEENVPROC +program, if specified (see the ENVIRONMENT PROCESSORS section below). .It Global variables Variables defined in the makefile or in included makefiles. .It Command line variables @@ -716,6 +718,47 @@ .It Cm U Converts variable to upper-case letters. .El +.Sh ENVIRONMENT PROCESSORS +External programs, called +.Dq environment processors , +may provide +additional environment data before any Makefile parsing is done. +If the +.Ev MAKEENVPROC +environment variable is set before +.Nm +is invoked, it is interpreted as a command to obtain additional environment +variables from. +.Nm +executes the command using the +.Xr popen 3 +function and examines each line of its output. +If the line contains a +.Sq = +character, it is treated as a +.Ar variable Ns No = Ns Ar value +assignment operator and +.Nm +sets the respective variable in its environment to the specified value. +If the line does not contain a +.Sq = +character, it is treated as the name of a variable to be removed from the +.Nm +environment. +.Pp +If the +.Ev MAKEENVDIR +environment variable is also set, +.Nm +treats it as an extended regular expression (see +.Xr re_format 7 ) +and matches the current directory against it. +If there is no match, the environment processor is not executed at all. +This allows for running the processor only in certain directory trees, e.g. +.Pa /usr/ports , +without the burden of the additional command execution when running +.Nm +in other directories. .Sh DIRECTIVES, CONDITIONALS, AND FOR LOOPS Directives, conditionals, and for loops reminiscent of the C programming language are provided in @@ -1174,6 +1217,8 @@ uses the following environment variables, if they exist: .Ev MACHINE , .Ev MAKE , +.Ev MAKEENVDIR , +.Ev MAKEENVPROC , .Ev MAKEFLAGS , .Ev MAKEOBJDIR , and To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 25 14:29:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id 672A637B405 for ; Tue, 25 Dec 2001 14:29:19 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id fBPMTHvT092793 for ; Tue, 25 Dec 2001 23:29:17 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id fBPMTHnF092790 for ; Tue, 25 Dec 2001 23:29:17 +0100 (CET) Date: Tue, 25 Dec 2001 23:29:17 +0100 (CET) From: Michal Mertl To: arch@freebsd.org Subject: 64 bit counters Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I would expect this topic already popped on the list but search didn't revealed anything. As a hostmaster of several FreeBSD servers I noticed the problem of some counters overflowing (e.g. byte counters for IP/TCP/UDP overflow in several days on my systems). I looked at the source code and it seems pretty trivial to change the counters to 64 bits (e.g. in /sys/netinet/tcp_var.h change the type of members of tcpstat structure from u_long to u_int64_t and in usr.bin/netstat/inet.c change printf from %lu to %llu). I tried the change and it seems it didn't do any harm and the counters are correct. I am interested in hearing if someone knows about possible problem with that change. I would like to see it (along with other counters possibly - interrupts, interface, vm counters ...) in the RELENG_4 tree (not in 4.5 of course). Addition on 64 bit integer is of course little bit more expensive than 32 bit but I think it's only minimal slowdown. At least I'm able to saturate the 100FDX ethernet just as easily as before. I volunteer to do the changes - they're straightforward. Only I don't have CURRENT system - but can get one quite easily I hope. -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 25 20: 8:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from po3.wam.umd.edu (po3.wam.umd.edu [128.8.10.165]) by hub.freebsd.org (Postfix) with ESMTP id 63FA637B41B for ; Tue, 25 Dec 2001 20:08:09 -0800 (PST) Received: from rac3.wam.umd.edu (IDENT:root@rac3.wam.umd.edu [128.8.10.143]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id XAA06317; Tue, 25 Dec 2001 23:08:05 -0500 (EST) Received: from rac3.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac3.wam.umd.edu (8.9.3/8.9.3) with SMTP id XAA04573; Tue, 25 Dec 2001 23:08:05 -0500 (EST) Received: from localhost (culverk@localhost) by rac3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id XAA04569; Tue, 25 Dec 2001 23:08:05 -0500 (EST) X-Authentication-Warning: rac3.wam.umd.edu: culverk owned process doing -bs Date: Tue, 25 Dec 2001 23:08:05 -0500 (EST) From: Kenneth Wayne Culver To: Michal Mertl Cc: arch@FreeBSD.ORG Subject: Re: 64 bit counters In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I did this a while back where I work for our "product" to support 64-bit counters in FreeBSD, and it didn't cause any major problems at all. I had to do this on a 2.2.8 kernel, and I had to modify some mbuf handling code that expected one type of message header to fit inside one mbuf, but that won't be a problem in -CURRENT b/c I believe that the size of an mbuf went up to 256 bytes from 128 bytes. Ken On Tue, 25 Dec 2001, Michal Mertl wrote: > I would expect this topic already popped on the list but search didn't > revealed anything. > > As a hostmaster of several FreeBSD servers I noticed the problem of some > counters overflowing (e.g. byte counters for IP/TCP/UDP overflow in > several days on my systems). I looked at the source code and it seems > pretty trivial to change the counters to 64 bits (e.g. in > /sys/netinet/tcp_var.h change the type of members of tcpstat structure > from u_long to u_int64_t and in usr.bin/netstat/inet.c change printf from > %lu to %llu). I tried the change and it seems it didn't do any harm and > the counters are correct. I am interested in hearing if someone knows > about possible problem with that change. I would like to see it (along > with other counters possibly - interrupts, interface, vm counters ...) > in the RELENG_4 tree (not in 4.5 of course). Addition on 64 bit integer is > of course little bit more expensive than 32 bit but I think it's only > minimal slowdown. At least I'm able to saturate the 100FDX ethernet just > as easily as before. > > I volunteer to do the changes - they're straightforward. Only I don't have > CURRENT system - but can get one quite easily I hope. > > -- > Michal Mertl > mime@traveller.cz > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 25 23:14:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from technokratis.com (modemcable099.144-201-24.mtl.mc.videotron.ca [24.201.144.99]) by hub.freebsd.org (Postfix) with ESMTP id 231EA37B41A; Tue, 25 Dec 2001 23:14:03 -0800 (PST) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id fBQ7I1N14795; Wed, 26 Dec 2001 02:18:01 -0500 (EST) (envelope-from bmilekic) Date: Wed, 26 Dec 2001 02:18:00 -0500 From: Bosko Milekic To: freebsd-arch@freebsd.org, freebsd-smp@freebsd.org Subject: SMPng: Interrupt Latency Issues Message-ID: <20011226021800.A14608@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, It has become obvious, recently in particular, that some important improvements are required in the way we take interrupts in -CURRENT SMPng. As previously mentionned, we are experiencing lousy interrupt latency in -CURRENT. This comes as no surprise. The purpose of this Email is to get the ball rolling on a discussion pertaining not only to the approach that we're going to take to properly remedy the latency issues, but also on the overall ways that we will be handeling interrupts in SMPng. I know that there are already several ideas floating around, and briefly talking to Jake and some others over IRC, I see that there are a couple that are more common than others. Now I know that this is a sensitive topic but in discussing it, I would appreciate it if all points are strictly technical and deal with the implementation, that we not over-generalize (in other words, that we stay `on topic' [*]), and that after the discussion is done, that we set up some milestones and get the work done _soon_ (I'm prepared to take up some of the work, yes - however, I do not feel that *I* am the right person to oversee _all_ of the technical aspects of this heavily burdened task alone). [*] This means please don't start bashing anything and everything in our system and stating useless things like "well, yeah, but our VM system does not do X, Y, and Z" if it is of no _direct_ relevance to the way we take interrupts. With that out of the way, here's our situation: 1. We presently take an interrupt, and in the general case, proceed to schedule an interrupt thread to run. While placing the thread on the run queue and because we need to check for the "SWAIT" process flag we must acquire the sched_lock. This is where the jist of the problem lies. We bottleneck here because it means that only one CPU can be scheduling the interrupt thread at a time, and the rest have to spin waiting for sched_lock. To make matters worse, interrupts are disabled on the local CPU and we cannot take any other interrupts either. This is where we stand. 2. BSD/OS does things differently. An interrupt comes in and in the general case, the interrupted thread's VM address space is borrowed and the handler is immediately executed after interrupts are re-enabled. Then the handler(s) run and only if it happens to hit a mutex lock for which it must wait, a clean-up is done to provide a thread that can block on the mutex for the interrupt, and to allow the interrupted thread to continue doing its thing. The tradeoff is that the interrupted thread _cannot_ run anywhere else, not even on another CPU, while the interrupt that pre-empted it is not finished executing or has not hit a mutex and could not aquire it quickly. This may result in some kernel thread priority rules not being 100% obeyed but I guess that this is part of the tradeoff. 3. I believe that some others have alternative suggestions. I encourage them to present them here clearly, assuming that they are realistic and implementable approaches, so that we are sure to make the right decision before we setup milestones. In particular, I know that, after briefly speaking to Jake, there is the idea of per-CPU "interrupt-only run queues" floating around. The jist of this method would be to keep per-CPU run queues to which each CPU can schedule their own interrupt threads without having to acquire any locks (i.e., only have interrupts disabled). The un-balancing of the queues as well as special priority cases - should they arise - could be handeled by issuing IPIs. I also know that some others (notably Rik van Riel - I hope I spelled that correctly :-) ) have mentionned realistic ideas that are quite logical in light of what we presently have and the points above. To me, following a very brief overview, some of them shared some of the qualities of the BSD/OS way of doing it so I'd like to invite him (and others) to lay those methods out for us now, so that we have a greater picture of various alternatives. That's all for now. I hope that we can agree on something worthwhile soon so that we can establish clear milestones and get this thing done. It's been long overdue. Best regards and Seasons Greetings to you all, -- Bosko Milekic bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 5:44:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [66.31.234.148]) by hub.freebsd.org (Postfix) with ESMTP id 39F5537B416; Wed, 26 Dec 2001 05:44:47 -0800 (PST) Received: (from root@localhost) by thehousleys.net (8.11.6/8.11.2) id fBQDilx83553; Wed, 26 Dec 2001 08:44:47 -0500 (EST) (envelope-from jeh@FreeBSD.org) Received: from FreeBSD.org (baby.int.thehousleys.net [192.168.0.24]) (authenticated) by thehousleys.net (8.11.6/8.11.6) with ESMTP id fBQDifu83545; Wed, 26 Dec 2001 08:44:45 -0500 (EST) (envelope-from jeh@FreeBSD.org) Message-ID: <3C29D449.7EC7EFCF@FreeBSD.org> Date: Wed, 26 Dec 2001 08:44:41 -0500 From: "James E. Housley" Organization: FreeBSD X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Michal Mertl Cc: arch@FreeBSD.org Subject: Re: 64 bit counters References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michal Mertl wrote: > > I would expect this topic already popped on the list but search didn't > revealed anything. > > As a hostmaster of several FreeBSD servers I noticed the problem of some > counters overflowing (e.g. byte counters for IP/TCP/UDP overflow in > several days on my systems). I looked at the source code and it seems On a system that I have access to with GigE cards, running constantly over 200Mb/s, the netstat -i counters will overflow on the order of once every minute or two. As an aside questions. When we update the network interface to use the larger 64bit counters, will external programs like SNMP be able to function with the larger sizes or will these have problems. I am not sugesting we don't do this, I just want to know. Jim -- /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ ----------------------------------------------------------------- jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve jim@TheHousleys.Net http://www.TheHousleys.net jhousley@SimTel.Net http://www.SimTel.Net --------------------------------------------------------------------- It's always a long day, 86400 doesn't fit into a short. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 7:41: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id F15D737B416; Wed, 26 Dec 2001 07:40:58 -0800 (PST) Received: from rac1.wam.umd.edu (IDENT:root@rac1.wam.umd.edu [128.8.10.141]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id KAA23883; Wed, 26 Dec 2001 10:40:57 -0500 (EST) Received: from rac1.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac1.wam.umd.edu (8.9.3/8.9.3) with SMTP id KAA13933; Wed, 26 Dec 2001 10:40:56 -0500 (EST) Received: from localhost (culverk@localhost) by rac1.wam.umd.edu (8.9.3/8.9.3) with ESMTP id KAA13929; Wed, 26 Dec 2001 10:40:56 -0500 (EST) X-Authentication-Warning: rac1.wam.umd.edu: culverk owned process doing -bs Date: Wed, 26 Dec 2001 10:40:56 -0500 (EST) From: Kenneth Wayne Culver To: "James E. Housley" Cc: Michal Mertl , arch@FreeBSD.ORG Subject: Re: 64 bit counters In-Reply-To: <3C29D449.7EC7EFCF@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG SNMP shouldn't have a problem, especially if rfc 2233 (interfaces mib) is implemented. This mib calls for 64-bit counters in many cases anyway. For cases that don't need 64-bit counters, a simple typecast to a u_long works fine, saving the lower 32 bits. Ken On Wed, 26 Dec 2001, James E. Housley wrote: > Michal Mertl wrote: > > > > I would expect this topic already popped on the list but search didn't > > revealed anything. > > > > As a hostmaster of several FreeBSD servers I noticed the problem of some > > counters overflowing (e.g. byte counters for IP/TCP/UDP overflow in > > several days on my systems). I looked at the source code and it seems > > On a system that I have access to with GigE cards, running constantly > over 200Mb/s, the netstat -i counters will overflow on the order of once > every minute or two. As an aside questions. When we update the network > interface to use the larger 64bit counters, will external programs like > SNMP be able to function with the larger sizes or will these have > problems. I am not sugesting we don't do this, I just want to know. > > Jim > -- > /"\ ASCII Ribbon Campaign . > \ / - NO HTML/RTF in e-mail . > X - NO Word docs in e-mail . > / \ ----------------------------------------------------------------- > jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve > jim@TheHousleys.Net http://www.TheHousleys.net > jhousley@SimTel.Net http://www.SimTel.Net > --------------------------------------------------------------------- > It's always a long day, 86400 doesn't fit into a short. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 7:47:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id 485D737B419; Wed, 26 Dec 2001 07:47:26 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id fBQFlOvT022811; Wed, 26 Dec 2001 16:47:25 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id fBQFlOki022808; Wed, 26 Dec 2001 16:47:24 +0100 (CET) Date: Wed, 26 Dec 2001 16:47:24 +0100 (CET) From: Michal Mertl To: "James E. Housley" Cc: arch@FreeBSD.ORG Subject: Re: 64 bit counters In-Reply-To: <3C29D449.7EC7EFCF@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 26 Dec 2001, James E. Housley wrote: > Michal Mertl wrote: > > > > I would expect this topic already popped on the list but search didn't > > revealed anything. > > > > As a hostmaster of several FreeBSD servers I noticed the problem of some > > counters overflowing (e.g. byte counters for IP/TCP/UDP overflow in > > several days on my systems). I looked at the source code and it seems > > On a system that I have access to with GigE cards, running constantly > over 200Mb/s, the netstat -i counters will overflow on the order of once > every minute or two. As an aside questions. When we update the network > interface to use the larger 64bit counters, will external programs like > SNMP be able to function with the larger sizes or will these have > problems. I am not sugesting we don't do this, I just want to know. > SNMPv3 has 64bit counter support. Programs accessing the counters should include the file which declares the struct and so they will know that members are u_int64_t. If you use it like int compiler should complain. > Jim > -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 8:16:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id 0CE1737B416 for ; Wed, 26 Dec 2001 08:16:30 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id fBQGGTvT023792; Wed, 26 Dec 2001 17:16:29 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id fBQGGSuG023789; Wed, 26 Dec 2001 17:16:28 +0100 (CET) Date: Wed, 26 Dec 2001 17:16:28 +0100 (CET) From: Michal Mertl To: John Hanley Cc: arch@freebsd.org Subject: Re: 64 bit counters In-Reply-To: <20011226005810.5475.qmail@web10102.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 25 Dec 2001, John Hanley wrote: > My only caution is this: > > On some platforms, 64 bit ints are not atomically written. > First 32 bits is written, then the remaining 32. If, say, > only the bottom half of the kernel accesses the counter, What do you mean by "the bottom half of the kernel"? > then likely all is well. If an interrupt routine can read > or write in the middle of a non-atomic operation, then all > hell can break loose, in ways that are extremely difficult > to track down because they only happen rarely. > Well I didn't think of that but I believe it shouldn't be that much a problem. At most the counter could become wrong :-). -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 8:57:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from voi.aagh.net (pc1-hart4-0-cust168.mid.cable.ntl.com [62.254.84.168]) by hub.freebsd.org (Postfix) with ESMTP id 8AD5737B419 for ; Wed, 26 Dec 2001 08:57:27 -0800 (PST) Received: from freaky by voi.aagh.net with local (Exim 3.33 #1) id 16JHMr-000P8s-00 for arch@freebsd.org; Wed, 26 Dec 2001 16:57:25 +0000 Date: Wed, 26 Dec 2001 16:57:25 +0000 From: Thomas Hurst To: arch@freebsd.org Subject: Re: 64 bit counters Message-ID: <20011226165725.GA96426@voi.aagh.net> Mail-Followup-To: arch@freebsd.org References: <20011226005810.5475.qmail@web10102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i Organization: Not much. X-Operating-System: FreeBSD/4.5-PRERELEASE (i386) X-Uptime: 4:45PM up 6 days, 1:30, 4 users, load averages: 2.00, 2.00, 2.00 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Michal Mertl (mime@traveller.cz) wrote: > > then likely all is well. If an interrupt routine can read or write > > in the middle of a non-atomic operation, then all hell can break > > loose, in ways that are extremely difficult to track down because > > they only happen rarely. > > Well I didn't think of that but I believe it shouldn't be that much a > problem. At most the counter could become wrong :-). When they're overflowing every few days they're wrong anyway. At least if the counter shoots up to 1000TB you *know* it's wrong. -- Thomas 'Freaky' Hurst - freaky@aagh.net - http://www.aagh.net/ - Support wildlife -- vote for an orgy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 11:40:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 9870837B437 for ; Wed, 26 Dec 2001 11:40:10 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBQJliM01092; Wed, 26 Dec 2001 11:47:45 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112261947.fBQJliM01092@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Michal Mertl Cc: John Hanley , arch@freebsd.org Subject: Re: 64 bit counters In-reply-to: Your message of "Wed, 26 Dec 2001 17:16:28 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Dec 2001 11:47:44 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Tue, 25 Dec 2001, John Hanley wrote: > > > My only caution is this: > > > > On some platforms, 64 bit ints are not atomically written. > > First 32 bits is written, then the remaining 32. If, say, > > only the bottom half of the kernel accesses the counter, > > What do you mean by "the bottom half of the kernel"? Consider the case where two threads are updating the counter at the same time; the only solution for this is a lock around the counter which makes it much more expensive. > > then likely all is well. If an interrupt routine can read > > or write in the middle of a non-atomic operation, then all > > hell can break loose, in ways that are extremely difficult > > to track down because they only happen rarely. > > > > Well I didn't think of that but I believe it shouldn't be that much a > problem. At most the counter could become wrong :-). This would be completely unacceptable. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 11:59:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 8784337B41C; Wed, 26 Dec 2001 11:59:02 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 339B781E0B; Wed, 26 Dec 2001 13:59:02 -0600 (CST) Date: Wed, 26 Dec 2001 13:59:02 -0600 From: Alfred Perlstein To: Mike Smith Cc: Michal Mertl , John Hanley , arch@freebsd.org Subject: Re: 64 bit counters Message-ID: <20011226135902.O91594@elvis.mu.org> References: <200112261947.fBQJliM01092@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112261947.fBQJliM01092@mass.dis.org>; from msmith@freebsd.org on Wed, Dec 26, 2001 at 11:47:44AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Mike Smith [011226 13:40] wrote: > > On Tue, 25 Dec 2001, John Hanley wrote: > > > > Well I didn't think of that but I believe it shouldn't be that much a > > problem. At most the counter could become wrong :-). > > This would be completely unacceptable. Agreed. A lot of people think that a small window where data is inconsistant and exposed to other subsystems is acceptable. This is far from the truth, if a decision is made based on an incorrect counter or that incorrect counter value is then used in some critical function the entire system will obviously misbehave. This can have widespread and dire consequences. So it's not acceptable in the general case. One solution is to implement it correctly then add a knob to turn off the syncronization for those that want speed over correctness. They can poison their data if they so desire. sysctl kern.hardstats=1 stats_mtx_aquired = 0; if (hardstats) { mtx_lock(&stats_mtx); stats_mtx_aquired = 1; } update_stats(); if (stats_mtx_aquired) { mtx_unlock(&stats_mtx); } -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 12:14: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 321D637B42A for ; Wed, 26 Dec 2001 12:14:00 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBQKLbM01442; Wed, 26 Dec 2001 12:21:37 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112262021.fBQKLbM01442@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: 64 bit counters In-reply-to: Your message of "Wed, 26 Dec 2001 13:59:02 CST." <20011226135902.O91594@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Dec 2001 12:21:37 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > One solution is to implement it correctly then add a knob to > turn off the syncronization for those that want speed over > correctness. They can poison their data if they so desire. This isn't good either; if you give someone a knob that can be switched from "works" to "does not work", then someone is going to set it to "does not work" and then complain. Better would be to architect a solution that works universally. You can do this with 32-bit 'working' counters which you access atomically, and maintain a 64-bit global counter that's only updated under a lock: u_int32_t wcounter u_int64_t ggounter lock_t gc_lock u_int32_t x; acquire_lock(gc_lock) x = atomic_fetch_32(wcounter) atomic_subtract_32(wcounter, x) gcounter += x release_lock(gc_lock) Do this on a periodic basis, with the interval tuned so that stats update "often enough" but without imposing too much lock load. If atomic ops on the working counters are too expensive on SMP systems, you can keep per-CPU working counters. Reaping them becomes somewhat more expensive (since you have one reap per CPU per interval) however. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 13:40:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id B0E1C37B405; Wed, 26 Dec 2001 13:40:13 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011226214008.DVKN6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 26 Dec 2001 21:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA83879; Wed, 26 Dec 2001 13:36:42 -0800 (PST) Date: Wed, 26 Dec 2001 13:36:42 -0800 (PST) From: Julian Elischer To: Mike Smith Cc: arch@freebsd.org Subject: Re: 64 bit counters In-Reply-To: <200112262021.fBQKLbM01442@mass.dis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG AAARGGGHHHH On Wed, 26 Dec 2001, Mike Smith wrote: > Better would be to architect a solution that works universally. You can Architect. Noun.. A person. Design. Verb "Better would be to design a solution that works universally." "I think I'm going to fisherman some fish today" "He was going to priest to the congregation" "She wanted to prostitute him" (!) "Mike mechanic'ed the dashboard in his car." (if you saw what the mechaninc did to his car you'd understand that this is not a good thing). While they have "humour" value and I can even imagine a marginal use for them, in storytelling, there is a perfectly good english verb.. "design" , that is shorter and more succinct. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 14:45:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id B1F0037B405; Wed, 26 Dec 2001 14:45:38 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id fBQMjavT035086; Wed, 26 Dec 2001 23:45:37 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id fBQMjaFp035083; Wed, 26 Dec 2001 23:45:36 +0100 (CET) Date: Wed, 26 Dec 2001 23:45:36 +0100 (CET) From: Michal Mertl To: Alfred Perlstein Cc: Mike Smith , John Hanley , Subject: Re: 64 bit counters In-Reply-To: <20011226135902.O91594@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 26 Dec 2001, Alfred Perlstein wrote: > * Mike Smith [011226 13:40] wrote: > > > On Tue, 25 Dec 2001, John Hanley wrote: > > > > > > Well I didn't think of that but I believe it shouldn't be that much a > > > problem. At most the counter could become wrong :-). > > > > This would be completely unacceptable. > > Agreed. > > A lot of people think that a small window where data is inconsistant > and exposed to other subsystems is acceptable. This is far from > the truth, if a decision is made based on an incorrect counter or > that incorrect counter value is then used in some critical function > the entire system will obviously misbehave. > Ok. It seems to me a bit like that sio problem. There is a problem lot of people experience (I had it too on 4.3 but on 4.5PRE it's gone). There is known quick and working workaround (Matt's) - yet it is unacceptable. One reason to not use the workaround was (not quoting MAINTAINER precisely): "I keep this partly as a check if the interrupt latency didn't get even worse" which seems quite strange to me. So we have for years problem for which exists generally usable workaround. We have counters which overflow pretty often (one guy wrote they overflow for him every 1-2 minutes) - they're almost useless. They aren't updated with atomic_?? (are they then guaranteed to contain the right value?) but there maybe isn't the need since they're 32bit. I thought about possibility of the counter to become wrong a lot and think the counter (at least the counters I was thinking about implementing) can never become wrong. It can probably be wrong by 0x100000000 for the very short moment and I don't know how to reliably check if at the time of reading the value isn't wrong. Maybe doing two reads. Why do I think it never becomes wrong? Generally I'm adding rather small value (<1e6 or so) to 64 bit counter. When one addition overflows less significant 32 bits, several next additions don't overflow. u_int64_t+=u_long is: addl %eax,(u_int64_t) ; this is atomic, right? adcl $0,4(u_int64_t) If interrupt occurs in between these two instructions, then the less significant halt is right and more significant will be fixed after the execution returns to second instruction. Even if the interrupt modified the value, we can expect (read - be sure) it didn't modify the more significant half. So I see here two problems: how to read the value and how to assure we won't use the same principle on counters which grow much faster. If you thing this is really unacceptable, I don't blame you. It really isn't perfect (nothing else is either). If I was looking for quick fix I woudln't look any further (I can't see any serious use for the counters - for me they're just providing an insight on the system and then there is more important behaviour in time than exact value). On arch list we probably talk about "the real solutions" which this approach doesn't provide. I'm just afraid I won't be able to help with more "mature" approach. Locking etc. is beyond my abilities. If someone tells me what/how to code - Mike Smith's approach or whatever - I can try to work on that too but I can't promiss anything then. BTW Mike Smith's approach isn't that much better - there can be overflow of the less significant 32 bit (which is unlikely but more likely than in my naive approach). Only there would be guaranteed contents of 64 bit counter - which is probably the improtant part. Still willing to work on making FreeBSD even better :-). -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 17: 5:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2AF5337B405 for ; Wed, 26 Dec 2001 17:05:19 -0800 (PST) Received: from localhost (imp@69.imp.village.org [10.0.0.69]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBR15Hl14326 for ; Wed, 26 Dec 2001 18:05:18 -0700 (MST) (envelope-from imp@village.org) Date: Wed, 26 Dec 2001 01:55:31 -0700 (MST) Message-Id: <20011226.015531.63813856.imp@village.org> To: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/isa fd.c From: "M. Warner Losh" In-Reply-To: <20011220193618.B19756@uriah.heep.sax.de> References: <20011219095119.B93645@sunbay.com> <20011220235518.V673-100000@gamplex.bde.org> <20011220193618.B19756@uriah.heep.sax.de> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : What does NetBSD do here? It would surprise me if they didn't have a : method to distinguish between their various machines at the cpp level. NetBSD does what FreeBSD does. They define __${MACHINE}__ and __${MACHINE_ARCH}__ for each port. The trouble happens when MACHINE == MACHINE_ARCH and there's more than one. I'm not sure what NetBSD/pc98 is going to do once it is integrated into the tree. For the NetBSD architectures that have more than one MACHINE for a given MACHINE_ARCH, these names are always different (again, I'm not sure if this will hold once pc98 goes into the NetBSD tree). _MACHINE_ARCH and MACHINE_ARCH are used only by make and maybe one or two other minor things. The problem with using anything in machine/*.h is that FreeBSD/pc98 and FreeBSD/i386 use the same files. You'd have to have the ifdefs in there based on PC98 being defined or not. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 22: 0:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id A9DBD37B416 for ; Wed, 26 Dec 2001 22:00:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011227060010.XFMN20122.rwcrmhc53.attbi.com@InterJet.elischer.org> for ; Thu, 27 Dec 2001 06:00:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA85663 for ; Wed, 26 Dec 2001 21:40:59 -0800 (PST) Date: Wed, 26 Dec 2001 21:40:58 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: the condvar stuff. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok, so, I[ve looked at the code, I've read teh man pages. I've looked at soem usages.. Why do we need the condvar stuff? it seems very similar to the existing msleep code. Now we have: msleep mutexes, condvars sx locks (on the way out) lockmanager I'm not sure I see what you can achieve with convars that you can't achieve with msleep(). However it's unlikely that someone would have gone to so much trouble for no reason, so I'm missing something.. Are they only implimented as a building block for sx locks? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 26 22:14: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 9333737B41A for ; Wed, 26 Dec 2001 22:14:06 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 1389881D01; Thu, 27 Dec 2001 00:14:01 -0600 (CST) Date: Thu, 27 Dec 2001 00:14:01 -0600 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: the condvar stuff. Message-ID: <20011227001401.Y91594@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Wed, Dec 26, 2001 at 09:40:58PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [011227 00:00] wrote: > > Ok, so, I[ve looked at the code, > I've read teh man pages. > I've looked at soem usages.. > > > Why do we need the condvar stuff? it seems very similar > to the existing msleep code. They're a lot easier to get right than the flags based approach since you don't have to roll your own. They also specify a specific rendivous so that at a later date we won't need the sched_lock to place processes on the condvar's waiting queue. You use the mutex passed in as the protection over the condvar, this is possible because if you think about it, it makes no sense to use more than one mutex with either a condvar or a set of flags, right? :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 0:13:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A9D1A37B419; Thu, 27 Dec 2001 00:13:42 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBR8Dc150215; Thu, 27 Dec 2001 00:13:38 -0800 (PST) (envelope-from dillon) Date: Thu, 27 Dec 2001 00:13:38 -0800 (PST) From: Matthew Dillon Message-Id: <200112270813.fBR8Dc150215@apollo.backplane.com> To: Michal Mertl Cc: Alfred Perlstein , Mike Smith , John Hanley , Subject: Re: 64 bit counters References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Why do I think it never becomes wrong? Generally I'm adding rather small :value (<1e6 or so) to 64 bit counter. When one addition overflows less :significant 32 bits, several next additions don't overflow. : :u_int64_t+=u_long is: :addl %eax,(u_int64_t) ; this is atomic, right? :adcl $0,4(u_int64_t) : :If interrupt occurs in between these two instructions, then the less :significant halt is right and more significant will be fixed after the :execution returns to second instruction. Even if the interrupt modified :the value, we can expect (read - be sure) it didn't modify the more :significant half. You are absolutely right. The carry will only be set on the addl which overflows the 32 bit counter and will not be set on any of the other addl's that might be occuring just before, inbetween the two instructions, or just after. So only one of those will cause the msb to increment. For UP the addl instruction is atomic. For SMP we still have to lock the bus cycle. Something like this: lock; addl %eax,(u_int64_t) lock; adcl $0,4(u_int64_t) Or this: lock; addl %eax,(u_int64_t) jnc 1f lock; incl 4(u_int64_t) 1: :So I see here two problems: how to read the value and how to assure we :won't use the same principle on counters which grow much faster. : :If you thing this is really unacceptable, I don't blame you. It really I think putting sophistication in the code reading the value of the counters (by checking against a previously read value and making appropriate assumptions if the new value appears to be too small or too large), in order to avoid having to make the increment operation complex, is a good idea. -Matt :Still willing to work on making FreeBSD even better :-). : :-- :Michal Mertl :mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 1:20:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id EEDF237B417 for ; Thu, 27 Dec 2001 01:20:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011227092009.BDY20122.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 27 Dec 2001 09:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA86370; Thu, 27 Dec 2001 01:18:09 -0800 (PST) Date: Thu, 27 Dec 2001 01:18:08 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: the condvar stuff. In-Reply-To: <20011227001401.Y91594@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 27 Dec 2001, Alfred Perlstein wrote: > * Julian Elischer [011227 00:00] wrote: > > > > Ok, so, I[ve looked at the code, > > I've read teh man pages. > > I've looked at soem usages.. > > > > > > Why do we need the condvar stuff? it seems very similar > > to the existing msleep code. > > They're a lot easier to get right than the flags based approach > since you don't have to roll your own. In other words they are like msleep. > > They also specify a specific rendivous so that at a later date we > won't need the sched_lock to place processes on the condvar's waiting > queue. You'll still need to hold schedlock to take the running thread out of the running state and select the next to run so I don't see a great advantage to that. > You use the mutex passed in as the protection over the > condvar, this is possible because if you think about it, it makes > no sense to use more than one mutex with either a condvar or a > set of flags, right? :) I see a weakness in that there is a cv_wait() with no cancelability. I need to be able to cancel any cv or msleep in a threads world... Well I don't NEED to but if I can't cancel a thread waiting on a cv then exit() can take arbitrarily long as the exiting thread has to wait for all the other threads to finish waiting on the CV. The problem is that there is no return value, so you can not tell the calling code that it's thread has just been shot in the head. I have two new functions in the KSE tree abortsleep(td) and cv_abort(td), that rip the given thread out of whatever it's doing when the process exits. but it's not possible to tell if a particular CV was done using cv_wait() or cv_wait_sig() or whatever, so I don't really know if it's safe to wake it. I just wake it and let whatever it was that went to sleep (e.g. cv_wait_sig()) discover the "I'm Exititng" flag for itself.) Basically one of the changes I'll be doing in the KSE tree as that all msleeps and cv waits and sx waits and mutx waits have to either be identifiable as uninterruptable, or ba capable of being interrupted (so at least the next layer can catch it and back out). because when one thread runs 'exit()' it waits around for all the other threads to exit before proceeding. This also applies to exec() except that I haven't written that yet. Julian (diffs available from my web page on freefall) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 1:26: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by hub.freebsd.org (Postfix) with ESMTP id 50B7D37B405 for ; Thu, 27 Dec 2001 01:26:05 -0800 (PST) Received: from localhost (root@localhost [127.0.0.1]) (authenticated as iwa with CRAM-MD5) by tasogare.imasy.or.jp (8.11.6+3.4W/8.11.6/tasogare) with ESMTP/inet id fBR9Q2P89625 for ; Thu, 27 Dec 2001 18:26:03 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Thu, 27 Dec 2001 18:25:33 +0900 (JST) Message-Id: <20011227.182533.112880512.iwasaki@jp.FreeBSD.org> To: arch@freebsd.org Subject: CFR: Generalized power profile From: Mitsuru IWASAKI X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I've made the changes for generalized power profile based on ACPI power profile code, dev/acpica/acpi_powerprofile.c and some related files. This makes other power-management system (APM for now) to be able to generate power profile change events (ie. AC-line status changes), and other kernel components, not only the ACPI components, can be notified the events. The patche is available at http://people.freebsd.org/~iwasaki/acpi/power_profile-20011226.diff This includes: - move subroutines in acpi_powerprofile.c to kern/subr_power.c - call power_profile_set_state() also from APM driver when AC-line status changes - add call-back function for Crusoe LongRun controlling on power profile changes for a example I'll commit the patches early next year if no objections. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 2: 1:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 3F88037B417 for ; Thu, 27 Dec 2001 02:01:47 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id B4DED81D01; Thu, 27 Dec 2001 04:01:46 -0600 (CST) Date: Thu, 27 Dec 2001 04:01:46 -0600 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: the condvar stuff. Message-ID: <20011227040146.A55891@elvis.mu.org> References: <20011227001401.Y91594@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Thu, Dec 27, 2001 at 01:18:08AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [011227 03:20] wrote: > > > On Thu, 27 Dec 2001, Alfred Perlstein wrote: > > > * Julian Elischer [011227 00:00] wrote: > > > > > > Ok, so, I[ve looked at the code, > > > I've read teh man pages. > > > I've looked at soem usages.. > > > > > > > > > Why do we need the condvar stuff? it seems very similar > > > to the existing msleep code. > > > > They're a lot easier to get right than the flags based approach > > since you don't have to roll your own. > > In other words they are like msleep. Yes. > > They also specify a specific rendivous so that at a later date we > > won't need the sched_lock to place processes on the condvar's waiting > > queue. > > You'll still need to hold schedlock to take the running thread > out of the running state and select the next to run so I don't see > a great advantage to that. > > > You use the mutex passed in as the protection over the > > condvar, this is possible because if you think about it, it makes > > no sense to use more than one mutex with either a condvar or a > > set of flags, right? :) > > I see a weakness in that there is a cv_wait() with no cancelability. I > need to be able to cancel any cv or msleep in a threads world... Well I > don't NEED to but if I can't cancel a thread waiting on a cv then exit() > can take arbitrarily long as the exiting thread has to wait for all the > other threads to finish waiting on the CV. This is too much work. What you want to do is post signals to each "thread", this will make all interruptable (PCATCH/cv_sig) threads return up the syscall path. You may have to wait for non PCATCH/cv_sig threads because you have no choice. Most of those uninterruptable sleeps are there because it would be really difficult to handle an abort at that stage or becuase you've loaned out a resource that you must reclaim in order to "set right". For now you should just consider using the existing mechanisms, something like a posted signal and not worry about the uninterruptable sleeps. > Basically one of the changes I'll be doing in the KSE tree > as that all msleeps and cv waits and sx waits and mutx waits have > to either be identifiable as uninterruptable, or ba capable of > being interrupted (so at least the next layer can catch it and back out). Yes, this is what PCATCH is for. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 6:49:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 78E5637B41A for ; Thu, 27 Dec 2001 06:49:34 -0800 (PST) Received: from vigrid.com (pm3-pt23.pcnet.net [206.105.29.97]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id fBREmNVm019359; Thu, 27 Dec 2001 09:48:27 -0500 (EST) Message-ID: <3C2B36EB.77BE2A1F@vigrid.com> Date: Thu, 27 Dec 2001 09:57:47 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: the condvar stuff. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > On Thu, 27 Dec 2001, Alfred Perlstein wrote: > > > * Julian Elischer [011227 00:00] wrote: > > > > > > Ok, so, I[ve looked at the code, > > > I've read teh man pages. > > > I've looked at soem usages.. > > > > > > > > > Why do we need the condvar stuff? it seems very similar > > > to the existing msleep code. > > > > They're a lot easier to get right than the flags based approach > > since you don't have to roll your own. > > In other words they are like msleep. I think msleep should go bye-bye. Instances of it should be converted to mutex/cv pairs. > > > > They also specify a specific rendivous so that at a later date we > > won't need the sched_lock to place processes on the condvar's waiting > > queue. > > You'll still need to hold schedlock to take the running thread > out of the running state and select the next to run so I don't see > a great advantage to that. > > > You use the mutex passed in as the protection over the > > condvar, this is possible because if you think about it, it makes > > no sense to use more than one mutex with either a condvar or a > > set of flags, right? :) > > I see a weakness in that there is a cv_wait() with no cancelability. I > need to be able to cancel any cv or msleep in a threads world... Well I > don't NEED to but if I can't cancel a thread waiting on a cv then exit() > can take arbitrarily long as the exiting thread has to wait for all the > other threads to finish waiting on the CV. Isn't there cv_wait_sig/cv_timedwait_sig? I don't think you should be able to cancel (interrupt) threads that are waiting on mutexes or cv's that are not in cv_wait_sig/cv_timedwait_sig. Mutexes should be used for only very short periods of time. Calling code should use cv_wait_sig and cv_timedwait_sig if at all possible and handle the interruption when it occurs. > The problem is that there is no return value, so you can not tell the > calling code that it's thread has just been shot in the head. There are return values for cv_[timed]wait_sig. > I have two new functions in the KSE tree abortsleep(td) and cv_abort(td), > that rip the given thread out of whatever it's doing when the process > exits. but it's not possible to tell if a particular CV was done using > cv_wait() or cv_wait_sig() or whatever, so I don't really know if it's > safe to wake it. > > I just wake it and let whatever it was that went to sleep > (e.g. cv_wait_sig()) discover the "I'm Exititng" flag for itself.) > > Basically one of the changes I'll be doing in the KSE tree > as that all msleeps and cv waits and sx waits and mutx waits have > to either be identifiable as uninterruptable, or ba capable of > being interrupted (so at least the next layer can catch it and back out). Convert msleeps to mutex/cv pairs, and cv_[timed]wait to cv_[timed]wait_sig. If the calling code can be made to handle an interruption, then it should be using *_sig variants anyways. There might be places that can't handle it though... -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 9:40:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 4E2B137B419 for ; Thu, 27 Dec 2001 09:40:11 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011227174011.HUEJ20122.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 27 Dec 2001 17:40:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA88180; Thu, 27 Dec 2001 09:34:13 -0800 (PST) Date: Thu, 27 Dec 2001 09:34:11 -0800 (PST) From: Julian Elischer To: Dan Eischen Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: the condvar stuff. In-Reply-To: <3C2B36EB.77BE2A1F@vigrid.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG BTW Dan, I'm not that far from adding the syscall that allows you to fire up a KSE, and have a couple of threads running. I have defined the structures you need in an include file sys/kse.h it defines the structures needed by the userland scheduler. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 9:40:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 1C3AA37B405 for ; Thu, 27 Dec 2001 09:40:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011227174008.HUDR20122.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 27 Dec 2001 17:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA88172; Thu, 27 Dec 2001 09:26:49 -0800 (PST) Date: Thu, 27 Dec 2001 09:26:48 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: the condvar stuff. In-Reply-To: <20011227040146.A55891@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 27 Dec 2001, Alfred Perlstein wrote: > * Julian Elischer [011227 03:20] wrote: > > need to be able to cancel any cv or msleep in a threads world... Well I > > don't NEED to but if I can't cancel a thread waiting on a cv then exit() > > can take arbitrarily long as the exiting thread has to wait for all the > > other threads to finish waiting on the CV. > > This is too much work. What you want to do is post signals to > each "thread", this will make all interruptable (PCATCH/cv_sig) > threads return up the syscall path. You may have to wait for > non PCATCH/cv_sig threads because you have no choice. Most of > those uninterruptable sleeps are there because it would be really > difficult to handle an abort at that stage or becuase you've loaned > out a resource that you must reclaim in order to "set right". > > For now you should just consider using the existing mechanisms, > something like a posted signal and not worry about the uninterruptable > sleeps. That's what I'm doing.... > > > Basically one of the changes I'll be doing in the KSE tree > > as that all msleeps and cv waits and sx waits and mutx waits have > > to either be identifiable as uninterruptable, or ba capable of > > being interrupted (so at least the next layer can catch it and back out). > > Yes, this is what PCATCH is for. I know, I'm just dissapointed at the ease that I have in finding cases where all I can do is wait... :-/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 10:28:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 807AC37B417 for ; Thu, 27 Dec 2001 10:28:09 -0800 (PST) Received: from vigrid.com (pm3-pt26.pcnet.net [206.105.29.100]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id fBRIR2Vm021464; Thu, 27 Dec 2001 13:27:03 -0500 (EST) Message-ID: <3C2B6A2F.B0A4F664@vigrid.com> Date: Thu, 27 Dec 2001 13:36:31 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: the condvar stuff. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > BTW Dan, I'm not that far from adding the syscall that allows > you to fire up a KSE, and have a couple of threads running. Cool :-) > I have defined the structures you need in an include file > sys/kse.h > > it defines the structures needed by the userland scheduler. Thanks, I'll take a look at it. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 11:20:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 496DC37B41C for ; Thu, 27 Dec 2001 11:20:04 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id C333A81E0B; Thu, 27 Dec 2001 13:19:53 -0600 (CST) Date: Thu, 27 Dec 2001 13:19:53 -0600 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: the condvar stuff. Message-ID: <20011227131953.C55891@elvis.mu.org> References: <20011227040146.A55891@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Thu, Dec 27, 2001 at 09:26:48AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [011227 11:40] wrote: > > > On Thu, 27 Dec 2001, Alfred Perlstein wrote: > > > > For now you should just consider using the existing mechanisms, > > something like a posted signal and not worry about the uninterruptable > > sleeps. > > That's what I'm doing.... Good, I don't want you killing yourself working on this, we need you around to help flush out the bugs. :) > > > Basically one of the changes I'll be doing in the KSE tree > > > as that all msleeps and cv waits and sx waits and mutx waits have > > > to either be identifiable as uninterruptable, or ba capable of > > > being interrupted (so at least the next layer can catch it and back out). > > > > Yes, this is what PCATCH is for. > > I know, I'm just dissapointed at the ease that I have in finding cases > where all I can do is wait... > :-/ It's UNIX dude. :) If you use the existing PCATCH/cv_sig (at least for now) you'll be all good and a lot cleaner than fixing all the places with uninterruptable sleeps. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 11:33:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 517A737B405 for ; Thu, 27 Dec 2001 11:33:26 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBRJfCF01253; Thu, 27 Dec 2001 11:41:12 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112271941.fBRJfCF01253@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matthew Dillon Cc: Michal Mertl , Alfred Perlstein , John Hanley , arch@FreeBSD.ORG Subject: Re: 64 bit counters In-reply-to: Your message of "Thu, 27 Dec 2001 00:13:38 PST." <200112270813.fBR8Dc150215@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Dec 2001 11:41:12 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > :Why do I think it never becomes wrong? Generally I'm adding rather small > :value (<1e6 or so) to 64 bit counter. When one addition overflows less > :significant 32 bits, several next additions don't overflow. > : > :u_int64_t+=u_long is: > :addl %eax,(u_int64_t) ; this is atomic, right? > :adcl $0,4(u_int64_t) > : > :If interrupt occurs in between these two instructions, then the less > :significant halt is right and more significant will be fixed after the > :execution returns to second instruction. Even if the interrupt modified > :the value, we can expect (read - be sure) it didn't modify the more > :significant half. > > You are absolutely right. The carry will only be set on the addl > which overflows the 32 bit counter and will not be set on any of > the other addl's that might be occuring just before, inbetween the > two instructions, or just after. So only one of those will cause the > msb to increment. > > For UP the addl instruction is atomic. For SMP we still have to lock the > bus cycle. Something like this: > > lock; addl %eax,(u_int64_t) > lock; adcl $0,4(u_int64_t) This is all well and good, but not portable. Sorry folks. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 11:35:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 2B35937B421 for ; Thu, 27 Dec 2001 11:35:05 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBRJh0F01276; Thu, 27 Dec 2001 11:43:00 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112271943.fBRJh0F01276@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: Alfred Perlstein , arch@freebsd.org Subject: Re: the condvar stuff. In-reply-to: Your message of "Thu, 27 Dec 2001 01:18:08 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Dec 2001 11:43:00 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > Why do we need the condvar stuff? it seems very similar > > > to the existing msleep code. > > > > They're a lot easier to get right than the flags based approach > > since you don't have to roll your own. > > In other words they are like msleep. No, they are condition variables. They exist to provide a mechanism that is familiar to a large number of thread programmers, and which has a good body of related algorithms already established. They directly parallel the condition variables found in the pthread library, again keeping the kernel and userland programming metaphors as close as is practical. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 11:40:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 3A90037B405 for ; Thu, 27 Dec 2001 11:40:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011227194008.DOIC6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 27 Dec 2001 19:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA88703; Thu, 27 Dec 2001 11:34:44 -0800 (PST) Date: Thu, 27 Dec 2001 11:34:44 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: the condvar stuff. In-Reply-To: <20011227131953.C55891@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 27 Dec 2001, Alfred Perlstein wrote: > * Julian Elischer [011227 11:40] wrote: > > > > > > On Thu, 27 Dec 2001, Alfred Perlstein wrote: > > > > > > For now you should just consider using the existing mechanisms, > > > something like a posted signal and not worry about the uninterruptable > > > sleeps. > > > > That's what I'm doing.... > > Good, I don't want you killing yourself working on this, we need > you around to help flush out the bugs. :) > > > > > Basically one of the changes I'll be doing in the KSE tree > > > > as that all msleeps and cv waits and sx waits and mutx waits have > > > > to either be identifiable as uninterruptable, or ba capable of > > > > being interrupted (so at least the next layer can catch it and back out). > > > > > > Yes, this is what PCATCH is for. > > > > I know, I'm just dissapointed at the ease that I have in finding cases > > where all I can do is wait... > > :-/ > > It's UNIX dude. :) > > If you use the existing PCATCH/cv_sig (at least for now) you'll be > all good and a lot cleaner than fixing all the places with > uninterruptable sleeps. On cases with timeouts I'm accelerating the timelut. in _sig cases I'm similating a signal. if it's neither, I guess I'll just have to leave it. (the exit will never complete if the thread never leaves the CV.) > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 11:52:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 35F0F37B419 for ; Thu, 27 Dec 2001 11:52:22 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id C721E81E0B; Thu, 27 Dec 2001 13:52:21 -0600 (CST) Date: Thu, 27 Dec 2001 13:52:21 -0600 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: the condvar stuff. Message-ID: <20011227135221.F55891@elvis.mu.org> References: <20011227131953.C55891@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Thu, Dec 27, 2001 at 11:34:44AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [011227 13:40] wrote: > > On cases with timeouts I'm accelerating the timelut. > in _sig cases I'm similating a signal. > if it's neither, I guess I'll just have to leave it. > (the exit will never complete if the thread never leaves the CV.) Please do not accelerate the timeouts. I can imagine someone doing this: error = tsleep(&req, TIMEOUT); if (error == ETIMEOUT) panic("lost req!"); For now just signal the process using a special signal number. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 12: 0:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 0135E37B41F; Thu, 27 Dec 2001 12:00:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011227200014.EHPE6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 27 Dec 2001 20:00:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA88775; Thu, 27 Dec 2001 11:43:31 -0800 (PST) Date: Thu, 27 Dec 2001 11:43:29 -0800 (PST) From: Julian Elischer To: Mike Smith Cc: Alfred Perlstein , arch@freebsd.org Subject: Re: the condvar stuff. In-Reply-To: <200112271943.fBRJh0F01276@mass.dis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG so, is there such a thing in pthread condvars as an uncancellable condvar? On Thu, 27 Dec 2001, Mike Smith wrote: > No, they are condition variables. > > They exist to provide a mechanism that is familiar to a large number of > thread programmers, and which has a good body of related algorithms > already established. > > They directly parallel the condition variables found in the pthread > library, again keeping the kernel and userland programming metaphors as > close as is practical. I don't know how good an idea this is.. we are getting VERY kitchen-sinky in the kernel. Can I have a C++ allocator too? enumerate: mem allocators: mbuf/malloc/zalloc/kvalloc-etal/bus-space-alloc synchronisation: primatives CV/msleep/mtx/sx/lockmanager(gone?) thread schemes: (aio/kthreads/linux-thread-support/KSE) etc :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 12:14:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 2A0A537B405; Thu, 27 Dec 2001 12:14:13 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id C252481E0C; Thu, 27 Dec 2001 14:14:12 -0600 (CST) Date: Thu, 27 Dec 2001 14:14:12 -0600 From: Alfred Perlstein To: Julian Elischer Cc: Mike Smith , arch@freebsd.org Subject: Re: the condvar stuff. Message-ID: <20011227141412.G55891@elvis.mu.org> References: <200112271943.fBRJh0F01276@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Thu, Dec 27, 2001 at 11:43:29AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [011227 14:00] wrote: > so, is there such a thing in > pthread condvars as an uncancellable condvar? > > > On Thu, 27 Dec 2001, Mike Smith wrote: > > No, they are condition variables. > > > > They exist to provide a mechanism that is familiar to a large number of > > thread programmers, and which has a good body of related algorithms > > already established. > > > > They directly parallel the condition variables found in the pthread > > library, again keeping the kernel and userland programming metaphors as > > close as is practical. > > I don't know how good an idea this is.. > we are getting VERY kitchen-sinky in the kernel. Can I have a C++ > allocator too? > > enumerate: > mem allocators: mbuf/malloc/zalloc/kvalloc-etal/bus-space-alloc I hope to finish my slab allocator in the next couple of months this should collapse malloc and zalloc into a single subsystem. > synchronisation: primatives CV/msleep/mtx/sx/lockmanager(gone?) Eventually we will be able to get rid of msleep. > thread schemes: (aio/kthreads/linux-thread-support/KSE) > etc :-) Hopefully KSE will be flexible enough to implement aio, kthreads and linux-threads with a small wrapper, right? :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 12:23:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 462ED37B405; Thu, 27 Dec 2001 12:23:34 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBRKVUF01826; Thu, 27 Dec 2001 12:31:30 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112272031.fBRKVUF01826@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: Mike Smith , Alfred Perlstein , arch@freebsd.org Subject: Re: the condvar stuff. In-reply-to: Your message of "Thu, 27 Dec 2001 11:43:29 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Dec 2001 12:31:30 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > They directly parallel the condition variables found in the pthread > > library, again keeping the kernel and userland programming metaphors as > > close as is practical. > > I don't know how good an idea this is.. It's a very good idea. > we are getting VERY kitchen-sinky in the kernel. Can I have a C++ > allocator too? > > enumerate: > mem allocators: mbuf/malloc/zalloc/kvalloc-etal/bus-space-alloc > synchronisation: primatives CV/msleep/mtx/sx/lockmanager(gone?) > thread schemes: (aio/kthreads/linux-thread-support/KSE) Yeah, let's only have one way of allocating memory, and damn the fact that it's a poor fit for all the things we need to do. By all means keep the API as lean as possible (eg. msleep->cv/mutex conversions), but don't fall into the myopic mentality that believes that "allocating memory" or "synchronisation" or "thread schemes" are trivial little things with only a few facets. There's not really a lot of redundancy in the kernel API, and sane efforts to clean it up where it does exist are always welcome. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 12:33: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (h24-64-56-135.cg.shawcable.net [24.64.56.135]) by hub.freebsd.org (Postfix) with ESMTP id 2F68037B419; Thu, 27 Dec 2001 12:33:05 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id fBRKX1I00570; Thu, 27 Dec 2001 13:33:01 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id fBRKX0d34197; Thu, 27 Dec 2001 13:33:00 -0700 (MST) (envelope-from davidc) Date: Thu, 27 Dec 2001 13:33:00 -0700 From: Chad David To: Alfred Perlstein Cc: Julian Elischer , Mike Smith , arch@FreeBSD.ORG Subject: Re: the condvar stuff. Message-ID: <20011227133300.A34181@colnta.acns.ab.ca> Mail-Followup-To: Alfred Perlstein , Julian Elischer , Mike Smith , arch@FreeBSD.ORG References: <200112271943.fBRJh0F01276@mass.dis.org> <20011227141412.G55891@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011227141412.G55891@elvis.mu.org>; from bright@mu.org on Thu, Dec 27, 2001 at 02:14:12PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 27, 2001 at 02:14:12PM -0600, Alfred Perlstein wrote: > > I hope to finish my slab allocator in the next couple of months > this should collapse malloc and zalloc into a single subsystem. If you are willing, I would be very interested in seeing what you have done so far, and hearing about your design. I'm holding a Solaris kernel engineer hostage in my basement until the new year, and it would be great to compare what you are doing with the changes in the 5.9 allocator. -- Chad David davidc@acns.ab.ca ACNS Inc. Calgary, Alberta Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 13: 0:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D0C5F37B417; Thu, 27 Dec 2001 13:00:51 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id fBRKxjDR014013; Thu, 27 Dec 2001 15:59:45 -0500 (EST) Date: Thu, 27 Dec 2001 15:59:45 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: Mike Smith , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: the condvar stuff. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 27 Dec 2001, Julian Elischer wrote: > so, is there such a thing in > pthread condvars as an uncancellable condvar? Sort of. Cancellability is a separately managed thing. Threads have a cancel state and type. You can enable or disable the cancel state to allow or disallow cancellation, and you can set the cancel type to deferred or asynchronous cancellation. Threads in pthread_cond_wait, pthread_mutex_lock, etc, can be cancelled if their state and type allow them to be cancelled. They can also be signaled to allow a signal handler to run regardless of whether they are in a pthread_cond_wait, pthread_mutex_lock, etc., blocking condition. See pthread_setcancelstate, pthread_setcanceltype, etc. One thing about cancelling a thread in pthread_cond_wait is that the mutex is relocked by the thread after the cancellation. The thread needs to install a cleanup function (to be run at thread exit) that can unlock the mutex (see pthread_cleanup_push, pthread_cleanup_pop). I don't think you want all the cancellation facilities of the pthread library in the kernel. It is probably sufficient just to have the _sig synchronization variants (as Solaris seems to get by with this). Some might argue for being able to push thread cleanup handlers in the kernel, though... -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 13: 5:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 6175F37B428; Thu, 27 Dec 2001 13:05:09 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 0CCED81D01; Thu, 27 Dec 2001 15:05:09 -0600 (CST) Date: Thu, 27 Dec 2001 15:05:09 -0600 From: Alfred Perlstein To: Chad David Cc: Julian Elischer , Mike Smith , arch@FreeBSD.ORG Subject: Re: the condvar stuff. Message-ID: <20011227150508.M55891@elvis.mu.org> References: <200112271943.fBRJh0F01276@mass.dis.org> <20011227141412.G55891@elvis.mu.org> <20011227133300.A34181@colnta.acns.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011227133300.A34181@colnta.acns.ab.ca>; from davidc@acns.ab.ca on Thu, Dec 27, 2001 at 01:33:00PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Chad David [011227 14:35] wrote: > On Thu, Dec 27, 2001 at 02:14:12PM -0600, Alfred Perlstein wrote: > > > > I hope to finish my slab allocator in the next couple of months > > this should collapse malloc and zalloc into a single subsystem. > > If you are willing, I would be very interested in seeing what you > have done so far, and hearing about your design. I'm holding a > Solaris kernel engineer hostage in my basement until the new year, > and it would be great to compare what you are doing with the changes > in the 5.9 allocator. Sure, a more specific version of it is already implemented by Bosko Milekic in the mbuf allocator. Here's a copy of it: http://people.freebsd.org/~alfred/memcache/ It don't work, but I'm pretty sure I could get it working given the time and space. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 13:20:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 02C2137B4CF; Thu, 27 Dec 2001 13:20:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011227212009.HDXM6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 27 Dec 2001 21:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA89230; Thu, 27 Dec 2001 13:16:45 -0800 (PST) Date: Thu, 27 Dec 2001 13:16:44 -0800 (PST) From: Julian Elischer To: Daniel Eischen Cc: Mike Smith , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: the condvar stuff. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is relevant of course because one of the things we need to impliment is a way that the userland can cancel a thread when it's off in the kernel. This is why I'm trying to figure out how to bring threads back from various 'stop-points' in the kernel On Thu, 27 Dec 2001, Daniel Eischen wrote: > On Thu, 27 Dec 2001, Julian Elischer wrote: > > so, is there such a thing in > > pthread condvars as an uncancellable condvar? > > Sort of. Cancellability is a separately managed thing. > Threads have a cancel state and type. You can enable or disable > the cancel state to allow or disallow cancellation, and you > can set the cancel type to deferred or asynchronous cancellation. > Threads in pthread_cond_wait, pthread_mutex_lock, etc, can be > cancelled if their state and type allow them to be cancelled. > They can also be signaled to allow a signal handler to run > regardless of whether they are in a pthread_cond_wait, > pthread_mutex_lock, etc., blocking condition. See > pthread_setcancelstate, pthread_setcanceltype, etc. > > One thing about cancelling a thread in pthread_cond_wait is > that the mutex is relocked by the thread after the cancellation. > The thread needs to install a cleanup function (to be run at > thread exit) that can unlock the mutex (see pthread_cleanup_push, > pthread_cleanup_pop). > > I don't think you want all the cancellation facilities of the > pthread library in the kernel. It is probably sufficient just > to have the _sig synchronization variants (as Solaris seems to > get by with this). Some might argue for being able to push > thread cleanup handlers in the kernel, though... > > -- > Dan Eischen > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 14:10:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id 2397737B416; Thu, 27 Dec 2001 14:10:25 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id fBRMALvT097735; Thu, 27 Dec 2001 23:10:21 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id fBRMAKkR097732; Thu, 27 Dec 2001 23:10:20 +0100 (CET) Date: Thu, 27 Dec 2001 23:10:20 +0100 (CET) From: Michal Mertl To: Mike Smith Cc: Matthew Dillon , Alfred Perlstein , John Hanley , Subject: Re: 64 bit counters In-Reply-To: <200112271941.fBRJfCF01253@mass.dis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 27 Dec 2001, Mike Smith wrote: > > :Why do I think it never becomes wrong? Generally I'm adding rather small > > :value (<1e6 or so) to 64 bit counter. When one addition overflows less > > :significant 32 bits, several next additions don't overflow. > > : > > :u_int64_t+=u_long is: > > :addl %eax,(u_int64_t) ; this is atomic, right? > > :adcl $0,4(u_int64_t) > > : > > :If interrupt occurs in between these two instructions, then the less > > :significant halt is right and more significant will be fixed after the > > :execution returns to second instruction. Even if the interrupt modified > > :the value, we can expect (read - be sure) it didn't modify the more > > :significant half. > > > > You are absolutely right. The carry will only be set on the addl > > which overflows the 32 bit counter and will not be set on any of > > the other addl's that might be occuring just before, inbetween the > > two instructions, or just after. So only one of those will cause the > > msb to increment. > > > > For UP the addl instruction is atomic. For SMP we still have to lock the > > bus cycle. Something like this: > > > > lock; addl %eax,(u_int64_t) > > lock; adcl $0,4(u_int64_t) > > This is all well and good, but not portable. Aren't all other architectures we support 64 bit? On i386 even present form (32 bit addition) isn't atomic (no lock involved). On i386 for 64 bits the compiler generates the code above (without locks) and on 64 bit platforms I expect it would generate something at least similarly atomic like 32 bit addition on i386 we use today (both stable and current). On i586 we can have 64 bit atomic operations with cmpxchg8b. On Aplha I think the long is 64 bit so counters are already 64 bit. Anyway the code probably should be rewritten to use mutexes or atomic operations or whatever. I'll look at some current sources and maybe I'll be able to understand what are all these locks, mutexes, msleep and so on. In the time being I'll keep my naive patch to add the functionality to stable (it happens to work (probably only in 99.99999% of time and bit less on SMP)). > Sorry folks. 8( Not at all. -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 27 15: 6:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C6C8C37B417 for ; Thu, 27 Dec 2001 15:06:09 -0800 (PST) Received: from localhost (imp@dhcp30.timing.com [206.168.13.252]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBRN5xl18182; Thu, 27 Dec 2001 16:06:00 -0700 (MST) (envelope-from imp@village.org) Date: Thu, 27 Dec 2001 16:05:59 -0700 (MST) Message-Id: <20011227.160559.105390559.imp@village.org> To: iwasaki@jp.FreeBSD.org Cc: arch@FreeBSD.ORG Subject: Re: CFR: Generalized power profile From: "M. Warner Losh" In-Reply-To: <20011227.182533.112880512.iwasaki@jp.FreeBSD.org> References: <20011227.182533.112880512.iwasaki@jp.FreeBSD.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : http://people.freebsd.org/~iwasaki/acpi/power_profile-20011226.diff As far as I can tell, this looks good to me. Now that I have a Crusoe laptop, I'd love for it to last longer than 2 hours on battery. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 28 10:31:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id C987F37B416 for ; Fri, 28 Dec 2001 10:31:33 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBSIdGF13050; Fri, 28 Dec 2001 10:39:20 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112281839.fBSIdGF13050@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mitsuru IWASAKI Cc: arch@freebsd.org Subject: Re: CFR: Generalized power profile In-reply-to: Your message of "Thu, 27 Dec 2001 18:25:33 +0900." <20011227.182533.112880512.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Dec 2001 10:39:16 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I've made the changes for generalized power profile based on ACPI > power profile code, dev/acpica/acpi_powerprofile.c and some related > files. This makes other power-management system (APM for now) to be > able to generate power profile change events (ie. AC-line status > changes), and other kernel components, not only the ACPI components, > can be notified the events. Thanks for picking up on this. > This includes: > - move subroutines in acpi_powerprofile.c to kern/subr_power.c If we think this might become more complicated, do we want sys/dev/power? If not, this is an OK place. What do you think of POWER_PROFILE_OFF as an alternate mechanism for switching the system off, rather than the current shutdown hook? Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 28 23:28:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from femail11.sdc1.sfba.home.com (femail11.sdc1.sfba.home.com [24.0.95.107]) by hub.freebsd.org (Postfix) with ESMTP id 91DD037B436 for ; Fri, 28 Dec 2001 23:28:24 -0800 (PST) Received: from laptop.baldwin.cx ([24.2.39.156]) by femail11.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011229072824.CBLQ2594.femail11.sdc1.sfba.home.com@laptop.baldwin.cx>; Fri, 28 Dec 2001 23:28:24 -0800 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011222055111.C28FA38CC@overcee.netplex.com.au> Date: Fri, 28 Dec 2001 23:28:12 -0800 (PST) From: John Baldwin To: Peter Wemm Subject: Re: blurk! KSE vs the X86 Cc: arch@FreeBSD.ORG, Julian Elischer Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 22-Dec-01 Peter Wemm wrote: > Julian Elischer wrote: >> >> Ok so we have this wonderful thing called a TSS >> there is one per CPU by default, but you can ask that your process has it >> own.. that would be one per process.. it has such things as the address >> to load the system stack pointer from when running your process and take a >> trap e.g. syscall. >> >> This is in the PCB extension area. At this time there is only the >> capacity to set an extension into the single thread that would want it, >> and it isn't associated with the process as such via the proc structure, >> just via the PCB extension pointer. So since threads are transient in KSE >> processes when the thread migrates away (almost immediatly in some cases) >> you have no trace of your extension area (hense TSS) so at teh next >> swtch() it'll be gone again.. >> the QUICK answer is to say that vm86 and KSE can't be mixed, but >> is that the best solution we can do? > > Do not worry about the "best" yet. Lets get a functional baseline > code set that can actually do an upcall and actually do something useful > before worrying about this sort of thing. > > ie: until we have something functional in the tree, the policy should > be: KSE is not allowed with {VM86, local LDT, PCB extensions [io port > access], etc.} > > The "best" solution will be apparent after we have got the basics > working. LDT is already fine. TSS will be harder as you need a per-process TSS template that each thread builds its TSS from (possibly on the fly on each kernel entry/exit). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 28 23:28:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from femail24.sdc1.sfba.home.com (femail24.sdc1.sfba.home.com [24.0.95.149]) by hub.freebsd.org (Postfix) with ESMTP id C758C37B43D; Fri, 28 Dec 2001 23:28:31 -0800 (PST) Received: from laptop.baldwin.cx ([24.2.39.156]) by femail24.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011229072830.USF20896.femail24.sdc1.sfba.home.com@laptop.baldwin.cx>; Fri, 28 Dec 2001 23:28:30 -0800 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 28 Dec 2001 23:28:18 -0800 (PST) From: John Baldwin To: Michal Mertl Subject: Re: 64 bit counters Cc: arch@FreeBSD.ORG, John Hanley , Alfred Perlstein , Matthew Dillon , Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 27-Dec-01 Michal Mertl wrote: > On Thu, 27 Dec 2001, Mike Smith wrote: >> > :Why do I think it never becomes wrong? Generally I'm adding rather small >> > :value (<1e6 or so) to 64 bit counter. When one addition overflows less >> > :significant 32 bits, several next additions don't overflow. >> > : >> > :u_int64_t+=u_long is: >> > :addl %eax,(u_int64_t) ; this is atomic, right? >> > :adcl $0,4(u_int64_t) >> > : >> > :If interrupt occurs in between these two instructions, then the less >> > :significant halt is right and more significant will be fixed after the >> > :execution returns to second instruction. Even if the interrupt modified >> > :the value, we can expect (read - be sure) it didn't modify the more >> > :significant half. >> > >> > You are absolutely right. The carry will only be set on the addl >> > which overflows the 32 bit counter and will not be set on any of >> > the other addl's that might be occuring just before, inbetween the >> > two instructions, or just after. So only one of those will cause the >> > msb to increment. >> > >> > For UP the addl instruction is atomic. For SMP we still have to lock >> > the >> > bus cycle. Something like this: >> > >> > lock; addl %eax,(u_int64_t) >> > lock; adcl $0,4(u_int64_t) >> >> This is all well and good, but not portable. > > Aren't all other architectures we support 64 bit? On i386 even present > form (32 bit addition) isn't atomic (no lock involved). On i386 for 64 > bits the compiler generates the code above (without locks) and on 64 bit > platforms I expect it would generate something at least similarly atomic > like 32 bit addition on i386 we use today (both stable and current). On > i586 we can have 64 bit atomic operations with cmpxchg8b. On Aplha I think > the long is 64 bit so counters are already 64 bit. > > Anyway the code probably should be rewritten to use mutexes or atomic > operations or whatever. I'll look at some current sources and maybe I'll > be able to understand what are all these locks, mutexes, msleep and so on. > > In the time being I'll keep my naive patch to add the functionality to > stable (it happens to work (probably only in 99.99999% of time and bit > less on SMP)). You can use cmpxchg8b on SMP systems (it's available on all machines that support SMP I think) and use non-SMP versions otherwise where needed. You would just implement the atomic_foo_64 versions this way. You would need to use cmpxchg8b instead of addl/adcl for the acq and rel variants for SMP. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 28 23:41:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 0C3E637B421; Fri, 28 Dec 2001 23:41:39 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBT7nZF20289; Fri, 28 Dec 2001 23:49:37 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112290749.fBT7nZF20289@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: 64 bit counters In-reply-to: Your message of "Fri, 28 Dec 2001 23:28:18 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Dec 2001 23:49:35 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >> > lock; addl %eax,(u_int64_t) > >> > lock; adcl $0,4(u_int64_t) > >> > >> This is all well and good, but not portable. > > > > Aren't all other architectures we support 64 bit? Not PowerPC, for example. > > On i386 even present > > form (32 bit addition) isn't atomic (no lock involved). That's not correct; these counters currently hide behind Giant. > > Anyway the code probably should be rewritten to use mutexes or atomic > > operations or whatever. I'll look at some current sources and maybe I'll > > be able to understand what are all these locks, mutexes, msleep and so on. Mutexes and atomic ops are both *expensive*. The sampled approach I described is relatively cheap (and has a known, fixed cost). > You can use cmpxchg8b on SMP systems (it's available on all machines that > support SMP I think) and use non-SMP versions otherwise where needed. You > would just implement the atomic_foo_64 versions this way. You would need to > use cmpxchg8b instead of addl/adcl for the acq and rel variants for SMP. This is probably the best way to go, though the cost of the atomic operations makes me twitchy. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 29 7:24:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C85B437B41F for ; Sat, 29 Dec 2001 07:23:59 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBTFNvD85031 for ; Sat, 29 Dec 2001 10:23:57 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 29 Dec 2001 10:23:57 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: adding cred argument to socreate(), making NFS connect using , mount-time credential Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Attached please find a diff that does the following: (1) Makes the credential used by socreate() an explicit argument to socreate(), rather than getting it implicitly from the thread argument. (2) Make NFS cache the credential provided at mount-time, and use the cached credential (nfsmount->nm_so) when making calls to socreate(). This fixes the following bug: When NFS re-connects TCP (or initially connects UDP) it uses the credential of the process initiating the current NFS vnode operation. When IPFW uid/gid rules are used to limit traffic based on the sending/delivering socket credential, NFS traffic may unintentionally be limited. Likewise, use of ident and related getcred() on connections will return the wrong credential. It also fixes the soon-to-be bug: When using mandatory access control to limit interface and socket delivery of packets with inappropriate labels (integrity, sensitivity, type enforcement), the label on the socket will be set based on the credential initiating the NFS vode operation. This means that the first process to generate NFS I/O, or later on a reconnect, will determine the label of the NFS requests, which in some cases will result in NFS failure due to NFS packets being blocked by access control rules on the socket/interface. It might be worth considering pushing the ucred from struct nfsmount to struct mount if other filesystems need it. However, none currently do. I plan to commit it in a couple of days unless there are objections. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services ==== //depot/vendor/freebsd/sys/dev/streams/streams.c#3 (text+ko) - //depot/user/rwatson/mountcred/sys/dev/streams/streams.c#2 (text+ko) ==== content @@ -264,7 +264,8 @@ if ((error = falloc(td, &fp, &fd)) != 0) return error; - if ((error = socreate(family, &so, type, protocol, td)) != 0) { + if ((error = socreate(family, &so, type, protocol, + td->td_proc->p_ucred, td)) != 0) { p->p_fd->fd_ofiles[fd] = 0; ffree(fp); return error; ==== //depot/vendor/freebsd/sys/fs/fifofs/fifo_vnops.c#4 (text+ko) - //depot/user/rwatson/mountcred/sys/fs/fifofs/fifo_vnops.c#2 (text+ko) ==== content @@ -174,14 +174,16 @@ if ((fip = vp->v_fifoinfo) == NULL) { MALLOC(fip, struct fifoinfo *, sizeof(*fip), M_VNODE, M_WAITOK); vp->v_fifoinfo = fip; - error = socreate(AF_LOCAL, &rso, SOCK_STREAM, 0, ap->a_td); + error = socreate(AF_LOCAL, &rso, SOCK_STREAM, 0, + ap->a_td->td_proc->p_ucred, ap->a_td); if (error) { free(fip, M_VNODE); vp->v_fifoinfo = NULL; return (error); } fip->fi_readsock = rso; - error = socreate(AF_LOCAL, &wso, SOCK_STREAM, 0, ap->a_td); + error = socreate(AF_LOCAL, &wso, SOCK_STREAM, 0, + ap->a_td->td_proc->p_ucred, ap->a_td); if (error) { (void)soclose(rso); free(fip, M_VNODE); ==== //depot/vendor/freebsd/sys/fs/portalfs/portal_vnops.c#2 (text+ko) - //depot/user/rwatson/mountcred/sys/fs/portalfs/portal_vnops.c#2 (text+ko) ==== content @@ -246,7 +246,8 @@ /* * Create a new socket. */ - error = socreate(AF_UNIX, &so, SOCK_STREAM, 0, ap->a_td); + error = socreate(AF_UNIX, &so, SOCK_STREAM, 0, + ap->a_td->td_proc->p_ucred, ap->a_td); if (error) goto bad; ==== //depot/vendor/freebsd/sys/kern/uipc_socket.c#9 (text+ko) - //depot/user/rwatson/mountcred/sys/kern/uipc_socket.c#2 (text+ko) ==== content @@ -137,11 +137,12 @@ * closed with soclose(). */ int -socreate(dom, aso, type, proto, td) +socreate(dom, aso, type, proto, cred, td) int dom; struct socket **aso; register int type; int proto; + struct ucred *cred; struct thread *td; { register struct protosw *prp; @@ -172,7 +173,7 @@ TAILQ_INIT(&so->so_incomp); TAILQ_INIT(&so->so_comp); so->so_type = type; - so->so_cred = crhold(td->td_proc->p_ucred); + so->so_cred = crhold(cred); so->so_proto = prp; soref(so); error = (*prp->pr_usrreqs->pru_attach)(so, proto, td); ==== //depot/vendor/freebsd/sys/kern/uipc_syscalls.c#5 (text+ko) - //depot/user/rwatson/mountcred/sys/kern/uipc_syscalls.c#3 (text+ko) ==== content @@ -132,7 +132,8 @@ if (error) goto done2; fhold(fp); - error = socreate(uap->domain, &so, uap->type, uap->protocol, td); + error = socreate(uap->domain, &so, uap->type, uap->protocol, + td->td_proc->p_ucred, td); if (error) { if (fdp->fd_ofiles[fd] == fp) { fdp->fd_ofiles[fd] = NULL; @@ -478,10 +479,12 @@ int fd, error, sv[2]; mtx_lock(&Giant); - error = socreate(uap->domain, &so1, uap->type, uap->protocol, td); + error = socreate(uap->domain, &so1, uap->type, uap->protocol, + td->td_proc->p_ucred, td); if (error) goto done2; - error = socreate(uap->domain, &so2, uap->type, uap->protocol, td); + error = socreate(uap->domain, &so2, uap->type, uap->protocol, + td->td_proc->p_ucred, td); if (error) goto free1; error = falloc(td, &fp1, &fd); ==== //depot/vendor/freebsd/sys/netgraph/ng_ksocket.c#6 (text+ko) - //depot/user/rwatson/mountcred/sys/netgraph/ng_ksocket.c#2 (text+ko) ==== content @@ -586,7 +586,8 @@ return (EINVAL); /* Create the socket */ - error = socreate(family, &priv->so, type, protocol, td); + error = socreate(family, &priv->so, type, protocol, + td->td_proc->p_ucred, td); if (error != 0) return (error); ==== //depot/vendor/freebsd/sys/netsmb/smb_trantcp.c#2 (text+ko) - //depot/user/rwatson/mountcred/sys/netsmb/smb_trantcp.c#2 (text+ko) ==== content @@ -226,7 +226,8 @@ struct socket *so; int error, s; - error = socreate(AF_INET, &so, SOCK_STREAM, IPPROTO_TCP, td); + error = socreate(AF_INET, &so, SOCK_STREAM, IPPROTO_TCP, + td->td_proc->p_ucred, td); if (error) return error; nbp->nbp_tso = so; ==== //depot/vendor/freebsd/sys/nfsclient/bootp_subr.c#3 (text+ko) - //depot/user/rwatson/mountcred/sys/nfsclient/bootp_subr.c#2 (text+ko) ==== content @@ -586,7 +586,8 @@ /* * Create socket and set its recieve timeout. */ - error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td); + error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td->td_proc->p_ucred, + td); if (error != 0) goto out; @@ -971,7 +972,8 @@ struct ifaddr *ifa; struct sockaddr_dl *sdl; - error = socreate(AF_INET, &ifctx->so, SOCK_DGRAM, 0, td); + error = socreate(AF_INET, &ifctx->so, SOCK_DGRAM, 0, + td->td_proc->p_ucred, td); if (error != 0) panic("nfs_boot: socreate, error=%d", error); ==== //depot/vendor/freebsd/sys/nfsclient/krpc_subr.c#3 (text+ko) - //depot/user/rwatson/mountcred/sys/nfsclient/krpc_subr.c#2 (text+ko) ==== content @@ -215,7 +215,8 @@ /* * Create socket and set its recieve timeout. */ - if ((error = socreate(AF_INET, &so, SOCK_DGRAM, 0, td))) + if ((error = socreate(AF_INET, &so, SOCK_DGRAM, 0, + td->td_proc->p_ucred, td))) goto out; tv.tv_sec = 1; ==== //depot/vendor/freebsd/sys/nfsclient/nfs_socket.c#6 (text+ko) - //depot/user/rwatson/mountcred/sys/nfsclient/nfs_socket.c#4 (text+ko) ==== content @@ -162,7 +162,7 @@ nmp->nm_so = (struct socket *)0; saddr = nmp->nm_nam; error = socreate(saddr->sa_family, &nmp->nm_so, nmp->nm_sotype, - nmp->nm_soproto, td); + nmp->nm_soproto, nmp->nm_cred, td); if (error) goto bad; so = nmp->nm_so; ==== //depot/vendor/freebsd/sys/nfsclient/nfs_vfsops.c#9 (text+ko) - //depot/user/rwatson/mountcred/sys/nfsclient/nfs_vfsops.c#4 (text+ko) ==== content @@ -92,7 +92,8 @@ static int nfs_iosize(struct nfsmount *nmp); static void nfs_decode_args(struct nfsmount *nmp, struct nfs_args *argp); static int mountnfs(struct nfs_args *, struct mount *, - struct sockaddr *, char *, char *, struct vnode **); + struct sockaddr *, char *, char *, struct vnode **, + struct ucred *cred); static int nfs_mount(struct mount *mp, char *path, caddr_t data, struct nameidata *ndp, struct thread *td); static int nfs_unmount(struct mount *mp, int mntflags, struct thread *td); @@ -377,6 +378,7 @@ nfs_mountroot(struct mount *mp) { struct mount *swap_mp; + struct nfsmount *nmp = VFSTONFS(mp); struct nfsv3_diskless *nd = &nfsv3_diskless; struct socket *so; struct vnode *vp; @@ -419,7 +421,8 @@ * Do enough of ifconfig(8) so that the critical net interface can * talk to the server. */ - error = socreate(nd->myif.ifra_addr.sa_family, &so, SOCK_DGRAM, 0, td); + error = socreate(nd->myif.ifra_addr.sa_family, &so, SOCK_DGRAM, 0, + nmp->nm_cred, td); if (error) panic("nfs_mountroot: socreate(%04x): %d", nd->myif.ifra_addr.sa_family, error); @@ -557,7 +560,8 @@ mp->mnt_kern_flag = 0; mp->mnt_flag = mountflag; nam = dup_sockaddr((struct sockaddr *)sin, 1); - if ((error = mountnfs(args, mp, nam, which, path, vpp)) != 0) { + if ((error = mountnfs(args, mp, nam, which, path, vpp, td->td_ucred)) + != 0) { printf("nfs_mountroot: mount %s on %s: %d", path, which, error); mp->mnt_vfc->vfc_refcount--; vfs_unbusy(mp, td); @@ -785,7 +789,7 @@ if (error) return (error); args.fh = nfh; - error = mountnfs(&args, mp, nam, path, hst, &vp); + error = mountnfs(&args, mp, nam, path, hst, &vp, td->td_ucred); return (error); } @@ -794,7 +798,7 @@ */ static int mountnfs(struct nfs_args *argp, struct mount *mp, struct sockaddr *nam, - char *pth, char *hst, struct vnode **vpp) + char *pth, char *hst, struct vnode **vpp, struct ucred *cred) { struct nfsmount *nmp; struct nfsnode *np; @@ -814,6 +818,7 @@ } vfs_getnewfsid(mp); nmp->nm_mountp = mp; + nmp->nm_cred = crhold(cred); /* * V2 can only handle 32 bit filesizes. A 4GB-1 limit may be too ==== //depot/vendor/freebsd/sys/nfsclient/nfsmount.h#2 (text+ko) - //depot/user/rwatson/mountcred/sys/nfsclient/nfsmount.h#3 (text+ko) ==== content @@ -53,6 +53,7 @@ u_char nm_fh[NFSX_V3FHMAX]; /* File handle of root dir */ int nm_fhsize; /* Size of root file handle */ struct socket *nm_so; /* Rpc socket */ + struct ucred *nm_cred; /* Cached mount-time credential */ int nm_sotype; /* Type of socket */ int nm_soproto; /* and protocol */ int nm_soflags; /* pr_flags for socket protocol */ ==== //depot/vendor/freebsd/sys/sys/socketvar.h#9 (text+ko) - //depot/user/rwatson/mountcred/sys/sys/socketvar.h#2 (text+ko) ==== content @@ -383,7 +383,7 @@ int soconnect __P((struct socket *so, struct sockaddr *nam, struct thread *td)); int soconnect2 __P((struct socket *so1, struct socket *so2)); int socreate __P((int dom, struct socket **aso, int type, int proto, - struct thread *td)); + struct ucred *cred, struct thread *td)); int sodisconnect __P((struct socket *so)); void sofree __P((struct socket *so)); int sogetopt __P((struct socket *so, struct sockopt *sopt)); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 29 10:21:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 5A6F737B438; Sat, 29 Dec 2001 10:21:17 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 5A27081D03; Sat, 29 Dec 2001 12:21:11 -0600 (CST) Date: Sat, 29 Dec 2001 12:21:11 -0600 From: Alfred Perlstein To: Robert Watson Cc: arch@FreeBSD.org Subject: Re: adding cred argument to socreate(), making NFS connect using , mount-time credential Message-ID: <20011229122111.D16101@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.org on Sat, Dec 29, 2001 at 10:23:57AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Robert Watson [011229 09:24] wrote: > > Attached please find a diff that does the following: > > (1) Makes the credential used by socreate() an explicit argument to > socreate(), rather than getting it implicitly from the thread > argument. This looks good, on the same note do you think we ought to remove vn_open_cred and make vn_open just always require a cred argument? I would like to see that. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 29 12:16:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 07B8C37B421; Sat, 29 Dec 2001 12:16:36 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBTKGWR01735; Sat, 29 Dec 2001 12:16:32 -0800 (PST) (envelope-from dillon) Date: Sat, 29 Dec 2001 12:16:32 -0800 (PST) From: Matthew Dillon Message-Id: <200112292016.fBTKGWR01735@apollo.backplane.com> To: John Baldwin Cc: Michal Mertl , arch@FreeBSD.ORG, John Hanley , Alfred Perlstein , Mike Smith Subject: Re: 64 bit counters References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :You can use cmpxchg8b on SMP systems (it's available on all machines that :support SMP I think) and use non-SMP versions otherwise where needed. You :would just implement the atomic_foo_64 versions this way. You would need to :use cmpxchg8b instead of addl/adcl for the acq and rel variants for SMP. : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ :"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ This seems quite reasonable to me. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 29 13:27:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4C01637B41E for ; Sat, 29 Dec 2001 13:27:16 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBTLRBD87796; Sat, 29 Dec 2001 16:27:12 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 29 Dec 2001 16:27:11 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alfred Perlstein Cc: arch@FreeBSD.org Subject: Re: adding cred argument to socreate(), making NFS connect using , mount-time credential In-Reply-To: <20011229122111.D16101@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 29 Dec 2001, Alfred Perlstein wrote: > * Robert Watson [011229 09:24] wrote: > > > > Attached please find a diff that does the following: > > > > (1) Makes the credential used by socreate() an explicit argument to > > socreate(), rather than getting it implicitly from the thread > > argument. > > This looks good, on the same note do you think we ought to remove > vn_open_cred and make vn_open just always require a cred argument? > > I would like to see that. Yes -- in fact I only saw recently that the vn_open change didn't do that, and was somewhat surprised. :-) Feel free to go ahead and commit whenever, or if you don't get to it I'll do it next week. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 29 13:44:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 5ED4637B419; Sat, 29 Dec 2001 13:44:35 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 1211581D03; Sat, 29 Dec 2001 15:44:35 -0600 (CST) Date: Sat, 29 Dec 2001 15:44:35 -0600 From: Alfred Perlstein To: Robert Watson Cc: arch@FreeBSD.org Subject: Re: adding cred argument to socreate(), making NFS connect using , mount-time credential Message-ID: <20011229154435.G16101@elvis.mu.org> References: <20011229122111.D16101@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.org on Sat, Dec 29, 2001 at 04:27:11PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Robert Watson [011229 15:27] wrote: > > On Sat, 29 Dec 2001, Alfred Perlstein wrote: > > > * Robert Watson [011229 09:24] wrote: > > > > > > Attached please find a diff that does the following: > > > > > > (1) Makes the credential used by socreate() an explicit argument to > > > socreate(), rather than getting it implicitly from the thread > > > argument. > > > > This looks good, on the same note do you think we ought to remove > > vn_open_cred and make vn_open just always require a cred argument? > > > > I would like to see that. > > Yes -- in fact I only saw recently that the vn_open change didn't do that, > and was somewhat surprised. :-) Feel free to go ahead and commit > whenever, or if you don't get to it I'll do it next week. Well, when I first looked at your patch I was annoyed that you handn't picked my _cred way of doing it, then I realized mine was kinda gross. :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 29 13:53:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lycos.co.kr (catv-kwangjoo-210205028145.usr2.hananet.net [210.205.28.145]) by hub.freebsd.org (Postfix) with SMTP id 70D1037B435 for ; Sat, 29 Dec 2001 13:52:23 -0800 (PST) Reply-To: adfree114@lycos.co.kr From: adfree114 To: Subject: [광고]문구가 들어간 메일을 100% 차단하는법 !! Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 30 Dec 2001 06:54:03 +0900 X-Priority: 3 X-Mailer: Mailtouch 1.0 Message-Id: <20011229215223.70D1037B435@hub.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [광고]문구가 들어간 메일을 100% 차단하는 방법 !!

[광고]문구가 들어간 메일을 100% 차단하는법 !!

컴을 알고나면 스팸메일 걱정안하고 얼마든지 메일을 이용할 수가 있지여~

웹메일 메뉴중 환경설정이나옵션선택 - 필터선택후 - [광고]문구를 수신거부에 추가하면 다음부터 제목에 [광고]라는 문구가 들어간 메일과 영원히 이별을 할 수 있답니다..^^    (욕을 하거나 신고만으론 전혀 효과가 없음)

모든 웹메일에는 스팸차단 기능외 싫어하는 메일만 막을 수 있는 기능이 있으며 .. 성인, 쇼핑, CD, 동영상 등... 받기싫은 내용이 들어간 것만 거부할 수도 있는데 조금만 신경쓰면 [광고]메일 걱정 뚝...!! 간단하죠...^ ^

만약 제목에 [광고]라는 문구가 없다면 본문에 "수신거부"란 문구를 필터링으로 해보세요 그럼 광고메일은 못 들어오고 휴지통으로 사라집니다
 (즉 광고메일은 본문에 "수신거부를 해주세요 등... 죄송합니다 등의 문구가 있으니 그 문구를 포함한 것은 모두 막아 줍니다 )

새로운 도메인 등록안내...바이러스 경고안내...새로운 신상품을 싼 가격에 구입할 수 있는 쇼핑몰...관광안내...학원안내...각종정보 소식지...성인...등...그 모두를 [광고]라고 하지요~

그리고 수신자들중 60%가 광고메일에 의해 수많은 정보를 얻는다고 합니다, 수많은 광고들 중 꼭 그 정보를 필요로 하는 분도 계시다는 사실 때문에 광고는 존재하는 것입니다

그리고 이 어려운 시대에 살아남기 위해 몸부림치는 분들을 위해 자기집 문단속을 하는의미에서 [광고] 필터링 선택하심이 어떨런지요~~
광고주들도 더불어 살아가는 사람들이니까요

광고를 필요로 하는 사람만 보기를 바라는 마음에서....

무료성인영화보기

무료성인만화보기

 

  - 최후의 희망은 긍정적인 사고방식 그리고 사랑... -

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 29 16:48:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id B515F37B405 for ; Sat, 29 Dec 2001 16:48:11 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id fBU0m7lk049972; Sun, 30 Dec 2001 01:48:07 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id fBU0m7j7049969; Sun, 30 Dec 2001 01:48:07 +0100 (CET) Date: Sun, 30 Dec 2001 01:48:07 +0100 (CET) From: Michal Mertl To: Matthew Dillon Cc: arch@freebsd.org Subject: Re: 64 bit counters In-Reply-To: <200112292016.fBTKGWR01735@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 29 Dec 2001, Matthew Dillon wrote: > :You can use cmpxchg8b on SMP systems (it's available on all machines that > :support SMP I think) and use non-SMP versions otherwise where needed. You > :would just implement the atomic_foo_64 versions this way. You would need to > :use cmpxchg8b instead of addl/adcl for the acq and rel variants for SMP. > : > :-- > : > :John Baldwin <>< http://www.FreeBSD.org/~jhb/ > :"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > This seems quite reasonable to me. > Yes. I wrote the atomic functions (set, add, get) with cmpxchg8b. I also measured the preformance and here are the results (100 mil additions on pII 366): default 32 bit implementation took 1.25821 secs atomic 32 bit implementation (from ) took 1.74043 secs default 64 bit implementation took 2.226189 secs atomic 64 bit implementation took 5.205156 secs With locks (for SMP) both 32 and 64 bit are quite a lot slower (32bit 6.3 and 64 12.3 sec). I doesn't seem too bad to me, but I do have a problem - I can't implement real atomic 64 bit operations on an i386. It shouldn't be named atomic_XXX if it isn't atomic. So that other people don't start to use it on <586 with some variable which changes fast. What about making the counters not 64 bit, but the size of biggest atomic type? Something like type u_maxatomic_t which would be 32 bit on <586 and 64 bit otherwise. There would still be problem in determining at compile time the size but we could choose the safe size if not somewhere defined otherwise. I can make changes to my local tree but how should I send them someone for review? Should I send them to arch? I tried to find the answer to this question in developers's handbook but didn't find it. > -Matt -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 29 16:59:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id F19C537B41A for ; Sat, 29 Dec 2001 16:59:22 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 74C7B81D03; Sat, 29 Dec 2001 18:59:17 -0600 (CST) Date: Sat, 29 Dec 2001 18:59:17 -0600 From: Alfred Perlstein To: Michal Mertl Cc: Matthew Dillon , arch@freebsd.org Subject: Re: 64 bit counters Message-ID: <20011229185917.J16101@elvis.mu.org> References: <200112292016.fBTKGWR01735@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mime@traveller.cz on Sun, Dec 30, 2001 at 01:48:07AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Michal Mertl [011229 18:49] wrote: > I doesn't seem too bad to me, but I do have a problem - I can't implement > real atomic 64 bit operations on an i386. It shouldn't be named atomic_XXX > if it isn't atomic. So that other people don't start to use it on <586 > with some variable which changes fast. > > What about making the counters not 64 bit, but the size of biggest atomic > type? Something like type u_maxatomic_t which would be 32 bit on <586 and > 64 bit otherwise. There would still be problem in determining at compile > time the size but we could choose the safe size if not somewhere defined > otherwise. > > I can make changes to my local tree but how should I send them someone for > review? Should I send them to arch? I tried to find the answer to this > question in developers's handbook but didn't find it. *laff* the concept of atomic_t was initially proposed by me over a year ago (i got the idea from linux) however it never seemed to get done. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message