From owner-freebsd-arch Sun May 20 4: 2:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id D6CB937B424; Sun, 20 May 2001 04:02:13 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4KB29n04567; Sun, 20 May 2001 14:02:09 +0300 (EEST) (envelope-from ru) Date: Sun, 20 May 2001 14:02:09 +0300 From: Ruslan Ermilov To: sobomax@FreeBSD.org Cc: nik@FreeBSD.org, audit@FreeBSD.org, arch@FreeBSD.org Subject: Re: Integrating new scrshot(1) utility into vidcontrol(1) [patch for review] Message-ID: <20010520140209.C3338@sunbay.com> Mail-Followup-To: sobomax@FreeBSD.org, nik@FreeBSD.org, audit@FreeBSD.org, arch@FreeBSD.org References: <200105182342.f4INgJx36064@mail.uic-in.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105182342.f4INgJx36064@mail.uic-in.net>; from sobomax@mail-in.net on Sat, May 19, 2001 at 02:42:28AM +0300 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, May 19, 2001 at 02:42:28AM +0300, Maxim Sobolev wrote: > Ok, as it was agreed I've integrated scrshot(1) into > vidcontrol(1) and also added ability to dump contents > of display buffer in plain text format, so you don't > even need a special utility to see what's going on > on a console of display-less machine. :-) > > Please somebody review attached patches (esp. manpage). > Thank you! > > -Maxim > > Index: vidcontrol.1 > =================================================================== > RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.1,v > retrieving revision 1.34 > diff -d -u -r1.34 vidcontrol.1 > --- vidcontrol.1 2001/04/18 15:51:56 1.34 > +++ vidcontrol.1 2001/05/18 23:32:37 > @@ -36,6 +36,8 @@ > .Op Fl M Ar char > .Op Fl m Cm on | off > .Op Fl r Ar foreground Ar background > +.Op Fl p > +.Op Fl P > .Op Fl s Ar number > .Op Fl t Ar N | Cm off > .Op Fl x > Sort these (put them before `r'). > @@ -185,6 +187,21 @@ > Used together with the > .Xr moused 8 > daemon for text mode cut & paste functionality. > +.It Fl p > +Capture the current contents of the video buffer corresponding > +to the terminal device referred to by standard input. > +.Nm > +writes contents of the video buffer to the standard > +output in a raw binary format. For details about that ^^ Always start a new sentence with a new line. Don't even use two spaces (though it's valid). Using two spaces, while technically speaking is right, complicates verifying of the document. Often, two spaces are put by mistake, and produce weird results. Always starting a new sentence with a new line significantly helps to debug such problems, not to say to a) speed up the proccessing and b) save the disk space. > +.Ss Format of Video Buffer Dump > If assume this hunk was simply copied from the original manpage, so it doesn't need a review. > .Sh SEE ALSO > .Xr kbdcontrol 1 , > .Xr vidfont 1 , > @@ -339,5 +468,13 @@ > .Xr rc.conf 5 , > .Xr kldload 8 , > .Xr moused 8 > +.Xr watch 8 > Missing comma after "Xr moused 8". > .Sh AUTHORS > .An S\(/oren Schmidt Aq sos@FreeBSD.org > I think Nik deserves the credits here. > @@ -70,8 +75,8 @@ > fprintf(stderr, "%s\n%s\n%s\n%s\n", > "usage: vidcontrol [-r fg bg] [-b color] [-c appearance] [-d] [-l scrmap]", > " [-i adapter | mode] [-L] [-M char] [-m on|off]", > -" [-f size file] [-s number] [-t N|off] [-x] [-g geometry]", > -" [mode] [fgcol [bgcol]] [show]"); > +" [-f size file] [-s number] [-t N|off] [-x] [-g geometry]", > +" [-p] [-P] [mode] [fgcol [bgcol]] [show]"); > exit(1); > } Similarly, sort this. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 20 5:36: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id E82D937B424; Sun, 20 May 2001 05:35:51 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4KCZTU08627; Sun, 20 May 2001 15:35:29 +0300 (EEST) (envelope-from ru) Date: Sun, 20 May 2001 15:35:28 +0300 From: Ruslan Ermilov To: Bruce Evans Cc: freebsd-arch@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) Message-ID: <20010520153528.B7358@sunbay.com> Mail-Followup-To: Bruce Evans , freebsd-arch@FreeBSD.ORG, freebsd-fs@FreeBSD.org References: <20010518175335.A90576@sunbay.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 bde@zeta.org.au on Sun, May 20, 2001 at 01:57:45AM +1000 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, May 20, 2001 at 01:57:45AM +1000, Bruce Evans wrote: > On Fri, 18 May 2001, Ruslan Ermilov wrote: > > > > sbin/mount_null/Makefile > > > sbin/mount_portal/Makefile > > > sbin/mount_umap/Makefile > > > sbin/mount_union/Makefile > > > > > FS headers should go into /usr/include/fs/fs.h, one per > > each filesystem. > > without a slash? This isn't so clear. Lots of headers may be > needed for _fsck. > Hmm, right. Actually, I just want a consistency here, no matter which way we choose, so we could get rif of all bogus -I${.CURDIR}/.../sys lines in Makefiles. Should we put all FS-related headers under /usr/include/fs//*.h then? That would imply moving src/sys/ufs to src/sys/fs/ufs so that we could make `make SHARED=symlinks' work as well. (Similarly for src/sys/miscfs -> src/sys/fs/miscfs.) I'm not sure what impact on third-party software that would have. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 20 6: 2:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id CC35337B424; Sun, 20 May 2001 06:02:42 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id f4KCtiK26571; Sun, 20 May 2001 13:55:44 +0100 (BST) (envelope-from nik) Date: Sun, 20 May 2001 13:55:44 +0100 From: Nik Clayton To: sobomax@FreeBSD.org, nik@FreeBSD.org, audit@FreeBSD.org, arch@FreeBSD.org Subject: Re: Integrating new scrshot(1) utility into vidcontrol(1) [patch for review] Message-ID: <20010520135543.A25841@catkin.nothing-going-on.org> References: <200105182342.f4INgJx36064@mail.uic-in.net> <20010520140209.C3338@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010520140209.C3338@sunbay.com>; from ru@FreeBSD.org on Sun, May 20, 2001 at 02:02:09PM +0300 Organization: FreeBSD Project 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 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 20, 2001 at 02:02:09PM +0300, Ruslan Ermilov wrote: > > .Sh AUTHORS > > .An S\(/oren Schmidt Aq sos@FreeBSD.org > >=20 > I think Nik deserves the credits here. Nope. Joel Holveck wrote the original ioctl implementation, and the first version of scrshot. I just forwarded ported them to -current, extended scrshot slightly, and wrote the man page. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsHvs8ACgkQk6gHZCw343XvsACghRgUq5pwzJ/9niKhUrh+FFGC ONYAn0uvtz5agw/Eo78f1tLDYUjDowp9 =eNUy -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 20 6:12:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 6396837B424; Sun, 20 May 2001 06:12:42 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id f4KD7lG26613; Sun, 20 May 2001 14:07:48 +0100 (BST) (envelope-from nik) Date: Sun, 20 May 2001 14:07:47 +0100 From: Nik Clayton To: sobomax@FreeBSD.ORG Cc: nik@FreeBSD.ORG, ru@FreeBSD.ORG, audit@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Integrating new scrshot(1) utility into vidcontrol(1) [patch for review] Message-ID: <20010520140747.B25841@catkin.nothing-going-on.org> References: <20010519194435.A22224@catkin.nothing-going-on.org> <200105191939.f4JJdjr00870@mail.uic-in.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="b5gNqxB1S1yM7hjW" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105191939.f4JJdjr00870@mail.uic-in.net>; from sobomax@mail-in.net on Sat, May 19, 2001 at 10:39:47PM +0300 Organization: FreeBSD Project 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 --b5gNqxB1S1yM7hjW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 19, 2001 at 10:39:47PM +0300, Maxim Sobolev wrote: > BTW, I think that the kernel's part of this feature has > to be extended to dump not only visible portion of the > screen buffer, but the whole history buffer as well. What > do you think? Shouldn't be too hard.=20 (a) It should be optional, either as a flag to the existing ioctl, or as a new ioctl. (b) CONS_GETINFO will need to be extended (or we need a new ioctl for the scrollback) to include information about how big the scrollback buffer is. (c) It might be worth providing a mechanism to let the application specify a rectangular window that it wants to grab from the buffer. I'm a bit busy most of this week, but I might be able to do this toward the end of the week. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --b5gNqxB1S1yM7hjW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsHwaMACgkQk6gHZCw343W2jwCeKrsTl/RAQLL0rPfCXMH5xQAW YmgAnR1jKRr+kt1eFZeqx5Wr5lWRr2Ub =BHUD -----END PGP SIGNATURE----- --b5gNqxB1S1yM7hjW-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 20 13:16:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id 1685B37B42C; Sun, 20 May 2001 13:16:29 -0700 (PDT) (envelope-from sobomax@mail-in.net) Received: from mail.uic-in.net (root@[212.35.189.4]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4KKHpa98928; Sun, 20 May 2001 23:17:52 +0300 (EEST) (envelope-from sobomax@mail-in.net) Received: from notebook.vega.com (das0-l77.uic-in.net [212.35.189.204]) by mail.uic-in.net (8.11.3/8.11.3) with ESMTP id f4KKGDS00936; Sun, 20 May 2001 23:16:14 +0300 (EEST) (envelope-from sobomax@mail-in.net) Date: Sun, 20 May 2001 23:16:14 +0300 (EEST) Message-Id: <200105202016.f4KKGDS00936@mail.uic-in.net> To: nik@FreeBSD.ORG Cc: nik@FreeBSD.ORG, ru@FreeBSD.ORG, audit@FreeBSD.ORG, arch@FreeBSD.ORG From: Maxim Sobolev Reply-To: sobomax@FreeBSD.ORG Subject: Re: Integrating new scrshot(1) utility into vidcontrol(1) [patch for review] X-Mailer: Pygmy (v0.5.8) In-Reply-To: <20010520140747.B25841@catkin.nothing-going-on.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 On Sun, 20 May 2001 14:07:47 +0100, Nik Clayton wrote: > On Sat, May 19, 2001 at 10:39:47PM +0300, Maxim Sobolev wrote: > > BTW, I think that the kernel's part of this feature has > > to be extended to dump not only visible portion of the > > screen buffer, but the whole history buffer as well. What > > do you think? > > Shouldn't be too hard. > > (a) It should be optional, either as a flag to the existing ioctl, or > as a new ioctl. I would vote for the former. In fact, it could be merged with (c) below, i.e. ioctl extended to allow application fill in a dimension of a rectangular window that it want to grab, so for example, specifying 80x24 for 80x24 text mode will give you current content of the terminal, while 80x25 - current content of the terminal plus one line from the history buffer and so on. This would prevent unnecessary API cluter. > (b) CONS_GETINFO will need to be extended (or we need a new ioctl for > the scrollback) to include information about how big the scrollback > buffer is. I am voting for extending. We already have quite large number of syscons specific ioctls and probably don't really need a new one in this case. I also would like to extend information returned by this ioctl to include information about font size used by the current video mode, which AFAIK currently is not possible to get from userland. Perhaps we could co-ordinate somehow to minimise cosequences of ABI breakage. > (c) It might be worth providing a mechanism to let the application > specify a rectangular window that it wants to grab from the buffer. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 20 14:32:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 7BB5C37B424; Sun, 20 May 2001 14:32:44 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id f4KLQ7N29751; Sun, 20 May 2001 22:26:07 +0100 (BST) (envelope-from nik) Date: Sun, 20 May 2001 22:26:07 +0100 From: Nik Clayton To: Nik Clayton Cc: sobomax@FreeBSD.ORG, ru@FreeBSD.ORG, audit@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Integrating new scrshot(1) utility into vidcontrol(1) [patch for review] Message-ID: <20010520222607.A29709@catkin.nothing-going-on.org> References: <20010519194435.A22224@catkin.nothing-going-on.org> <200105191939.f4JJdjr00870@mail.uic-in.net> <20010520140747.B25841@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010520140747.B25841@catkin.nothing-going-on.org>; from nik@freebsd.org on Sun, May 20, 2001 at 02:07:47PM +0100 Organization: FreeBSD Project 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 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 20, 2001 at 02:07:47PM +0100, Nik Clayton wrote: > Shouldn't be too hard.=20 I forgot one. (d) It should be documented. Unless I'm missing something, the=20 syscons ioctls aren't documented anywhere except the source code. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsINm0ACgkQk6gHZCw343Wm5QCbBdh2aQsa2STawBolb85uO5JQ dzEAnAkihwF71HXz75O+MMIgMucNdUEG =jhoT -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 20 17:52:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-32.dsl.lsan03.pacbell.net [63.207.60.32]) by hub.freebsd.org (Postfix) with ESMTP id E99CC37B422; Sun, 20 May 2001 17:52:29 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 73AB566E1D; Sun, 20 May 2001 17:52:29 -0700 (PDT) Date: Sun, 20 May 2001 17:52:29 -0700 From: Kris Kennaway To: Greg Lehey Cc: arch@FreeBSD.ORG, Ruslan Ermilov Subject: Re: Compiler-neutral warning flags Message-ID: <20010520175229.B39141@xor.obsecurity.org> References: <200105181040.f4IAeYi56574@freefall.freebsd.org> <20010519111635.I7513@wantadilla.lemis.com> <20010518191949.A2362@xor.obsecurity.org> <20010519124613.C64759@wantadilla.lemis.com> <20010518203024.A20917@xor.obsecurity.org> <20010519132658.H64759@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010519132658.H64759@wantadilla.lemis.com>; from grog@lemis.com on Sat, May 19, 2001 at 01:26:58PM +0930 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 --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 19, 2001 at 01:26:58PM +0930, Greg Lehey wrote: > > We don't have a compiler-neutral way to do this. > > > > It would be great to be able to turn on -Werror and -Wall when > > building with gcc, as various parts of the tree get clean, to prevent > > the introduction of new warnings. >=20 > Have I missed more than I thought? Are we contemplating using a > different compiler? That would make it more reasonable. No, but we shouldn't make it harder to do that. GCC-isms should be abstracted into things which can easily be turned off when you want to try building with a different compiler. Kris P.S. Your mailer seemed to ignore the reply-to I set on this email. The goal was to shift discussion off of the CVS lists where it doesn't belong. --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7CGbMWry0BWjoQKURAji5AKCQhKcpIDEHkwiNVjZDRrNmmU3u4wCeIXut Ekg4XzFQkhB8AG/uxWMWb6o= =xT8m -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 21 8:42: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 1385437B424; Mon, 21 May 2001 08:41:42 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4LFfck20097; Mon, 21 May 2001 18:41:38 +0300 (EEST) (envelope-from ru) Date: Mon, 21 May 2001 18:41:38 +0300 From: Ruslan Ermilov To: arch@FreeBSD.org, fs@FreeBSD.org Cc: Boris Popov Subject: [CFR] /sys/miscfs/* -> /sys/fs/ Message-ID: <20010521184138.A19159@sunbay.com> Mail-Followup-To: arch@FreeBSD.org, fs@FreeBSD.org, Boris Popov 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! The below patch moves /sys/miscfs/* to /sys/fs. Also, it installs missing headers to /usr/include and removes explicit -I${.CURDIR}/../../sys lines from various Makefiles. For testers: the patch assumes that the repo-copy of /sys/miscfs/* to /sys/fs has already been made, so you will also need to (cd /sys; mv miscfs/* fs) before applying the patch. The patch is available from here: http://www.FreeBSD.org/~ru/miscfs2fs.patch Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 21 9:12:30 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 704FB37B422; Mon, 21 May 2001 09:12:23 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4LGCEL60130; Mon, 21 May 2001 18:12:14 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Ruslan Ermilov Cc: arch@FreeBSD.ORG, fs@FreeBSD.ORG, Boris Popov Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ In-Reply-To: Your message of "Mon, 21 May 2001 18:41:38 +0300." <20010521184138.A19159@sunbay.com> Date: Mon, 21 May 2001 18:12:14 +0200 Message-ID: <60128.990461534@critter> 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 <20010521184138.A19159@sunbay.com>, Ruslan Ermilov writes: >Hi! > >The below patch moves /sys/miscfs/* to /sys/fs. >Also, it installs missing headers to /usr/include >and removes explicit -I${.CURDIR}/../../sys lines >from various Makefiles. Yes! Rather sooner than later! -- 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 Mon May 21 10:28: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id DCF0937B422; Mon, 21 May 2001 10:27:59 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f4LHRxr01636; Mon, 21 May 2001 10:27:59 -0700 (PDT) (envelope-from dillon) Date: Mon, 21 May 2001 10:27:59 -0700 (PDT) From: Matt Dillon Message-Id: <200105211727.f4LHRxr01636@earth.backplane.com> To: Nik Clayton Cc: Tor.Egge@fast.no, arch@freebsd.org Subject: Re: Final O_DIRECT patch (first stage, without rawread/rawwrite) References: <200105162222.f4GMMpC81247@earth.backplane.com> <200105162331.BAA04708@midten.fast.no> <200105180440.f4I4eiB05429@earth.backplane.com> <20010518090956.A10344@catkin.nothing-going-on.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 : :On Thu, May 17, 2001 at 09:40:44PM -0700, Matt Dillon wrote: :> The patch below is for -stable. I will continue testing it on stable :> through the weekend. I'll probably commit the -current version on the :> weekend and the stable version the weekend after. : :Man page update? : :N Yah, will do. I didn't have time this weekend to get it into -current, I ran out of time trying to ugprade a -stable test box to test it under -current. I hope to get to it today or tomorrow. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 21 11:11:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 88FE737B422; Mon, 21 May 2001 11:11:44 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f4LIBdG45356; Mon, 21 May 2001 11:11:39 -0700 (PDT) (envelope-from jhb@FreeBSD.org) 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: <20010521184138.A19159@sunbay.com> Date: Mon, 21 May 2001 11:11:45 -0700 (PDT) From: John Baldwin To: Ruslan Ermilov Subject: RE: [CFR] /sys/miscfs/* -> /sys/fs/ Cc: Boris Popov , fs@FreeBSD.org, arch@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 On 21-May-01 Ruslan Ermilov wrote: > Hi! > > The below patch moves /sys/miscfs/* to /sys/fs. > Also, it installs missing headers to /usr/include > and removes explicit -I${.CURDIR}/../../sys lines > from various Makefiles. > > For testers: the patch assumes that the repo-copy > of /sys/miscfs/* to /sys/fs has already been made, > so you will also need to (cd /sys; mv miscfs/* fs) > before applying the patch. > > The patch is available from here: > > http://www.FreeBSD.org/~ru/miscfs2fs.patch I'm hoping it follows http://www.FreeBSD.org/~jhb/docs/sysorg.txt? Note that to be consistent in the naming scheme, I have portal -> portalfs, fdesc -> fdescfs, and union -> unionfs. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Mon May 21 11:18:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 8AFBE37B43C; Mon, 21 May 2001 11:18:18 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id LAA12849; Mon, 21 May 2001 11:18:17 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200105211818.LAA12849@beastie.mckusick.com> To: Ruslan Ermilov Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ Cc: Boris Popov , fs@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: Your message of "Mon, 21 May 2001 11:11:45 PDT." Date: Mon, 21 May 2001 11:18:17 -0700 From: Kirk McKusick 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 agree that this change is appropriate. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 21 18:54:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id C9D5B37B422; Mon, 21 May 2001 18:54:44 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id A9F1F28CBB; Tue, 22 May 2001 08:54:38 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 4F2CD28CBA; Tue, 22 May 2001 08:54:38 +0700 (ALMST) Date: Tue, 22 May 2001 08:54:38 +0700 (ALMST) From: Boris Popov To: Ruslan Ermilov Cc: arch@FreeBSD.org, fs@FreeBSD.org Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ In-Reply-To: <20010521184138.A19159@sunbay.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 Mon, 21 May 2001, Ruslan Ermilov wrote: > The below patch moves /sys/miscfs/* to /sys/fs. Sounds good. nwfs, ntfs and msdosfs also can be safely moved under fs/ hierarchy. Not sure about the rest. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 2:45:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from shutdown.com (adsl-151-202-29-28.nyc.adsl.bellatlantic.net [151.202.29.28]) by hub.freebsd.org (Postfix) with SMTP id 257E937B43F for ; Tue, 22 May 2001 02:45:32 -0700 (PDT) (envelope-from j@shutdown.com) From: "John" To: Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 22 May 2001 04:24:49 -0700 Reply-To: "John" Content-Transfer-Encoding: 8bit Message-Id: <20010522094532.257E937B43F@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 Hey there, I found a great retail site with all kinds of products. Home decor, office decor, travel, outdoors, kitchen, etc... Take a look around at http://www.merchandisewholesale.com just click on the images of the product to enlarge it for a better view. Sincerely, John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 2:59: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by hub.freebsd.org (Postfix) with ESMTP id 5FD5E37B422; Tue, 22 May 2001 02:58:57 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (pool0077.cvx21-bradley.dialup.earthlink.net [209.179.192.77]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id FAA29245; Tue, 22 May 2001 05:58:49 -0400 (EDT) Message-ID: <3B0A3871.1BA0C0DB@mindspring.com> Date: Tue, 22 May 2001 02:59:13 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Youse Cc: Terry Lambert , Peter Pentchev , Ruslan Ermilov , Nik Clayton , arch@FreeBSD.ORG Subject: Re: [PATCH] syscons ioctl() to grab text mode buffer 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 Chuck Youse wrote: > > On a practical note, the code generated merely inverts the sense > > of the same cmpl at default optimization, and at -O2 ends up being > > either: > > > > testl %eax,%eax > > jge .L3 > > > > or: > > > > cmpl $-1,%eax > > jne .L3 > > > > So the number of instruction cycles is identical. Off the top of > > Well, the second sequence is longer by a byte. I don't have the data > sheets handy, it probably also takes another cycle as it involves an > immediate operand sign-extended to 32-bits instead of just a > register-register compare. > > Just nitpicking If we want to nitpick, we should probably generate the same test cases for the Alpha... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 4:48:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8E21637B422; Tue, 22 May 2001 04:48:03 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA17467; Tue, 22 May 2001 21:48:01 +1000 Date: Tue, 22 May 2001 21:46:34 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Ruslan Ermilov , Boris Popov , fs@FreeBSD.ORG, arch@FreeBSD.ORG Subject: RE: [CFR] /sys/miscfs/* -> /sys/fs/ 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 Mon, 21 May 2001, John Baldwin wrote: > On 21-May-01 Ruslan Ermilov wrote: > > The below patch moves /sys/miscfs/* to /sys/fs. > > ... > > The patch is available from here: > > > > http://www.FreeBSD.org/~ru/miscfs2fs.patch > > I'm hoping it follows http://www.FreeBSD.org/~jhb/docs/sysorg.txt? > > Note that to be consistent in the naming scheme, I have portal -> portalfs, > fdesc -> fdescfs, and union -> unionfs. This would be bogus unless the filesystems are also renamed. Many filesystem names don't end in "fs": $ ls /sbin/mount_* /sbin/mount_cd9660 /sbin/mount_devfs /sbin/mount_ext2fs /sbin/mount_fdesc /sbin/mount_ifs /sbin/mount_linprocfs /sbin/mount_mfs /sbin/mount_msdos /sbin/mount_nfs /sbin/mount_ntfs /sbin/mount_null /sbin/mount_nwfs /sbin/mount_portal /sbin/mount_procfs /sbin/mount_std /sbin/mount_umap /sbin/mount_union nullfs and umapfs are already bogusly named. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 4:51:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7E8D637B42C; Tue, 22 May 2001 04:51:10 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA17586; Tue, 22 May 2001 21:49:15 +1000 Date: Tue, 22 May 2001 21:47:48 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Boris Popov Cc: Ruslan Ermilov , arch@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ 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 Tue, 22 May 2001, Boris Popov wrote: > On Mon, 21 May 2001, Ruslan Ermilov wrote: > > > The below patch moves /sys/miscfs/* to /sys/fs. > > Sounds good. nwfs, ntfs and msdosfs also can be safely moved under > fs/ hierarchy. Not sure about the rest. ext2fs would go in fs/gnu/ext2fs (or is it gnu/fs/ext2fs?). Ugh. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 5:26:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 0450137B42C; Tue, 22 May 2001 05:26:37 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f4MCQaK45095; Tue, 22 May 2001 05:26:36 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f4MCQZJ41755; Tue, 22 May 2001 05:26:35 -0700 (PDT) (envelope-from jhb) 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: Tue, 22 May 2001 05:26:35 -0700 (PDT) From: John Baldwin To: Bruce Evans Subject: RE: [CFR] /sys/miscfs/* -> /sys/fs/ Cc: arch@FreeBSD.ORG, fs@FreeBSD.ORG, Boris Popov , Ruslan Ermilov 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-May-01 Bruce Evans wrote: > On Mon, 21 May 2001, John Baldwin wrote: > >> On 21-May-01 Ruslan Ermilov wrote: >> > The below patch moves /sys/miscfs/* to /sys/fs. >> > ... >> > The patch is available from here: >> > >> > http://www.FreeBSD.org/~ru/miscfs2fs.patch >> >> I'm hoping it follows http://www.FreeBSD.org/~jhb/docs/sysorg.txt? >> >> Note that to be consistent in the naming scheme, I have portal -> portalfs, >> fdesc -> fdescfs, and union -> unionfs. > > This would be bogus unless the filesystems are also renamed. Many filesystem > names don't end in "fs": > > $ ls /sbin/mount_* > /sbin/mount_cd9660 > /sbin/mount_devfs > /sbin/mount_ext2fs > /sbin/mount_fdesc > /sbin/mount_ifs > /sbin/mount_linprocfs > /sbin/mount_mfs > /sbin/mount_msdos > /sbin/mount_nfs > /sbin/mount_ntfs > /sbin/mount_null > /sbin/mount_nwfs > /sbin/mount_portal > /sbin/mount_procfs > /sbin/mount_std > /sbin/mount_umap > /sbin/mount_union > > nullfs and umapfs are already bogusly named. Consistency would be nice. :) I agree that the filesystem names need to be the same everywhere: mount_*, fsck_*, *.ko, sys/modules/* sys/fs/*. > Bruce -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "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 Tue May 22 6:27:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 8C2DA37B424; Tue, 22 May 2001 06:27:34 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4MDRO808142; Tue, 22 May 2001 16:27:24 +0300 (EEST) (envelope-from ru) Date: Tue, 22 May 2001 16:27:24 +0300 From: Ruslan Ermilov To: John Baldwin Cc: Bruce Evans , arch@FreeBSD.ORG, fs@FreeBSD.ORG, Boris Popov Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ Message-ID: <20010522162724.C99517@sunbay.com> Mail-Followup-To: John Baldwin , Bruce Evans , arch@FreeBSD.ORG, fs@FreeBSD.ORG, Boris Popov 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 jhb@FreeBSD.ORG on Tue, May 22, 2001 at 05:26:35AM -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 On Tue, May 22, 2001 at 05:26:35AM -0700, John Baldwin wrote: > > On 22-May-01 Bruce Evans wrote: > > On Mon, 21 May 2001, John Baldwin wrote: > > > >> On 21-May-01 Ruslan Ermilov wrote: > >> > The below patch moves /sys/miscfs/* to /sys/fs. > >> > ... > >> > The patch is available from here: > >> > > >> > http://www.FreeBSD.org/~ru/miscfs2fs.patch > >> > >> I'm hoping it follows http://www.FreeBSD.org/~jhb/docs/sysorg.txt? > >> > >> Note that to be consistent in the naming scheme, I have portal -> portalfs, > >> fdesc -> fdescfs, and union -> unionfs. > > > > This would be bogus unless the filesystems are also renamed. Many filesystem > > names don't end in "fs": > > > > $ ls /sbin/mount_* > > /sbin/mount_cd9660 > > /sbin/mount_devfs > > /sbin/mount_ext2fs > > /sbin/mount_fdesc > > /sbin/mount_ifs > > /sbin/mount_linprocfs > > /sbin/mount_mfs > > /sbin/mount_msdos > > /sbin/mount_nfs > > /sbin/mount_ntfs > > /sbin/mount_null > > /sbin/mount_nwfs > > /sbin/mount_portal > > /sbin/mount_procfs > > /sbin/mount_std > > /sbin/mount_umap > > /sbin/mount_union > > > > nullfs and umapfs are already bogusly named. > > Consistency would be nice. :) I agree that the filesystem names need to be the > same everywhere: mount_*, fsck_*, *.ko, sys/modules/* sys/fs/*. > Except for mount_* please. Doing this would break people's fstab(5)'s. I've implemented the rest. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 8:32: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 3CD2F37B424; Tue, 22 May 2001 08:32:03 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@[206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f4MFVwl09032; Tue, 22 May 2001 08:31:59 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f4MFVvK48159; Tue, 22 May 2001 08:31:57 -0700 (PDT) (envelope-from obrien) Date: Tue, 22 May 2001 08:31:57 -0700 From: "David O'Brien - Arch" To: Bruce Evans Cc: Boris Popov , Ruslan Ermilov , arch@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ Message-ID: <20010522083156.A48074@dragon.nuxi.com> Reply-To: arch@FreeBSD.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 bde@zeta.org.au on Tue, May 22, 2001 at 09:47:48PM +1000 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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, May 22, 2001 at 09:47:48PM +1000, Bruce Evans wrote: > > Sounds good. nwfs, ntfs and msdosfs also can be safely moved under > > fs/ hierarchy. Not sure about the rest. > > ext2fs would go in fs/gnu/ext2fs (or is it gnu/fs/ext2fs?). Ugh. Should be sys/gnu. We don't want people having to search all over the place for the GPVed code if they need to dike all of it out for there use. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 11: 5:39 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 8D54837B42C; Tue, 22 May 2001 11:05:34 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4MI4mL71131; Tue, 22 May 2001 20:04:48 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: Boris Popov , Ruslan Ermilov , arch@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ In-Reply-To: Your message of "Tue, 22 May 2001 21:47:48 +1000." Date: Tue, 22 May 2001 20:04:48 +0200 Message-ID: <71129.990554688@critter> 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 , Bruce Ev ans writes: >On Tue, 22 May 2001, Boris Popov wrote: > >> On Mon, 21 May 2001, Ruslan Ermilov wrote: >> >> > The below patch moves /sys/miscfs/* to /sys/fs. >> >> Sounds good. nwfs, ntfs and msdosfs also can be safely moved under >> fs/ hierarchy. Not sure about the rest. > >ext2fs would go in fs/gnu/ext2fs (or is it gnu/fs/ext2fs?). Ugh. it would be src/sys/gnu/fs/ext2fs or src/sys/contrib/fs/ext2fs -- 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 Tue May 22 11:43: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id A5DE337B422 for ; Tue, 22 May 2001 11:42:54 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4MIgrY03521 for ; Tue, 22 May 2001 19:42:53 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4MIgqb84117; Tue, 22 May 2001 19:42:52 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105221842.f4MIgqb84117@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: freebsd-arch@FreeBSD.org Cc: Brian Somers Subject: RFC: unit_list routines Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 May 2001 19:42:52 +0100 From: Brian Somers 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 want to change if_tun.c so that userland can open /dev/tun and get back a /dev/tunX device. To do this, I need to track the units that have (or haven't) been opened, and I figure other devices may wish to do this too. To this end, I've written the attached URLs for /sys/kern/unit_list.c /sys/sys/unit_list.h and have also attached URLs for patches to /sys/conf/files and /sys/net/if_tun.c. The unit_list stuff is designed to be an easy way of tracking sparce arrays of units - arrays that are generally expected to start at zero and increment, but may sometimes be allocated randomly. I haven't tested as extensively as I plan to because my dev box is useless at the moment due to mutex problems, but I believe it works :) I ansified if_tun.c while I was there - sorry if that complicates any reviews :-/ Comments ? ftp://ftp.Awfulhak.org/pub/unit_list/sys-kern-unit_list.c ftp://ftp.Awfulhak.org/pub/unit_list/sys-sys-unit_list.h ftp://ftp.Awfulhak.org/pub/unit_list/sys-conf-files.patch ftp://ftp.Awfulhak.org/pub/unit_list/sys-net-if_tun.c.patch Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 12: 5:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id ACAF437B42C for ; Tue, 22 May 2001 12:05:34 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA20698; Tue, 22 May 2001 15:05:27 -0400 (EDT) (envelope-from wollman) Date: Tue, 22 May 2001 15:05:27 -0400 (EDT) From: Garrett Wollman Message-Id: <200105221905.PAA20698@khavrinen.lcs.mit.edu> To: brian@Awfulhak.org Cc: arch@freebsd.org Subject: Re: RFC: unit_list routines In-Reply-To: <200105221842.f4MIgqb84117@hak.lan.Awfulhak.org> Organization: MIT Laboratory for Computer Science Cc: 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 <200105221842.f4MIgqb84117@hak.lan.Awfulhak.org> Brian Somers writes: >The unit_list stuff is designed to be an easy way of tracking sparce >arrays of units - arrays that are generally expected to start at zero >and increment, but may sometimes be allocated randomly. The resource manager code was designed to do precisely that, and already exists. It may have gotten too entwined with the bus stuff, though, but it was certainly my intent that you should be able to use it for this purpose. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 12:16:10 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 8F1BB37B422 for ; Tue, 22 May 2001 12:16:04 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4MJFrL72213; Tue, 22 May 2001 21:15:53 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: Your message of "Tue, 22 May 2001 19:42:52 BST." <200105221842.f4MIgqb84117@hak.lan.Awfulhak.org> Date: Tue, 22 May 2001 21:15:53 +0200 Message-ID: <72211.990558953@critter> 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 Hi Brian, Couldn't the resource manager used for interrupts and similar do this as well ? In message <200105221842.f4MIgqb84117@hak.lan.Awfulhak.org>, Brian Somers write s: >Hi, > >I want to change if_tun.c so that userland can open /dev/tun and get >back a /dev/tunX device. To do this, I need to track the units that >have (or haven't) been opened, and I figure other devices may wish to >do this too. > >To this end, I've written the attached URLs for > > /sys/kern/unit_list.c > /sys/sys/unit_list.h > >and have also attached URLs for patches to /sys/conf/files and >/sys/net/if_tun.c. > >The unit_list stuff is designed to be an easy way of tracking sparce >arrays of units - arrays that are generally expected to start at zero >and increment, but may sometimes be allocated randomly. > >I haven't tested as extensively as I plan to because my dev box is >useless at the moment due to mutex problems, but I believe it works :) > >I ansified if_tun.c while I was there - sorry if that complicates any >reviews :-/ > >Comments ? > > ftp://ftp.Awfulhak.org/pub/unit_list/sys-kern-unit_list.c > ftp://ftp.Awfulhak.org/pub/unit_list/sys-sys-unit_list.h > ftp://ftp.Awfulhak.org/pub/unit_list/sys-conf-files.patch > ftp://ftp.Awfulhak.org/pub/unit_list/sys-net-if_tun.c.patch > >Cheers. >-- >Brian > >Don't _EVER_ lose your sense of humour ! > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-arch" in the body of the message > -- 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 Tue May 22 16: 3:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id D2DF337B618 for ; Tue, 22 May 2001 16:03:44 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id A99E76ACBC; Wed, 23 May 2001 08:33:42 +0930 (CST) Date: Wed, 23 May 2001 08:33:42 +0930 From: Greg Lehey To: arch@FreeBSD.org Subject: Re: Re: http://uptime.netcraft.com/up/accuracy.html#cycle Message-ID: <20010523083342.E41189@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF 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 Comments? Greg ----- Forwarded message from Richard Wendland ----- > Date: Tue, 22 May 2001 21:51:02 +0100 (BST) > From: Richard Wendland > To: grog@FreeBSD.org (Greg Lehey) > Cc: webmaster@netcraft.com > Subject: Re: http://uptime.netcraft.com/up/accuracy.html#cycle > X-Mailer: ELM [version 2.5 PL2] > >> At this link, you claim: >> >> Additionally HP-UX, Linux, Solaris and recent releases of FreeBSD >> cycle back to zero after 497 days, exactly as if the machine had >> been rebooted at that precise point. Thus it is not possible to see >> a HP-UX, Linux or Solaris system with an uptime measurement above >> 497 days. >> >> FreeBSD does not suffer from this problem. You'll notice that you >> have a large number of FreeBSD systems with uptimes of over 497 days. >> I'd appreciate if you would correct this statement. > > Hi Greg, > > I think that statement is accurate. Note that we're not talking about > the FreeBSD 'uptime' command, but our ability to ascertain uptime remotely > by decoding the TCP timestamp option. > > Prior to FreeBSD 3 the TCP timestamp option was incremented every 500ms, > as is traditional with BSD. From FreeBSD 3 it was incremented every > 10ms, presumably to improve RTT measurement. But it does have the > consequence that the 32-bit TCP timestamp wraps around at 497.1 days. > Hence, with our current method at least, we don't detect uptimes above > this for FreeBSD 3 and later. > > So the FreeBSD systems listed > 497 days are running FreeBSD 2. > Once everyone has upgraded from FreeBSD 2, FreeBSD will no longer get > in that top uptimes list! > >> I also have been told that the Linux 2.4 kernel no longer suffers from >> this problem, but I can't confirm this information. > > Yep, as I understand it at one time the Linux 'uptime' command would wrap > at 497.1 days; presumably because the kernel stored uptime in 10ms units > in 32-bits. That was fixed, but our remote uptime detection would still > suffer this problem. It explains why no Linux (nor Solaris or HP-UX) > systems are in that list. > > Richard > -- > Richard Wendland richard@netcraft.com ----- End forwarded message ----- -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 17:38:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 1893037B422 for ; Tue, 22 May 2001 17:38:13 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4N0cBY05551; Wed, 23 May 2001 01:38:11 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4N0cAb12470; Wed, 23 May 2001 01:38:10 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105230038.f4N0cAb12470@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Poul-Henning Kamp , Garrett Wollman Cc: Brian Somers , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Poul-Henning Kamp of "Tue, 22 May 2001 21:15:53 +0200." <72211.990558953@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 01:38:09 +0100 From: Brian Somers 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 phk said: > Hi Brian, > > Couldn't the resource manager used for interrupts and similar > do this as well ? wollman said: > The resource manager code was designed to do precisely that, and > already exists. It may have gotten too entwined with the bus stuff, > though, but it was certainly my intent that you should be able to use > it for this purpose. There doesn't seem to be anything at all suitable there. I assume you (pl.) are referring to the struct resource_list stuff declared in bus.h ? The unit_list is an ordered list of ranges where the count is implicit and a resource id or type field have no meaning. The idea is to be able to allocate and release unit numbers relatively frequently without obfuscating things with redundant information or including odd things such bus hierarchies and unit counts. I can't see any way of deriving the two from any common set of routines either - the resource_list stuff needs a hierarchy by it's nature, and I guess the ``count'' bits are intended (eventually) for handling limited resources such as power - not really applicable to unit allocation. Maybe I'm missing something though ? -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 18:54: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from newsguy.com (smtp.newsguy.com [209.155.56.71]) by hub.freebsd.org (Postfix) with ESMTP id 845B437B422 for ; Tue, 22 May 2001 18:53:58 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (ppp185-bsace7001.telebrasilia.net.br [200.181.80.185]) by newsguy.com (8.11.0/8.9.1) with ESMTP id f4N1qiF11150; Tue, 22 May 2001 18:52:44 -0700 (PDT) Message-ID: <3B0B1816.729E3928@newsguy.com> Date: Tue, 22 May 2001 22:53:26 -0300 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en,pt-BR,pt,en-GB,en-US,ja MIME-Version: 1.0 To: Brian Somers Cc: Poul-Henning Kamp , Garrett Wollman , freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines References: <200105230038.f4N0cAb12470@hak.lan.Awfulhak.org> 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 Brian Somers wrote: > > I can't see any way of deriving the two from any common set of > routines either - the resource_list stuff needs a hierarchy by it's > nature, and I guess the ``count'' bits are intended (eventually) for > handling limited resources such as power - not really applicable to > unit allocation. > > Maybe I'm missing something though ? Isn't what you want precisely what md does (at least on current)? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.secret.bsdconspiracy.net wow regex humor... I'm a geek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 19:23:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 0396837B422 for ; Tue, 22 May 2001 19:23:30 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4N2NTM85186 for ; Tue, 22 May 2001 19:23:29 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id ADF97380A; Tue, 22 May 2001 19:23:29 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Brian Somers Cc: Poul-Henning Kamp , Garrett Wollman , freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: <200105230038.f4N0cAb12470@hak.lan.Awfulhak.org> Date: Tue, 22 May 2001 19:23:29 -0700 From: Peter Wemm Message-Id: <20010523022329.ADF97380A@overcee.netplex.com.au> 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 Brian Somers wrote: > phk said: > > Hi Brian, > > > > Couldn't the resource manager used for interrupts and similar > > do this as well ? > > wollman said: > > The resource manager code was designed to do precisely that, and > > already exists. It may have gotten too entwined with the bus stuff, > > though, but it was certainly my intent that you should be able to use > > it for this purpose. > > There doesn't seem to be anything at all suitable there. I assume > you (pl.) are referring to the struct resource_list stuff declared in > bus.h ? No, kern/subr_rman.c, sys/rman.h. struct resource_list is bus stuff, not rman stuff. > The unit_list is an ordered list of ranges where the count is > implicit and a resource id or type field have no meaning. The idea > is to be able to allocate and release unit numbers relatively > frequently without obfuscating things with redundant information or > including odd things such bus hierarchies and unit counts. That is exactly what the rman stuff is for. > I can't see any way of deriving the two from any common set of > routines either - the resource_list stuff needs a hierarchy by it's > nature, and I guess the ``count'' bits are intended (eventually) for > handling limited resources such as power - not really applicable to > unit allocation. > > Maybe I'm missing something though ? Yes, you're looking at the wrong thing. :-) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 21: 0:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id BA20237B42C; Tue, 22 May 2001 21:00:18 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id EF98628754; Wed, 23 May 2001 11:00:10 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id E6AF22874D; Wed, 23 May 2001 11:00:10 +0700 (ALMST) Date: Wed, 23 May 2001 11:00:10 +0700 (ALMST) From: Boris Popov To: Ruslan Ermilov Cc: John Baldwin , Bruce Evans , arch@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ In-Reply-To: <20010522162724.C99517@sunbay.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, 22 May 2001, Ruslan Ermilov wrote: > > Consistency would be nice. :) I agree that the filesystem names need to be the > > same everywhere: mount_*, fsck_*, *.ko, sys/modules/* sys/fs/*. > > > Except for mount_* please. Doing this would break people's fstab(5)'s. > I've implemented the rest. This will break only cd9660 and msdos entries. Others are rarely used and heads-up will be sufficient. ...(mount_stdfs ? :) -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 22 23:20:37 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 1742E37B42C for ; Tue, 22 May 2001 23:20:33 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4N6K7L78442; Wed, 23 May 2001 08:20:07 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Daniel C. Sobral" Cc: Brian Somers , Garrett Wollman , freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: Your message of "Tue, 22 May 2001 22:53:26 -0300." <3B0B1816.729E3928@newsguy.com> Date: Wed, 23 May 2001 08:20:07 +0200 Message-ID: <78440.990598807@critter> 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 <3B0B1816.729E3928@newsguy.com>, "Daniel C. Sobral" writes: >Brian Somers wrote: >> >> I can't see any way of deriving the two from any common set of >> routines either - the resource_list stuff needs a hierarchy by it's >> nature, and I guess the ``count'' bits are intended (eventually) for >> handling limited resources such as power - not really applicable to >> unit allocation. >> >> Maybe I'm missing something though ? > >Isn't what you want precisely what md does (at least on current)? nope. -- 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 Wed May 23 1:15:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id B150037B424 for ; Wed, 23 May 2001 01:15:45 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4N8FhY08267; Wed, 23 May 2001 09:15:43 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4N8FfC20001; Wed, 23 May 2001 09:15:41 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105230815.f4N8FfC20001@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Peter Wemm Cc: Brian Somers , Poul-Henning Kamp , Garrett Wollman , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Peter Wemm of "Tue, 22 May 2001 19:23:29 PDT." <20010523022329.ADF97380A@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 09:15:41 +0100 From: Brian Somers 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 > > The unit_list is an ordered list of ranges where the count is > > implicit and a resource id or type field have no meaning. The idea > > is to be able to allocate and release unit numbers relatively > > frequently without obfuscating things with redundant information or > > including odd things such bus hierarchies and unit counts. > > That is exactly what the rman stuff is for. The rman stuff seems to be overkill: o It uses a global mutex when allocating resources. o It has a local mutex for waiting on resources (and an RF_ACTIVE flag). o It supports RF_SHARABLE/RF_TIMESHARE resources (I guess this isn't an overhead, just unnecessary). o It's implemented in terms of ``struct resource *''s, most of which inappropriate. o It mucks about with device structs when reserving resources unit_list just concerns itself with allocating a bunch of int ranges. Do you really think it's appropriate to try to re-use the rman stuff for what I want to do ? > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > "All of this is for nothing if we don't go to the stars" - JMS/B5 -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 1:50:41 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 AD65137B424 for ; Wed, 23 May 2001 01:50:37 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4N8oKL79942; Wed, 23 May 2001 10:50:20 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: Peter Wemm , Garrett Wollman , freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: Your message of "Wed, 23 May 2001 09:15:41 BST." <200105230815.f4N8FfC20001@hak.lan.Awfulhak.org> Date: Wed, 23 May 2001 10:50:20 +0200 Message-ID: <79940.990607820@critter> 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 <200105230815.f4N8FfC20001@hak.lan.Awfulhak.org>, Brian Somers write s: >The rman stuff seems to be overkill: > >unit_list just concerns itself with allocating a bunch of int ranges. > >Do you really think it's appropriate to try to re-use the rman stuff >for what I want to do ? If using rman means less readable code more arcane magic parameters larger binaries Then the answer is no... -- 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 Wed May 23 2:21:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id A319F37B42C; Wed, 23 May 2001 02:21:32 -0700 (PDT) (envelope-from sheldonh@uunet.co.za) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 152UpW-0002Kw-00; Wed, 23 May 2001 11:21:22 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id LAA05656; Wed, 23 May 2001 11:21:14 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 5428; Wed May 23 11:20:05 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.22 #1) id 152UoG-0009d4-00; Wed, 23 May 2001 11:20:04 +0200 To: Poul-Henning Kamp Cc: Bruce Evans , Boris Popov , Ruslan Ermilov , arch@freebsd.org, fs@freebsd.org Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ In-reply-to: Your message of "Tue, 22 May 2001 20:04:48 +0200." <71129.990554688@critter> Date: Wed, 23 May 2001 11:20:04 +0200 Message-ID: <37017.990609604@axl.fw.uunet.co.za> From: Sheldon Hearn 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, 22 May 2001 20:04:48 +0200, Poul-Henning Kamp wrote: > >ext2fs would go in fs/gnu/ext2fs (or is it gnu/fs/ext2fs?). Ugh. > > it would be src/sys/gnu/fs/ext2fs or src/sys/contrib/fs/ext2fs Is it feasible to keep this consistent with userland by putting the source in src/sys/contrib and the build infrastructure in src/sys/gnu? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 2:45: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 173D437B424; Wed, 23 May 2001 02:45:03 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA09799; Wed, 23 May 2001 19:45:00 +1000 Date: Wed, 23 May 2001 19:43:32 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Greg Lehey Cc: arch@FreeBSD.ORG Subject: Re: Re: http://uptime.netcraft.com/up/accuracy.html#cycle In-Reply-To: <20010523083342.E41189@wantadilla.lemis.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 Wed, 23 May 2001, Greg Lehey wrote: > Comments? > > Greg > > ----- Forwarded message from Richard Wendland ----- > > > Date: Tue, 22 May 2001 21:51:02 +0100 (BST) > > From: Richard Wendland > > To: grog@FreeBSD.org (Greg Lehey) > > Cc: webmaster@netcraft.com > > Subject: Re: http://uptime.netcraft.com/up/accuracy.html#cycle > > X-Mailer: ELM [version 2.5 PL2] > > > >> At this link, you claim: > >> > >> Additionally HP-UX, Linux, Solaris and recent releases of FreeBSD > >> cycle back to zero after 497 days, exactly as if the machine had > >> been rebooted at that precise point. Thus it is not possible to see > >> a HP-UX, Linux or Solaris system with an uptime measurement above > >> 497 days. > >> > >> FreeBSD does not suffer from this problem. You'll notice that you > >> have a large number of FreeBSD systems with uptimes of over 497 days. > >> I'd appreciate if you would correct this statement. > > > > Hi Greg, > > > > I think that statement is accurate. Note that we're not talking about > > the FreeBSD 'uptime' command, but our ability to ascertain uptime remotely > > by decoding the TCP timestamp option. > > > > Prior to FreeBSD 3 the TCP timestamp option was incremented every 500ms, > > as is traditional with BSD. From FreeBSD 3 it was incremented every > > 10ms, presumably to improve RTT measurement. But it does have the > > consequence that the 32-bit TCP timestamp wraps around at 497.1 days. > > Hence, with our current method at least, we don't detect uptimes above > > this for FreeBSD 3 and later. > > > > So the FreeBSD systems listed > 497 days are running FreeBSD 2. > > Once everyone has upgraded from FreeBSD 2, FreeBSD will no longer get > > in that top uptimes list! The TCP timestamp is actually incremented every 1/hz seconds, so it overflows after every 48.5 days on alphas (and on i386's with "options HZ=1024"). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 5:55:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id B15E737B422; Wed, 23 May 2001 05:55:43 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA24838; Wed, 23 May 2001 22:51:55 +1000 Date: Wed, 23 May 2001 22:50:27 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Sheldon Hearn Cc: Poul-Henning Kamp , Boris Popov , Ruslan Ermilov , arch@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ In-Reply-To: <37017.990609604@axl.fw.uunet.co.za> 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, 23 May 2001, Sheldon Hearn wrote: > On Tue, 22 May 2001 20:04:48 +0200, Poul-Henning Kamp wrote: > > > >ext2fs would go in fs/gnu/ext2fs (or is it gnu/fs/ext2fs?). Ugh. > > > > it would be src/sys/gnu/fs/ext2fs or src/sys/contrib/fs/ext2fs s/Ugh/Bletch/g > Is it feasible to keep this consistent with userland by putting the > source in src/sys/contrib and the build infrastructure in src/sys/gnu? No. ext2fs is not contrib'ed. (It's only 30% GPL'ed too, except the GPL makes in all GPL'ed.) Userland at least installs things in reasonable places, so that there is no /usr/include/contrib (or is it /usr/contrib/include?). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 8:17:34 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 65B5D37B422 for ; Wed, 23 May 2001 08:17:32 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f4NFPMq00934; Wed, 23 May 2001 08:25:22 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200105231525.f4NFPMq00934@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-reply-to: Your message of "Wed, 23 May 2001 09:15:41 BST." <200105230815.f4N8FfC20001@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 08:25:22 -0700 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 > unit_list just concerns itself with allocating a bunch of int ranges. > > Do you really think it's appropriate to try to re-use the rman stuff > for what I want to do ? Yes. By all means, wrap the rman interface with something that makes it clearer what you're doing, but if you're managing a finite set of resources of some sort, you should avoid reinventing the wheel where possible. (It's not clear yet whether any of the items on your list actually relate to tangible performance penalties, about the only good reason to consider NIH.) -- ... 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 May 23 8:23:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 0DA6037B42C for ; Wed, 23 May 2001 08:23:44 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA29635; Wed, 23 May 2001 11:23:32 -0400 (EDT) (envelope-from wollman) Date: Wed, 23 May 2001 11:23:32 -0400 (EDT) From: Garrett Wollman Message-Id: <200105231523.LAA29635@khavrinen.lcs.mit.edu> To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: <200105230815.f4N8FfC20001@hak.lan.Awfulhak.org> References: <20010523022329.ADF97380A@overcee.netplex.com.au> <200105230815.f4N8FfC20001@hak.lan.Awfulhak.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 < said: > The rman stuff seems to be overkill: > o It uses a global mutex when allocating resources. ...which you can ignore... > o It has a local mutex for waiting on resources (and an RF_ACTIVE flag). ...which you can also ignore... > o It supports RF_SHARABLE/RF_TIMESHARE resources (I guess this isn't > an overhead, just unnecessary). ...which you can also ignore... > o It's implemented in terms of ``struct resource *''s, most of which > inappropriate. Inappropriate in what way? > o It mucks about with device structs when reserving resources ...which you can just pass as a null pointer.... > Do you really think it's appropriate to try to re-use the rman stuff > for what I want to do ? Given that the code is already there, and is already compiled into every kernel, and (I hope) already has the bugs worked out, I would suggest that it would not be a bad thing. OTOH, if all you are doing is keeping an array of one-bit flags, and having an arbitrarily-large upper limit on the number of devices is acceptable, it's probably cheaper to just do it with a few macros. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 8:53:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 4FC7B37B423 for ; Wed, 23 May 2001 08:53:06 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NFr0Y10931; Wed, 23 May 2001 16:53:00 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NFqwF05688; Wed, 23 May 2001 16:52:58 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105231552.f4NFqwF05688@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Garrett Wollman Cc: Brian Somers , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Garrett Wollman of "Wed, 23 May 2001 11:23:32 EDT." <200105231523.LAA29635@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 16:52:58 +0100 From: Brian Somers 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 > < said: > > > The rman stuff seems to be overkill: > > > o It uses a global mutex when allocating resources. > > ...which you can ignore... > > > o It has a local mutex for waiting on resources (and an RF_ACTIVE flag). > > ...which you can also ignore... The way I see it, holding and releasing mutexes will introduce contention between consumers that only want to maintain a [completely private] sparce array. > > o It supports RF_SHARABLE/RF_TIMESHARE resources (I guess this isn't > > an overhead, just unnecessary). > > ...which you can also ignore... Yes. It's just memory overhead. > > o It's implemented in terms of ``struct resource *''s, most of which > > inappropriate. > > Inappropriate in what way? Allocating a ``struct resource'' munges a completely separate resource (allocated units) in with all of the existing resources providing contention, obfuscating the intent and providing all sorts of lists and backwards pointers to achieve something that means nothing in the context of these allocated units. > > o It mucks about with device structs when reserving resources > > ...which you can just pass as a null pointer.... Unless DPRINTF is defined. But that could be fixed. > > Do you really think it's appropriate to try to re-use the rman stuff > > for what I want to do ? > > Given that the code is already there, and is already compiled into > every kernel, and (I hope) already has the bugs worked out, I would > suggest that it would not be a bad thing. Hmmm, I would think that the memory and locking overheads outweigh the code size overheads. The unit_list code is simple enough, so I wouldn't think that the possibility of bugs would be a real problem. > OTOH, if all you are doing is keeping an array of one-bit flags, and > having an arbitrarily-large upper limit on the number of devices is > acceptable, it's probably cheaper to just do it with a few macros. I didn't do it that way because the ``usual'' way units are allocated is sequentially. Using bits when there are large numbers of units gets awkward. I figured what was required was something small and simple that would cover the requirements of most/all drivers that need to track their units so that it's easy to find an unused one, and it's easy to allocate/deallocate things. > -GAWollman -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 9: 0:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 2BAA937B424; Wed, 23 May 2001 09:00:35 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NG0XY10981; Wed, 23 May 2001 17:00:33 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NG0VF05877; Wed, 23 May 2001 17:00:31 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105231600.f4NG0VF05877@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Mike Smith Cc: Brian Somers , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Mike Smith of "Wed, 23 May 2001 08:25:22 PDT." <200105231525.f4NFPMq00934@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 17:00:31 +0100 From: Brian Somers 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 > > unit_list just concerns itself with allocating a bunch of int ranges. > > > > Do you really think it's appropriate to try to re-use the rman stuff > > for what I want to do ? > > Yes. By all means, wrap the rman interface with something that makes it > clearer what you're doing, but if you're managing a finite set of > resources of some sort, you should avoid reinventing the wheel where > possible. The way I see it, I need a wheel. rman is a chassis that you can attach a wheel to. I'd rather have my own private wheel as I don't need the tires, inner tubes and all the other stuff that comes with rman :) > (It's not clear yet whether any of the items on your list actually relate > to tangible performance penalties, about the only good reason to consider > NIH.) My real problems are the mutexes (unnecessary contention), the memory overheads (all this extra zero-filled memory) and the obfuscation. > -- > ... 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 -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 9:54:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (beachchick.freebsd.dk [212.242.34.253]) by hub.freebsd.org (Postfix) with ESMTP id BDD3437B423 for ; Wed, 23 May 2001 09:54:45 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4NGsVm03489; Wed, 23 May 2001 18:54:31 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: Garrett Wollman , freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: Your message of "Wed, 23 May 2001 16:52:58 BST." <200105231552.f4NFqwF05688@hak.lan.Awfulhak.org> Date: Wed, 23 May 2001 18:54:31 +0200 Message-ID: <3487.990636871@critter> 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 <200105231552.f4NFqwF05688@hak.lan.Awfulhak.org>, Brian Somers write s: >I didn't do it that way because the ``usual'' way units are allocated >is sequentially. Using bits when there are large numbers of units >gets awkward. I figured what was required was something small and >simple that would cover the requirements of most/all drivers that >need to track their units so that it's easy to find an unused one, >and it's easy to allocate/deallocate things. How does newbus allocate/manage unit numbers ? -- 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 Wed May 23 10: 2:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 63FA137B422 for ; Wed, 23 May 2001 10:02:12 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NH2AY11391; Wed, 23 May 2001 18:02:10 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NH29F07183; Wed, 23 May 2001 18:02:09 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105231702.f4NH29F07183@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: Brian Somers , Garrett Wollman , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Poul-Henning Kamp of "Wed, 23 May 2001 18:54:31 +0200." <3487.990636871@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 18:02:09 +0100 From: Brian Somers 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 <200105231552.f4NFqwF05688@hak.lan.Awfulhak.org>, Brian Somers write > s: > > >I didn't do it that way because the ``usual'' way units are allocated > >is sequentially. Using bits when there are large numbers of units > >gets awkward. I figured what was required was something small and > >simple that would cover the requirements of most/all drivers that > >need to track their units so that it's easy to find an unused one, > >and it's easy to allocate/deallocate things. > > How does newbus allocate/manage unit numbers ? I don't think it does. The only way to find out what's in use (AFAIK) is by looking at every specinfo in dev_hash.... > -- > 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. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 10:11:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 68FB537B422 for ; Wed, 23 May 2001 10:11:54 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA30721; Wed, 23 May 2001 13:11:45 -0400 (EDT) (envelope-from wollman) Date: Wed, 23 May 2001 13:11:45 -0400 (EDT) From: Garrett Wollman Message-Id: <200105231711.NAA30721@khavrinen.lcs.mit.edu> To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: <200105231552.f4NFqwF05688@hak.lan.Awfulhak.org> References: <200105231523.LAA29635@khavrinen.lcs.mit.edu> <200105231552.f4NFqwF05688@hak.lan.Awfulhak.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 < said: > The way I see it, holding and releasing mutexes will introduce > contention between consumers that only want to maintain a [completely > private] sparce array. I think the usual watchword is ``Don't optimize initialization.'' > Allocating a ``struct resource'' munges a completely separate > resource (allocated units) in with all of the existing resources I'm having a bit of difficulty understanding the point you're trying to make here. It's a general interface; you need a subset of that functionality. Your resource is not ``munged [...] in with all of the existing resources'' -- each resource is managed separately, through its rman structure. > of lists and backwards pointers to achieve something that means > nothing in the context of these allocated units. Those lists and backwards pointers are not there for the benefit of clients, and should be treated as opaque. Actually, the whole `struct resource' should be treated as opaque, although because accessors are provided as macros rather than functions it can't be made literally so. > Using bits when there are large numbers of units gets awkward. Just wrap it in macros. I almost posted an implementation with my last message, but decided that since it was so trivial it would be almost insulting for me to do so. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 10:13:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (beachchick.freebsd.dk [212.242.34.253]) by hub.freebsd.org (Postfix) with ESMTP id EE85337B424 for ; Wed, 23 May 2001 10:13:23 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4NHDBm04338; Wed, 23 May 2001 19:13:11 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: Garrett Wollman , freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: Your message of "Wed, 23 May 2001 18:02:09 BST." <200105231702.f4NH29F07183@hak.lan.Awfulhak.org> Date: Wed, 23 May 2001 19:13:11 +0200 Message-ID: <4336.990637991@critter> 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 <200105231702.f4NH29F07183@hak.lan.Awfulhak.org>, Brian Somers write s: >> In message <200105231552.f4NFqwF05688@hak.lan.Awfulhak.org>, Brian Somers write >> s: >> >> >I didn't do it that way because the ``usual'' way units are allocated >> >is sequentially. Using bits when there are large numbers of units >> >gets awkward. I figured what was required was something small and >> >simple that would cover the requirements of most/all drivers that >> >need to track their units so that it's easy to find an unused one, >> >and it's easy to allocate/deallocate things. >> >> How does newbus allocate/manage unit numbers ? > >I don't think it does. The only way to find out what's in use >(AFAIK) is by looking at every specinfo in dev_hash.... newbus shouldn't be f**king around with dev_t's and last I heard it wasn't, so I don't think that is the right answer really... -- 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 Wed May 23 10:16:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 87C7637B43E for ; Wed, 23 May 2001 10:16:20 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA31092; Wed, 23 May 2001 13:16:10 -0400 (EDT) (envelope-from wollman) Date: Wed, 23 May 2001 13:16:10 -0400 (EDT) From: Garrett Wollman Message-Id: <200105231716.NAA31092@khavrinen.lcs.mit.edu> To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: <200105231702.f4NH29F07183@hak.lan.Awfulhak.org> References: <3487.990636871@critter> <200105231702.f4NH29F07183@hak.lan.Awfulhak.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 < said: >> How does newbus allocate/manage unit numbers ? > I don't think it does. The only way to find out what's in use > (AFAIK) is by looking at every specinfo in dev_hash.... You're looking in the wrong place again. This may have changed, but my recollection is that new-bus looks for the greatest allocated unit number and then takes the next one. Since this is initialization code, the fact that this is O(n^2) is of no consequence. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 10:19:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (beachchick.freebsd.dk [212.242.34.253]) by hub.freebsd.org (Postfix) with ESMTP id 4B4A937B422 for ; Wed, 23 May 2001 10:19:21 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4NHJAm09641; Wed, 23 May 2001 19:19:10 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Garrett Wollman Cc: Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: Your message of "Wed, 23 May 2001 13:16:10 EDT." <200105231716.NAA31092@khavrinen.lcs.mit.edu> Date: Wed, 23 May 2001 19:19:10 +0200 Message-ID: <9639.990638350@critter> 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 <200105231716.NAA31092@khavrinen.lcs.mit.edu>, Garrett Wollman write s: >< said: > >>> How does newbus allocate/manage unit numbers ? > >> I don't think it does. The only way to find out what's in use >> (AFAIK) is by looking at every specinfo in dev_hash.... > >You're looking in the wrong place again. > >This may have changed, but my recollection is that new-bus looks for >the greatest allocated unit number and then takes the next one. Since >this is initialization code, the fact that this is O(n^2) is of no >consequence. For pty and tun devices, this assumption may not hold... -- 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 Wed May 23 10:48:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 6F6C237B496 for ; Wed, 23 May 2001 10:48:25 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NHmNY11720; Wed, 23 May 2001 18:48:23 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NHmMF08217; Wed, 23 May 2001 18:48:22 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105231748.f4NHmMF08217@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Garrett Wollman Cc: Brian Somers , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Garrett Wollman of "Wed, 23 May 2001 13:11:45 EDT." <200105231711.NAA30721@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 18:48:22 +0100 From: Brian Somers 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 > < said: > > > The way I see it, holding and releasing mutexes will introduce > > contention between consumers that only want to maintain a [completely > > private] sparce array. > > I think the usual watchword is ``Don't optimize initialization.'' Maybe, but pessimising for no gains seems odd. > > Allocating a ``struct resource'' munges a completely separate > > resource (allocated units) in with all of the existing resources > > I'm having a bit of difficulty understanding the point you're trying > to make here. It's a general interface; you need a subset of that > functionality. Your resource is not ``munged [...] in with all of the > existing resources'' -- each resource is managed separately, through > its rman structure. > > > of lists and backwards pointers to achieve something that means > > nothing in the context of these allocated units. > > Those lists and backwards pointers are not there for the benefit of > clients, and should be treated as opaque. Actually, the whole `struct > resource' should be treated as opaque, although because accessors are > provided as macros rather than functions it can't be made literally > so. But they're required for the benefit of clients - so that they can allocate existing resources, add and remove other resources etc. I want a list of number ranges, not a resource management subsystem that happens to manage number ranges for individual resources in a way that could be bent to my needs. > > Using bits when there are large numbers of units gets awkward. > > Just wrap it in macros. I almost posted an implementation with my > last message, but decided that since it was so trivial it would be > almost insulting for me to do so. Not true - I'm too thick skinned to be insulted :oI I'll look at a macro implementation. > -GAWollman -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 12:44:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 5A94037B423 for ; Wed, 23 May 2001 12:44:36 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NJiYY12182; Wed, 23 May 2001 20:44:34 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NJiXF09637; Wed, 23 May 2001 20:44:33 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105231944.f4NJiXF09637@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Brian Somers Cc: Garrett Wollman , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Brian Somers of "Wed, 23 May 2001 18:48:22 BST." <200105231748.f4NHmMF08217@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 20:44:33 +0100 From: Brian Somers 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 > > > Using bits when there are large numbers of units gets awkward. > > > > Just wrap it in macros. I almost posted an implementation with my > > last message, but decided that since it was so trivial it would be > > almost insulting for me to do so. > > Not true - I'm too thick skinned to be insulted :oI > > I'll look at a macro implementation. Ok, I've thought about this :-/ I don't think it's practical to do this with bits if someone does # ppp -unit 16777215 I then have to go off and allocate an array of 0x7fffff bytes just to record the fact that someone's using a silly unit number. I think this must be done as a sparce set of ranges.... ie, my original idea seems to still stand. Comments ? -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 12:47:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (beachchick.freebsd.dk [212.242.34.253]) by hub.freebsd.org (Postfix) with ESMTP id A07AC37B423 for ; Wed, 23 May 2001 12:47:06 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4NJktm50439; Wed, 23 May 2001 21:46:55 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: Garrett Wollman , freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: Your message of "Wed, 23 May 2001 20:44:33 BST." <200105231944.f4NJiXF09637@hak.lan.Awfulhak.org> Date: Wed, 23 May 2001 21:46:55 +0200 Message-ID: <50437.990647215@critter> 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 <200105231944.f4NJiXF09637@hak.lan.Awfulhak.org>, Brian Somers write s: >> > > Using bits when there are large numbers of units gets awkward. >> > >> > Just wrap it in macros. I almost posted an implementation with my >> > last message, but decided that since it was so trivial it would be >> > almost insulting for me to do so. >> >> Not true - I'm too thick skinned to be insulted :oI >> >> I'll look at a macro implementation. > >Ok, I've thought about this :-/ I don't think it's practical to >do this with bits if someone does > > # ppp -unit 16777215 > >I then have to go off and allocate an array of 0x7fffff bytes just to >record the fact that someone's using a silly unit number. If true, the rman code should have a big "XXX: rewrite" on top of it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 12:48: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 72C4137B424 for ; Wed, 23 May 2001 12:48:00 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA32360; Wed, 23 May 2001 15:47:50 -0400 (EDT) (envelope-from wollman) Date: Wed, 23 May 2001 15:47:50 -0400 (EDT) From: Garrett Wollman Message-Id: <200105231947.PAA32360@khavrinen.lcs.mit.edu> To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: <200105231944.f4NJiXF09637@hak.lan.Awfulhak.org> References: <200105231748.f4NHmMF08217@hak.lan.Awfulhak.org> <200105231944.f4NJiXF09637@hak.lan.Awfulhak.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 < said: > Ok, I've thought about this :-/ I don't think it's practical to > do this with bits if someone does > # ppp -unit 16777215 You then return ERANGE or ENXIO or something of the sort. At some point, you eventually have to say ``no''. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 12:51: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 7B63937B424 for ; Wed, 23 May 2001 12:51:02 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA32383; Wed, 23 May 2001 15:50:51 -0400 (EDT) (envelope-from wollman) Date: Wed, 23 May 2001 15:50:51 -0400 (EDT) From: Garrett Wollman Message-Id: <200105231950.PAA32383@khavrinen.lcs.mit.edu> To: Poul-Henning Kamp Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: <50437.990647215@critter> References: <200105231944.f4NJiXF09637@hak.lan.Awfulhak.org> <50437.990647215@critter> 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 < said: > If true, the rman code should have a big "XXX: rewrite" on top of it. You're not paying attention. The resource manager has no such problem -- sparse ranges like that are precisely what it was written for. I suggested that, if Brian was unhappy with the overhead of the resource manager, he should just keep a bitmap of available numbers. He responded with this strawman. I responded that his strawman was not reasonable. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 13: 0:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id CE81237B423 for ; Wed, 23 May 2001 13:00:37 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NK0aY12322; Wed, 23 May 2001 21:00:36 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NK0YF10017; Wed, 23 May 2001 21:00:34 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105232000.f4NK0YF10017@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Garrett Wollman Cc: Brian Somers , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Garrett Wollman of "Wed, 23 May 2001 15:47:50 EDT." <200105231947.PAA32360@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 21:00:34 +0100 From: Brian Somers 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 > < said: > > > Ok, I've thought about this :-/ I don't think it's practical to > > do this with bits if someone does > > > # ppp -unit 16777215 > > You then return ERANGE or ENXIO or something of the sort. At some > point, you eventually have to say ``no''. The ``no'' point is already defined as 0xffffff (16777215). Wanting to allocate that many units is silly, but allocating a high unit number is perfectly valid and is already done in many drivers. Should those drivers be prevented from using this (proposed) standard way of tracking unit numbers ? > -GAWollman -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 13: 2:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 21ABE37B422 for ; Wed, 23 May 2001 13:02:16 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NK2EY12332; Wed, 23 May 2001 21:02:14 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NK2DF10033; Wed, 23 May 2001 21:02:13 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105232002.f4NK2DF10033@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: Brian Somers , Garrett Wollman , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Poul-Henning Kamp of "Wed, 23 May 2001 21:46:55 +0200." <50437.990647215@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 21:02:13 +0100 From: Brian Somers 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 <200105231944.f4NJiXF09637@hak.lan.Awfulhak.org>, Brian Somers write > s: > >> > > Using bits when there are large numbers of units gets awkward. > >> > > >> > Just wrap it in macros. I almost posted an implementation with my > >> > last message, but decided that since it was so trivial it would be > >> > almost insulting for me to do so. > >> > >> Not true - I'm too thick skinned to be insulted :oI > >> > >> I'll look at a macro implementation. > > > >Ok, I've thought about this :-/ I don't think it's practical to > >do this with bits if someone does > > > > # ppp -unit 16777215 > > > >I then have to go off and allocate an array of 0x7fffff bytes just to > >record the fact that someone's using a silly unit number. > > If true, the rman code should have a big "XXX: rewrite" on top of it. rman doesn't use bitmasks - I was following up on Garrett's suggestion that some bitmask macros should do the trick. > -- > 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. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 13:17:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id D061137B423; Wed, 23 May 2001 13:17:21 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NKHKY12437; Wed, 23 May 2001 21:17:20 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NKHIF10323; Wed, 23 May 2001 21:17:18 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105232017.f4NKHIF10323@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Mike Smith Cc: Brian Somers , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Mike Smith of "Wed, 23 May 2001 13:17:51 PDT." <200105232017.f4NKHp400923@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 21:17:18 +0100 From: Brian Somers 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 didn't do it that way because the ``usual'' way units are allocated > > > >is sequentially. Using bits when there are large numbers of units > > > >gets awkward. I figured what was required was something small and > > > >simple that would cover the requirements of most/all drivers that > > > >need to track their units so that it's easy to find an unused one, > > > >and it's easy to allocate/deallocate things. > > > > > > How does newbus allocate/manage unit numbers ? > > > > I don't think it does. The only way to find out what's in use > > (AFAIK) is by looking at every specinfo in dev_hash.... > > Er, what exactly are you smoking? > > Newbus manages unit numbers using the devclass: > > struct devclass { > TAILQ_ENTRY(devclass) link; > driver_list_t drivers; /* bus devclasses store drivers for bus */ > char *name; > device_t *devices; /* array of devices indexed by unit */ > int maxunit; /* size of devices array */ > }; Yes, Garrett pointed this out. I misunderstood the question because newbus doesn't manage unit numbers. It ``manages'' the maximum unit number allocated and nothing else. My answer was describing the only way I know of to figure out which units for a given device are allocated/opened. > -- > ... 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 -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 13:20:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 4D4E637B423; Wed, 23 May 2001 13:20:05 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NKK3Y12456; Wed, 23 May 2001 21:20:03 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NKK2F10389; Wed, 23 May 2001 21:20:02 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105232020.f4NKK2F10389@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Brian Somers Cc: Mike Smith , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Brian Somers of "Wed, 23 May 2001 21:17:18 BST." <200105232017.f4NKHIF10323@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 21:20:02 +0100 From: Brian Somers 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 didn't do it that way because the ``usual'' way units are allocated > > > > >is sequentially. Using bits when there are large numbers of units > > > > >gets awkward. I figured what was required was something small and > > > > >simple that would cover the requirements of most/all drivers that > > > > >need to track their units so that it's easy to find an unused one, > > > > >and it's easy to allocate/deallocate things. > > > > > > > > How does newbus allocate/manage unit numbers ? > > > > > > I don't think it does. The only way to find out what's in use > > > (AFAIK) is by looking at every specinfo in dev_hash.... > > > > Er, what exactly are you smoking? > > > > Newbus manages unit numbers using the devclass: > > > > struct devclass { > > TAILQ_ENTRY(devclass) link; > > driver_list_t drivers; /* bus devclasses store drivers for bus */ > > char *name; > > device_t *devices; /* array of devices indexed by unit */ > > int maxunit; /* size of devices array */ > > }; > > Yes, Garrett pointed this out. I misunderstood the question because > newbus doesn't manage unit numbers. It ``manages'' the maximum unit > number allocated and nothing else. > > My answer was describing the only way I know of to figure out which > units for a given device are allocated/opened. Hmm, hang on. I'll stop smoking.... If that device_t array knows which devices are open it could solve my problems... -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 13:47: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id C86F137B423 for ; Wed, 23 May 2001 13:47:05 -0700 (PDT) (envelope-from DougB@DougBarton.net) Received: from DougBarton.net (master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id NAA08425; Wed, 23 May 2001 13:46:50 -0700 (PDT) (envelope-from DougB@DougBarton.net) Message-ID: <3B0C21BA.D73C026B@DougBarton.net> Date: Wed, 23 May 2001 13:46:50 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ References: <37017.990609604@axl.fw.uunet.co.za> 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 Sheldon Hearn wrote: > > On Tue, 22 May 2001 20:04:48 +0200, Poul-Henning Kamp wrote: > > > >ext2fs would go in fs/gnu/ext2fs (or is it gnu/fs/ext2fs?). Ugh. > > > > it would be src/sys/gnu/fs/ext2fs or src/sys/contrib/fs/ext2fs > > Is it feasible to keep this consistent with userland by putting the > source in src/sys/contrib and the build infrastructure in src/sys/gnu? That's an abomination all its own. Way back when /usr/src/gnu was used (essentially) just like /usr/src/contrib, with all of the code there and the build stuff in the "normal" place in the tree. It's hard to say at this point what's the best way to fix the current silliness, but perpetuating it definitely shouldn't be an option. Doug -- I need someone really bad. Are you really bad? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 14: 9:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 8614437B423; Wed, 23 May 2001 14:09:30 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NL9SY12822; Wed, 23 May 2001 22:09:29 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NL9RF11365; Wed, 23 May 2001 22:09:27 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105232109.f4NL9RF11365@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Brian Somers Cc: Mike Smith , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Brian Somers of "Wed, 23 May 2001 21:20:02 BST." <200105232020.f4NKK2F10389@hak.lan.Awfulhak.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11358.990652166.1@hak.lan.Awfulhak.org> Date: Wed, 23 May 2001 22:09:27 +0100 From: Brian Somers 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 didn't do it that way because the ``usual'' way units are allocated > > > > > >is sequentially. Using bits when there are large numbers of units > > > > > >gets awkward. I figured what was required was something small and > > > > > >simple that would cover the requirements of most/all drivers that > > > > > >need to track their units so that it's easy to find an unused one, > > > > > >and it's easy to allocate/deallocate things. > > > > > > > > > > How does newbus allocate/manage unit numbers ? > > > > > > > > I don't think it does. The only way to find out what's in use > > > > (AFAIK) is by looking at every specinfo in dev_hash.... > > > > > > Er, what exactly are you smoking? > > > > > > Newbus manages unit numbers using the devclass: > > > > > > struct devclass { > > > TAILQ_ENTRY(devclass) link; > > > driver_list_t drivers; /* bus devclasses store drivers for bus */ > > > char *name; > > > device_t *devices; /* array of devices indexed by unit */ > > > int maxunit; /* size of devices array */ > > > }; > > > > Yes, Garrett pointed this out. I misunderstood the question because > > newbus doesn't manage unit numbers. It ``manages'' the maximum unit > > number allocated and nothing else. > > > > My answer was describing the only way I know of to figure out which > > units for a given device are allocated/opened. > > Hmm, hang on. I'll stop smoking.... If that device_t array knows > which devices are open it could solve my problems... Where did I put that smoke.... Anyone care to try # ppp -unit 16777215 I don't care for the consistency of the results (/dev/tun16777215 is created ok, but seems to be talking to interface tun0). Is subr_bus.c *really* trying to allocate 0xffffff device_t pointers and set them all except the last to NULL ? That's 67Mb of memory. Funnily enough, netstat -i takes quite a while to run, and yep, I'm using up a bit of swap. I think devclass needs to be fixed. Maybe it should use this new ``struct unit_list'' that I happen to have handy - or even better, it could use the rman stuff !!! :*D -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 14:27:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 32A3137B423 for ; Wed, 23 May 2001 14:27:35 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f4NLRFG88570; Wed, 23 May 2001 14:27:19 -0700 (PDT) (envelope-from jhb@FreeBSD.org) 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: <3B0C21BA.D73C026B@DougBarton.net> Date: Wed, 23 May 2001 14:27:20 -0700 (PDT) From: John Baldwin To: Doug Barton Subject: Re: [CFR] /sys/miscfs/* -> /sys/fs/ Cc: arch@FreeBSD.org, Sheldon Hearn 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 23-May-01 Doug Barton wrote: > Sheldon Hearn wrote: >> >> On Tue, 22 May 2001 20:04:48 +0200, Poul-Henning Kamp wrote: >> >> > >ext2fs would go in fs/gnu/ext2fs (or is it gnu/fs/ext2fs?). Ugh. >> > >> > it would be src/sys/gnu/fs/ext2fs or src/sys/contrib/fs/ext2fs >> >> Is it feasible to keep this consistent with userland by putting the >> source in src/sys/contrib and the build infrastructure in src/sys/gnu? > > That's an abomination all its own. Way back when /usr/src/gnu was used > (essentially) just like /usr/src/contrib, with all of the code there and > the build stuff in the "normal" place in the tree. It's hard to say at this > point what's the best way to fix the current silliness, but perpetuating it > definitely shouldn't be an option. There is no build infrastructure part in the kernel. You just have the code. Right now the difference between gnu and contrib is the GPL part. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Wed May 23 14:31:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id AB0CD37B422; Wed, 23 May 2001 14:31:19 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NLVIY12958; Wed, 23 May 2001 22:31:18 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NLVGF11782; Wed, 23 May 2001 22:31:16 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105232131.f4NLVGF11782@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Mike Smith Cc: freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Brian Somers of "Wed, 23 May 2001 22:09:27 BST." <200105232109.f4NL9RF11365@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 22:31:16 +0100 From: Brian Somers 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 > Where did I put that smoke.... > > Anyone care to try > > # ppp -unit 16777215 > > I don't care for the consistency of the results (/dev/tun16777215 is > created ok, but seems to be talking to interface tun0). Is subr_bus.c > *really* trying to allocate 0xffffff device_t pointers and set them > all except the last to NULL ? That's 67Mb of memory. No, I mistyped the command line. When I actually type the above the device_t * malloc fails (M_NOWAIT). As it turns out, because struct ifnet's if_unit is a short, allocating a tun unit > 32767 fails, but unfortunately (due to another bug) creates an interface with a wrapped unit number. I guess this provides a practical limit unit as far as tun is concerned. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 15:22:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id DD43837B422; Wed, 23 May 2001 15:22:34 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NMMXY13249; Wed, 23 May 2001 23:22:33 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4NMMVF12972; Wed, 23 May 2001 23:22:31 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105232222.f4NMMVF12972@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Brian Somers Cc: Mike Smith , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines In-Reply-To: Message from Brian Somers of "Wed, 23 May 2001 21:20:02 BST." <200105232020.f4NKK2F10389@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 23:22:31 +0100 From: Brian Somers 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 didn't do it that way because the ``usual'' way units are allocated > > > > > >is sequentially. Using bits when there are large numbers of units > > > > > >gets awkward. I figured what was required was something small and > > > > > >simple that would cover the requirements of most/all drivers that > > > > > >need to track their units so that it's easy to find an unused one, > > > > > >and it's easy to allocate/deallocate things. > > > > > > > > > > How does newbus allocate/manage unit numbers ? > > > > > > > > I don't think it does. The only way to find out what's in use > > > > (AFAIK) is by looking at every specinfo in dev_hash.... > > > > > > Er, what exactly are you smoking? > > > > > > Newbus manages unit numbers using the devclass: > > > > > > struct devclass { > > > TAILQ_ENTRY(devclass) link; > > > driver_list_t drivers; /* bus devclasses store drivers for bus */ > > > char *name; > > > device_t *devices; /* array of devices indexed by unit */ > > > int maxunit; /* size of devices array */ > > > }; > > > > Yes, Garrett pointed this out. I misunderstood the question because > > newbus doesn't manage unit numbers. It ``manages'' the maximum unit > > number allocated and nothing else. > > > > My answer was describing the only way I know of to figure out which > > units for a given device are allocated/opened. > > Hmm, hang on. I'll stop smoking.... If that device_t array knows > which devices are open it could solve my problems... Guessing again (and realising that it's time I slept), if_tun doesn't have a devclass. It doesn't look that appropriate to add one either as methods like devclass_destroy() seem to be missing from the devclass interface. I'll try to figure out what I really think later... -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 17:18: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id DF5ED37B424 for ; Wed, 23 May 2001 17:17:57 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 56B6F6ACBC; Thu, 24 May 2001 09:47:50 +0930 (CST) Date: Thu, 24 May 2001 09:47:50 +0930 From: Greg Lehey To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: Re: http://uptime.netcraft.com/up/accuracy.html#cycle Message-ID: <20010524094750.A74859@wantadilla.lemis.com> References: <20010523083342.E41189@wantadilla.lemis.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 bde@zeta.org.au on Wed, May 23, 2001 at 07:43:32PM +1000 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF 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 Wednesday, 23 May 2001 at 19:43:32 +1000, Bruce Evans wrote: > On Wed, 23 May 2001, Greg Lehey wrote: > >> Comments? >> >> Greg >> >> ----- Forwarded message from Richard Wendland ----- >> >>> Date: Tue, 22 May 2001 21:51:02 +0100 (BST) >>> From: Richard Wendland >>> To: grog@FreeBSD.org (Greg Lehey) >>> Cc: webmaster@netcraft.com >>> Subject: Re: http://uptime.netcraft.com/up/accuracy.html#cycle >>> X-Mailer: ELM [version 2.5 PL2] >>> >>>> At this link, you claim: >>>> >>>> Additionally HP-UX, Linux, Solaris and recent releases of FreeBSD >>>> cycle back to zero after 497 days, exactly as if the machine had >>>> been rebooted at that precise point. Thus it is not possible to see >>>> a HP-UX, Linux or Solaris system with an uptime measurement above >>>> 497 days. >>>> >>>> FreeBSD does not suffer from this problem. You'll notice that you >>>> have a large number of FreeBSD systems with uptimes of over 497 days. >>>> I'd appreciate if you would correct this statement. >>> >>> Hi Greg, >>> >>> I think that statement is accurate. Note that we're not talking about >>> the FreeBSD 'uptime' command, but our ability to ascertain uptime remotely >>> by decoding the TCP timestamp option. >>> >>> Prior to FreeBSD 3 the TCP timestamp option was incremented every 500ms, >>> as is traditional with BSD. From FreeBSD 3 it was incremented every >>> 10ms, presumably to improve RTT measurement. But it does have the >>> consequence that the 32-bit TCP timestamp wraps around at 497.1 days. >>> Hence, with our current method at least, we don't detect uptimes above >>> this for FreeBSD 3 and later. >>> >>> So the FreeBSD systems listed > 497 days are running FreeBSD 2. >>> Once everyone has upgraded from FreeBSD 2, FreeBSD will no longer get >>> in that top uptimes list! > > The TCP timestamp is actually incremented every 1/hz seconds, so it > overflows after every 48.5 days on alphas (and on i386's with > "options HZ=1024"). So what's Richard talking about? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 22:47:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (adsl-64-166-71-242.dsl.sntc01.pacbell.net [64.166.71.242]) by hub.freebsd.org (Postfix) with ESMTP id E170F37B43C for ; Wed, 23 May 2001 22:47:07 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f4NKHp400923; Wed, 23 May 2001 13:17:52 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200105232017.f4NKHp400923@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-reply-to: Your message of "Wed, 23 May 2001 18:02:09 BST." <200105231702.f4NH29F07183@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 May 2001 13:17:51 -0700 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 didn't do it that way because the ``usual'' way units are allocated > > >is sequentially. Using bits when there are large numbers of units > > >gets awkward. I figured what was required was something small and > > >simple that would cover the requirements of most/all drivers that > > >need to track their units so that it's easy to find an unused one, > > >and it's easy to allocate/deallocate things. > > > > How does newbus allocate/manage unit numbers ? > > I don't think it does. The only way to find out what's in use > (AFAIK) is by looking at every specinfo in dev_hash.... Er, what exactly are you smoking? Newbus manages unit numbers using the devclass: struct devclass { TAILQ_ENTRY(devclass) link; driver_list_t drivers; /* bus devclasses store drivers for bus */ char *name; device_t *devices; /* array of devices indexed by unit */ int maxunit; /* size of devices array */ }; -- ... 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 May 23 23: 4: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 6EAE537B422 for ; Wed, 23 May 2001 23:03:59 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4O63xM90402 for ; Wed, 23 May 2001 23:03:59 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 3746D380C; Wed, 23 May 2001 23:03:59 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: Garrett Wollman , Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: <9639.990638350@critter> Date: Wed, 23 May 2001 23:03:59 -0700 From: Peter Wemm Message-Id: <20010524060359.3746D380C@overcee.netplex.com.au> 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 Poul-Henning Kamp wrote: > In message <200105231716.NAA31092@khavrinen.lcs.mit.edu>, Garrett Wollman wri te > s: > >< said : > > > >>> How does newbus allocate/manage unit numbers ? > > > >> I don't think it does. The only way to find out what's in use > >> (AFAIK) is by looking at every specinfo in dev_hash.... > > > >You're looking in the wrong place again. > > > >This may have changed, but my recollection is that new-bus looks for > >the greatest allocated unit number and then takes the next one. Since > >this is initialization code, the fact that this is O(n^2) is of no > >consequence. > > For pty and tun devices, this assumption may not hold... .. which have *nothing* to do with newbus. rman is a completely different animal. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 23 23:12:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 34B1E37B423; Wed, 23 May 2001 23:12:35 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4O6CZM90436; Wed, 23 May 2001 23:12:35 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 0413C380C; Wed, 23 May 2001 23:12:35 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Brian Somers Cc: Mike Smith , freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines In-Reply-To: <200105232109.f4NL9RF11365@hak.lan.Awfulhak.org> Date: Wed, 23 May 2001 23:12:34 -0700 From: Peter Wemm Message-Id: <20010524061235.0413C380C@overcee.netplex.com.au> 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 Brian Somers wrote: > > > > > > >I didn't do it that way because the ``usual'' way units are alloca ted > > > > > > >is sequentially. Using bits when there are large numbers of units > > > > > > >gets awkward. I figured what was required was something small and > > > > > > >simple that would cover the requirements of most/all drivers that > > > > > > >need to track their units so that it's easy to find an unused one, > > > > > > >and it's easy to allocate/deallocate things. > > > > > > > > > > > > How does newbus allocate/manage unit numbers ? > > > > > > > > > > I don't think it does. The only way to find out what's in use > > > > > (AFAIK) is by looking at every specinfo in dev_hash.... > > > > > > > > Er, what exactly are you smoking? > > > > > > > > Newbus manages unit numbers using the devclass: > > > > > > > > struct devclass { > > > > TAILQ_ENTRY(devclass) link; > > > > driver_list_t drivers; /* bus devclasses store drivers for bu s */ > > > > char *name; > > > > device_t *devices; /* array of devices indexed by unit * / > > > > int maxunit; /* size of devices array */ > > > > }; > > > > > > Yes, Garrett pointed this out. I misunderstood the question because > > > newbus doesn't manage unit numbers. It ``manages'' the maximum unit > > > number allocated and nothing else. > > > > > > My answer was describing the only way I know of to figure out which > > > units for a given device are allocated/opened. > > > > Hmm, hang on. I'll stop smoking.... If that device_t array knows > > which devices are open it could solve my problems... > > Where did I put that smoke.... > > Anyone care to try > > # ppp -unit 16777215 > > I don't care for the consistency of the results (/dev/tun16777215 is > created ok, but seems to be talking to interface tun0). Is subr_bus.c > *really* trying to allocate 0xffffff device_t pointers and set them > all except the last to NULL ? That's 67Mb of memory. > > Funnily enough, netstat -i takes quite a while to run, and yep, I'm > using up a bit of swap. > > I think devclass needs to be fixed. Uhh... what crack are you smoking? devclasses are not invloved here. if_tun does not use *any* newbus code or interfaces. subr_bus.c is not involved. peter@overcee[11:06pm]~src/sys/net-118> grep bus.h if_tun* peter@overcee[11:07pm]~src/sys/net-119> > Maybe it should use this new > ``struct unit_list'' that I happen to have handy - or even better, it > could use the rman stuff !!! :*D Exactly. rman will deal with this just fine. The network stack may not, since it uses indexes etc, but rman wont have the slightest problem. Suppose you have tun0, tun1 and tun16777215.. That is something like 4 struct rman nodes. (one for tun0, one for tun1, one placeholder for the sparse range between tun2 and tun16777214, and one for tun16777215) Besides, the sys/kern/unit_list.c and sys/unit_list.h files are badly misnamed. At the very least, it should be sys/kern/subr_units.c or something along those lines. (next to subr_bus.c and subr_rman.c). I still dont believe that we need it though. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 24 0: 1:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 9914B37B422 for ; Thu, 24 May 2001 00:01:53 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4O71rM90669 for ; Thu, 24 May 2001 00:01:53 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 6DECA3811; Thu, 24 May 2001 00:01:53 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Greg Lehey Cc: arch@FreeBSD.ORG Subject: Re: http://uptime.netcraft.com/up/accuracy.html#cycle In-Reply-To: <20010524094750.A74859@wantadilla.lemis.com> Date: Thu, 24 May 2001 00:01:53 -0700 From: Peter Wemm Message-Id: <20010524070153.6DECA3811@overcee.netplex.com.au> 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 Greg Lehey wrote: > On Wednesday, 23 May 2001 at 19:43:32 +1000, Bruce Evans wrote: > > On Wed, 23 May 2001, Greg Lehey wrote: > > > >> Comments? > >> > >> Greg > >> > >> ----- Forwarded message from Richard Wendland ----- > >> > >>> Date: Tue, 22 May 2001 21:51:02 +0100 (BST) > >>> From: Richard Wendland > >>> To: grog@FreeBSD.org (Greg Lehey) > >>> Cc: webmaster@netcraft.com > >>> Subject: Re: http://uptime.netcraft.com/up/accuracy.html#cycle > >>> X-Mailer: ELM [version 2.5 PL2] > >>> > >>>> At this link, you claim: > >>>> > >>>> Additionally HP-UX, Linux, Solaris and recent releases of FreeBSD > >>>> cycle back to zero after 497 days, exactly as if the machine had > >>>> been rebooted at that precise point. Thus it is not possible to see > >>>> a HP-UX, Linux or Solaris system with an uptime measurement above > >>>> 497 days. > >>>> > >>>> FreeBSD does not suffer from this problem. You'll notice that you > >>>> have a large number of FreeBSD systems with uptimes of over 497 days. > >>>> I'd appreciate if you would correct this statement. > >>> > >>> Hi Greg, > >>> > >>> I think that statement is accurate. Note that we're not talking about > >>> the FreeBSD 'uptime' command, but our ability to ascertain uptime remotel y > >>> by decoding the TCP timestamp option. > >>> > >>> Prior to FreeBSD 3 the TCP timestamp option was incremented every 500ms, > >>> as is traditional with BSD. From FreeBSD 3 it was incremented every > >>> 10ms, presumably to improve RTT measurement. But it does have the > >>> consequence that the 32-bit TCP timestamp wraps around at 497.1 days. > >>> Hence, with our current method at least, we don't detect uptimes above > >>> this for FreeBSD 3 and later. > >>> > >>> So the FreeBSD systems listed > 497 days are running FreeBSD 2. > >>> Once everyone has upgraded from FreeBSD 2, FreeBSD will no longer get > >>> in that top uptimes list! > > > > The TCP timestamp is actually incremented every 1/hz seconds, so it > > overflows after every 48.5 days on alphas (and on i386's with > > "options HZ=1024"). > > So what's Richard talking about? I think it means that we need to run a timer on it at a fixed 20hz so that our uptime values double. ;-) Actually, I dont think that will help because they check over several days to determine the CC count rate. But we should probably use a fixed rate since people do change their HZ values in certain situations. netcraft's uptime counter looks at the RFC1323 timestamp option (which we have off by default now, so it is academic :-( ) and detects the 500ms update rate or the 10ms update rate for FreeBSD systems. It can use this to determine the uptime 'remotely' by fingerprinting the system. See: http://uptime.netcraft.co.uk/up/graph?site=www.freebsd.org Incidently, we should turn TCP_EXTENSIONS (rfc1323) back on by default. Linux has had it on for a while now and has "cleared the way" for us. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 24 0: 2: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id E9A1437B423 for ; Thu, 24 May 2001 00:02:04 -0700 (PDT) (envelope-from sheldonh@uunet.co.za) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 152p87-00004k-00; Thu, 24 May 2001 09:01:55 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id JAA29434; Thu, 24 May 2001 09:01:54 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 29283; Thu May 24 09:01:07 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.22 #1) id 152p7L-000EPI-00; Thu, 24 May 2001 09:01:07 +0200 To: Doug Barton Cc: arch@freebsd.org Subject: contrib code and gnu build glue (was [CFR] /sys/miscfs/* -> /sys/fs/) In-reply-to: Your message of "Wed, 23 May 2001 13:46:50 MST." <3B0C21BA.D73C026B@DougBarton.net> Date: Thu, 24 May 2001 09:01:07 +0200 Message-ID: <55383.990687667@axl.fw.uunet.co.za> From: Sheldon Hearn 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, 23 May 2001 13:46:50 MST, Doug Barton wrote: > That's an abomination all its own. Way back when /usr/src/gnu was used > (essentially) just like /usr/src/contrib, with all of the code there and > the build stuff in the "normal" place in the tree. It's hard to say at this > point what's the best way to fix the current silliness, but perpetuating it > definitely shouldn't be an option. Okay, let's forget about the kernel, since you're criticising the userland stuff now. :-) I've always thought that putting code in one place and build glue in another is clever. It allows us to provide the code as close as supplied as possible. You don't actually say what you have against the scheme. Care to elaborate? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 24 0:27:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 9F72437B422 for ; Thu, 24 May 2001 00:27:11 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f4O7R8P22454; Thu, 24 May 2001 00:27:08 -0700 (PDT) (envelope-from dillon) Date: Thu, 24 May 2001 00:27:08 -0700 (PDT) From: Matt Dillon Message-Id: <200105240727.f4O7R8P22454@earth.backplane.com> To: Tor.Egge@fast.no Cc: arch@FreeBSD.ORG Subject: O_DIRECT patch committed to -current 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 committed the O_DIRECT patch to -current. It took about 6 hours to get -current running on one of my test boxes to test the patch. After several tries I finally gave up trying to buildworld on the test box (which by that time was hopelessly mixed up with partially installed kernels, modules, and worlds) and instead did a buildworld and buildkernel of -current on my main -stable box, then installworld and installkernel's it via NFS mounts of /usr/src and /usr/obj. To my complete amazement, that actually worked! And not having the source or object files on the -current machine itself means I can very easily reinstall -current on test boxes now by booting the 4.2 CD into an emergency shell and going from there. I highly recommend the methodology. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 24 2:53:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 20CEF37B422; Thu, 24 May 2001 02:53:19 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4O9rG799857; Thu, 24 May 2001 12:53:16 +0300 (EEST) (envelope-from ru) Date: Thu, 24 May 2001 12:53:16 +0300 From: Ruslan Ermilov To: Mike Smith Cc: arch@FreeBSD.org Subject: mlxio.h (was: Re: Where to put include files) Message-ID: <20010524125316.E79111@sunbay.com> Mail-Followup-To: Mike Smith , arch@FreeBSD.org References: <200105171600.f4HG0Pl05438@billy-club.village.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dfr@nlsystems.com on Fri, May 18, 2001 at 11:39:14AM +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 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 18, 2001 at 11:39:14AM +0100, Doug Rabson wrote: > On Thu, 17 May 2001, Warner Losh wrote: > > > In message <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> Brian > > Somers writes: > > : Solaris calls it's ioctl files /usr/include/sys/_io.h so I'd > > : spell digiio.h /usr/include/sys/digi_io.h. > > > > Actually, the more I think about it, the more I like putting it in > > /usr/include/sys/fooio.h. We have lots of other files there now. The > > down side to this approach is that it breaks up the driver sources > > that we've been trying to concentrate into sys/dev/foo/* (or > > introduces asymetry such that you can't just toss in a -I/sys and have > > the same tree that gets stuck under /usr/include). > > I quite like the fact that the programming interface is > separated from the driver implementation. There is less chance that the > driver writer will expose irrelavent implementation details in the API, > which in turn makes for a more stable ABI. > Hi! What I propose is to make mlxio.h self-contained to be suitable for userland, and move it to /sys/sys where it belongs, and to get rid of that bogus -I line in mlxcontrol/Makefile. The attached patch merely moves the (non-kernel) part of mlxreg.h into mlxio.h (which is IMHO belongs to API anyway), unconnects mlxreg.h from userland, and removes _KERNEL conditional from mlxreg.h. If this looks acceptable, the next step would be: 1. repo-copy mlxio.h to /sys/sys (so that it gets installed into /usr/include/sys) 2. fix mlxcontrol's #include's for the new location 3. remove CFLAGS+=-I${.CURDIR}/../../sys from mlxcontrol/Makefile. I've verified that both mlx module and mlxcontrol build OK with this patch. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: sys/dev/mlx/mlxio.h =================================================================== RCS file: /home/ncvs/src/sys/dev/mlx/mlxio.h,v retrieving revision 1.3 diff -u -r1.3 mlxio.h --- sys/dev/mlx/mlxio.h 2000/04/11 02:52:44 1.3 +++ sys/dev/mlx/mlxio.h 2001/05/24 09:36:29 @@ -95,3 +95,332 @@ #define MLX_REBUILDASYNC _IOWR('M', 5, struct mlx_rebuild_request) #define MLX_REBUILDSTAT _IOR ('M', 6, struct mlx_rebuild_status) #define MLX_GET_SYSDRIVE _IOWR('M', 7, int) + + +#define MLX_BLKSIZE 512 /* fixed feature */ + +/* + * Selected command codes. + */ +#define MLX_CMD_ENQUIRY_OLD 0x05 +#define MLX_CMD_ENQUIRY 0x53 +#define MLX_CMD_ENQUIRY2 0x1c +#define MLX_CMD_ENQSYSDRIVE 0x19 +#define MLX_CMD_READSG 0xb6 +#define MLX_CMD_WRITESG 0xb7 +#define MLX_CMD_READSG_OLD 0x82 +#define MLX_CMD_WRITESG_OLD 0x83 +#define MLX_CMD_FLUSH 0x0a +#define MLX_CMD_LOGOP 0x72 +#define MLX_CMD_REBUILDASYNC 0x16 +#define MLX_CMD_CHECKASYNC 0x1e +#define MLX_CMD_REBUILDSTAT 0x0c +#define MLX_CMD_STOPCHANNEL 0x13 +#define MLX_CMD_STARTCHANNEL 0x12 +#define MLX_CMD_READ_CONFIG 0x4e +#define MLX_CMD_DIRECT_CDB 0x04 +#define MLX_CMD_DEVICE_STATE 0x50 + + +/* + * Scatter-gather list format, type 1, kind 00. + */ +struct mlx_sgentry +{ + u_int32_t sg_addr; + u_int32_t sg_count; +} __attribute__ ((packed)); + +/* + * Command result buffers, as placed in system memory by the controller. + */ + +struct mlx_enquiry_old /* MLX_CMD_ENQUIRY_OLD */ +{ + u_int8_t me_num_sys_drvs; + u_int8_t res1[3]; + u_int32_t me_drvsize[8]; + u_int16_t me_flash_age; + u_int8_t me_status_flags; + u_int8_t me_free_state_change_count; + u_int8_t me_fwminor; + u_int8_t me_fwmajor; + u_int8_t me_rebuild_flag; + u_int8_t me_max_commands; + u_int8_t me_offline_sd_count; + u_int8_t res3; + u_int8_t me_critical_sd_count; + u_int8_t res4[3]; + u_int8_t me_dead_count; + u_int8_t res5; + u_int8_t me_rebuild_count; + u_int8_t me_misc_flags; + struct + { + u_int8_t dd_targ; + u_int8_t dd_chan; + } __attribute__ ((packed)) me_dead[20]; +} __attribute__ ((packed)); + +struct mlx_enquiry /* MLX_CMD_ENQUIRY */ +{ + u_int8_t me_num_sys_drvs; + u_int8_t res1[3]; + u_int32_t me_drvsize[32]; + u_int16_t me_flash_age; + u_int8_t me_status_flags; +#define MLX_ENQ_SFLAG_DEFWRERR (1<<0) /* deferred write error indicator */ +#define MLX_ENQ_SFLAG_BATTLOW (1<<1) /* battery low */ + u_int8_t res2; + u_int8_t me_fwminor; + u_int8_t me_fwmajor; + u_int8_t me_rebuild_flag; + u_int8_t me_max_commands; + u_int8_t me_offline_sd_count; + u_int8_t res3; + u_int16_t me_event_log_seq_num; + u_int8_t me_critical_sd_count; + u_int8_t res4[3]; + u_int8_t me_dead_count; + u_int8_t res5; + u_int8_t me_rebuild_count; + u_int8_t me_misc_flags; +#define MLX_ENQ_MISC_BBU (1<<3) /* battery backup present */ + struct + { + u_int8_t dd_targ; + u_int8_t dd_chan; + } __attribute__ ((packed)) me_dead[20]; +} __attribute__ ((packed)); + +struct mlx_enquiry2 /* MLX_CMD_ENQUIRY2 */ +{ + u_int32_t me_hardware_id; + u_int32_t me_firmware_id; + u_int32_t res1; + u_int8_t me_configured_channels; + u_int8_t me_actual_channels; + u_int8_t me_max_targets; + u_int8_t me_max_tags; + u_int8_t me_max_sys_drives; + u_int8_t me_max_arms; + u_int8_t me_max_spans; + u_int8_t res2; + u_int32_t res3; + u_int32_t me_mem_size; + u_int32_t me_cache_size; + u_int32_t me_flash_size; + u_int32_t me_nvram_size; + u_int16_t me_mem_type; + u_int16_t me_clock_speed; + u_int16_t me_mem_speed; + u_int16_t me_hardware_speed; + u_int8_t res4[12]; + u_int16_t me_max_commands; + u_int16_t me_max_sg; + u_int16_t me_max_dp; + u_int16_t me_max_iod; + u_int16_t me_max_comb; + u_int8_t me_latency; + u_int8_t res5; + u_int8_t me_scsi_timeout; + u_int8_t res6; + u_int16_t me_min_freelines; + u_int8_t res7[8]; + u_int8_t me_rate_const; + u_int8_t res8[11]; + u_int16_t me_physblk; + u_int16_t me_logblk; + u_int16_t me_maxblk; + u_int16_t me_blocking_factor; + u_int16_t me_cacheline; + u_int8_t me_scsi_cap; + u_int8_t res9[5]; + u_int16_t me_firmware_build; + u_int8_t me_fault_mgmt_type; + u_int8_t res10; + u_int32_t me_firmware_features; + u_int8_t res11[8]; +} __attribute__ ((packed)); + +struct mlx_enq_sys_drive /* MLX_CMD_ENQSYSDRIVE returns an array of 32 of these */ +{ + u_int32_t sd_size; + u_int8_t sd_state; + u_int8_t sd_raidlevel; + u_int16_t res1; +} __attribute__ ((packed)); + +struct mlx_eventlog_entry /* MLX_CMD_LOGOP/MLX_LOGOP_GET */ +{ + u_int8_t el_type; + u_int8_t el_length; + u_char el_target:5; + u_char el_channel:3; + u_char el_lun:6; + u_char res1:2; + u_int16_t el_seqno; + u_char el_errorcode:7; + u_char el_valid:1; + u_int8_t el_segment; + u_char el_sensekey:4; + u_char res2:1; + u_char el_ILI:1; + u_char el_EOM:1; + u_char el_filemark:1; + u_int8_t el_information[4]; + u_int8_t el_addsense; + u_int8_t el_csi[4]; + u_int8_t el_asc; + u_int8_t el_asq; + u_int8_t res3[12]; +} __attribute__ ((packed)); + +#define MLX_LOGOP_GET 0x00 /* operation codes for MLX_CMD_LOGOP */ +#define MLX_LOGMSG_SENSE 0x00 /* log message contents codes */ + +struct mlx_rebuild_stat /* MLX_CMD_REBUILDSTAT */ +{ + u_int32_t rb_drive; + u_int32_t rb_size; + u_int32_t rb_remaining; +} __attribute__ ((packed)); + +struct mlx_config2 +{ + u_int16_t cf_flags1; +#define MLX_CF2_ACTV_NEG (1<<1) +#define MLX_CF2_NORSTRTRY (1<<7) +#define MLX_CF2_STRGWRK (1<<8) +#define MLX_CF2_HPSUPP (1<<9) +#define MLX_CF2_NODISCN (1<<10) +#define MLX_CF2_ARM (1<<13) +#define MLX_CF2_OFM (1<<15) +#define MLX_CF2_AEMI (MLX_CF2_ARM | MLX_CF2_OFM) + u_int8_t cf_oemid; + u_int8_t cf_oem_model; + u_int8_t cf_physical_sector; + u_int8_t cf_logical_sector; + u_int8_t cf_blockfactor; + u_int8_t cf_flags2; +#define MLX_CF2_READAH (1<<0) +#define MLX_CF2_BIOSDLY (1<<1) +#define MLX_CF2_REASS1S (1<<4) +#define MLX_CF2_FUAENABL (1<<6) +#define MLX_CF2_R5ALLS (1<<7) + u_int8_t cf_rcrate; + u_int8_t cf_res1; + u_int8_t cf_blocks_per_cache_line; + u_int8_t cf_blocks_per_stripe; + u_int8_t cf_scsi_param_0; + u_int8_t cf_scsi_param_1; + u_int8_t cf_scsi_param_2; + u_int8_t cf_scsi_param_3; + u_int8_t cf_scsi_param_4; + u_int8_t cf_scsi_param_5; + u_int8_t cf_scsi_initiator_id; + u_int8_t cf_res2; + u_int8_t cf_startup_mode; + u_int8_t cf_simultaneous_spinup_devices; + u_int8_t cf_delay_between_spinups; + u_int8_t cf_res3; + u_int16_t cf_checksum; +} __attribute__ ((packed)); + +struct mlx_sys_drv_span +{ + u_int32_t sp_start_lba; + u_int32_t sp_nblks; + u_int8_t sp_arm[8]; +} __attribute__ ((packed)); + +struct mlx_sys_drv +{ + u_int8_t sd_status; + u_int8_t sd_ext_status; + u_int8_t sd_mod1; + u_int8_t sd_mod2; + u_int8_t sd_raidlevel; +#define MLX_SYS_DRV_WRITEBACK (1<<7) +#define MLX_SYS_DRV_RAID0 0 +#define MLX_SYS_DRV_RAID1 1 +#define MLX_SYS_DRV_RAID3 3 +#define MLX_SYS_DRV_RAID5 5 +#define MLX_SYS_DRV_RAID6 6 +#define MLX_SYS_DRV_JBOD 7 + u_int8_t sd_valid_arms; + u_int8_t sd_valid_spans; + u_int8_t sd_init_state; +#define MLX_SYS_DRV_INITTED 0x81; + struct mlx_sys_drv_span sd_span[4]; +} __attribute__ ((packed)); + +struct mlx_phys_drv +{ + u_int8_t pd_flags1; +#define MLX_PHYS_DRV_PRESENT (1<<0) + u_int8_t pd_flags2; +#define MLX_PHYS_DRV_OTHER 0x00 +#define MLX_PHYS_DRV_DISK 0x01 +#define MLX_PHYS_DRV_SEQUENTIAL 0x02 +#define MLX_PHYS_DRV_CDROM 0x03 +#define MLX_PHYS_DRV_FAST20 (1<<3) +#define MLX_PHYS_DRV_SYNC (1<<4) +#define MLX_PHYS_DRV_FAST (1<<5) +#define MLX_PHYS_DRV_WIDE (1<<6) +#define MLX_PHYS_DRV_TAG (1<<7) + u_int8_t pd_status; +#define MLX_PHYS_DRV_DEAD 0x00 +#define MLX_PHYS_DRV_WRONLY 0x02 +#define MLX_PHYS_DRV_ONLINE 0x03 +#define MLX_PHYS_DRV_STANDBY 0x10 + u_int8_t pd_res1; + u_int8_t pd_period; + u_int8_t pd_offset; + u_int32_t pd_config_size; +} __attribute__ ((packed)); + +struct mlx_core_cfg +{ + u_int8_t cc_num_sys_drives; + u_int8_t cc_res1[3]; + struct mlx_sys_drv cc_sys_drives[32]; + struct mlx_phys_drv cc_phys_drives[5 * 16]; +} __attribute__ ((packed)); + +struct mlx_dcdb +{ + u_int8_t dcdb_target:4; + u_int8_t dcdb_channel:4; + u_int8_t dcdb_flags; +#define MLX_DCDB_NO_DATA 0x00 +#define MLX_DCDB_DATA_IN 0x01 +#define MLX_DCDB_DATA_OUT 0x02 +#define MLX_DCDB_EARLY_STATUS (1<<2) +#define MLX_DCDB_TIMEOUT_10S 0x10 +#define MLX_DCDB_TIMEOUT_60S 0x20 +#define MLX_DCDB_TIMEOUT_20M 0x30 +#define MLX_DCDB_TIMEOUT_24H 0x40 +#define MLX_DCDB_NO_AUTO_SENSE (1<<6) +#define MLX_DCDB_DISCONNECT (1<<7) + u_int16_t dcdb_datasize; + u_int32_t dcdb_physaddr; + u_int8_t dcdb_cdb_length:4; + u_int8_t dcdb_datasize_high:4; + u_int8_t dcdb_sense_length; + u_int8_t dcdb_cdb[12]; + u_int8_t dcdb_sense[64]; + u_int8_t dcdb_status; + u_int8_t res1; +} __attribute__ ((packed)); + +struct mlx_bbtable_entry +{ + u_int32_t bbt_block_number; + u_int8_t bbt_extent; + u_int8_t res1; + u_int8_t bbt_entry_type; + u_int8_t bbt_system_drive:5; + u_int8_t res2:3; +} __attribute__ ((packed)); + Index: sys/dev/mlx/mlxreg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/mlx/mlxreg.h,v retrieving revision 1.7 diff -u -r1.7 mlxreg.h --- sys/dev/mlx/mlxreg.h 2000/04/11 02:52:45 1.7 +++ sys/dev/mlx/mlxreg.h 2001/05/24 09:36:29 @@ -26,32 +26,6 @@ * $FreeBSD: src/sys/dev/mlx/mlxreg.h,v 1.7 2000/04/11 02:52:45 msmith Exp $ */ -#define MLX_BLKSIZE 512 /* fixed feature */ - -/* - * Selected command codes. - */ -#define MLX_CMD_ENQUIRY_OLD 0x05 -#define MLX_CMD_ENQUIRY 0x53 -#define MLX_CMD_ENQUIRY2 0x1c -#define MLX_CMD_ENQSYSDRIVE 0x19 -#define MLX_CMD_READSG 0xb6 -#define MLX_CMD_WRITESG 0xb7 -#define MLX_CMD_READSG_OLD 0x82 -#define MLX_CMD_WRITESG_OLD 0x83 -#define MLX_CMD_FLUSH 0x0a -#define MLX_CMD_LOGOP 0x72 -#define MLX_CMD_REBUILDASYNC 0x16 -#define MLX_CMD_CHECKASYNC 0x1e -#define MLX_CMD_REBUILDSTAT 0x0c -#define MLX_CMD_STOPCHANNEL 0x13 -#define MLX_CMD_STARTCHANNEL 0x12 -#define MLX_CMD_READ_CONFIG 0x4e -#define MLX_CMD_DIRECT_CDB 0x04 -#define MLX_CMD_DEVICE_STATE 0x50 - -#ifdef _KERNEL - #define MLX_CFG_BASE0 0x10 /* first region */ #define MLX_CFG_BASE1 0x14 /* second region (type 3 only) */ @@ -190,312 +164,7 @@ #define MLX_V5_FWERROR_PEND (1<<2) /* firmware error pending */ -#endif /* _KERNEL */ - /* - * Scatter-gather list format, type 1, kind 00. - */ -struct mlx_sgentry -{ - u_int32_t sg_addr; - u_int32_t sg_count; -} __attribute__ ((packed)); - -/* - * Command result buffers, as placed in system memory by the controller. - */ - -struct mlx_enquiry_old /* MLX_CMD_ENQUIRY_OLD */ -{ - u_int8_t me_num_sys_drvs; - u_int8_t res1[3]; - u_int32_t me_drvsize[8]; - u_int16_t me_flash_age; - u_int8_t me_status_flags; - u_int8_t me_free_state_change_count; - u_int8_t me_fwminor; - u_int8_t me_fwmajor; - u_int8_t me_rebuild_flag; - u_int8_t me_max_commands; - u_int8_t me_offline_sd_count; - u_int8_t res3; - u_int8_t me_critical_sd_count; - u_int8_t res4[3]; - u_int8_t me_dead_count; - u_int8_t res5; - u_int8_t me_rebuild_count; - u_int8_t me_misc_flags; - struct - { - u_int8_t dd_targ; - u_int8_t dd_chan; - } __attribute__ ((packed)) me_dead[20]; -} __attribute__ ((packed)); - -struct mlx_enquiry /* MLX_CMD_ENQUIRY */ -{ - u_int8_t me_num_sys_drvs; - u_int8_t res1[3]; - u_int32_t me_drvsize[32]; - u_int16_t me_flash_age; - u_int8_t me_status_flags; -#define MLX_ENQ_SFLAG_DEFWRERR (1<<0) /* deferred write error indicator */ -#define MLX_ENQ_SFLAG_BATTLOW (1<<1) /* battery low */ - u_int8_t res2; - u_int8_t me_fwminor; - u_int8_t me_fwmajor; - u_int8_t me_rebuild_flag; - u_int8_t me_max_commands; - u_int8_t me_offline_sd_count; - u_int8_t res3; - u_int16_t me_event_log_seq_num; - u_int8_t me_critical_sd_count; - u_int8_t res4[3]; - u_int8_t me_dead_count; - u_int8_t res5; - u_int8_t me_rebuild_count; - u_int8_t me_misc_flags; -#define MLX_ENQ_MISC_BBU (1<<3) /* battery backup present */ - struct - { - u_int8_t dd_targ; - u_int8_t dd_chan; - } __attribute__ ((packed)) me_dead[20]; -} __attribute__ ((packed)); - -struct mlx_enquiry2 /* MLX_CMD_ENQUIRY2 */ -{ - u_int32_t me_hardware_id; - u_int32_t me_firmware_id; - u_int32_t res1; - u_int8_t me_configured_channels; - u_int8_t me_actual_channels; - u_int8_t me_max_targets; - u_int8_t me_max_tags; - u_int8_t me_max_sys_drives; - u_int8_t me_max_arms; - u_int8_t me_max_spans; - u_int8_t res2; - u_int32_t res3; - u_int32_t me_mem_size; - u_int32_t me_cache_size; - u_int32_t me_flash_size; - u_int32_t me_nvram_size; - u_int16_t me_mem_type; - u_int16_t me_clock_speed; - u_int16_t me_mem_speed; - u_int16_t me_hardware_speed; - u_int8_t res4[12]; - u_int16_t me_max_commands; - u_int16_t me_max_sg; - u_int16_t me_max_dp; - u_int16_t me_max_iod; - u_int16_t me_max_comb; - u_int8_t me_latency; - u_int8_t res5; - u_int8_t me_scsi_timeout; - u_int8_t res6; - u_int16_t me_min_freelines; - u_int8_t res7[8]; - u_int8_t me_rate_const; - u_int8_t res8[11]; - u_int16_t me_physblk; - u_int16_t me_logblk; - u_int16_t me_maxblk; - u_int16_t me_blocking_factor; - u_int16_t me_cacheline; - u_int8_t me_scsi_cap; - u_int8_t res9[5]; - u_int16_t me_firmware_build; - u_int8_t me_fault_mgmt_type; - u_int8_t res10; - u_int32_t me_firmware_features; - u_int8_t res11[8]; -} __attribute__ ((packed)); - -struct mlx_enq_sys_drive /* MLX_CMD_ENQSYSDRIVE returns an array of 32 of these */ -{ - u_int32_t sd_size; - u_int8_t sd_state; - u_int8_t sd_raidlevel; - u_int16_t res1; -} __attribute__ ((packed)); - -struct mlx_eventlog_entry /* MLX_CMD_LOGOP/MLX_LOGOP_GET */ -{ - u_int8_t el_type; - u_int8_t el_length; - u_char el_target:5; - u_char el_channel:3; - u_char el_lun:6; - u_char res1:2; - u_int16_t el_seqno; - u_char el_errorcode:7; - u_char el_valid:1; - u_int8_t el_segment; - u_char el_sensekey:4; - u_char res2:1; - u_char el_ILI:1; - u_char el_EOM:1; - u_char el_filemark:1; - u_int8_t el_information[4]; - u_int8_t el_addsense; - u_int8_t el_csi[4]; - u_int8_t el_asc; - u_int8_t el_asq; - u_int8_t res3[12]; -} __attribute__ ((packed)); - -#define MLX_LOGOP_GET 0x00 /* operation codes for MLX_CMD_LOGOP */ -#define MLX_LOGMSG_SENSE 0x00 /* log message contents codes */ - -struct mlx_rebuild_stat /* MLX_CMD_REBUILDSTAT */ -{ - u_int32_t rb_drive; - u_int32_t rb_size; - u_int32_t rb_remaining; -} __attribute__ ((packed)); - -struct mlx_config2 -{ - u_int16_t cf_flags1; -#define MLX_CF2_ACTV_NEG (1<<1) -#define MLX_CF2_NORSTRTRY (1<<7) -#define MLX_CF2_STRGWRK (1<<8) -#define MLX_CF2_HPSUPP (1<<9) -#define MLX_CF2_NODISCN (1<<10) -#define MLX_CF2_ARM (1<<13) -#define MLX_CF2_OFM (1<<15) -#define MLX_CF2_AEMI (MLX_CF2_ARM | MLX_CF2_OFM) - u_int8_t cf_oemid; - u_int8_t cf_oem_model; - u_int8_t cf_physical_sector; - u_int8_t cf_logical_sector; - u_int8_t cf_blockfactor; - u_int8_t cf_flags2; -#define MLX_CF2_READAH (1<<0) -#define MLX_CF2_BIOSDLY (1<<1) -#define MLX_CF2_REASS1S (1<<4) -#define MLX_CF2_FUAENABL (1<<6) -#define MLX_CF2_R5ALLS (1<<7) - u_int8_t cf_rcrate; - u_int8_t cf_res1; - u_int8_t cf_blocks_per_cache_line; - u_int8_t cf_blocks_per_stripe; - u_int8_t cf_scsi_param_0; - u_int8_t cf_scsi_param_1; - u_int8_t cf_scsi_param_2; - u_int8_t cf_scsi_param_3; - u_int8_t cf_scsi_param_4; - u_int8_t cf_scsi_param_5; - u_int8_t cf_scsi_initiator_id; - u_int8_t cf_res2; - u_int8_t cf_startup_mode; - u_int8_t cf_simultaneous_spinup_devices; - u_int8_t cf_delay_between_spinups; - u_int8_t cf_res3; - u_int16_t cf_checksum; -} __attribute__ ((packed)); - -struct mlx_sys_drv_span -{ - u_int32_t sp_start_lba; - u_int32_t sp_nblks; - u_int8_t sp_arm[8]; -} __attribute__ ((packed)); - -struct mlx_sys_drv -{ - u_int8_t sd_status; - u_int8_t sd_ext_status; - u_int8_t sd_mod1; - u_int8_t sd_mod2; - u_int8_t sd_raidlevel; -#define MLX_SYS_DRV_WRITEBACK (1<<7) -#define MLX_SYS_DRV_RAID0 0 -#define MLX_SYS_DRV_RAID1 1 -#define MLX_SYS_DRV_RAID3 3 -#define MLX_SYS_DRV_RAID5 5 -#define MLX_SYS_DRV_RAID6 6 -#define MLX_SYS_DRV_JBOD 7 - u_int8_t sd_valid_arms; - u_int8_t sd_valid_spans; - u_int8_t sd_init_state; -#define MLX_SYS_DRV_INITTED 0x81; - struct mlx_sys_drv_span sd_span[4]; -} __attribute__ ((packed)); - -struct mlx_phys_drv -{ - u_int8_t pd_flags1; -#define MLX_PHYS_DRV_PRESENT (1<<0) - u_int8_t pd_flags2; -#define MLX_PHYS_DRV_OTHER 0x00 -#define MLX_PHYS_DRV_DISK 0x01 -#define MLX_PHYS_DRV_SEQUENTIAL 0x02 -#define MLX_PHYS_DRV_CDROM 0x03 -#define MLX_PHYS_DRV_FAST20 (1<<3) -#define MLX_PHYS_DRV_SYNC (1<<4) -#define MLX_PHYS_DRV_FAST (1<<5) -#define MLX_PHYS_DRV_WIDE (1<<6) -#define MLX_PHYS_DRV_TAG (1<<7) - u_int8_t pd_status; -#define MLX_PHYS_DRV_DEAD 0x00 -#define MLX_PHYS_DRV_WRONLY 0x02 -#define MLX_PHYS_DRV_ONLINE 0x03 -#define MLX_PHYS_DRV_STANDBY 0x10 - u_int8_t pd_res1; - u_int8_t pd_period; - u_int8_t pd_offset; - u_int32_t pd_config_size; -} __attribute__ ((packed)); - -struct mlx_core_cfg -{ - u_int8_t cc_num_sys_drives; - u_int8_t cc_res1[3]; - struct mlx_sys_drv cc_sys_drives[32]; - struct mlx_phys_drv cc_phys_drives[5 * 16]; -} __attribute__ ((packed)); - -struct mlx_dcdb -{ - u_int8_t dcdb_target:4; - u_int8_t dcdb_channel:4; - u_int8_t dcdb_flags; -#define MLX_DCDB_NO_DATA 0x00 -#define MLX_DCDB_DATA_IN 0x01 -#define MLX_DCDB_DATA_OUT 0x02 -#define MLX_DCDB_EARLY_STATUS (1<<2) -#define MLX_DCDB_TIMEOUT_10S 0x10 -#define MLX_DCDB_TIMEOUT_60S 0x20 -#define MLX_DCDB_TIMEOUT_20M 0x30 -#define MLX_DCDB_TIMEOUT_24H 0x40 -#define MLX_DCDB_NO_AUTO_SENSE (1<<6) -#define MLX_DCDB_DISCONNECT (1<<7) - u_int16_t dcdb_datasize; - u_int32_t dcdb_physaddr; - u_int8_t dcdb_cdb_length:4; - u_int8_t dcdb_datasize_high:4; - u_int8_t dcdb_sense_length; - u_int8_t dcdb_cdb[12]; - u_int8_t dcdb_sense[64]; - u_int8_t dcdb_status; - u_int8_t res1; -} __attribute__ ((packed)); - -struct mlx_bbtable_entry -{ - u_int32_t bbt_block_number; - u_int8_t bbt_extent; - u_int8_t res1; - u_int8_t bbt_entry_type; - u_int8_t bbt_system_drive:5; - u_int8_t res2:3; -} __attribute__ ((packed)); - -#ifdef _KERNEL -/* * Inlines to build various command structures */ static __inline void @@ -616,5 +285,3 @@ mc->mc_mailbox[0xb] = (f4 >> 24) & 0xff; mc->mc_mailbox[0xc] = f5; } - -#endif /* _KERNEL */ Index: usr.sbin/mlxcontrol/command.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/mlxcontrol/command.c,v retrieving revision 1.2 diff -u -r1.2 command.c --- usr.sbin/mlxcontrol/command.c 2000/04/11 23:04:17 1.2 +++ usr.sbin/mlxcontrol/command.c 2001/05/24 09:36:30 @@ -35,7 +35,6 @@ #include #include -#include #include "mlxcontrol.h" Index: usr.sbin/mlxcontrol/config.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/mlxcontrol/config.c,v retrieving revision 1.2 diff -u -r1.2 config.c --- usr.sbin/mlxcontrol/config.c 2000/04/11 23:04:17 1.2 +++ usr.sbin/mlxcontrol/config.c 2001/05/24 09:36:33 @@ -35,7 +35,6 @@ #include #include -#include #include "mlxcontrol.h" Index: usr.sbin/mlxcontrol/interface.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/mlxcontrol/interface.c,v retrieving revision 1.2 diff -u -r1.2 interface.c --- usr.sbin/mlxcontrol/interface.c 2000/04/11 23:04:17 1.2 +++ usr.sbin/mlxcontrol/interface.c 2001/05/24 09:36:33 @@ -34,7 +34,6 @@ #include #include -#include #include "mlxcontrol.h" Index: usr.sbin/mlxcontrol/util.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/mlxcontrol/util.c,v retrieving revision 1.2 diff -u -r1.2 util.c --- usr.sbin/mlxcontrol/util.c 2000/04/11 23:04:17 1.2 +++ usr.sbin/mlxcontrol/util.c 2001/05/24 09:36:33 @@ -32,7 +32,6 @@ #include #include -#include #include "mlxcontrol.h" --+HP7ph2BbKc20aGI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 24 2:59: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 3E35037B42C; Thu, 24 May 2001 02:59:06 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 152rtZ-0005bq-0Y; Thu, 24 May 2001 10:59:05 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f4O9vn758825; Thu, 24 May 2001 10:57:49 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 24 May 2001 10:57:49 +0100 (BST) From: Doug Rabson To: Brian Somers Cc: Mike Smith , Subject: Re: RFC: unit_list routines In-Reply-To: <200105231600.f4NG0VF05877@hak.lan.Awfulhak.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, 23 May 2001, Brian Somers wrote: > > > unit_list just concerns itself with allocating a bunch of int ranges. > > > > > > Do you really think it's appropriate to try to re-use the rman stuff > > > for what I want to do ? > > > > Yes. By all means, wrap the rman interface with something that makes it > > clearer what you're doing, but if you're managing a finite set of > > resources of some sort, you should avoid reinventing the wheel where > > possible. > > The way I see it, I need a wheel. rman is a chassis that you can > attach a wheel to. > > I'd rather have my own private wheel as I don't need the tires, > inner tubes and all the other stuff that comes with rman :) > > > (It's not clear yet whether any of the items on your list actually relate > > to tangible performance penalties, about the only good reason to consider > > NIH.) > > My real problems are the mutexes (unnecessary contention), the memory > overheads (all this extra zero-filled memory) and the obfuscation. I'm sorry but just how many unit allocations are you planning to do? There are only going to be a handful of them and the mutex/memory overheads are just noise compared to the rest of the kernel. -- 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 Thu May 24 3: 1:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id AF57F37B423 for ; Thu, 24 May 2001 03:01:05 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 152rvU-000Bi3-0K; Thu, 24 May 2001 10:01:04 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f4O9xm758829; Thu, 24 May 2001 10:59:48 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 24 May 2001 10:59:48 +0100 (BST) From: Doug Rabson To: Poul-Henning Kamp Cc: Brian Somers , Garrett Wollman , Subject: Re: RFC: unit_list routines In-Reply-To: <3487.990636871@critter> 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, 23 May 2001, Poul-Henning Kamp wrote: > In message <200105231552.f4NFqwF05688@hak.lan.Awfulhak.org>, Brian Somers write > s: > > >I didn't do it that way because the ``usual'' way units are allocated > >is sequentially. Using bits when there are large numbers of units > >gets awkward. I figured what was required was something small and > >simple that would cover the requirements of most/all drivers that > >need to track their units so that it's easy to find an unused one, > >and it's easy to allocate/deallocate things. > > How does newbus allocate/manage unit numbers ? The devclass object manages them. A devclass more-or-less represents all devices which share a name. For instance if a new pci bus is discovered, the system finds the devclass for "pci" and asks for the next available unit number. This stuff pre-dates the resource manager which is being discussed which accounts for the duplicated functionality. -- 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 Thu May 24 3: 2:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 25EA537B43E for ; Thu, 24 May 2001 03:02:29 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 152rwq-00076o-0Y; Thu, 24 May 2001 11:02:28 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f4OA1C758839; Thu, 24 May 2001 11:01:12 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 24 May 2001 11:01:12 +0100 (BST) From: Doug Rabson To: Brian Somers Cc: Poul-Henning Kamp , Garrett Wollman , Subject: Re: RFC: unit_list routines In-Reply-To: <200105231702.f4NH29F07183@hak.lan.Awfulhak.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, 23 May 2001, Brian Somers wrote: > > In message <200105231552.f4NFqwF05688@hak.lan.Awfulhak.org>, Brian Somers write > > s: > > > > >I didn't do it that way because the ``usual'' way units are allocated > > >is sequentially. Using bits when there are large numbers of units > > >gets awkward. I figured what was required was something small and > > >simple that would cover the requirements of most/all drivers that > > >need to track their units so that it's easy to find an unused one, > > >and it's easy to allocate/deallocate things. > > > > How does newbus allocate/manage unit numbers ? > > I don't think it does. The only way to find out what's in use > (AFAIK) is by looking at every specinfo in dev_hash.... Wrong layer. The dev_hash stuff is part of the devfs layer - not all the devices which newbus manages are represented in devfs. -- 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 Thu May 24 3: 4:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 03D9437B422 for ; Thu, 24 May 2001 03:04:44 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 152rz1-0008AQ-0Y; Thu, 24 May 2001 11:04:43 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f4OA3R758856; Thu, 24 May 2001 11:03:27 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 24 May 2001 11:03:27 +0100 (BST) From: Doug Rabson To: Brian Somers Cc: Garrett Wollman , Subject: Re: RFC: unit_list routines In-Reply-To: <200105231944.f4NJiXF09637@hak.lan.Awfulhak.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, 23 May 2001, Brian Somers wrote: > > > > Using bits when there are large numbers of units gets awkward. > > > > > > Just wrap it in macros. I almost posted an implementation with my > > > last message, but decided that since it was so trivial it would be > > > almost insulting for me to do so. > > > > Not true - I'm too thick skinned to be insulted :oI > > > > I'll look at a macro implementation. > > Ok, I've thought about this :-/ I don't think it's practical to > do this with bits if someone does > > # ppp -unit 16777215 > > I then have to go off and allocate an array of 0x7fffff bytes just to > record the fact that someone's using a silly unit number. > > I think this must be done as a sparce set of ranges.... ie, my > original idea seems to still stand. The resource manager implementation would handle this efficiently. It is pretty good at managing large sparse ranges (such as device memory maps). -- 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 Thu May 24 3: 8:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id 82EB637B423; Thu, 24 May 2001 03:08:14 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 152s2P-0007QH-0B; Thu, 24 May 2001 10:08:13 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f4OA6v758884; Thu, 24 May 2001 11:06:57 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 24 May 2001 11:06:57 +0100 (BST) From: Doug Rabson To: Brian Somers Cc: Mike Smith , Subject: Re: RFC: unit_list routines In-Reply-To: <200105232020.f4NKK2F10389@hak.lan.Awfulhak.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, 23 May 2001, Brian Somers wrote: > > > > > >I didn't do it that way because the ``usual'' way units are allocated > > > > > >is sequentially. Using bits when there are large numbers of units > > > > > >gets awkward. I figured what was required was something small and > > > > > >simple that would cover the requirements of most/all drivers that > > > > > >need to track their units so that it's easy to find an unused one, > > > > > >and it's easy to allocate/deallocate things. > > > > > > > > > > How does newbus allocate/manage unit numbers ? > > > > > > > > I don't think it does. The only way to find out what's in use > > > > (AFAIK) is by looking at every specinfo in dev_hash.... > > > > > > Er, what exactly are you smoking? > > > > > > Newbus manages unit numbers using the devclass: > > > > > > struct devclass { > > > TAILQ_ENTRY(devclass) link; > > > driver_list_t drivers; /* bus devclasses store drivers for bus */ > > > char *name; > > > device_t *devices; /* array of devices indexed by unit */ > > > int maxunit; /* size of devices array */ > > > }; > > > > Yes, Garrett pointed this out. I misunderstood the question because > > newbus doesn't manage unit numbers. It ``manages'' the maximum unit > > number allocated and nothing else. > > > > My answer was describing the only way I know of to figure out which > > units for a given device are allocated/opened. > > Hmm, hang on. I'll stop smoking.... If that device_t array knows > which devices are open it could solve my problems... This object will not help you unless we rewrite the pseudo devices to use newbus. You don't have a device_t instance for your tunX instance. I can think of good reasons for wanting to represent pseudo devices with newbus but it doesn't work that way right now. -- 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 Thu May 24 3: 9:58 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 5CC1937B422; Thu, 24 May 2001 03:09:54 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 152s41-000Iwo-0V; Thu, 24 May 2001 11:09:53 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f4OA8b758888; Thu, 24 May 2001 11:08:37 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 24 May 2001 11:08:37 +0100 (BST) From: Doug Rabson To: Brian Somers Cc: Mike Smith , Subject: Re: RFC: unit_list routines In-Reply-To: <200105232109.f4NL9RF11365@hak.lan.Awfulhak.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, 23 May 2001, Brian Somers wrote: > > > > > > >I didn't do it that way because the ``usual'' way units are allocated > > > > > > >is sequentially. Using bits when there are large numbers of units > > > > > > >gets awkward. I figured what was required was something small and > > > > > > >simple that would cover the requirements of most/all drivers that > > > > > > >need to track their units so that it's easy to find an unused one, > > > > > > >and it's easy to allocate/deallocate things. > > > > > > > > > > > > How does newbus allocate/manage unit numbers ? > > > > > > > > > > I don't think it does. The only way to find out what's in use > > > > > (AFAIK) is by looking at every specinfo in dev_hash.... > > > > > > > > Er, what exactly are you smoking? > > > > > > > > Newbus manages unit numbers using the devclass: > > > > > > > > struct devclass { > > > > TAILQ_ENTRY(devclass) link; > > > > driver_list_t drivers; /* bus devclasses store drivers for bus */ > > > > char *name; > > > > device_t *devices; /* array of devices indexed by unit */ > > > > int maxunit; /* size of devices array */ > > > > }; > > > > > > Yes, Garrett pointed this out. I misunderstood the question because > > > newbus doesn't manage unit numbers. It ``manages'' the maximum unit > > > number allocated and nothing else. > > > > > > My answer was describing the only way I know of to figure out which > > > units for a given device are allocated/opened. > > > > Hmm, hang on. I'll stop smoking.... If that device_t array knows > > which devices are open it could solve my problems... > > Where did I put that smoke.... > > Anyone care to try > > # ppp -unit 16777215 > > I don't care for the consistency of the results (/dev/tun16777215 is > created ok, but seems to be talking to interface tun0). Is subr_bus.c > *really* trying to allocate 0xffffff device_t pointers and set them > all except the last to NULL ? That's 67Mb of memory. > > Funnily enough, netstat -i takes quite a while to run, and yep, I'm > using up a bit of swap. > > I think devclass needs to be fixed. Maybe it should use this new > ``struct unit_list'' that I happen to have handy - or even better, it > could use the rman stuff !!! :*D It might be worthwhile to make devclass use rman. Fortunately for driver writers, this part of the implementation is entireley hidden and changing it would be trivial and wouldn't affect existing drivers (source *or* binary). -- 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 Thu May 24 3:17:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id D2C7337B424; Thu, 24 May 2001 03:17:09 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 152sB2-000EEi-0K; Thu, 24 May 2001 10:17:08 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f4OAFq758915; Thu, 24 May 2001 11:15:53 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 24 May 2001 11:15:52 +0100 (BST) From: Doug Rabson To: Peter Wemm Cc: Brian Somers , Mike Smith , Subject: Re: RFC: unit_list routines In-Reply-To: <20010524061235.0413C380C@overcee.netplex.com.au> 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, 23 May 2001, Peter Wemm wrote: > Besides, the sys/kern/unit_list.c and sys/unit_list.h files are badly > misnamed. At the very least, it should be sys/kern/subr_units.c or > something along those lines. (next to subr_bus.c and subr_rman.c). > I still dont believe that we need it though. Also, there is absolutely no need to define 'struct unit_list' in the header. It isn't needed if you are using the api - a simple forward declaration would suffice. Having it defined publically encourages perverted users to dig around in the implementation's private structures and can cause unnescessary binary compatibility problems if the implementation changes. -- 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 Thu May 24 18: 6:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 9A4FC37B422 for ; Thu, 24 May 2001 18:06:49 -0700 (PDT) (envelope-from DougB@DougBarton.net) Received: from DougBarton.net (master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id SAA18971; Thu, 24 May 2001 18:06:40 -0700 (PDT) (envelope-from DougB@DougBarton.net) Message-ID: <3B0DB020.885F5ED0@DougBarton.net> Date: Thu, 24 May 2001 18:06:40 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: contrib code and gnu build glue (was [CFR] /sys/miscfs/* -> /sys/fs/) References: <55383.990687667@axl.fw.uunet.co.za> 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 Sheldon Hearn wrote: > > On Wed, 23 May 2001 13:46:50 MST, Doug Barton wrote: > I've always thought that putting code in one place and build glue in another > is clever. It allows us to provide the code as close as supplied as > possible. > > You don't actually say what you have against the scheme. Care to > elaborate? I wish the whole thing were cleaner. There is too much "a little bit of this," and "a little bit of that" in the status quo. What'd really be nice for the current arrangement is if src/gnu had all of the 3rd party GPV'ed code, and src/contrib had all of the other 3rd party code except the bits related to encryption, which should still go in src/secure to help the people living under oppressive regimes. Then ALL of the build glue should go in its respective home under src/whatever. However, the work spent on that would be better spent on making the system more modular to start with, and that's a bikeshed of a different color. -- I need someone really bad. Are you really bad? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 24 18:15: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id D4AF537B423 for ; Thu, 24 May 2001 18:14:59 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@[206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f4P1Ewl25025; Thu, 24 May 2001 18:14:58 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f4P1Eoe14321; Thu, 24 May 2001 18:14:50 -0700 (PDT) (envelope-from obrien) Date: Thu, 24 May 2001 18:14:49 -0700 From: "David O'Brien" To: Doug Barton Cc: Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: contrib code and gnu build glue (was [CFR] /sys/miscfs/* -> /sys/fs/) Message-ID: <20010524181449.C13912@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <55383.990687667@axl.fw.uunet.co.za> <3B0DB020.885F5ED0@DougBarton.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B0DB020.885F5ED0@DougBarton.net>; from DougB@DougBarton.net on Thu, May 24, 2001 at 06:06:40PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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, May 24, 2001 at 06:06:40PM -0700, Doug Barton wrote: > I wish the whole thing were cleaner. There is too much "a little bit of > this," and "a little bit of that" in the status quo. What'd really be nice > for the current arrangement is if src/gnu had all of the 3rd party GPV'ed > code, and src/contrib had all of the other 3rd party code except the bits > related to encryption, I would like that -- say /usr/src/gnu/dist/ for the GPV bits in /usr/src/contrib/ However, there is the repo bloat.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 24 18:15:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-39.dsl.lsan03.pacbell.net [63.207.60.39]) by hub.freebsd.org (Postfix) with ESMTP id A1B1837B423 for ; Thu, 24 May 2001 18:15:09 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3571866B5F; Thu, 24 May 2001 18:15:09 -0700 (PDT) Date: Thu, 24 May 2001 18:15:09 -0700 From: Kris Kennaway To: Peter Wemm Cc: Greg Lehey , arch@FreeBSD.ORG Subject: Re: http://uptime.netcraft.com/up/accuracy.html#cycle Message-ID: <20010524181509.A38098@xor.obsecurity.org> References: <20010524094750.A74859@wantadilla.lemis.com> <20010524070153.6DECA3811@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010524070153.6DECA3811@overcee.netplex.com.au>; from peter@wemm.org on Thu, May 24, 2001 at 12:01:53AM -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 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 24, 2001 at 12:01:53AM -0700, Peter Wemm wrote: > I think it means that we need to run a timer on it at a fixed 20hz so that > our uptime values double. ;-) Actually, I dont think that will help beca= use > they check over several days to determine the CC count rate. But we shou= ld > probably use a fixed rate since people do change their HZ values in certa= in > situations. >=20 > netcraft's uptime counter looks at the RFC1323 timestamp option (which we > have off by default now, so it is academic :-( ) and detects the 500ms > update rate or the 10ms update rate for FreeBSD systems. It can use this= to > determine the uptime 'remotely' by fingerprinting the system. >=20 > See: > http://uptime.netcraft.co.uk/up/graph?site=3Dwww.freebsd.org >=20 > Incidently, we should turn TCP_EXTENSIONS (rfc1323) back on by default. > Linux has had it on for a while now and has "cleared the way" for us. It may not be something some people care about, but there have been a number of remote attacks which depend on knowing precisely how long the target machine has been up for. Kris --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7DbIcWry0BWjoQKURAo07AJ9civyaHQT4hwG7in8Z5+q57mtVPACfWXW4 HLVQ+PK4Odn9y6iXYqxglsg= =4Jzn -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 24 21:12:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B232337B423 for ; Thu, 24 May 2001 21:12:26 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f4P4CCE60046; Thu, 24 May 2001 22:12:12 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200105250412.f4P4CCE60046@harmony.village.org> To: Poul-Henning Kamp Subject: Re: RFC: unit_list routines Cc: Garrett Wollman , Brian Somers , freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 23 May 2001 19:19:10 +0200." <9639.990638350@critter> References: <9639.990638350@critter> Date: Thu, 24 May 2001 22:12:12 -0600 From: Warner Losh 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 <9639.990638350@critter> Poul-Henning Kamp writes: : >This may have changed, but my recollection is that new-bus looks for : >the greatest allocated unit number and then takes the next one. Since : >this is initialization code, the fact that this is O(n^2) is of no : >consequence. : : For pty and tun devices, this assumption may not hold... Only if you want a packed name space. VMS for years just bumped a counter that wrapped at 65k. It then checked for collisions. There was also a count of the number of PTYs so that you'd know if you'd hit the pathological case of all 65k PTYs in use :-). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 24 21:13:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9100537B422 for ; Thu, 24 May 2001 21:13:43 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f4P4DbE60065; Thu, 24 May 2001 22:13:37 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200105250413.f4P4DbE60065@harmony.village.org> To: Brian Somers Subject: Re: RFC: unit_list routines Cc: Garrett Wollman , freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 23 May 2001 18:48:22 BST." <200105231748.f4NHmMF08217@hak.lan.Awfulhak.org> References: <200105231748.f4NHmMF08217@hak.lan.Awfulhak.org> Date: Thu, 24 May 2001 22:13:37 -0600 From: Warner Losh 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 <200105231748.f4NHmMF08217@hak.lan.Awfulhak.org> Brian Somers writes: : > I think the usual watchword is ``Don't optimize initialization.'' : : Maybe, but pessimising for no gains seems odd. Not optimizing is different than pessimizing. The usual phrase I hear around here is "premature submicro optimization." That is, optimizing before you know what's slow and in a way that won't matter in the end. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 24 21:20:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 498FF37B422 for ; Thu, 24 May 2001 21:20:46 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f4P4KYE60097; Thu, 24 May 2001 22:20:34 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200105250420.f4P4KYE60097@harmony.village.org> To: Doug Barton Subject: Re: contrib code and gnu build glue (was [CFR] /sys/miscfs/* -> /sys/fs/) Cc: Sheldon Hearn , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 24 May 2001 18:06:40 PDT." <3B0DB020.885F5ED0@DougBarton.net> References: <3B0DB020.885F5ED0@DougBarton.net> <55383.990687667@axl.fw.uunet.co.za> Date: Thu, 24 May 2001 22:20:34 -0600 From: Warner Losh 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 <3B0DB020.885F5ED0@DougBarton.net> Doug Barton writes: : I wish the whole thing were cleaner. There is too much "a little bit of : this," and "a little bit of that" in the status quo. What'd really be nice : for the current arrangement is if src/gnu had all of the 3rd party GPV'ed : code, and src/contrib had all of the other 3rd party code except the bits : related to encryption, which should still go in src/secure to help the : people living under oppressive regimes. Then ALL of the build glue should : go in its respective home under src/whatever. You see a transition state. All the GPL'd code is moved out of src/gnu into src/contrib. src/gnu is the tree for building code only, not for storing it. src/usr.bin (et al) are used when the code isn't gpl'd. We do this so that the build can easily eliminate building of gpl by removing gnu from the top level makefile. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 25 0: 3:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 2FEBB37B42C for ; Fri, 25 May 2001 00:03:51 -0700 (PDT) (envelope-from DougB@DougBarton.net) Received: from DougBarton.net (master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id AAA21443; Fri, 25 May 2001 00:03:40 -0700 (PDT) (envelope-from DougB@DougBarton.net) Message-ID: <3B0E03CC.4B5971F1@DougBarton.net> Date: Fri, 25 May 2001 00:03:40 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: Sheldon Hearn , arch@FreeBSD.ORG Subject: Re: contrib code and gnu build glue (was [CFR] /sys/miscfs/* -> /sys/fs/) References: <3B0DB020.885F5ED0@DougBarton.net> <55383.990687667@axl.fw.uunet.co.za> <200105250420.f4P4KYE60097@harmony.village.org> 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 Warner Losh wrote: > > In message <3B0DB020.885F5ED0@DougBarton.net> Doug Barton writes: > : I wish the whole thing were cleaner. There is too much "a little bit of > : this," and "a little bit of that" in the status quo. What'd really be nice > : for the current arrangement is if src/gnu had all of the 3rd party GPV'ed > : code, and src/contrib had all of the other 3rd party code except the bits > : related to encryption, which should still go in src/secure to help the > : people living under oppressive regimes. Then ALL of the build glue should > : go in its respective home under src/whatever. > > You see a transition state. All the GPL'd code is moved out of > src/gnu into src/contrib. src/gnu is the tree for building code only, > not for storing it. src/usr.bin (et al) are used when the code isn't > gpl'd. We do this so that the build can easily eliminate building of > gpl by removing gnu from the top level makefile. I understand the current situation, I just don't like it. :) IMO it would be better to leave the sources in src/gnu and have the make glue depend on whether the sources are present to build or not. That way all I have to do is remove the directory with the specific sources I want to delete and get rid of the source and the build decision in one step. But as I said previously, any effort spent on this would be better spent on making the whole system more modular. -- I need someone really bad. Are you really bad? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 25 5:40:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id B834C37B422 for ; Fri, 25 May 2001 05:40:31 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f4PCeO612402 for ; Fri, 25 May 2001 14:40:27 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200105251240.f4PCeO612402@gratis.grondar.za> To: arch@freebsd.org Subject: PAM, S/Key and authentication schemes. Date: Fri, 25 May 2001 14:42:40 +0200 From: Mark Murray 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 We currently have a slew of authentication schemes in FreeBSD. There is the usual lot in getpwent(3) and friends, OPIE, S/Key and PAM, and then a bunch of home-rolled ones such as the WHEELSU rules in su(1), and the anonymous user rules in ftpd(8). There is also kerberos in 2 forms, SSH, and the r-utils .rhosts files. I'd like to simplify this lot in a way that makes it easy for the administrator to decide her own policy. PAM is ideal for this. I have already tested this on my home cluster with su(1) (I just made su a PAM-only thing), and this makes the code a whole lot simpler. Simpler code == safer code. I'd like to properly PAM-ize the things that need it, and simplify where possible and where appropriate. In most cases, this means gutting out the convoluted logic if favour of pam _only_. (Obviously SSH will need its own scheme as well). This means that PAM modules like pam_rhosts, pam_anonymous, pam_shells pam_tcpd and so on can be used to set custom policies on a per-site basis (Yeah, yeah, these need to be written!). S/Key is OBE in my opinion and needs to be entirely replaced by OPIE. (And in the majority of cases pam_opie will do the job). Comments? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 25 5:47:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 37F3E37B422 for ; Fri, 25 May 2001 05:47:49 -0700 (PDT) (envelope-from sheldonh@uunet.co.za) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 153H0L-00050e-00; Fri, 25 May 2001 14:47:45 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id OAA28301; Fri, 25 May 2001 14:47:44 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 28118; Fri May 25 14:47:04 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.22 #1) id 153Gzg-000NKA-00; Fri, 25 May 2001 14:47:04 +0200 From: Sheldon Hearn To: Mark Murray Cc: arch@freebsd.org Subject: Re: PAM, S/Key and authentication schemes. In-reply-to: Your message of "Fri, 25 May 2001 14:42:40 +0200." <200105251240.f4PCeO612402@gratis.grondar.za> Date: Fri, 25 May 2001 14:47:04 +0200 Message-ID: <89661.990794824@axl.fw.uunet.co.za> 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 Fri, 25 May 2001 14:42:40 +0200, Mark Murray wrote: > I have already tested this on my home cluster with su(1) (I just > made su a PAM-only thing), and this makes the code a whole lot > simpler. Simpler code == safer code. I think that the real win here is that we come out with a FreeBSD that uses a flexible authentication management system that requires once-off learning that can then be applied to the configuration of policies for multiple tools. Of course there are other benefits. One is the ease of implementation of new authentication schemes that, once deployed, are immediately available in all the appropraite tools). I think where you're going with this is excellent. What's your anticipated time frame for getting what we have today rationalized? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 25 8: 8:26 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 D54E737B42C for ; Fri, 25 May 2001 08:08:17 -0700 (PDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f4PF8G670260; Fri, 25 May 2001 09:08:16 -0600 (MDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f4PF8Rl42469; Fri, 25 May 2001 09:08:27 -0600 (MDT) Message-Id: <200105251508.f4PF8Rl42469@billy-club.village.org> To: Doug Barton Subject: Re: contrib code and gnu build glue (was [CFR] /sys/miscfs/* -> /sys/fs/) Cc: Sheldon Hearn , arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 25 May 2001 00:03:40 PDT." <3B0E03CC.4B5971F1@DougBarton.net> References: <3B0E03CC.4B5971F1@DougBarton.net> <3B0DB020.885F5ED0@DougBarton.net> <55383.990687667@axl.fw.uunet.co.za> <200105250420.f4P4KYE60097@harmony.village.org> Date: Fri, 25 May 2001 09:08:27 -0600 From: Warner Losh 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 <3B0E03CC.4B5971F1@DougBarton.net> Doug Barton writes: : I understand the current situation, I just don't like it. :) IMO it would : be better to leave the sources in src/gnu and have the make glue depend on : whether the sources are present to build or not. That way all I have to do : is remove the directory with the specific sources I want to delete and get : rid of the source and the build decision in one step. I disagree. As someone who has to build reduced systems, this would be a huge pain. Hacking one file is far easier than trying to remove sources. This is especially true when you are building a "development" system that has everything, and a "deployed" system that has only non-gnu stuff to the extent possible. Having to remove trees to do that when you keep it under CVS is a huge pain. Believe me, I've tried both models and the delete it first one always leads to pain and suffering. Esepcially when you accidentally delete a change that you needed for the other side of the house. FreeBSD is very modular right now. With a tiny amount of glue, we were able to install only the files we needed on the system. A couple of more tweaks and we wouldn't need a "cleanup" pass that we do on our systems. It just isn't worth the pain to go that rought. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat May 26 14:55:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id CB8CD37B422 for ; Sat, 26 May 2001 14:55:24 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@[206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f4QLtNl37907; Sat, 26 May 2001 14:55:23 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f4QLtLp12084; Sat, 26 May 2001 14:55:21 -0700 (PDT) (envelope-from obrien) Date: Sat, 26 May 2001 14:55:21 -0700 From: "David O'Brien" To: Mark Murray Cc: arch@freebsd.org Subject: Re: PAM, S/Key and authentication schemes. Message-ID: <20010526145521.D11876@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200105251240.f4PCeO612402@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105251240.f4PCeO612402@gratis.grondar.za>; from mark@grondar.za on Fri, May 25, 2001 at 02:42:40PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 Fri, May 25, 2001 at 02:42:40PM +0200, Mark Murray wrote: > We currently have a slew of authentication schemes in FreeBSD. There > is the usual lot in getpwent(3) and friends, OPIE, S/Key and PAM, and Is there some reason we cannot `cvs rm' S/Key and only use OPIE? OPIE was intended as a replacement for S/Key. > S/Key is OBE in my opinion and needs to be entirely replaced by OPIE. > (And in the majority of cases pam_opie will do the job). Do you know why ?ache? did not totally replace S/Key when he imported OPIE? -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message