From owner-freebsd-arch Sun Feb 25 0: 7:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-199.dsl.lsan03.pacbell.net [63.207.60.199]) by hub.freebsd.org (Postfix) with ESMTP id 5565837B503; Sun, 25 Feb 2001 00:07:02 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 028FE67150; Sun, 25 Feb 2001 00:07:01 -0800 (PST) Date: Sun, 25 Feb 2001 00:07:01 -0800 From: Kris Kennaway To: Matt Dillon Cc: Bruce Evans , Robert Watson , Nick Sayer , cvs-committers@FreeBSD.ORG, arch@FreeBSD.org Subject: Re: cvs commit: ports/astro/xglobe/files patch-random Message-ID: <20010225000701.B10488@mollari.cthul.hu> References: <200102250640.f1P6e0q11960@earth.backplane.com> <20010224225935.A769@mollari.cthul.hu> <200102250725.f1P7PVs12297@earth.backplane.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102250725.f1P7PVs12297@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Feb 24, 2001 at 11:25:31PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 24, 2001 at 11:25:31PM -0800, Matt Dillon wrote: > :This isn't true -- as it stands now, people are writing code which > :produces bad behaviour (e.g. the xglobe stars thing), or is insecure, > :because they are ignoring the documentation. If we add a link-time > :warning it will probably catch more software writers, and the net > :result is positive. It also points out instances of possibly bad > :software which FreeBSD porters and committers can address, again a > :positive change. It wastes no-one's time except about 30 seconds of > :mine, which I was happy to give :-) >=20 > All that adding a compile-time warning will do is annoy anyone trying > to use the interface legitimately. If you have a problem with a > particular programmer's use of the interface, you should email that > programmer. We are not responsible for programmers who ignore=20 > documentation. While it is nice to have some warnings in there, > there is a limit to what we should be doing to save the programmer > from himself. Many of these people aren't even using FreeBSD, so > I really doubt that adding #warnings to our compilation environment > will actually do what you think it will do, especially in regards > to ports. Yes, many software authors don't use FreeBSD, but many do, and the second benefit I pointed out above stands. > People have gone overboard before... the strftime() warning, for > example, is extremely annoying to me because I am using strftime() > exactly the way it is documented to be used. Some overzealous bozo > decided the best way to warn everyone about Y2K was to cause the > compiler to spew warnings out from 2-digit years formatted with > strftime(). Bah. What you are proposing here is something of the > same ilk. Stop complaining to me about strftime, it's not the same thing. Kris --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6mL0lWry0BWjoQKURAo6pAKDl/mb1qAa5ddux7g6iDnrXfr8qqQCgviz+ Kd4LGPtHLdMw5NCzpBe7wc0= =WSFn -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 0:58:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-199.dsl.lsan03.pacbell.net [63.207.60.199]) by hub.freebsd.org (Postfix) with ESMTP id 2747537B491 for ; Sun, 25 Feb 2001 00:58:14 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CCB8066F83; Sun, 25 Feb 2001 00:58:13 -0800 (PST) Date: Sun, 25 Feb 2001 00:58:13 -0800 From: Kris Kennaway To: arch@FreeBSD.org Subject: Re: cvs commit: ports/astro/xglobe/files patch-random Message-ID: <20010225005813.A29124@mollari.cthul.hu> References: <200102250640.f1P6e0q11960@earth.backplane.com> <20010224225935.A769@mollari.cthul.hu> <20010225095240.A77183@student.uu.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010225095240.A77183@student.uu.se>; from ertr1013@student.uu.se on Sun, Feb 25, 2001 at 09:52:40AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 25, 2001 at 09:52:40AM +0100, Erik Trulsson wrote: > No, the algorithm of rand() is not standardized in the C standard. >=20 > OTOH, there is an example of a portable implementation of rand() in the > C standard and FreeBSD uses the same algorithm (as does many other > implementations of rand()). This is probably what you were thinking of. >=20 > As long as rand() and srand() behaves as describe in the man-page for > rand(3) they confirm to the C standard. (Provided that RAND_MAX is at=20 > least 32767.) That's good to know. I'll look at replacing it with something better that has the same semantics, so we solve this problem at the source. Kris --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6mMklWry0BWjoQKURApBcAKCTBilq4rUIMRjveYg1ZuFxPsSLCACfUNY4 R2TN08DNdTm6W5F4o5Aures= =JsDu -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 2:52:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 5C21137B401 for ; Sun, 25 Feb 2001 02:52:13 -0800 (PST) (envelope-from oppermann@monzoon.net) Received: (qmail 34650 invoked from network); 25 Feb 2001 10:49:07 -0000 Received: from unknown (HELO monzoon.net) ([195.134.140.21]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 25 Feb 2001 10:49:07 -0000 Message-ID: <3A98DB77.AE110714@monzoon.net> Date: Sun, 25 Feb 2001 11:16:23 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Wes Peters Cc: Jos Backus , arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102190547.WAA12829@usr05.primenet.com> <3A90CA94.D7CBCB65@softweyr.com> <20010218233916.J28286@lizzy.bugworks.com> <3A9149CC.7A1FADB8@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > > Jos Backus wrote: > > > > [This is rapidly turning into a bikeshed...] > > > > On Mon, Feb 19, 2001 at 12:25:50AM -0700, Wes Peters wrote: > > > Some of the assumptions behind the operation of djbdns may not hold true > > > for your installation. > > > > Some of those behind BIND's operation may not either. > > > > BIND's instability and problems are costing people and companies all over the > > world real time and money. > > But with BIND, you the user can fix them. You can do that with DJBDNS, too, > but you can't share your fixes with anyone else. You can but you have to distribute them separatly. See qmail-ldap. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 2:52:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 5C1AC37B491 for ; Sun, 25 Feb 2001 02:52:15 -0800 (PST) (envelope-from oppermann@monzoon.net) Received: (qmail 34661 invoked from network); 25 Feb 2001 10:49:11 -0000 Received: from unknown (HELO monzoon.net) ([195.134.140.21]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 25 Feb 2001 10:49:11 -0000 Message-ID: <3A98E2F9.C5573CD6@monzoon.net> Date: Sun, 25 Feb 2001 11:48:25 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Matt Dillon , Alfred Perlstein , josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200251.TAA06099@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > :For DJBDNS, this would mean extracting the changes to the code as > > :a set of patches, and then having the new owners apply the patches > > :to the unaltered DJBDNS code, since the binaries of the modified > > :code themselves are not permitted to be redistributed. > > > > It means nothing of the sort. Unless DJBDNS explicitly says that > > a change of ownership (company bought, merger,... ) requires doing > > the above very silly thing, there is no legal risk whatsoever. > > A company being sold to another company is a very, very, very > > different beast then a company selling software commercially. > > Selling the company transfers ownership of the binaries. Nope. The owner is still the company. Just the shareholders of the company changed. If you would look up the law books you would see that that a company constitutes a legal person. The ownership of the company is not matter. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 7:14:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id E55BA37B4EC for ; Sun, 25 Feb 2001 07:14:20 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1PFEHh97295; Sun, 25 Feb 2001 10:14:17 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 25 Feb 2001 10:14:17 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Randell Jesup Cc: arch@FreeBSD.ORG, Alfred Perlstein , Mike Sinz , Bruce Bauman Subject: Re: ELF and diskless boot In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23 Feb 2001, Randell Jesup wrote: > FYI, is there a reason that we've set up our kernel interface to top, > etc to fail unless the kernel (in this case 4.x) is loaded with > _debugging_ symbols? I.e. if you strip a kernel, top (and a bunch of > other stuff) doesn't work because they can't find certain kernel > structures. To make this worse, they also fail if you etherboot > (because debug symbols aren't loaded). I won't comment on the symbol stripping issue since I don't know much/anything about that, but I can comment that we're in the process of moving to using sysctl() for top and other kernel-grubbing utilities, when used on a live system. top has already been changed to do this on -CURRENT, and patches to systat/dmesg/vmstat/... are in the wings. While this doesn't address your symbol stripping problem, it does mean that these utilities will continue to work despite a possibly over-stripped kernel. Before anyone asks, as they always do before reading the patches: yes, we're retaining support for using these commands on core dumps, as appropriate. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 7:52:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 30F4C37B401; Sun, 25 Feb 2001 07:52:17 -0800 (PST) (envelope-from iedowse@maths.tcd.ie) Received: from gosset.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 25 Feb 2001 15:52:16 +0000 (GMT) To: Robert Watson Cc: Randell Jesup , arch@FreeBSD.ORG, Alfred Perlstein , Mike Sinz , Bruce Bauman , iedowse@maths.tcd.ie Subject: Re: ELF and diskless boot In-Reply-To: Your message of "Sun, 25 Feb 2001 10:14:17 EST." Date: Sun, 25 Feb 2001 15:52:16 +0000 From: Ian Dowse Message-ID: <200102251552.aa44515@salmon.maths.tcd.ie> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Robe rt Watson writes: > >I won't comment on the symbol stripping issue since I don't know >much/anything about that, but I can comment that we're in the process of >moving to using sysctl() for top and other kernel-grubbing utilities, when >used on a live system. top has already been changed to do this on >-CURRENT, and patches to systat/dmesg/vmstat/... are in the wings. While The reason that these utilities fail when not using loader(8) is that they depend on being able to look up static variables within the kernel using kldsym(). I think symbols declared as static end up with debugging information, so are only made available through some loader magic. It would be possible to go around the tree, removing the `static' from all symbols that are used by libkvm utilities - I've tried this, and it certainly fixes the problem with etherbooted kernels. It might also be possible to hack libkvm to try the old-style symbol lookup mechanism if kldsym fails to find a symbol. However, the move towards using sysctl() instead of libkvm will solve this problem completely. Thanks to Thomas Moestl and others who have done the work to make this happen! Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 8:26:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id 55EE837B401 for ; Sun, 25 Feb 2001 08:26:39 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.11.2/8.11.2) id f1PGQAe39000; Sun, 25 Feb 2001 08:26:10 -0800 (PST) (envelope-from sgk) From: Steve Kargl Message-Id: <200102251626.f1PGQAe39000@troutmask.apl.washington.edu> Subject: Re: cvs commit: ports/astro/xglobe/files patch-random In-Reply-To: <20010225005813.A29124@mollari.cthul.hu> from Kris Kennaway at "Feb 25, 2001 00:58:13 am" To: Kris Kennaway Date: Sun, 25 Feb 2001 08:26:10 -0800 (PST) Cc: arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: > On Sun, Feb 25, 2001 at 09:52:40AM +0100, Erik Trulsson wrote: > > > No, the algorithm of rand() is not standardized in the C standard. > > > > OTOH, there is an example of a portable implementation of rand() in the > > C standard and FreeBSD uses the same algorithm (as does many other > > implementations of rand()). This is probably what you were thinking of. > > > > As long as rand() and srand() behaves as describe in the man-page for > > rand(3) they confirm to the C standard. (Provided that RAND_MAX is at > > least 32767.) > > That's good to know. I'll look at replacing it with something better > that has the same semantics, so we solve this problem at the source. > > Kris Kris, If you're looking for a candidate algorithm, you might consider the Mersenne Twister (MT). http://www.math.keio.ac.jp/~matumoto/emt.html MT is for Monte Carlos type work. It isn't crypto strong. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 13:10: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-10.dsl.lsan03.pacbell.net [63.207.60.10]) by hub.freebsd.org (Postfix) with ESMTP id D908937B4EC; Sun, 25 Feb 2001 13:10:02 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8276B66F83; Sun, 25 Feb 2001 13:10:02 -0800 (PST) Date: Sun, 25 Feb 2001 13:10:02 -0800 From: Kris Kennaway To: "Andrey A. Chernov" Cc: "Jacques A. Vidrine" , Matt Dillon , Bruce Evans , Kris Kennaway , Robert Watson , Nick Sayer , cvs-all@freebsd.org, arch@freebsd.org Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010225131002.A38192@mollari.cthul.hu> Reply-To: arch@FreeBSD.org References: <200102250900.f1P90Qc12868@earth.backplane.com> <20010225092416.A46959@hamlet.nectar.com> <20010225185535.A55782@nagual.pp.ru> <20010225191316.A56093@nagual.pp.ru> <20010225193409.A56351@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010225193409.A56351@nagual.pp.ru>; from ache@nagual.pp.ru on Sun, Feb 25, 2001 at 07:34:09PM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 25, 2001 at 07:34:09PM +0300, Andrey A. Chernov wrote: > On Sun, Feb 25, 2001 at 19:13:17 +0300, Andrey A. Chernov wrote: > > On Sun, Feb 25, 2001 at 18:55:36 +0300, Andrey A. Chernov wrote: > > > On Sun, Feb 25, 2001 at 09:24:16 -0600, Jacques A. Vidrine wrote: > > > > My conclusion is that either: > > > > =20 > > > > Our implementation of `rand' loses. =20 > > >=20 > > > We can easily improve much our rand() random distribution staying ins= ide > > > the same API by using just different calculation formula, as we alrea= dy do > > > with random(). I plan to do it long time ago, but lost interest. I ca= n dig > > > out this formula, if someone is interested. > >=20 > > We already use this formula (in different context), see > > good_rand() function in stdlib/random.c >=20 > Patch for review: Can't you just wrap it around random() and srandom() instead of duplicating the code? Kris --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6mXSpWry0BWjoQKURAh9lAKC7LLf1TyVH1JDKQMhJAR/MOhi9GwCaA+G5 MAYzAKuqwsHtWZEK8PkVFmg= =y/Rx -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 13:22: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-10.dsl.lsan03.pacbell.net [63.207.60.10]) by hub.freebsd.org (Postfix) with ESMTP id 359FD37B491; Sun, 25 Feb 2001 13:21:53 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id ACEFB66F83; Sun, 25 Feb 2001 13:21:52 -0800 (PST) Date: Sun, 25 Feb 2001 13:21:52 -0800 From: Kris Kennaway To: arch@FreeBSD.ORG Cc: "Andrey A. Chernov" , "Jacques A. Vidrine" , Matt Dillon , Bruce Evans , Kris Kennaway , Robert Watson , Nick Sayer , cvs-all@FreeBSD.ORG Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010225132152.A39554@mollari.cthul.hu> Reply-To: arch@freebsd.org References: <200102250900.f1P90Qc12868@earth.backplane.com> <20010225092416.A46959@hamlet.nectar.com> <20010225185535.A55782@nagual.pp.ru> <20010225191316.A56093@nagual.pp.ru> <20010225193409.A56351@nagual.pp.ru> <20010225131002.A38192@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010225131002.A38192@mollari.cthul.hu>; from kris@obsecurity.org on Sun, Feb 25, 2001 at 01:10:02PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 25, 2001 at 01:10:02PM -0800, Kris Kennaway wrote: > > Patch for review: >=20 > Can't you just wrap it around random() and srandom() instead of > duplicating the code? Nevermind, I read the followup about needing to have independent state. I think you should duplicate the rest of the random() and srandom() stuff, not just good_rand() -- random.c does more work to seed things, for example, which I'd feel better about. Also, document in rand.c and random.c that they should be kept in sync modulo the missing srandomdev() code. Kris --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6mXdwWry0BWjoQKURAtRWAJ0dogbT2Lfgrj9tWMvR/MWgqP/vXACfb+n/ RP0F5P0D1vSW83S7LOrC9g4= =/AME -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 13:29:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 0B3D337B401; Sun, 25 Feb 2001 13:29:38 -0800 (PST) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.2/8.11.2) id f1PLTau59870; Mon, 26 Feb 2001 00:29:36 +0300 (MSK) (envelope-from ache) Date: Mon, 26 Feb 2001 00:29:35 +0300 From: "Andrey A. Chernov" To: arch@FreeBSD.org Cc: "Jacques A. Vidrine" , Matt Dillon , Bruce Evans , Kris Kennaway , Robert Watson , Nick Sayer , cvs-all@FreeBSD.org Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226002934.A59772@nagual.pp.ru> References: <200102250900.f1P90Qc12868@earth.backplane.com> <20010225092416.A46959@hamlet.nectar.com> <20010225185535.A55782@nagual.pp.ru> <20010225191316.A56093@nagual.pp.ru> <20010225193409.A56351@nagual.pp.ru> <20010225131002.A38192@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010225131002.A38192@mollari.cthul.hu>; from kris@obsecurity.org on Sun, Feb 25, 2001 at 01:10:02PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 25, 2001 at 13:10:02 -0800, Kris Kennaway wrote: > On Sun, Feb 25, 2001 at 07:34:09PM +0300, Andrey A. Chernov wrote: > > On Sun, Feb 25, 2001 at 19:13:17 +0300, Andrey A. Chernov wrote: > > > On Sun, Feb 25, 2001 at 18:55:36 +0300, Andrey A. Chernov wrote: > > > > On Sun, Feb 25, 2001 at 09:24:16 -0600, Jacques A. Vidrine wrote: > > > > > My conclusion is that either: > > > > > =20 > > > > > Our implementation of `rand' loses. =20 > > > >=20 > > > > We can easily improve much our rand() random distribution staying i= nside > > > > the same API by using just different calculation formula, as we alr= eady do > > > > with random(). I plan to do it long time ago, but lost interest. I = can dig > > > > out this formula, if someone is interested. > > >=20 > > > We already use this formula (in different context), see > > > good_rand() function in stdlib/random.c > >=20 > > Patch for review: >=20 > Can't you just wrap it around random() and srandom() instead of > duplicating the code? They can't be wrapped, they use completely different technique and must keep their state independently - see the rest of discussion.=20 Currenty only small portion of non-essential code from random.c is duplicated. good_rand() from random.c have different arg type and not truncate its return result - it means 1) wrapper code will be bigger than few lines of original code 2) whole random.o module will be linked increasing static binary size with big tables completely unneded for rand(). Few lines of code not worth to separate good_rand() into small file especially for it. --=20 Andrey A. Chernov http://ache.pp.ru/ --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBOpl5PuJgpPLZnQjrAQFHEAP/R8YyyCsrwTykJUotzCvtFY3U1DcBuXo9 fra1v+6BbfE51FU7EpGx9SP0CooZrF7m8qWrBRuG2/pvtJWu18/eg+/3z02D1MV4 UEd0jYYuTiAr4n1XG2Bo8WmvXfVDpRfxDKckbHhhZoT9q3vuxIuCvyUNR/pUM/rN CO3wvf0UvD8= =yy0s -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 13:50:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 5AC3637B491; Sun, 25 Feb 2001 13:50:10 -0800 (PST) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.2/8.11.2) id f1PLo8O60123; Mon, 26 Feb 2001 00:50:09 +0300 (MSK) (envelope-from ache) Date: Mon, 26 Feb 2001 00:50:04 +0300 From: "Andrey A. Chernov" To: arch@FreeBSD.ORG Cc: "Jacques A. Vidrine" , Matt Dillon , Bruce Evans , Kris Kennaway , Robert Watson , Nick Sayer , cvs-all@FreeBSD.ORG Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226005004.B59772@nagual.pp.ru> References: <200102250900.f1P90Qc12868@earth.backplane.com> <20010225092416.A46959@hamlet.nectar.com> <20010225185535.A55782@nagual.pp.ru> <20010225191316.A56093@nagual.pp.ru> <20010225193409.A56351@nagual.pp.ru> <20010225131002.A38192@mollari.cthul.hu> <20010225132152.A39554@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010225132152.A39554@mollari.cthul.hu>; from kris@obsecurity.org on Sun, Feb 25, 2001 at 01:21:52PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 25, 2001 at 13:21:52 -0800, Kris Kennaway wrote: > Nevermind, I read the followup about needing to have independent > state. I think you should duplicate the rest of the random() and > srandom() stuff, not just good_rand() -- random.c does more work to > seed things, for example, which I'd feel better about. Also, document > in rand.c and random.c that they should be kept in sync modulo the > missing srandomdev() code. Maybe, but only in case we need to care about rand() distribution _so_ match, I am not sure. Every manual nowdays marks rand() as deprecated. --=20 Andrey A. Chernov http://ache.pp.ru/ --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBOpl+DOJgpPLZnQjrAQFeBwQA6v0a6Ijih2mMqXPrWM0tONoGyenKitW1 4zPmc8yPFBjW+axRzad7aDfIvT5IUlPzEfg3Hj4jO2orCydW2hhkXmZH3OPNMKq5 /5L6YCD8JdmfjqzHhn1UnWrikqWRahA8Z2MRuw21F/hNswIDrTUm0VFG/iosvY3H ljOWkWnMNKI= =nchk -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 13:54:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-10.dsl.lsan03.pacbell.net [63.207.60.10]) by hub.freebsd.org (Postfix) with ESMTP id 9601C37B401; Sun, 25 Feb 2001 13:54:30 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 44FC766F83; Sun, 25 Feb 2001 13:54:30 -0800 (PST) Date: Sun, 25 Feb 2001 13:54:29 -0800 From: Kris Kennaway To: "Andrey A. Chernov" Cc: arch@FreeBSD.ORG, "Jacques A. Vidrine" , Matt Dillon , Bruce Evans , Kris Kennaway , Robert Watson , Nick Sayer , cvs-all@FreeBSD.ORG Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010225135429.A47615@mollari.cthul.hu> References: <200102250900.f1P90Qc12868@earth.backplane.com> <20010225092416.A46959@hamlet.nectar.com> <20010225185535.A55782@nagual.pp.ru> <20010225191316.A56093@nagual.pp.ru> <20010225193409.A56351@nagual.pp.ru> <20010225131002.A38192@mollari.cthul.hu> <20010225132152.A39554@mollari.cthul.hu> <20010226005004.B59772@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010226005004.B59772@nagual.pp.ru>; from ache@nagual.pp.ru on Mon, Feb 26, 2001 at 12:50:04AM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 26, 2001 at 12:50:04AM +0300, Andrey A. Chernov wrote: > On Sun, Feb 25, 2001 at 13:21:52 -0800, Kris Kennaway wrote: > > Nevermind, I read the followup about needing to have independent > > state. I think you should duplicate the rest of the random() and > > srandom() stuff, not just good_rand() -- random.c does more work to > > seed things, for example, which I'd feel better about. Also, document > > in rand.c and random.c that they should be kept in sync modulo the > > missing srandomdev() code. >=20 > Maybe, but only in case we need to care about rand() distribution _so_ > match, I am not sure. Every manual nowdays marks rand() as deprecated. Yet it's still used bogusly for cryptographic needs - e.g. even XFree86 4.x seems to use rand() for generating cookies, I discovered last night (as a result of my rand() warning :-). If we fix up rand() to have a decent cryptographic behaviour, we save all the idiot programmers from themselves. Kris --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6mX8VWry0BWjoQKURAlvLAKDXZIi2TYYsF45JVwhIYtt1S1tLOgCgt0vw LuSyosUBFNTiRTjhZQ4LVCQ= =RblQ -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 14: 4:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 2E17E37B401; Sun, 25 Feb 2001 14:04:27 -0800 (PST) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.2/8.11.2) id f1PM4Mn60370; Mon, 26 Feb 2001 01:04:23 +0300 (MSK) (envelope-from ache) Date: Mon, 26 Feb 2001 01:04:19 +0300 From: "Andrey A. Chernov" To: Kris Kennaway Cc: arch@FreeBSD.ORG, "Jacques A. Vidrine" , Matt Dillon , Bruce Evans , Robert Watson , Nick Sayer , cvs-all@FreeBSD.ORG Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226010418.A60234@nagual.pp.ru> References: <200102250900.f1P90Qc12868@earth.backplane.com> <20010225092416.A46959@hamlet.nectar.com> <20010225185535.A55782@nagual.pp.ru> <20010225191316.A56093@nagual.pp.ru> <20010225193409.A56351@nagual.pp.ru> <20010225131002.A38192@mollari.cthul.hu> <20010225132152.A39554@mollari.cthul.hu> <20010226005004.B59772@nagual.pp.ru> <20010225135429.A47615@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010225135429.A47615@mollari.cthul.hu>; from kris@obsecurity.org on Sun, Feb 25, 2001 at 01:54:29PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 25, 2001 at 13:54:29 -0800, Kris Kennaway wrote: > On Mon, Feb 26, 2001 at 12:50:04AM +0300, Andrey A. Chernov wrote: > > On Sun, Feb 25, 2001 at 13:21:52 -0800, Kris Kennaway wrote: > > > Nevermind, I read the followup about needing to have independent > > > state. I think you should duplicate the rest of the random() and > > > srandom() stuff, not just good_rand() -- random.c does more work to > > > seed things, for example, which I'd feel better about. Also, document > > > in rand.c and random.c that they should be kept in sync modulo the > > > missing srandomdev() code. > >=20 > > Maybe, but only in case we need to care about rand() distribution _so_ > > match, I am not sure. Every manual nowdays marks rand() as deprecated. >=20 > Yet it's still used bogusly for cryptographic needs - e.g. even > XFree86 4.x seems to use rand() for generating cookies, I discovered > last night (as a result of my rand() warning :-). If we fix up rand() > to have a decent cryptographic behaviour, we save all the idiot > programmers from themselves. Ok, I'll produce another patch implementing this in near future. --=20 Andrey A. Chernov http://ache.pp.ru/ --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBOpmBYuJgpPLZnQjrAQEBngP+LARkIdxQveQKKgxVwZoxaYuzieLbCcIe 3quly/G3qYlLuuDDq9K0zZxXxsRy8Fu1PrWpkngzWEc8y8MOWV2e4J6mdPBabw5L I/Fpz7Fi87xic0K0wrwvJyqDdhqFqnD6Yo2uLF55uTR8+lJrynG4+zcDsYAUSlCD oyfJvM8pjZw= =5D/b -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 14: 5:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cube.gelatinous.com (cube.gelatinous.com [207.82.194.150]) by hub.freebsd.org (Postfix) with SMTP id E60DE37B491 for ; Sun, 25 Feb 2001 14:05:37 -0800 (PST) (envelope-from aaron@mutex.org) Received: (qmail 67122 invoked by uid 1000); 25 Feb 2001 22:05:37 -0000 Date: Sun, 25 Feb 2001 14:05:37 -0800 From: Aaron Smith To: Kris Kennaway Cc: arch@freebsd.org Subject: Re: [cgd@netbsd.org: CVS commit: basesrc] Message-ID: <20010225140537.M4905@gelatinous.com> References: <20010220011548.A34873@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010220011548.A34873@mollari.cthul.hu>; from kris@obsecurity.org on Tue, Feb 20, 2001 at 01:15:48AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG is there any relationship here to FreeBSD's existing setproctitle(3) call? aaron On Tue, Feb 20, 2001 at 01:15:48AM -0800, Kris Kennaway wrote: > What does this list think about the merits of this idea? > > Kris > > ----- Forwarded message from "Chris G. Demetriou" ----- [...] > Log Message: > add getprogname() and setprogname(). These allow uses of __progname to > be wrapped in some sane fashion, for portability. [...] > ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 15: 8:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id BD01437B491; Sun, 25 Feb 2001 15:08:49 -0800 (PST) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.2/8.11.2) id f1PN8US61069; Mon, 26 Feb 2001 02:08:31 +0300 (MSK) (envelope-from ache) Date: Mon, 26 Feb 2001 02:08:28 +0300 From: "Andrey A. Chernov" To: Kris Kennaway Cc: arch@FreeBSD.ORG, "Jacques A. Vidrine" , Matt Dillon , Bruce Evans , Robert Watson , Nick Sayer , cvs-all@FreeBSD.ORG Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226020827.A61007@nagual.pp.ru> References: <200102250900.f1P90Qc12868@earth.backplane.com> <20010225092416.A46959@hamlet.nectar.com> <20010225185535.A55782@nagual.pp.ru> <20010225191316.A56093@nagual.pp.ru> <20010225193409.A56351@nagual.pp.ru> <20010225131002.A38192@mollari.cthul.hu> <20010225132152.A39554@mollari.cthul.hu> <20010226005004.B59772@nagual.pp.ru> <20010225135429.A47615@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010225135429.A47615@mollari.cthul.hu>; from kris@obsecurity.org on Sun, Feb 25, 2001 at 01:54:29PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 25, 2001 at 13:54:29 -0800, Kris Kennaway wrote: > On Mon, Feb 26, 2001 at 12:50:04AM +0300, Andrey A. Chernov wrote: > > On Sun, Feb 25, 2001 at 13:21:52 -0800, Kris Kennaway wrote: > > > Nevermind, I read the followup about needing to have independent > > > state. I think you should duplicate the rest of the random() and > > > srandom() stuff, not just good_rand() -- random.c does more work to > > > seed things, for example, which I'd feel better about. Also, document > > > in rand.c and random.c that they should be kept in sync modulo the > > > missing srandomdev() code. > >=20 > > Maybe, but only in case we need to care about rand() distribution _so_ > > match, I am not sure. Every manual nowdays marks rand() as deprecated. >=20 > Yet it's still used bogusly for cryptographic needs - e.g. even > XFree86 4.x seems to use rand() for generating cookies, I discovered > last night (as a result of my rand() warning :-). If we fix up rand() > to have a decent cryptographic behaviour, we save all the idiot > programmers from themselves. Bad news: we can't implement r_rand() via random() algorithm because r_rand() keeps its state in extenal unsigned variable (not in big table needed for random()). So, I suggest again to use my patch since it _is_ r_rand() compatible. --=20 Andrey A. Chernov http://ache.pp.ru/ --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBOpmQa+JgpPLZnQjrAQHqNwP7BKxpiO0l+r2jxxU7bfFeboN9y9+4rOe6 +O7HA/omuUTfIipvCpXN/J4aO0rhn9ra4nbZWRjGhDMe6/RXAjaR+pI4Z8md/4uF O1hf4vr6uhZiMTNRvhPEv10EwO8NeT1hBEJTrRuD9a6MCxFJxdx2hvd185o4rX6z 5TuVZGOJbB4= =/03r -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 15:15:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-10.dsl.lsan03.pacbell.net [63.207.60.10]) by hub.freebsd.org (Postfix) with ESMTP id 105CD37B4EC; Sun, 25 Feb 2001 15:15:22 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 145E366D2E; Sun, 25 Feb 2001 15:15:19 -0800 (PST) Date: Sun, 25 Feb 2001 15:15:19 -0800 From: Kris Kennaway To: "Andrey A. Chernov" Cc: Kris Kennaway , arch@FreeBSD.ORG, "Jacques A. Vidrine" , Matt Dillon , Bruce Evans , Robert Watson , Nick Sayer , cvs-all@FreeBSD.ORG Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010225151519.A63582@mollari.cthul.hu> References: <200102250900.f1P90Qc12868@earth.backplane.com> <20010225092416.A46959@hamlet.nectar.com> <20010225185535.A55782@nagual.pp.ru> <20010225191316.A56093@nagual.pp.ru> <20010225193409.A56351@nagual.pp.ru> <20010225131002.A38192@mollari.cthul.hu> <20010225132152.A39554@mollari.cthul.hu> <20010226005004.B59772@nagual.pp.ru> <20010225135429.A47615@mollari.cthul.hu> <20010226020827.A61007@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010226020827.A61007@nagual.pp.ru>; from ache@nagual.pp.ru on Mon, Feb 26, 2001 at 02:08:28AM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 26, 2001 at 02:08:28AM +0300, Andrey A. Chernov wrote: > > Yet it's still used bogusly for cryptographic needs - e.g. even > > XFree86 4.x seems to use rand() for generating cookies, I discovered > > last night (as a result of my rand() warning :-). If we fix up rand() > > to have a decent cryptographic behaviour, we save all the idiot > > programmers from themselves. >=20 > Bad news: we can't implement r_rand() via random() algorithm because > r_rand() keeps its state in extenal unsigned variable (not in big table > needed for random()). So, I suggest again to use my patch since it _is_ > r_rand() compatible. Hmm. Perhaps there's a way around that -- having a single state variable really does weaken things here. Anyone have any ideas? Kris --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6mZIGWry0BWjoQKURAojFAJ9GLjwJBHEwDNyiZxWbRJEfjTLB8ACg0SIg HjUvYqVj0xFwgksM5gYqlKU= =3oaf -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 15:29:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 504ED37B491; Sun, 25 Feb 2001 15:29:14 -0800 (PST) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.2/8.11.2) id f1PNT6561417; Mon, 26 Feb 2001 02:29:06 +0300 (MSK) (envelope-from ache) Date: Mon, 26 Feb 2001 02:29:03 +0300 From: "Andrey A. Chernov" To: Kris Kennaway Cc: arch@FreeBSD.ORG, "Jacques A. Vidrine" , Matt Dillon , Bruce Evans , Robert Watson , Nick Sayer , cvs-all@FreeBSD.ORG Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226022902.A61216@nagual.pp.ru> References: <20010225092416.A46959@hamlet.nectar.com> <20010225185535.A55782@nagual.pp.ru> <20010225191316.A56093@nagual.pp.ru> <20010225193409.A56351@nagual.pp.ru> <20010225131002.A38192@mollari.cthul.hu> <20010225132152.A39554@mollari.cthul.hu> <20010226005004.B59772@nagual.pp.ru> <20010225135429.A47615@mollari.cthul.hu> <20010226020827.A61007@nagual.pp.ru> <20010225151519.A63582@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010225151519.A63582@mollari.cthul.hu>; from kris@obsecurity.org on Sun, Feb 25, 2001 at 03:15:19PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 25, 2001 at 15:15:19 -0800, Kris Kennaway wrote: > On Mon, Feb 26, 2001 at 02:08:28AM +0300, Andrey A. Chernov wrote: > > > Yet it's still used bogusly for cryptographic needs - e.g. even > > > XFree86 4.x seems to use rand() for generating cookies, I discovered > > > last night (as a result of my rand() warning :-). If we fix up rand() > > > to have a decent cryptographic behaviour, we save all the idiot > > > programmers from themselves. > >=20 > > Bad news: we can't implement r_rand() via random() algorithm because > > r_rand() keeps its state in extenal unsigned variable (not in big table > > needed for random()). So, I suggest again to use my patch since it _is_ > > r_rand() compatible. >=20 > Hmm. Perhaps there's a way around that -- having a single state > variable really does weaken things here. Anyone have any ideas? As manpage says: "The rand_r() function is as proposed in the POSIX.4a Draft #6 document" Does anybody knows is there new versions of this draft exists and what they say? --=20 Andrey A. Chernov http://ache.pp.ru/ --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBOpmVPeJgpPLZnQjrAQHb9QQAzGK+xk+8QqDRA+ANcf6ts3O/KVzTy5vl JPVi0yZJblSQbCIvni/TGmnPigAxPLZgBW3/oyolvnHNNwOELvlJ0tLyB5neiv18 cpYCfjle85V3obQtZuybKpJqqed4aox5AwTV0a8L7G6dx9SKBQVavHSkdF4SqVaB s4hOFrznWXs= =nnB9 -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 15:39:26 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 DBF0737B503; Sun, 25 Feb 2001 15:39:21 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1PNdGF18914; Sun, 25 Feb 2001 15:39:16 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Feb 2001 15:39:16 -0800 (PST) From: Matt Dillon Message-Id: <200102252339.f1PNdGF18914@earth.backplane.com> To: "Andrey A. Chernov" Cc: Kris Kennaway , arch@FreeBSD.ORG, "Jacques A. Vidrine" , Bruce Evans , Robert Watson , Nick Sayer , cvs-all@FreeBSD.ORG Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) References: <200102250900.f1P90Qc12868@earth.backplane.com> <20010225092416.A46959@hamlet.nectar.com> <20010225185535.A55782@nagual.pp.ru> <20010225191316.A56093@nagual.pp.ru> <20010225193409.A56351@nagual.pp.ru> <20010225131002.A38192@mollari.cthul.hu> <20010225132152.A39554@mollari.cthul.hu> <20010226005004.B59772@nagual.pp.ru> <20010225135429.A47615@mollari.cthul.hu> <20010226020827.A61007@nagual.pp.ru> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Bad news: we can't implement r_rand() via random() algorithm because :r_rand() keeps its state in extenal unsigned variable (not in big table :needed for random()). So, I suggest again to use my patch since it _is_ :r_rand() compatible. : :--=20 :Andrey A. Chernov Ach, your right. The best we can hope for with rand() is to have it produce a reasonable pseudo-random sequence. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 15:45:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id A5A8037B401 for ; Sun, 25 Feb 2001 15:45:07 -0800 (PST) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.2/8.11.2) id f1PNj1c61711; Mon, 26 Feb 2001 02:45:02 +0300 (MSK) (envelope-from ache) Date: Mon, 26 Feb 2001 02:44:58 +0300 From: "Andrey A. Chernov" To: "Jacques A. Vidrine" Cc: arch@freebsd.org, kris@obsecurity.org Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226024456.A61566@nagual.pp.ru> References: <20010225191316.A56093@nagual.pp.ru> <20010225193409.A56351@nagual.pp.ru> <20010225131002.A38192@mollari.cthul.hu> <20010225132152.A39554@mollari.cthul.hu> <20010226005004.B59772@nagual.pp.ru> <20010225135429.A47615@mollari.cthul.hu> <20010226020827.A61007@nagual.pp.ru> <20010225151519.A63582@mollari.cthul.hu> <20010226022902.A61216@nagual.pp.ru> <20010225173445.A37510@spawn.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010225173445.A37510@spawn.nectar.com>; from n@nectar.com on Sun, Feb 25, 2001 at 05:34:45PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 25, 2001 at 17:34:45 -0600, Jacques A. Vidrine wrote: > On Mon, Feb 26, 2001 at 02:29:03AM +0300, Andrey A. Chernov wrote: > > As manpage says: > > "The rand_r() function is as proposed in the POSIX.4a Draft #6 document" > > Does anybody knows is there new versions of this draft exists and what > > they say? > > I don't, but does this help? > > http://www.opengroup.org/onlinepubs/007908799/xsh/rand.html It refers to POSIX Threads Extension (1003.1c-1995) for rand_r(), saying the same. It seems we can't separate rand() and rand_r() since it will be very strange when rand_r() will produce different sequence than plain rand(). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 16:14: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 1A07537B4EC; Sun, 25 Feb 2001 16:14:06 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 99E9C81D01; Sun, 25 Feb 2001 18:14:05 -0600 (CST) Date: Sun, 25 Feb 2001 18:14:05 -0600 From: Bill Fumerola To: Kris Kennaway Cc: Matt Dillon , Bruce Evans , Robert Watson , Nick Sayer , cvs-committers@FreeBSD.ORG, arch@FreeBSD.org Subject: Re: cvs commit: ports/astro/xglobe/files patch-random Message-ID: <20010225181405.V483@elvis.mu.org> References: <200102250640.f1P6e0q11960@earth.backplane.com> <20010224225935.A769@mollari.cthul.hu> <200102250725.f1P7PVs12297@earth.backplane.com> <20010225000701.B10488@mollari.cthul.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010225000701.B10488@mollari.cthul.hu>; from kris@obsecurity.org on Sun, Feb 25, 2001 at 12:07:01AM -0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 25, 2001 at 12:07:01AM -0800, Kris Kennaway wrote: > Stop complaining to me about strftime, it's not the same thing. Well, its more of the same thing, rand() functions as advertised. Please don't add this. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 18:41:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id E028B37B401 for ; Sun, 25 Feb 2001 18:41:49 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id TAA27453; Sun, 25 Feb 2001 19:36:07 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAAUpaiD1; Sun Feb 25 19:35:55 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA07028; Sun, 25 Feb 2001 19:41:32 -0700 (MST) From: Terry Lambert Message-Id: <200102260241.TAA07028@usr05.primenet.com> Subject: Re: cvs commit: ports/astro/xglobe/files patch-random To: kris@obsecurity.org (Kris Kennaway) Date: Mon, 26 Feb 2001 02:41:22 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: <20010225005813.A29124@mollari.cthul.hu> from "Kris Kennaway" at Feb 25, 2001 12:58:13 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > No, the algorithm of rand() is not standardized in the C standard. > > > > OTOH, there is an example of a portable implementation of rand() in the > > C standard and FreeBSD uses the same algorithm (as does many other > > implementations of rand()). This is probably what you were thinking of. > > > > As long as rand() and srand() behaves as describe in the man-page for > > rand(3) they confirm to the C standard. (Provided that RAND_MAX is at > > least 32767.) > > That's good to know. I'll look at replacing it with something better > that has the same semantics, so we solve this problem at the source. Please do not. The 48 bit linear congruential algorithm is often used to creat pseudo one-time pads for ciphering data. Changing the algorithm will result in ciphered data becoming inaccesable. Repeatability of results in montecarlo based physics simulations is also an issue. FreeBSD would end up being much less useful for real numeric work, should rand() be changed. Ignoring that, what makes you think you can come up with a better algorithm than Donald Knuth? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 18:54:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id A2D2637B401 for ; Sun, 25 Feb 2001 18:54:42 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id TAA17953; Sun, 25 Feb 2001 19:51:33 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAmpaOaJ; Sun Feb 25 19:51:25 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA07261; Sun, 25 Feb 2001 19:54:29 -0700 (MST) From: Terry Lambert Message-Id: <200102260254.TAA07261@usr05.primenet.com> Subject: Re: DJBDNS vs. BIND To: oppermann@monzoon.net (Andre Oppermann) Date: Mon, 26 Feb 2001 02:54:19 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), dillon@earth.backplane.com (Matt Dillon), bright@wintelcom.net (Alfred Perlstein), josb@cncdsl.com, arch@FreeBSD.ORG In-Reply-To: <3A98E2F9.C5573CD6@monzoon.net> from "Andre Oppermann" at Feb 25, 2001 11:48:25 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Selling the company transfers ownership of the binaries. > > Nope. The owner is still the company. Just the shareholders of the > company changed. If you would look up the law books you would see > that that a company constitutes a legal person. The ownership of > the company is not matter. A company can not own a patent or copyright, it can only have the rights assigned to it by someone. Much of the copyright statements out there are based on apriori assignment of rights. With patents, it's much more explicit, but 50 years after the death of the real author, a copyright becomes void. There's no need to wait out the life of the company. There are a lot of ways in which a company is not treated as a real person under the law. As another example, it is not possible to discriminate against a company: a company has no civil rights. Neither can a company vote, be imprisoned, etc.. A company is owned by it's shareholders. Ownership of the company assets derives to its shareholders; the company itself does not technically own anything. Please see the book: New Venture Creation: Entrepreneurship for the 21st Century Jeffry A. Timmons ISBN: 0256197563 (Get it at a library if you can; it's an MBA textbook, and it's very expensive). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 19:32: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-74.dsl.lsan03.pacbell.net [64.165.226.74]) by hub.freebsd.org (Postfix) with ESMTP id 7111937B503 for ; Sun, 25 Feb 2001 19:31:58 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 05C0E66B62; Sun, 25 Feb 2001 19:31:57 -0800 (PST) Date: Sun, 25 Feb 2001 19:31:57 -0800 From: Kris Kennaway To: Terry Lambert Cc: Kris Kennaway , arch@FreeBSD.ORG Subject: Re: cvs commit: ports/astro/xglobe/files patch-random Message-ID: <20010225193157.A16118@mollari.cthul.hu> References: <20010225005813.A29124@mollari.cthul.hu> <200102260241.TAA07028@usr05.primenet.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: <200102260241.TAA07028@usr05.primenet.com>; from tlambert@primenet.com on Mon, Feb 26, 2001 at 02:41:22AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 26, 2001 at 02:41:22AM +0000, Terry Lambert wrote: > > That's good to know. I'll look at replacing it with something better > > that has the same semantics, so we solve this problem at the source. >=20 > Please do not. The 48 bit linear congruential algorithm is often > used to creat pseudo one-time pads for ciphering data. Changing Only by idiots, perhaps. rand() is totally wrong for that application. > the algorithm will result in ciphered data becoming inaccesable. >=20 > Repeatability of results in montecarlo based physics simulations is > also an issue. FreeBSD would end up being much less useful for real > numeric work, should rand() be changed. This won't happen because the interface won't change. > Ignoring that, what makes you think you can come up with a better > algorithm than Donald Knuth? Me? No, but others have done so. Terry, the existing rand() is a bad algorithm just about any way you look at it. Kris --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6mc4tWry0BWjoQKURAvQLAJ9gh9jjUzzupKhYXkc/O3J14JGgzwCfeZWB nhJBux+Kv4+nSvrpYeLiEns= =M9qV -----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 Feb 25 19:32:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-74.dsl.lsan03.pacbell.net [64.165.226.74]) by hub.freebsd.org (Postfix) with ESMTP id AEE8B37B491 for ; Sun, 25 Feb 2001 19:32:38 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 73BFC66B62; Sun, 25 Feb 2001 19:32:38 -0800 (PST) Date: Sun, 25 Feb 2001 19:32:38 -0800 From: Kris Kennaway To: Terry Lambert Cc: Andre Oppermann , Matt Dillon , Alfred Perlstein , josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010225193238.B16118@mollari.cthul.hu> References: <3A98E2F9.C5573CD6@monzoon.net> <200102260254.TAA07261@usr05.primenet.com> 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: <200102260254.TAA07261@usr05.primenet.com>; from tlambert@primenet.com on Mon, Feb 26, 2001 at 02:54:19AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --b5gNqxB1S1yM7hjW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Oh, for crying out loud -- will you all please take this silly thread to -chat? Kris --b5gNqxB1S1yM7hjW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6mc5VWry0BWjoQKURAnkrAKCu5Xf/QE62Hg5XxM6wwyQTwOmdMQCgnKsk t8ulsmHBKLAcWMhPwcuVgDs= =y0kj -----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 Feb 25 23:33:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 6903637B401 for ; Sun, 25 Feb 2001 23:33:20 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id AAA20344 for arch@FreeBSD.org; Mon, 26 Feb 2001 00:33:19 -0700 (MST) (envelope-from ken) Date: Mon, 26 Feb 2001 00:33:19 -0700 From: "Kenneth D. Merry" To: arch@FreeBSD.org Subject: sbufs in userland Message-ID: <20010226003319.A19994@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As part of a re-write of the CAM error recovery code that Justin and I have been working on, I have been re-doing the CAM error printing code. One of the things I'm working on is making the error printing code in the kernel and in userland as similar as possible. I would like to use the sbuf(9) interface to do the string formatting, since it is fairly superior to my current string formatting method (see scsi_sense_string() in sys/cam/scsi/scsi_all.c). The problem is that the sbuf(9) code is kernel-only at the moment. So this brings up two basic questions: 1. Should we put sbufs in userland? - At least for my purposes, I think this is a good idea. For an example of the code with and without sbufs, see the snippets below from scsi_sense_string(). - I've already done the minimal work necessary to make sbufs compile and run in userland, so that isn't an issue. - I've mentioned this to DES (sbuf author), and he thinks it would be a good idea to have sbufs available in userland. 2. If we do put sbufs in userland, what is the best way to do it? There are three different ways I can think of: - Put sbufs in some existing library, or in a specially created library, i.e. "libsbuf" or something like that. The disadvantage to this from my perspective is that we'll have to change the build process for all third party applications that use libcam. Those include cdrecord, cdda2wav, tosha, SANE, xmcd, and who knows what else. They'll have to have some conditional make rule to figure out whether to add libsbuf or libfoo. It would probably be easier if sbufs were put in some new library, so the makefiles could check for the existence of libsbuf, and then add that to the link line. (Instead of checking the OS version.) - Put sbufs in libc. This has the advantage, from my perspective, that third-party applications wouldn't need any changes to build with libcam after the change. This has the distinct disadvantage of likely being contraversial, and would perhaps violate some standard or other for libc interfaces. - Put the code in libcam, and just don't advertise it. It'll be used for the CAM functions, but no one will know about it. One advantage to this approach is that it wouldn't break existing third-party applications that use libcam. It wouldn't create an additional "supported" interface, since it wouldn't be documented. This is the approach I would prefer, since it wouldn't be as contraversial as putting it in libc, and wouldn't require changes to third party applications. So, what color should this bike shed be? Code without sbufs: switch (error_code) { case SSD_DEFERRED_ERROR: retlen = snprintf(tmpstr, tmpstrlen, "Deferred Error: "); if ((tmplen = str_len - cur_len - 1) < 0) goto sst_bailout; strncat(str, tmpstr, tmplen); cur_len += retlen; str[str_len - 1] = '\0'; /* FALLTHROUGH */ Code with sbufs: switch (error_code) { case SSD_DEFERRED_ERROR: sbuf_printf(sb, "Deferred Error: "); /* FALLTHROUGH */ Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 23:41: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 371E637B401 for ; Sun, 25 Feb 2001 23:41:00 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA03250; Sun, 25 Feb 2001 23:40:58 -0800 Date: Sun, 25 Feb 2001 23:40:57 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland In-Reply-To: <20010226003319.A19994@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Uh- looks good to me! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 23:44:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0D6E337B491 for ; Sun, 25 Feb 2001 23:44:43 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id IAA64520; Mon, 26 Feb 2001 08:44:38 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland References: <20010226003319.A19994@panzer.kdm.org> From: Dag-Erling Smorgrav Date: 26 Feb 2001 08:44:37 +0100 In-Reply-To: "Kenneth D. Merry"'s message of "Mon, 26 Feb 2001 00:33:19 -0700" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Kenneth D. Merry" writes: > 2. If we do put sbufs in userland, what is the best way to do it? Whichever way you do it, you need to change userland sprintf() to behave like kernel sprintf(), i.e. use a backend function that does the actual formatting and takes a pointer to a character output function, instead of what it currently does, which is to fake a FILE structure with the target string as buffer. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 25 23:49:55 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 2BAEE37B4EC for ; Sun, 25 Feb 2001 23:49:52 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1Q7nGZ30306; Sun, 25 Feb 2001 23:49:16 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Feb 2001 23:49:16 -0800 (PST) From: Matt Dillon Message-Id: <200102260749.f1Q7nGZ30306@earth.backplane.com> To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland References: <20010226003319.A19994@panzer.kdm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :As part of a re-write of the CAM error recovery code that Justin and I have :been working on, I have been re-doing the CAM error printing code. : :One of the things I'm working on is making the error printing code in the :kernel and in userland as similar as possible. : :I would like to use the sbuf(9) interface to do the string formatting, :since it is fairly superior to my current string formatting method (see :scsi_sense_string() in sys/cam/scsi/scsi_all.c). Well, I'm on record as really hating the sbuf concept. For userland, why not simply use asprintf()? I use asprintf() for just about everything, though I give it a nifty little wrapper. char * safe_replacef(char **pptr, const char *ctl, ...) { va_list va; char *optr = *pptr; if (ctl) { va_start(va, ctl); if (vasprintf(pptr, ctl, va) < 0) fatalmem(); va_end(va); } safe_free(&optr); return(*pptr); } void safe_free(char **ptr) { if (*ptr) { free(*ptr); *ptr = NULL; } } So you can do this: char *tmpstr = NULL; /* preinitialization to NULL necessary */ safe_replacef(&tmpstr, "bah bah %s", "bah"); use tmpstr locally ... safe_replacef(&tmpstr, "black black %s", "black"); use tmpstr locally .. for ( ...) { safe_replacef(&tmpstr, "sheep sheep %s", "sheep"); use tmpstr locally ... } ... safe_free(&tmpstr); In anycase, I'd just use an appropriately wrapped asprintf() for userland. I used to be paranoid about malloc()'ing and free()ing temporary strings for performance reasons but I got over it, and it turns out not to be a performance issue. Now I use a safe_replacef() or a safe_asprintf() type of wrapper almost exclusively for just about all my string formatting. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 0: 3:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id AF3B237B4EC for ; Mon, 26 Feb 2001 00:03:32 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p47-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.112]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id RAA26234; Mon, 26 Feb 2001 17:03:22 +0900 (JST) Message-ID: <3A9A0D1F.BEC3ECA2@newsguy.com> Date: Mon, 26 Feb 2001 17:00:31 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Kris Kennaway Cc: Terry Lambert , arch@FreeBSD.ORG Subject: Re: cvs commit: ports/astro/xglobe/files patch-random References: <20010225005813.A29124@mollari.cthul.hu> <200102260241.TAA07028@usr05.primenet.com> <20010225193157.A16118@mollari.cthul.hu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: > > > the algorithm will result in ciphered data becoming inaccesable. > > > > Repeatability of results in montecarlo based physics simulations is > > also an issue. FreeBSD would end up being much less useful for real > > numeric work, should rand() be changed. > > This won't happen because the interface won't change. Huh? I have some Promela protocol simulations here. These simulations, which use huge amounts of memory, are stored in a simple fashion: the key used by rand() and the point at which the LTC conditions were satisfied. Whatever you do to the algorithm, just keep in mind that the sequence of numbers generated from that key must remain the same, or I'll have to throw out all the simulations I have stored. Kind of defeats the purpose of changing the algorithm, don't you think? > > Ignoring that, what makes you think you can come up with a better > > algorithm than Donald Knuth? > > Me? No, but others have done so. Terry, the existing rand() is a bad > algorithm just about any way you look at it. I don't see the rand() algorithm as being bad in any way, unless you stupidly try to use it for security purposes, like generating an encryption key. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@kzinti.bsdconspiracy.net Acabou o hipismo-arte. Mas a desculpa brasileira mais ouvida em Sydney e' que nao tem mais cavalo bobo por ai'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 0:24:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 1D90C37B401 for ; Mon, 26 Feb 2001 00:24:57 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1Q8P6M18976; Mon, 26 Feb 2001 09:25:06 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland In-Reply-To: Your message of "Mon, 26 Feb 2001 00:33:19 MST." <20010226003319.A19994@panzer.kdm.org> Date: Mon, 26 Feb 2001 09:25:06 +0100 Message-ID: <18974.983175906@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010226003319.A19994@panzer.kdm.org>, "Kenneth D. Merry" writes: >1. Should we put sbufs in userland? Yes. >2. If we do put sbufs in userland, what is the best way to do it? > There are three different ways I can think of: I think that libsbuf makes sense. -- 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 Feb 26 1: 2:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7762437B401 for ; Mon, 26 Feb 2001 01:02:44 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1Q90Am29065; Mon, 26 Feb 2001 01:00:10 -0800 (PST) Date: Mon, 26 Feb 2001 01:00:10 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Cc: "Kenneth D. Merry" , arch@FreeBSD.ORG Subject: Re: sbufs in userland Message-ID: <20010226010010.Z8663@fw.wintelcom.net> References: <20010226003319.A19994@panzer.kdm.org> <18974.983175906@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <18974.983175906@critter>; from phk@critter.freebsd.dk on Mon, Feb 26, 2001 at 09:25:06AM +0100 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Poul-Henning Kamp [010226 00:25] wrote: > In message <20010226003319.A19994@panzer.kdm.org>, "Kenneth D. Merry" writes: > > >1. Should we put sbufs in userland? > > Yes. > > >2. If we do put sbufs in userland, what is the best way to do it? > > There are three different ways I can think of: > > I think that libsbuf makes sense. Since sbuf was your idea, I'm wondering why you didn't make the allocation/init of sbufs not possibly require knowledge of the sbuf internal layout. Meaning sbuf_new() should return a struct sbuf * such that one can pass NULL in and get a pointer back without having to know the sbuf internals. Is it too late, impossible or not feasable to fix this? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@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 Feb 26 1: 5:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id EFE6337B503 for ; Mon, 26 Feb 2001 01:05:15 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1Q95JM19302; Mon, 26 Feb 2001 10:05:19 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Alfred Perlstein Cc: "Kenneth D. Merry" , arch@FreeBSD.ORG Subject: Re: sbufs in userland In-Reply-To: Your message of "Mon, 26 Feb 2001 01:00:10 PST." <20010226010010.Z8663@fw.wintelcom.net> Date: Mon, 26 Feb 2001 10:05:19 +0100 Message-ID: <19300.983178319@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010226010010.Z8663@fw.wintelcom.net>, Alfred Perlstein writes: >* Poul-Henning Kamp [010226 00:25] wrote: >> In message <20010226003319.A19994@panzer.kdm.org>, "Kenneth D. Merry" writes: >> >> >1. Should we put sbufs in userland? >> >> Yes. >> >> >2. If we do put sbufs in userland, what is the best way to do it? >> > There are three different ways I can think of: >> >> I think that libsbuf makes sense. > >Since sbuf was your idea, I'm wondering why you didn't make the >allocation/init of sbufs not possibly require knowledge of the >sbuf internal layout. The reason was that there may be places in the kernel where a static allocation of an sbuf is in order. >Meaning sbuf_new() should return a struct sbuf * such that one can >pass NULL in and get a pointer back without having to know the sbuf >internals. > >Is it too late, impossible or not feasable to fix this? Sounds like a good change to me. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 4: 7:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B5A3B37B491 for ; Mon, 26 Feb 2001 04:07:21 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA26651; Mon, 26 Feb 2001 07:06:49 -0500 (EST) Date: Mon, 26 Feb 2001 07:06:49 -0500 (EST) From: Daniel Eischen To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland In-Reply-To: <20010226003319.A19994@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Feb 2001, Kenneth D. Merry wrote: > 2. If we do put sbufs in userland, what is the best way to do it? > There are three different ways I can think of: > > - Put sbufs in some existing library, or in a specially > created library, i.e. "libsbuf" or something like that. > > The disadvantage to this from my perspective is that > we'll have to change the build process for all third > party applications that use libcam. Those include > cdrecord, cdda2wav, tosha, SANE, xmcd, and who knows what > else. They'll have to have some conditional make rule > to figure out whether to add libsbuf or libfoo. > > It would probably be easier if sbufs were put in some > new library, so the makefiles could check for the > existence of libsbuf, and then add that to the link > line. (Instead of checking the OS version.) > > - Put sbufs in libc. > > This has the advantage, from my perspective, that > third-party applications wouldn't need any changes to > build with libcam after the change. > > This has the distinct disadvantage of likely being > contraversial, and would perhaps violate some standard or > other for libc interfaces. You can put them in libc as long as you use weak definitions to them (#pragma weak sbuf_new=__sbuf_new). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 4:49:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id F2B6937B401 for ; Mon, 26 Feb 2001 04:49:37 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id FAA21322; Mon, 26 Feb 2001 05:43:16 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAiaaWNP; Mon Feb 26 05:43:08 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id FAA16208; Mon, 26 Feb 2001 05:49:25 -0700 (MST) From: Terry Lambert Message-Id: <200102261249.FAA16208@usr05.primenet.com> Subject: Re: cvs commit: ports/astro/xglobe/files patch-random To: kris@obsecurity.org (Kris Kennaway) Date: Mon, 26 Feb 2001 12:49:20 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), kris@obsecurity.org (Kris Kennaway), arch@FreeBSD.ORG In-Reply-To: <20010225193157.A16118@mollari.cthul.hu> from "Kris Kennaway" at Feb 25, 2001 07:31:57 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Ignoring that, what makes you think you can come up with a better > > algorithm than Donald Knuth? > > Me? No, but others have done so. Terry, the existing rand() is a bad > algorithm just about any way you look at it. It's useful because it creates repeatable results with the same seed, which are the same for the same seed on other platforms. We have supposed cryptographically strong random numbers from /dev/random. Are you going to replace the 48 bit algorithm with an algorithm that's cryptographically strong? If you do, could you put it on the bottom of /dev/random and kill of the "entropy harvesting" so I can use my 386 machines again? At least let it be a compile time option, set in make.conf. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 4:56:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id EEFE337B401 for ; Mon, 26 Feb 2001 04:56:33 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id FAA16424; Mon, 26 Feb 2001 05:51:23 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAmEaO_F; Mon Feb 26 05:51:17 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id FAA16315; Mon, 26 Feb 2001 05:56:22 -0700 (MST) From: Terry Lambert Message-Id: <200102261256.FAA16315@usr05.primenet.com> Subject: Re: sbufs in userland To: dillon@earth.backplane.com (Matt Dillon) Date: Mon, 26 Feb 2001 12:56:17 +0000 (GMT) Cc: ken@kdm.org (Kenneth D. Merry), arch@FreeBSD.ORG In-Reply-To: <200102260749.f1Q7nGZ30306@earth.backplane.com> from "Matt Dillon" at Feb 25, 2001 11:49:16 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > char * > safe_replacef(char **pptr, const char *ctl, ...) > { > va_list va; > char *optr = *pptr; > > if (ctl) { > va_start(va, ctl); > if (vasprintf(pptr, ctl, va) < 0) > fatalmem(); > va_end(va); > } > safe_free(&optr); > return(*pptr); > } So basically, why is there an "if (ctl)"? Is it so you can pass a NULL as the second argument to turn it into a "safe_free" call? That's weird... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 4:58:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 78D1F37B503; Mon, 26 Feb 2001 04:58:55 -0800 (PST) Date: Mon, 26 Feb 2001 04:58:55 -0800 From: Kris Kennaway To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: ports/astro/xglobe/files patch-random Message-ID: <20010226045855.A34109@hub.freebsd.org> References: <20010225193157.A16118@mollari.cthul.hu> <200102261249.FAA16208@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.2.5i In-Reply-To: <200102261249.FAA16208@usr05.primenet.com>; from tlambert@primenet.com on Mon, Feb 26, 2001 at 12:49:20PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 26, 2001 at 12:49:20PM +0000, Terry Lambert wrote: > > > Ignoring that, what makes you think you can come up with a better > > > algorithm than Donald Knuth? > >=20 > > Me? No, but others have done so. Terry, the existing rand() is a bad > > algorithm just about any way you look at it. >=20 > It's useful because it creates repeatable results with the > same seed, which are the same for the same seed on other > platforms. Well, so does Andrey's replacement. > Are you going to replace the 48 bit algorithm with an algorithm > that's cryptographically strong? Unfortunately, this isn't possible due to standardization constraints -- I'm thinking of adding an #ifdef LIBC_AUDIT clause to libc to monitor these so that those of us who care can modify applications which are using the wrong interface to use the correct one. > At least let it be a compile time option, set in make.conf. This has been requested -- I don't object, so those who are using unrandom PRNGs can maintain compatability as a transition mechanism. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 5: 9:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 7DA5E37B401 for ; Mon, 26 Feb 2001 05:09:34 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id GAA20358; Mon, 26 Feb 2001 06:04:24 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAMuaORN; Mon Feb 26 06:04:15 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id GAA16507; Mon, 26 Feb 2001 06:09:22 -0700 (MST) From: Terry Lambert Message-Id: <200102261309.GAA16507@usr05.primenet.com> Subject: Re: sbufs in userland To: ken@kdm.org (Kenneth D. Merry) Date: Mon, 26 Feb 2001 13:09:17 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: <20010226003319.A19994@panzer.kdm.org> from "Kenneth D. Merry" at Feb 26, 2001 12:33:19 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > - Put sbufs in some existing library, or in a specially > created library, i.e. "libsbuf" or something like that. This makes the most sense, to me. It should even be possible to link the kernel against the same code. The library could be built out of the kernel sources by reference (there are a number of libraries that use sources from other places/tools as part of their build). > - Put sbufs in libc. Don't do this. > This has the distinct disadvantage of likely being > contraversial, and would perhaps violate some standard or > other for libc interfaces. Yes; in particular, given the recent discussion on the GCC branding problems for determining ABI type for statically linked binaries, part of the referenced mailbox file contents specifically talked about using one platform's libc with a binary built on a different platform. This rather ignores the ld.so selection issue, but if you can get over that hump, it's clear that SGI, SCO, Intel, and so on expect this to work with IA64 binaries on their platforms and Linux (it seems to me that this is a bad tactic, but I'll leave that discussion for elsewhere). That pretty much means standardizing library names and entry points for anything moderately complex to sucessfully run with local libraries. I rather expect FreeBSD will find itself forced to update the resolver code, and break it out of libc into a libresolv, like everyone else, since otherwise network-using programs will not work. It probably also means the socket code will have to ignore uninitialized data fields in sockets, rather than barfing, since that works on other platforms, and it's a common portability problem with network using programs, when going to FreeBSD. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 5:55:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 7EF1037B401; Mon, 26 Feb 2001 05:55:31 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id GAA13250; Mon, 26 Feb 2001 06:49:11 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAR3aWYz; Mon Feb 26 06:49:04 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id GAA17234; Mon, 26 Feb 2001 06:55:21 -0700 (MST) From: Terry Lambert Message-Id: <200102261355.GAA17234@usr05.primenet.com> Subject: Re: cvs commit: ports/astro/xglobe/files patch-random To: kris@FreeBSD.ORG (Kris Kennaway) Date: Mon, 26 Feb 2001 13:55:21 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG In-Reply-To: <20010226045855.A34109@hub.freebsd.org> from "Kris Kennaway" at Feb 26, 2001 04:58:55 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Not to belabor the point, but... > > > Me? No, but others have done so. Terry, the existing rand() is a bad > > > algorithm just about any way you look at it. > > > > It's useful because it creates repeatable results with the > > same seed, which are the same for the same seed on other > > platforms. > > Well, so does Andrey's replacement. So if I run the same program, compiled on a Solaris box, and compiled on a FreeBSD box, both linked against the platform libc, I will get the same results from both machines, without having to carry the random number generator code with my program, over to the new platform? I didn't think so. What's the benchmark of the two algorithms for 100,000 numbers each, on the same machine? If the "improved" code takes longer to run, that would be a problem in itself. > > At least let it be a compile time option, set in make.conf. > > This has been requested -- I don't object, so those who are > using unrandom PRNGs can maintain compatability as a > transition mechanism. I think that the new code should not be turned on by default; people who worry about such things will be willing to turn it on, if they feel the need. I'd call it a compatability mechanism, not a transition mechanism. I know of several programs that work only because they were tested out with particular seeds; in other words, they depend on the algorithm to produce a deterministic set of data each time it is run, instead of saving a large pseudo-random data set to a file, and using that, instead. That's probably a "bad use" in your opinion, but it's a very clever hack, in mine. Someone has already pointed out their network simulation data becomes invalid if the algorithm changes, since they can't compare the same fictional network with new code. I have some physics code designed to run on a Cray, but which gets maintained and tested with new constraints on small machines, like FreeBSD boxes. I know several physicists who do similar work, in the same way. FreeBSD stops being useful if 100,000 generations don't match up between the Cray (or Hitachi, for one of them) and the FreeBSD box, to ensure that the code is behaving sanely on the big iron, before cranking the iterations up to a hundred million or more events. Finally... if the new code is not going to be cryptographically strong due to interface constraints, then what is the benefit, other than it being newer than the old code? I'm not seeing anything other than what looks like change for the sake of change, and some unhappy consequences. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 7: 0:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 8791937B65D for ; Mon, 26 Feb 2001 07:00:34 -0800 (PST) (envelope-from nectar@nectar.com) Received: by gw.nectar.com (Postfix, from userid 1001) id BC8BA18C91; Mon, 26 Feb 2001 09:00:31 -0600 (CST) Date: Mon, 26 Feb 2001 09:00:31 -0600 From: "Jacques A. Vidrine" To: "Daniel C. Sobral" Cc: Kris Kennaway , Terry Lambert , arch@FreeBSD.ORG Subject: Re: cvs commit: ports/astro/xglobe/files patch-random Message-ID: <20010226090031.B42108@spawn.nectar.com> References: <20010225005813.A29124@mollari.cthul.hu> <200102260241.TAA07028@usr05.primenet.com> <20010225193157.A16118@mollari.cthul.hu> <3A9A0D1F.BEC3ECA2@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A9A0D1F.BEC3ECA2@newsguy.com>; from dcs@newsguy.com on Mon, Feb 26, 2001 at 05:00:31PM +0900 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 26, 2001 at 05:00:31PM +0900, Daniel C. Sobral wrote: > I don't see the rand() algorithm as being bad in any way, unless you > stupidly try to use it for security purposes, like generating an > encryption key. Or unless you want numbers that actually look kind of random. See my previous posting about non-cryptography uses in which rand() was insufficient, for whatever reason. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@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 Feb 26 7: 1:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id A508337B65D; Mon, 26 Feb 2001 07:01:09 -0800 (PST) (envelope-from nectar@nectar.com) Received: by gw.nectar.com (Postfix, from userid 1001) id 3862C18CA0; Mon, 26 Feb 2001 09:01:09 -0600 (CST) Date: Mon, 26 Feb 2001 09:01:08 -0600 From: "Jacques A. Vidrine" To: Terry Lambert Cc: Kris Kennaway , arch@FreeBSD.ORG Subject: Re: cvs commit: ports/astro/xglobe/files patch-random Message-ID: <20010226090108.C42108@spawn.nectar.com> References: <20010226045855.A34109@hub.freebsd.org> <200102261355.GAA17234@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102261355.GAA17234@usr05.primenet.com>; from tlambert@primenet.com on Mon, Feb 26, 2001 at 01:55:21PM +0000 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 26, 2001 at 01:55:21PM +0000, Terry Lambert wrote: > So if I run the same program, compiled on a Solaris box, and > compiled on a FreeBSD box, both linked against the platform > libc, I will get the same results from both machines, without > having to carry the random number generator code with my > program, over to the new platform? Why do you expect this anyway? -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@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 Feb 26 7:51: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (sentinel.office1.bg [195.24.48.182]) by hub.freebsd.org (Postfix) with SMTP id 51A2437B65D for ; Mon, 26 Feb 2001 07:51:00 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 11072 invoked by uid 1000); 26 Feb 2001 15:48:53 -0000 Date: Mon, 26 Feb 2001 17:48:53 +0200 From: Peter Pentchev To: "Andrey A. Chernov" Cc: "Jacques A. Vidrine" , arch@freebsd.org, kris@obsecurity.org Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226174852.B435@ringworld.oblivion.bg> Mail-Followup-To: "Andrey A. Chernov" , "Jacques A. Vidrine" , arch@freebsd.org, kris@obsecurity.org References: <20010225193409.A56351@nagual.pp.ru> <20010225131002.A38192@mollari.cthul.hu> <20010225132152.A39554@mollari.cthul.hu> <20010226005004.B59772@nagual.pp.ru> <20010225135429.A47615@mollari.cthul.hu> <20010226020827.A61007@nagual.pp.ru> <20010225151519.A63582@mollari.cthul.hu> <20010226022902.A61216@nagual.pp.ru> <20010225173445.A37510@spawn.nectar.com> <20010226024456.A61566@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010226024456.A61566@nagual.pp.ru>; from ache@nagual.pp.ru on Mon, Feb 26, 2001 at 02:44:58AM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just thought I'd throw two cents before any patch is applied.. It seems that there are people who need the old rand() behavior. How about isolating the old (current) rand(), srand(), rand_r() and whatever else is needed, to a separate library (-lrand?), and announce that programs that need old (traditional) rand() behavior need to be linked against -lrand? (I hope that I'm correct in thinking that if -lrand is specified on the linker cmdline, its rand() shall override the one in libc?) G'luck, Peter -- When you are not looking at it, this sentence is in Spanish. On Mon, Feb 26, 2001 at 02:44:58AM +0300, Andrey A. Chernov wrote: > On Sun, Feb 25, 2001 at 17:34:45 -0600, Jacques A. Vidrine wrote: > > On Mon, Feb 26, 2001 at 02:29:03AM +0300, Andrey A. Chernov wrote: > > > As manpage says: > > > "The rand_r() function is as proposed in the POSIX.4a Draft #6 document" > > > Does anybody knows is there new versions of this draft exists and what > > > they say? > > > > I don't, but does this help? > > > > http://www.opengroup.org/onlinepubs/007908799/xsh/rand.html > > It refers to POSIX Threads Extension (1003.1c-1995) for rand_r(), saying > the same. > > It seems we can't separate rand() and rand_r() since it will be very > strange when rand_r() will produce different sequence than plain rand(). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 8:10:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 6BE5637B491 for ; Mon, 26 Feb 2001 08:10:20 -0800 (PST) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.2/8.11.2) id f1QGAA872505; Mon, 26 Feb 2001 19:10:10 +0300 (MSK) (envelope-from ache) Date: Mon, 26 Feb 2001 19:10:09 +0300 From: "Andrey A. Chernov" To: "Jacques A. Vidrine" , arch@freebsd.org, kris@obsecurity.org Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226191008.A72434@nagual.pp.ru> References: <20010225131002.A38192@mollari.cthul.hu> <20010225132152.A39554@mollari.cthul.hu> <20010226005004.B59772@nagual.pp.ru> <20010225135429.A47615@mollari.cthul.hu> <20010226020827.A61007@nagual.pp.ru> <20010225151519.A63582@mollari.cthul.hu> <20010226022902.A61216@nagual.pp.ru> <20010225173445.A37510@spawn.nectar.com> <20010226024456.A61566@nagual.pp.ru> <20010226174852.B435@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010226174852.B435@ringworld.oblivion.bg>; from roam@orbitel.bg on Mon, Feb 26, 2001 at 05:48:53PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 26, 2001 at 17:48:53 +0200, Peter Pentchev wrote: > Just thought I'd throw two cents before any patch is applied.. > > It seems that there are people who need the old rand() behavior. > How about isolating the old (current) rand(), srand(), rand_r() and > whatever else is needed, to a separate library (-lrand?), and > announce that programs that need old (traditional) rand() behavior > need to be linked against -lrand? We already go throught all this logn tume ago with the same change with random() (which is NOT original code). Practice says that nobody seriously want old behaviour. Moreover, standards (like SUSv2 f.e.) don't guarantee that the formula must be the same on different machines or even through different libc versions. It must be the same for single application run only, so in theory we can change formula for each application run :-) So, I plan to skip this step as superfuous. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 8:13:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 10A7037B491 for ; Mon, 26 Feb 2001 08:13:49 -0800 (PST) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id RAA22887; Mon, 26 Feb 2001 17:13:44 +0100 (CET) (envelope-from assar) To: Aaron Smith Cc: Kris Kennaway , arch@FreeBSD.ORG Subject: Re: [cgd@netbsd.org: CVS commit: basesrc] References: <20010220011548.A34873@mollari.cthul.hu> <20010225140537.M4905@gelatinous.com> From: Assar Westerlund Date: 26 Feb 2001 17:13:43 +0100 In-Reply-To: Aaron Smith's message of "Sun, 25 Feb 2001 14:05:37 -0800" Message-ID: <5lwvadjubs.fsf@assaris.sics.se> Lines: 6 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Aaron Smith writes: > is there any relationship here to FreeBSD's existing setproctitle(3) call? No /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 9: 5:47 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 5276537B491 for ; Mon, 26 Feb 2001 09:05:43 -0800 (PST) (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 EAA29238; Tue, 27 Feb 2001 04:05:36 +1100 Date: Tue, 27 Feb 2001 04:05:34 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland In-Reply-To: <20010226003319.A19994@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Feb 2001, Kenneth D. Merry wrote: > ... > I would like to use the sbuf(9) interface to do the string formatting, > since it is fairly superior to my current string formatting method (see > scsi_sense_string() in sys/cam/scsi/scsi_all.c). > ... > Code without sbufs: > > switch (error_code) { > case SSD_DEFERRED_ERROR: > retlen = snprintf(tmpstr, tmpstrlen, "Deferred Error: "); > > if ((tmplen = str_len - cur_len - 1) < 0) > goto sst_bailout; > > strncat(str, tmpstr, tmplen); > cur_len += retlen; > str[str_len - 1] = '\0'; > /* FALLTHROUGH */ This seems to be insufficiently large to be correct :-). It doesn't check for snprintf failing (retlen == -1) or truncating (retlen >= tmpstrlen). > > Code with sbufs: > > switch (error_code) { > case SSD_DEFERRED_ERROR: > sbuf_printf(sb, "Deferred Error: "); > > /* FALLTHROUGH */ Code with an funopen(3)'d stream: switch (error_code) { case SSD_DEFERRED_ERROR: fprintf(fp, "Deferred Error: "); /* FALLTHROUGH */ :-). funopen() is more general than sbufs, so it is not quite as easy to use, but I think it is easy enough. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 9: 8:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 4CD8837B491 for ; Mon, 26 Feb 2001 09:08:29 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1QH8YM22347; Mon, 26 Feb 2001 18:08:34 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: "Kenneth D. Merry" , arch@FreeBSD.ORG Subject: Re: sbufs in userland In-Reply-To: Your message of "Tue, 27 Feb 2001 04:05:34 +1100." Date: Mon, 26 Feb 2001 18:08:34 +0100 Message-ID: <22345.983207314@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Bruce Ev ans writes: >funopen() is more general than sbufs, so it is not quite as easy to use, >but I think it is easy enough. But we don't have funopen(3) in the kernel... -- 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 Feb 26 9:18:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id C230337B69E; Mon, 26 Feb 2001 09:18:31 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152C6332; Mon, 26 Feb 2001 12:18:38 -0500 Reply-To: Randell Jesup To: Matt Dillon Cc: John Baldwin , Nate Williams , arch@FreeBSD.ORG, josb@cncdsl.com, Alfred Perlstein , Terry Lambert , Randell Jesup , Wes Peters , Tony Finch Subject: Re: DJBDNS vs. BIND References: <200102250208.f1P28VC10795@earth.backplane.com> From: Randell Jesup Date: 26 Feb 2001 12:19:43 -0500 In-Reply-To: Matt Dillon's message of "Sat, 24 Feb 2001 18:08:31 -0800 (PST)" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon writes: >:>> applications >:>> in a single file is (A) a stupid idea, (B) a stupid idea, and most >:>> importantly (C) ... a stupid idea. >:> >:> So, does that mean we should get rid of /etc/rc.conf? > A file such as /etc/rc.conf may apply to many programs, but it's a > read-only typically boot-time-only entity. On top of that, while all > the /etc/rc* files reference many different programs, all of the > programs and defaults with only a very few exceptions are part of the > base system. 99.9% of third party programs don't use /etc/rc.conf > directly and don't know it even exists, and entries in rc.conf are > typically very small single-line entities. This means that even > though the parameters specified in /etc/rc.conf may apply to many > different programs, it is still a very far cry from what registry-like > system is designed to deal with. One can hardly compare /etc/rc.conf > against a registry. Minor quibble: In general I agree with you; however I should note that some things specified in rc.conf (especially network configuration information) is used by many programs, though they interact with the pieces of the system that took their information from rc.conf (via ifconfig for example). -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 9:29:48 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 2A54037B4EC for ; Mon, 26 Feb 2001 09:29:46 -0800 (PST) (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 EAA30196; Tue, 27 Feb 2001 04:29:15 +1100 Date: Tue, 27 Feb 2001 04:29:14 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Cc: "Kenneth D. Merry" , arch@FreeBSD.ORG Subject: Re: sbufs in userland In-Reply-To: <22345.983207314@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Feb 2001, Poul-Henning Kamp wrote: > In message , Bruce Ev > ans writes: > > >funopen() is more general than sbufs, so it is not quite as easy to use, > >but I think it is easy enough. > > But we don't have funopen(3) in the kernel... See subject line. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 9:35:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 588B737B401 for ; Mon, 26 Feb 2001 09:35:12 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1QHZGM22501; Mon, 26 Feb 2001 18:35:16 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: "Kenneth D. Merry" , arch@FreeBSD.ORG Subject: Re: sbufs in userland In-Reply-To: Your message of "Tue, 27 Feb 2001 04:29:14 +1100." Date: Mon, 26 Feb 2001 18:35:16 +0100 Message-ID: <22499.983208916@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Bruce Ev ans writes: >On Mon, 26 Feb 2001, Poul-Henning Kamp wrote: > >> In message , Bruce Ev >> ans writes: >> >> >funopen() is more general than sbufs, so it is not quite as easy to use, >> >but I think it is easy enough. >> >> But we don't have funopen(3) in the kernel... > >See subject line. See original email. Ken wanted to share sources between kernel and userland. -- 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 Feb 26 9:49:41 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 E507137B401 for ; Mon, 26 Feb 2001 09:49:38 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1QHnbB33892; Mon, 26 Feb 2001 09:49:37 -0800 (PST) (envelope-from dillon) Date: Mon, 26 Feb 2001 09:49:37 -0800 (PST) From: Matt Dillon Message-Id: <200102261749.f1QHnbB33892@earth.backplane.com> To: Terry Lambert Cc: ken@kdm.org (Kenneth D. Merry), arch@FreeBSD.ORG Subject: Re: sbufs in userland References: <200102261256.FAA16315@usr05.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> char * :> safe_replacef(char **pptr, const char *ctl, ...) :> { :> va_list va; :> char *optr = *pptr; :> :> if (ctl) { :> va_start(va, ctl); :> if (vasprintf(pptr, ctl, va) < 0) :> fatalmem(); :> va_end(va); :> } :> safe_free(&optr); :> return(*pptr); :> } : :So basically, why is there an "if (ctl)"? Is it so you can pass :a NULL as the second argument to turn it into a "safe_free" call? :That's weird... : : : Terry Lambert : terry@lambert.org Yah, that's just a left over from a NULL terminated looping construct I wanted to support. I never wound up using the feature so I should probably remove it. I generally have two versions: safe_replace(&str, original) safe_replacef(&str, ctl, ...) I've found that, as the syslog security hole shows us, the base version of any string manipulation function should never be var-args or people will start using it with arguments as the second argument instead of ctl. I also constructed a poor-mans string-append routine, aka safe_append() and safe_appendf(). Obviously extremely inefficient if used to build large strings since I free/malloc or realloc on each call, but otherwise generally quite useful. It utilizes the same idea of allowing the initial string to be NULL. So: char *str = NULL; for (node = firstnode(); node; node = nextnode(node)) { safe_appendf(&str, "%d\n", node->value); } ... safe_free(&str); /* str could very well be NULL if the list was empty */ All of these routines call fatalmem() (i.e. and exit) if the allocation fails, so all users of the routines can simply assume that they succeed. Which makes them a whole lot easier to use safely then the libc equivalents. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 13:30:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 23AD837B503 for ; Mon, 26 Feb 2001 13:30:44 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA25434; Mon, 26 Feb 2001 14:30:35 -0700 (MST) (envelope-from ken) Date: Mon, 26 Feb 2001 14:30:35 -0700 From: "Kenneth D. Merry" To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland Message-ID: <20010226143035.A25402@panzer.kdm.org> References: <20010226003319.A19994@panzer.kdm.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from des@ofug.org on Mon, Feb 26, 2001 at 08:44:37AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Feb 26, 2001 at 08:44:37 +0100, Dag-Erling Smorgrav wrote: > "Kenneth D. Merry" writes: > > 2. If we do put sbufs in userland, what is the best way to do it? > > Whichever way you do it, you need to change userland sprintf() to > behave like kernel sprintf(), i.e. use a backend function that does > the actual formatting and takes a pointer to a character output > function, instead of what it currently does, which is to fake a FILE > structure with the target string as buffer. Well, what I did was change the kernel implementation to do something that could also be done in userland. It is using vnsprintf() instead of kvprintf. Diffs for that, and the userland conversion are attached. Ken -- Kenneth Merry ken@kdm.org --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="subr_sbuf.c.20010226" ==== //depot/FreeBSD-adaptec/src/sys/kern/subr_sbuf.c#1 - /a/ken/perforce/FreeBSD-adaptec/src/sys/kern/subr_sbuf.c ==== *** /tmp/tmp.77466.0 Mon Feb 26 14:27:27 2001 --- /a/ken/perforce/FreeBSD-adaptec/src/sys/kern/subr_sbuf.c Wed Feb 14 15:33:36 2001 *************** *** 29,42 **** */ #include #include #include - #include #include - #include MALLOC_DEFINE(M_SBUF, "sbuf", "string buffers"); /* * Predicates --- 29,48 ---- */ #include + #include + + #ifdef _KERNEL #include #include #include #include + #else /* _KERNEL */ + #include + #endif /* _KERNEL */ + #ifdef _KERNEL MALLOC_DEFINE(M_SBUF, "sbuf", "string buffers"); + #endif /* _KERNEL */ /* * Predicates *************** *** 52,83 **** #define SBUF_SETFLAG(s, f) do { (s)->s_flags |= (f); } while (0) #define SBUF_CLEARFLAG(s, f) do { (s)->s_flags &= ~(f); } while (0) /* * Debugging support */ ! #ifdef INVARIANTS static void assert_sbuf_integrity(struct sbuf *s) { ! KASSERT(s != NULL, (__FUNCTION__ " called with a NULL sbuf pointer")); ! KASSERT(s->s_buf != NULL, (__FUNCTION__ " called with unitialized or corrupt sbuf")); ! KASSERT(s->s_len < s->s_size, ("wrote past end of sbuf (%d >= %d)", s->s_len, s->s_size)); } static void assert_sbuf_state(struct sbuf *s, int state) { ! KASSERT((s->s_flags & SBUF_FINISHED) == state, (__FUNCTION__ " called with %sfinished or corrupt sbuf", (state ? "un" : ""))); } ! #else #define assert_sbuf_integrity(s) do { } while (0) #define assert_sbuf_state(s, i) do { } while (0) ! #endif /* * Initialize an sbuf. --- 58,95 ---- #define SBUF_SETFLAG(s, f) do { (s)->s_flags |= (f); } while (0) #define SBUF_CLEARFLAG(s, f) do { (s)->s_flags &= ~(f); } while (0) + #ifdef _KERNEL + #define SBASSERT(e, m) KASSERT(e, m) + #else /* _KERNEL */ + #define SBASSERT(e, m) + #endif /* _KERNEL */ + /* * Debugging support */ ! #if defined(_KERNEL) && defined(INVARIANTS) static void assert_sbuf_integrity(struct sbuf *s) { ! SBASSERT(s != NULL, (__FUNCTION__ " called with a NULL sbuf pointer")); ! SBASSERT(s->s_buf != NULL, (__FUNCTION__ " called with unitialized or corrupt sbuf")); ! SBASSERT(s->s_len < s->s_size, ("wrote past end of sbuf (%d >= %d)", s->s_len, s->s_size)); } static void assert_sbuf_state(struct sbuf *s, int state) { ! SBASSERT((s->s_flags & SBUF_FINISHED) == state, (__FUNCTION__ " called with %sfinished or corrupt sbuf", (state ? "un" : ""))); } ! #else /* _KERNEL && INVARIANTS */ #define assert_sbuf_integrity(s) do { } while (0) #define assert_sbuf_state(s, i) do { } while (0) ! #endif /* _KERNEL && INVARIANTS */ /* * Initialize an sbuf. *************** *** 87,97 **** int sbuf_new(struct sbuf *s, char *buf, int length, int flags) { ! KASSERT(length >= 0, ("attempt to create an sbuf of negative length (%d)", length)); ! KASSERT(flags == 0, (__FUNCTION__ " called with non-zero flags")); ! KASSERT(s != NULL, (__FUNCTION__ " called with a NULL sbuf pointer")); bzero(s, sizeof *s); --- 99,109 ---- int sbuf_new(struct sbuf *s, char *buf, int length, int flags) { ! SBASSERT(length >= 0, ("attempt to create an sbuf of negative length (%d)", length)); ! SBASSERT(flags == 0, (__FUNCTION__ " called with non-zero flags")); ! SBASSERT(s != NULL, (__FUNCTION__ " called with a NULL sbuf pointer")); bzero(s, sizeof *s); *************** *** 100,106 **** --- 112,122 ---- s->s_buf = buf; return (0); } + #ifdef _KERNEL s->s_buf = malloc(s->s_size, M_SBUF, M_WAITOK); + #else /* _KERNEL */ + s->s_buf = (char *)malloc(s->s_size); + #endif /* _KERNEL */ if (s->s_buf == NULL) return (-1); SBUF_SETFLAG(s, SBUF_DYNAMIC); *************** *** 130,138 **** assert_sbuf_integrity(s); assert_sbuf_state(s, 0); ! KASSERT(pos >= 0, ("attempt to seek to a negative position (%d)", pos)); ! KASSERT(pos < s->s_size, ("attempt to seek past end of sbuf (%d >= %d)", pos, s->s_size)); if (pos < 0 || pos > s->s_len) --- 146,154 ---- assert_sbuf_integrity(s); assert_sbuf_state(s, 0); ! SBASSERT(pos >= 0, ("attempt to seek to a negative position (%d)", pos)); ! SBASSERT(pos < s->s_size, ("attempt to seek past end of sbuf (%d >= %d)", pos, s->s_size)); if (pos < 0 || pos > s->s_len) *************** *** 175,180 **** --- 191,197 ---- return (sbuf_cat(s, str)); } + #if 0 /* * PCHAR function for sbuf_printf() */ *************** *** 193,198 **** --- 210,216 ---- else SBUF_SETFLAG(s, SBUF_OVERFLOWED); } + #endif /* * Format the given arguments and append the resulting string to an sbuf. *************** *** 206,222 **** assert_sbuf_integrity(s); assert_sbuf_state(s, 0); ! KASSERT(fmt != NULL, (__FUNCTION__ " called with a NULL format string")); if (SBUF_HASOVERFLOWED(s)) return (-1); va_start(ap, fmt); len = kvprintf(fmt, _sbuf_pchar, s, 10, ap); va_end(ap); ! KASSERT(s->s_len < s->s_size, ("wrote past end of sbuf (%d >= %d)", s->s_len, s->s_size)); if (SBUF_HASOVERFLOWED(s)) --- 224,249 ---- assert_sbuf_integrity(s); assert_sbuf_state(s, 0); ! SBASSERT(fmt != NULL, (__FUNCTION__ " called with a NULL format string")); if (SBUF_HASOVERFLOWED(s)) return (-1); + #if 0 va_start(ap, fmt); len = kvprintf(fmt, _sbuf_pchar, s, 10, ap); va_end(ap); + #endif + va_start(ap, fmt); + len = vsnprintf(&s->s_buf[s->s_len], s->s_size - s->s_len, fmt, ap); + va_end(ap); + + s->s_len += len; + if (!SBUF_HASROOM(s)) + SBUF_SETFLAG(s, SBUF_OVERFLOWED); ! SBASSERT(s->s_len < s->s_size, ("wrote past end of sbuf (%d >= %d)", s->s_len, s->s_size)); if (SBUF_HASOVERFLOWED(s)) *************** *** 303,308 **** --- 330,339 ---- /* don't care if it's finished or not */ if (SBUF_ISDYNAMIC(s)) + #ifdef _KERNEL free(s->s_buf, M_SBUF); + #else /* _KERNEL */ + free(s->s_buf); + #endif /* _KERNEL */ bzero(s, sizeof *s); } --qMm9M+Fa2AknHoGS-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 14:22:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-74.dsl.lsan03.pacbell.net [63.207.60.74]) by hub.freebsd.org (Postfix) with ESMTP id 7120A37B401 for ; Mon, 26 Feb 2001 14:22:11 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4781466B09; Mon, 26 Feb 2001 14:22:11 -0800 (PST) Date: Mon, 26 Feb 2001 14:22:11 -0800 From: Kris Kennaway To: "Andrey A. Chernov" Cc: "Jacques A. Vidrine" , arch@freebsd.org Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226142211.A20768@mollari.cthul.hu> References: <20010225132152.A39554@mollari.cthul.hu> <20010226005004.B59772@nagual.pp.ru> <20010225135429.A47615@mollari.cthul.hu> <20010226020827.A61007@nagual.pp.ru> <20010225151519.A63582@mollari.cthul.hu> <20010226022902.A61216@nagual.pp.ru> <20010225173445.A37510@spawn.nectar.com> <20010226024456.A61566@nagual.pp.ru> <20010226174852.B435@ringworld.oblivion.bg> <20010226191008.A72434@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010226191008.A72434@nagual.pp.ru>; from ache@nagual.pp.ru on Mon, Feb 26, 2001 at 07:10:09PM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 26, 2001 at 07:10:09PM +0300, Andrey A. Chernov wrote: > We already go throught all this logn tume ago with the same change with > random() (which is NOT original code). Practice says that nobody seriously > want old behaviour. Moreover, standards (like SUSv2 f.e.) don't guarantee > that the formula must be the same on different machines or even through > different libc versions. It must be the same for single application run > only, so in theory we can change formula for each application run :-) >=20 > So, I plan to skip this step as superfuous. You have my support in this -- people who really want the broken, not-even-statistically-random rand() can add it to their applications; it's only about 5 lines of code. There's no need to penalize everyone else for their mistakes in using it (or misusing it; see concerns about people trying to compare rand() results across different platforms). Kris --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6mtcSWry0BWjoQKURAuBQAJwMaMT4VpTS2tCbHtQNeevwlgrnUwCbB5My kIBc5IetXchaKI9UTAqglnE= =C8cE -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 14:59:57 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 C520F37B401 for ; Mon, 26 Feb 2001 14:59:55 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1QMxhP46130; Mon, 26 Feb 2001 14:59:43 -0800 (PST) (envelope-from dillon) Date: Mon, 26 Feb 2001 14:59:43 -0800 (PST) From: Matt Dillon Message-Id: <200102262259.f1QMxhP46130@earth.backplane.com> To: Kris Kennaway Cc: "Andrey A. Chernov" , "Jacques A. Vidrine" , arch@FreeBSD.ORG Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) References: <20010225132152.A39554@mollari.cthul.hu> <20010226005004.B59772@nagual.pp.ru> <20010225135429.A47615@mollari.cthul.hu> <20010226020827.A61007@nagual.pp.ru> <20010225151519.A63582@mollari.cthul.hu> <20010226022902.A61216@nagual.pp.ru> <20010225173445.A37510@spawn.nectar.com> <20010226024456.A61566@nagual.pp.ru> <20010226174852.B435@ringworld.oblivion.bg> <20010226191008.A72434@nagual.pp.ru> <20010226142211.A20768@mollari.cthul.hu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> random() (which is NOT original code). Practice says that nobody seriously :> want old behaviour. Moreover, standards (like SUSv2 f.e.) don't guarantee :> that the formula must be the same on different machines or even through :> different libc versions. It must be the same for single application run :> only, so in theory we can change formula for each application run :-) :>=20 :> So, I plan to skip this step as superfuous. You can't change the formula for each application run. One of the biggest reasons one specifies a seed is to ensure that the same random sequence will be produced across multiple program runs. Otherwise debugging can very difficult to impossible. Calling srandomdev() for random/srandom is a sufficient statement of intent to not want a reproducable sequence. calling srandom() is a sufficient statement of intent that you want a reproducable sequence. For rand() you don't have a choice. You only have srand() to call (and get a fixed seed of 1 if you don't). The specs imply that if you will get the same random sequence given the same seed. While we can change the algorithm between releases without creating too much dissention, we sure as hell can't change the algorithm for every process. The way I see it, we can only protect programmers against their own stupidity to a certain degree. We should not be wasting resources trying to make rand() perfect. It just needs to be able to do its jobs fairly well within the bounds of the API. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 15: 9:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4DE1E37B65D for ; Mon, 26 Feb 2001 15:09:16 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA26427; Mon, 26 Feb 2001 16:09:07 -0700 (MST) (envelope-from ken) Date: Mon, 26 Feb 2001 16:09:07 -0700 From: "Kenneth D. Merry" To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland Message-ID: <20010226160907.A26335@panzer.kdm.org> References: <20010226003319.A19994@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from bde@zeta.org.au on Tue, Feb 27, 2001 at 04:05:34AM +1100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 27, 2001 at 04:05:34 +1100, Bruce Evans wrote: > On Mon, 26 Feb 2001, Kenneth D. Merry wrote: > > > ... > > I would like to use the sbuf(9) interface to do the string formatting, > > since it is fairly superior to my current string formatting method (see > > scsi_sense_string() in sys/cam/scsi/scsi_all.c). > > ... > > > Code without sbufs: > > > > switch (error_code) { > > case SSD_DEFERRED_ERROR: > > retlen = snprintf(tmpstr, tmpstrlen, "Deferred Error: "); > > > > if ((tmplen = str_len - cur_len - 1) < 0) > > goto sst_bailout; > > > > strncat(str, tmpstr, tmplen); > > cur_len += retlen; > > str[str_len - 1] = '\0'; > > /* FALLTHROUGH */ > > This seems to be insufficiently large to be correct :-). It doesn't check > for snprintf failing (retlen == -1) or truncating (retlen >= tmpstrlen). True, something like this might do the trick: switch (error_code) { case SSD_DEFERRED_ERROR: retlen = snprintf(tmpstr, tmpstrlen, "Deferred Error: "); if (((tmplen = str_len - cur_len - 1) < 0) || (retlen == -1)) goto sst_bailout; strncat(str, tmpstr, tmplen); cur_len += min(retlen, tmpstrlen); str[str_len - 1] = '\0'; /* FALLTHROUGH */ I think failures are unlikely -- tmpstr is generally long enough to handle anything thrown at it, and I think most of the cases that would cause snprintf() to return -1 are unlikely with our code. The most likely scenario that would cause it would be some sort of integer conversion overflow. In any case, if we end up going with the snprintf version of things instead of sbufs, I'll put the above fixes in to make sure things are correct. > > > > Code with sbufs: > > > > switch (error_code) { > > case SSD_DEFERRED_ERROR: > > sbuf_printf(sb, "Deferred Error: "); > > > > /* FALLTHROUGH */ > > Code with an funopen(3)'d stream: > > switch (error_code) { > case SSD_DEFERRED_ERROR: > fprintf(fp, "Deferred Error: "); > > /* FALLTHROUGH */ > > :-). > > funopen() is more general than sbufs, so it is not quite as easy to use, > but I think it is easy enough. As Poul-Henning pointed out, it would need to be available in the kernel as well as userland in order to accomplish the goal of getting rid of functionally duplicated code. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 16:41: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 4CC0637B401; Mon, 26 Feb 2001 16:41:38 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1R0fbd18655; Mon, 26 Feb 2001 17:41:37 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102270041.f1R0fbd18655@harmony.village.org> Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h To: John Baldwin , Matthew Jacob , cvs-committers@FreeBSD.org Cc: arch@FreeBSD.org Reply-To: arch@FreeBSD.org In-reply-to: Your message of "Thu, 25 Jan 2001 12:33:56 MST." <200101251933.f0PJXu972906@harmony.village.org> References: <200101251933.f0PJXu972906@harmony.village.org> Date: Mon, 26 Feb 2001 17:41:37 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK. I've let the documentation on this languish a month. You can find very rough drafts of the resource_query_stirng and resource_int_value man pages at http://people.freebsd.org/~imp/hint-doc.tar.gz Please reply to arch@ with comments on the docs. The interface could likely stand some work as well, but I'm less interested in bikeshedding that than I am in polishing these docs. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 19:10:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id A6B7437B4EC; Mon, 26 Feb 2001 19:10:47 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id UAA43730; Mon, 26 Feb 2001 20:10:20 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdeIMaya; Mon Feb 26 20:10:11 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA09594; Mon, 26 Feb 2001 20:10:31 -0700 (MST) From: Terry Lambert Message-Id: <200102270310.UAA09594@usr05.primenet.com> Subject: Re: cvs commit: ports/astro/xglobe/files patch-random To: n@nectar.com (Jacques A. Vidrine) Date: Tue, 27 Feb 2001 03:10:31 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), kris@FreeBSD.ORG (Kris Kennaway), arch@FreeBSD.ORG In-Reply-To: <20010226090108.C42108@spawn.nectar.com> from "Jacques A. Vidrine" at Feb 26, 2001 09:01:08 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > So if I run the same program, compiled on a Solaris box, and > > compiled on a FreeBSD box, both linked against the platform > > libc, I will get the same results from both machines, without > > having to carry the random number generator code with my > > program, over to the new platform? > > Why do you expect this anyway? I am a scientist. Repeatability of experiments is important. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 19:18: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 66E1E37B491; Mon, 26 Feb 2001 19:18:05 -0800 (PST) (envelope-from nectar@nectar.com) Received: by gw.nectar.com (Postfix, from userid 1001) id 57B0918C91; Mon, 26 Feb 2001 21:18:04 -0600 (CST) Date: Mon, 26 Feb 2001 21:18:04 -0600 From: "Jacques A. Vidrine" To: Terry Lambert Cc: Kris Kennaway , arch@FreeBSD.ORG Subject: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226211804.A44846@spawn.nectar.com> References: <20010226090108.C42108@spawn.nectar.com> <200102270310.UAA09594@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102270310.UAA09594@usr05.primenet.com>; from tlambert@primenet.com on Tue, Feb 27, 2001 at 03:10:31AM +0000 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 27, 2001 at 03:10:31AM +0000, Terry Lambert wrote: > > > So if I run the same program, compiled on a Solaris box, and > > > compiled on a FreeBSD box, both linked against the platform > > > libc, I will get the same results from both machines, without > > > having to carry the random number generator code with my > > > program, over to the new platform? > > > > Why do you expect this anyway? > > I am a scientist. Repeatability of experiments is important. I meant: Why do you expect that, for example, Solaris's rand() implementation would give the same results as FreeBSD's rand() implementation, or that on any other platform? The algorithm is not specified by ISO C, nor by POSIX, nor by SUSv2. In fact, the latter goes so far as to add: The following code defines a pair of functions which could be incorporated into applications wishing to ensure that the same sequence of numbers is generated across different machines: static unsigned long int next = 1; int myrand(void) { ... a random number generator ... } The implication being, of course, that if you want your results to be the same across platforms, than you need to provide your own PRNG instead of using rand(). Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@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 Feb 26 19:18:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 2D7C737B491 for ; Mon, 26 Feb 2001 19:18:08 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id UAA12226; Mon, 26 Feb 2001 20:12:55 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAuFaW0x; Mon Feb 26 20:12:49 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA09690; Mon, 26 Feb 2001 20:17:57 -0700 (MST) From: Terry Lambert Message-Id: <200102270317.UAA09690@usr05.primenet.com> Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) To: roam@orbitel.bg (Peter Pentchev) Date: Tue, 27 Feb 2001 03:17:57 +0000 (GMT) Cc: ache@nagual.pp.ru (Andrey A. Chernov), n@nectar.com (Jacques A. Vidrine), arch@FreeBSD.ORG, kris@obsecurity.org In-Reply-To: <20010226174852.B435@ringworld.oblivion.bg> from "Peter Pentchev" at Feb 26, 2001 05:48:53 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Just thought I'd throw two cents before any patch is applied.. > > It seems that there are people who need the old rand() behavior. > How about isolating the old (current) rand(), srand(), rand_r() and > whatever else is needed, to a separate library (-lrand?), and > announce that programs that need old (traditional) rand() behavior > need to be linked against -lrand? > > (I hope that I'm correct in thinking that if -lrand is specified > on the linker cmdline, its rand() shall override the one in libc?) Yes, this would work. As I said before, I'd like the traditional behaviour, exhibited by UNIX systems other than a modified FreeBSD, to be default, but could live with this FreeBSD specific hack being necessary, where it wasn't necessary on all other UNIX systems. With respect to the idea that shared ELF binaries are supposed to be portable between ELF platforms soon/eventually, I guess setting the platfor specific OS_ABI flag for FreeBSD, and requiring a section causing librand.so to be loaded only for FreeBSD would work (though I can't see vendors rushing to add FreeBSD specific hacks to their code, and more than I can see them rushing to add HP specific hacks to handle pure virtual base class construction). I know of at least two games which depend on the random number generator producing repeatable results in order to have maps that are actually fully navigable. I rather doubt their vendors will carry around their own working generators so that their code will run on FreeBSD, if it runs on Linux without such hacks. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 19:44:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from areilly.bpc-users.org (CPE-144-132-234-126.nsw.bigpond.net.au [144.132.234.126]) by hub.freebsd.org (Postfix) with SMTP id CED3E37B491 for ; Mon, 26 Feb 2001 19:44:08 -0800 (PST) (envelope-from areilly@bigpond.net.au) Received: (qmail 35159 invoked by uid 1000); 27 Feb 2001 03:44:08 -0000 From: "Andrew Reilly" Date: Tue, 27 Feb 2001 14:44:08 +1100 To: Terry Lambert Cc: Peter Pentchev , "Andrey A. Chernov" , "Jacques A. Vidrine" , arch@FreeBSD.ORG, kris@obsecurity.org Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010227144408.A34881@gurney.reilly.home> References: <20010226174852.B435@ringworld.oblivion.bg> <200102270317.UAA09690@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102270317.UAA09690@usr05.primenet.com>; from tlambert@primenet.com on Tue, Feb 27, 2001 at 03:17:57AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 27, 2001 at 03:17:57AM +0000, Terry Lambert wrote: > I know of at least two games which depend on the random number > generator producing repeatable results in order to have maps > that are actually fully navigable. I rather doubt their vendors > will carry around their own working generators so that their > code will run on FreeBSD, if it runs on Linux without such hacks. Relying on that sort of specific behaviour of joe Unix's rand() function, and you're calling _what_ a hack? That sort of assumption is simply insane, and frankly I don't believe you for a minute. (Well, OK: never underestimate stupidity, I guess...) Sure, rand() should produce the same results after successive calls to srand() with the same seed: that's what the spec says. Nothing anywhere has ever said that these _sequences_ should be portable between machines. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 20: 0:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id D2DB537B4EC; Mon, 26 Feb 2001 20:00:33 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id UAA15730; Mon, 26 Feb 2001 20:54:13 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAATlayOE; Mon Feb 26 20:54:05 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA11366; Mon, 26 Feb 2001 21:00:22 -0700 (MST) From: Terry Lambert Message-Id: <200102270400.VAA11366@usr05.primenet.com> Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) To: n@nectar.com (Jacques A. Vidrine) Date: Tue, 27 Feb 2001 04:00:22 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), kris@FreeBSD.ORG (Kris Kennaway), arch@FreeBSD.ORG In-Reply-To: <20010226211804.A44846@spawn.nectar.com> from "Jacques A. Vidrine" at Feb 26, 2001 09:18:04 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Why do you expect this anyway? > > > > I am a scientist. Repeatability of experiments is important. > > I meant: Why do you expect that, for example, Solaris's rand() > implementation would give the same results as FreeBSD's rand() > implementation, or that on any other platform? The algorithm > is not specified by ISO C, nor by POSIX, nor by SUSv2. [ ... ] > The implication being, of course, that if you want your results to be the same > across platforms, than you need to provide your own PRNG instead of using > rand(). The 48 bit linear congruential algorithm is a defacto standard for the implementation across UNIX platforms. While the standards do not specify this algorithm, in practice it is there, just as, in practice, select() does not modify the contents of timeval, even though the man page permits it to do so, since code would break. I would be much happier if you were to quote a platform standard instead of a language standard to permit change. Realize that C programs will not necessarily run everywhere without modification, unless they are simple, or unless the author takes great care in crafting the code. Even platform standards have been stretched to, for example, include NT and VMS as "technically POSIX compliant". If you can change the underlying implementation of rand(), you might as well do select() and qsort() (which the manual page acknowledges is modified in an unspecified way), since technically, you would be permitted to do so. The qsort() example is rather quixotic; the select() example, less so, since the change would in fact permit higher resolution in timing than is currently permitted in the context of a select timeout. Can someone put forth a use for rand() which requires this change to permit the use to employe rand() instead of its own code? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 20: 4:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 1EE6A37B491 for ; Mon, 26 Feb 2001 20:04:50 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id UAA26854; Mon, 26 Feb 2001 20:59:37 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAOgaqx0; Mon Feb 26 20:59:29 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA11459; Mon, 26 Feb 2001 21:04:34 -0700 (MST) From: Terry Lambert Message-Id: <200102270404.VAA11459@usr05.primenet.com> Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) To: areilly@bigpond.net.au (Andrew Reilly) Date: Tue, 27 Feb 2001 04:04:34 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), roam@orbitel.bg (Peter Pentchev), ache@nagual.pp.ru (Andrey A. Chernov), n@nectar.com (Jacques A. Vidrine), arch@FreeBSD.ORG, kris@obsecurity.org In-Reply-To: <20010227144408.A34881@gurney.reilly.home> from "Andrew Reilly" at Feb 27, 2001 02:44:08 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Sure, rand() should produce the same results after successive > calls to srand() with the same seed: that's what the spec says. > Nothing anywhere has ever said that these _sequences_ should be > portable between machines. Historically, they have been, whether or not someone has said they should be is not relevent, since they have been derived from common source code. I remember when the standard rand() went into the FreeBSD source base; almost immediately thereafter, I added patches to the f2c math library, and began using FreeBSD as a science platform. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 20:27: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 5802637B401; Mon, 26 Feb 2001 20:27:01 -0800 (PST) Date: Mon, 26 Feb 2001 20:27:01 -0800 From: Kris Kennaway To: Terry Lambert Cc: "Jacques A. Vidrine" , Kris Kennaway , arch@FreeBSD.ORG Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226202701.A13175@hub.freebsd.org> References: <20010226211804.A44846@spawn.nectar.com> <200102270400.VAA11366@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102270400.VAA11366@usr05.primenet.com>; from tlambert@primenet.com on Tue, Feb 27, 2001 at 04:00:22AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 27, 2001 at 04:00:22AM +0000, Terry Lambert wrote: > > > > Why do you expect this anyway? > > > > > > I am a scientist. Repeatability of experiments is important. > > > > I meant: Why do you expect that, for example, Solaris's rand() > > implementation would give the same results as FreeBSD's rand() > > implementation, or that on any other platform? The algorithm > > is not specified by ISO C, nor by POSIX, nor by SUSv2. > > [ ... ] > > > The implication being, of course, that if you want your results to be the same > > across platforms, than you need to provide your own PRNG instead of using > > rand(). > > The 48 bit linear congruential algorithm is a defacto standard for > the implementation across UNIX platforms. While the standards do > not specify this algorithm, in practice it is there, just as, in > practice, select() does not modify the contents of timeval, even > though the man page permits it to do so, since code would break. Don't know where you're pulling 48-bits from (though I have my suspicions :-) but it's not rand() you're talking about (rand is a 32 bit LCRNG). > Can someone put forth a use for rand() which requires this change > to permit the use to employe rand() instead of its own code? Parse error. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 20:42:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 3290837B4EC; Mon, 26 Feb 2001 20:42:33 -0800 (PST) (envelope-from kris@citusc17.usc.edu) Received: (from kris@localhost) by citusc17.usc.edu (8.11.2/8.11.2) id f1R4gPl91775; Mon, 26 Feb 2001 20:42:25 -0800 (PST) (envelope-from kris) Date: Mon, 26 Feb 2001 20:42:24 -0800 From: Kris Kennaway To: Terry Lambert Cc: "Jacques A. Vidrine" , Kris Kennaway , arch@FreeBSD.ORG Subject: Re: cvs commit: ports/astro/xglobe/files patch-random Message-ID: <20010226204224.A91585@citusc17.usc.edu> References: <20010226090108.C42108@spawn.nectar.com> <200102270310.UAA09594@usr05.primenet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102270310.UAA09594@usr05.primenet.com>; from tlambert@primenet.com on Tue, Feb 27, 2001 at 03:10:31AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 27, 2001 at 03:10:31AM +0000, Terry Lambert wrote: > > > So if I run the same program, compiled on a Solaris box, and > > > compiled on a FreeBSD box, both linked against the platform > > > libc, I will get the same results from both machines, without > > > having to carry the random number generator code with my > > > program, over to the new platform? > >=20 > > Why do you expect this anyway? >=20 > I am a scientist. Repeatability of experiments is important. As as scientist, you naturally care about your PRNG giving good statistical randomness, so you don't get skewed results from your simulation. rand() does not appear to give statistically random output - in fact, visual inspection shows it to be patterned. As a good scientist, you did TEST the properties of your PRNG before using it as the foundation for your simulations, didn't you? By fixing the algorithm, we are preventing future generations of scientists from making the same mistake, and thereby ensuring that FreeBSD used as a research platform gives good science, not bad science. Our children and children's children will thank us! Onward, mighty FreeBSD, platform for the future!! Kris --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6mzAwWry0BWjoQKURAmgQAKC8au9K6H82h6hr5yrDiDkYAPn8EACeNB4O N6tZsLTTtDTsJkz+ZfHZhoY= =mlzi -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 22:16:39 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 A08A737B67D for ; Mon, 26 Feb 2001 22:16:35 -0800 (PST) (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 RAA04558; Tue, 27 Feb 2001 17:16:29 +1100 Date: Tue, 27 Feb 2001 17:16:27 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland In-Reply-To: <20010226160907.A26335@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Feb 2001, Kenneth D. Merry wrote: > On Tue, Feb 27, 2001 at 04:05:34 +1100, Bruce Evans wrote: > > This seems to be insufficiently large to be correct :-). It doesn't check > > for snprintf failing (retlen == -1) or truncating (retlen >= tmpstrlen). > > True, something like this might do the trick: > > switch (error_code) { > case SSD_DEFERRED_ERROR: > retlen = snprintf(tmpstr, tmpstrlen, "Deferred Error: "); > > if (((tmplen = str_len - cur_len - 1) < 0) || (retlen == -1)) > goto sst_bailout; > > strncat(str, tmpstr, tmplen); > cur_len += min(retlen, tmpstrlen); > str[str_len - 1] = '\0'; > /* FALLTHROUGH */ > > I think failures are unlikely -- tmpstr is generally long enough to handle > anything thrown at it, and I think most of the cases that would cause > snprintf() to return -1 are unlikely with our code. The most likely > scenario that would cause it would be some sort of integer conversion > overflow. I think snprintf() is very unlikely to return -1 (integer conversion overflow gives undefined behaviour and isn't checked for in our implementation, so it won't cause snprintf() to return -1 ...). The check for retlen < tmpstrlen (indirectly via min()) has a off-by-1 error. > > funopen() is more general than sbufs, so it is not quite as easy to use, > > but I think it is easy enough. > > As Poul-Henning pointed out, it would need to be available in the kernel as > well as userland in order to accomplish the goal of getting rid of > functionally duplicated code. So everyone agrees that sbufs are a mistake :-). The kernel should use the same interfaces as userland for general things like printf() and malloc() (oops, too late), if it needs such interfaces at all, so that programmers can reuse their knowledge of userland. However, I doubt that general string handling in the kernel is needed often enough to justify having sbuf or funopen. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 22:22:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id EEFCD37B684; Mon, 26 Feb 2001 22:22:55 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id XAA06335; Mon, 26 Feb 2001 23:17:45 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAslaytm; Mon Feb 26 23:17:36 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id XAA13867; Mon, 26 Feb 2001 23:22:42 -0700 (MST) From: Terry Lambert Message-Id: <200102270622.XAA13867@usr05.primenet.com> Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) To: kris@FreeBSD.ORG (Kris Kennaway) Date: Tue, 27 Feb 2001 06:22:42 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), n@nectar.com (Jacques A. Vidrine), kris@FreeBSD.ORG (Kris Kennaway), arch@FreeBSD.ORG In-Reply-To: <20010226202701.A13175@hub.freebsd.org> from "Kris Kennaway" at Feb 26, 2001 08:27:01 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Can someone put forth a use for rand() which requires this change > > to permit the use to employe rand() instead of its own code? > > Parse error. What won't work without the change? What is the technical reason the change is necessary? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 22:39:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 6B6F337B6AD; Mon, 26 Feb 2001 22:39:12 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id XAA14392; Mon, 26 Feb 2001 23:38:48 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdATR.ya; Mon Feb 26 23:38:44 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id XAA14165; Mon, 26 Feb 2001 23:39:06 -0700 (MST) From: Terry Lambert Message-Id: <200102270639.XAA14165@usr05.primenet.com> Subject: Re: cvs commit: ports/astro/xglobe/files patch-random To: kris@FreeBSD.ORG (Kris Kennaway) Date: Tue, 27 Feb 2001 06:39:02 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), n@nectar.com (Jacques A. Vidrine), kris@FreeBSD.ORG (Kris Kennaway), arch@FreeBSD.ORG In-Reply-To: <20010226204224.A91585@citusc17.usc.edu> from "Kris Kennaway" at Feb 26, 2001 08:42:24 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > As as scientist, you naturally care about your PRNG giving good > statistical randomness, so you don't get skewed results from your > simulation. > > rand() does not appear to give statistically random output - in fact, > visual inspection shows it to be patterned. As a good scientist, you > did TEST the properties of your PRNG before using it as the foundation > for your simulations, didn't you? > > By fixing the algorithm, we are preventing future generations of > scientists from making the same mistake, and thereby ensuring that > FreeBSD used as a research platform gives good science, not bad > science. Our children and children's children will thank us! Onward, > mighty FreeBSD, platform for the future!! Please donate the code to Sun, SCO, Linux, and so on, then, and let us know when we should turn it on by default. When one uses a pseudo-random number generator to crank out a set of test data points, it is less the randomness of the data points which is important than it is that the data be replicable and "sufficiently random" for the number of samples involved. This is because the test data is not an end in itself, but is instead a data set against which algorithms may be applied in order to test how well theory predicts reality. The use with which I'm most familiar for this is in the output of relativistically invariant P-N and N-N collisions which result in pair production (this is also Berkeley code, BTW, it just happens to be FORTRAN). The value in doing this is not in the pairs produced, but is instead in the pairs discarded by constraints on which pair productions are "possible" or "impossible" according to the theory being tested. This is generally applied via matrix mechanics, involving the soloution of multiple Feynman-Dyson diagrams. Thus it is more important to test one theory vs. another on the same set of pair productions, than it is for the data to be "perfectly random". Without using the same event sets each time, one can not do this reasonably. This is the same argument that was given for a pseudo-random generated network topology and traffic, where the important issue was to test routing algorithms vs. each other on the same network, using the same set of generated traffic. The rand() generator is perfectly reasonable for this use; the randomness is irrelevent when you exceed the resoloution of the number of bits in the generator worth of events by 4 orders of magnitude, when you run the simulation. You might as well complain about the randomness being damaged by the limit on the number of bits the generator is capable of returning. In which case, your replacement is just as damaged as the current algorithm. The "pseudo" is more important than the "random", for all the uses which I (and others) have pointed to as examples. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 26 22:57:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id BB76537B70D for ; Mon, 26 Feb 2001 22:57:11 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1R6vHM26417; Tue, 27 Feb 2001 07:57:17 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: "Kenneth D. Merry" , arch@FreeBSD.ORG Subject: Re: sbufs in userland In-Reply-To: Your message of "Tue, 27 Feb 2001 17:16:27 +1100." Date: Tue, 27 Feb 2001 07:57:17 +0100 Message-ID: <26415.983257037@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Bruce Ev ans writes: >So everyone agrees that sbufs are a mistake :-). The kernel should use >the same interfaces as userland for general things like printf() and >malloc() (oops, too late), if it needs such interfaces at all, so that >programmers can reuse their knowledge of userland. However, I doubt >that general string handling in the kernel is needed often enough to >justify having sbuf or funopen. No we dont argee on that. *if* the kernel can use the same API it should, but most often it can't. strlen() comes to mind as an API where it can't use it. In the kernel strlen should return an error code if it tries to access non-accessible memory, rather than core-dumping as it does in userland. -- 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 Feb 26 23:15:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id DE3C637B71A for ; Mon, 26 Feb 2001 23:15:20 -0800 (PST) (envelope-from kris@citusc17.usc.edu) Received: (from kris@localhost) by citusc17.usc.edu (8.11.2/8.11.2) id f1R7FFY94216; Mon, 26 Feb 2001 23:15:15 -0800 (PST) (envelope-from kris) Date: Mon, 26 Feb 2001 23:15:15 -0800 From: Kris Kennaway To: Terry Lambert Cc: "Jacques A. Vidrine" , arch@FreeBSD.ORG Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010226231515.B94159@citusc17.usc.edu> References: <20010226202701.A13175@hub.freebsd.org> <200102270622.XAA13867@usr05.primenet.com> 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: <200102270622.XAA13867@usr05.primenet.com>; from tlambert@primenet.com on Tue, Feb 27, 2001 at 06:22:42AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --b5gNqxB1S1yM7hjW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 27, 2001 at 06:22:42AM +0000, Terry Lambert wrote: > > > Can someone put forth a use for rand() which requires this change > > > to permit the use to employe rand() instead of its own code? > >=20 > > Parse error. >=20 > What won't work without the change? >=20 > What is the technical reason the change is necessary? See the commit which is still in the subject line of this message. There are really only two possibilities for addressing this: 1) Change rand() to work better and/or 2) Make rand() yell louder when people use it Some people are opposed to both solutions (mainly you for 1). Frankly, I think your objections are the weaker of the two sets, since the number of people who would be affected by changing rand() is small (simulations which need to be replicable across platforms -- dangerous anyway -- or across time) and this set is easily taken care of by those people using a private copy of the 1-line function which is currently called rand(). I'm sure we could even make a libweakrand port for those people to relink against. Okay, now I'm annoyed. I just looked at glibc, and it already does what is being discussed here, namely aliasing rand() to random() (which appears to be the same algorithm we use for random()). There goes your "pseudo-standardization" argument out the window, which means you obviously hadn't checked your facts and were just describing the state of your internal fantasy universe. Thanks for wasting everyone's time with this silly thread. Kris --b5gNqxB1S1yM7hjW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6m1QCWry0BWjoQKURAnC9AKDtsT62g4BastcBGCOem7LBelXRpgCeL1LM ZNU8+bKpn5UwcnZw/gZj13g= =QOo4 -----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 Tue Feb 27 3:36:27 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 1EB9C37B718 for ; Tue, 27 Feb 2001 03:36:16 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f1RBa4R12865 for ; Tue, 27 Feb 2001 13:36:06 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200102271136.f1RBa4R12865@gratis.grondar.za> To: arch@freebsd.org Subject: FreeBSD sources from 20000' Date: Tue, 27 Feb 2001 13:36:49 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello all. There was a pretty good response to my initial probe a few days ago, so the time comes by to revive the discussion, and to slowly begin on the path to an actual solution. REMINDER REMINDER - The whole point of this exercise is NOT to remove ANYTHING from FreeBSD. Effectively, FreeBSD will become a grow-only system with the configuration and installation policies placed in the hands of the owners or sysadmins. By "grow-only", I do not mean we cannot throw out the trash; it just means that arguments such as "please don't remove UUCP" or "please remove the r-utils" are largely irrelevant. REMINDER REMINDER - I am going to be giving a lot of "real life" examples here to attempt to make the explanation understandable - PLEASE do not bikeshed those examples. OK - lets take a look at what we have. FreeBSD is divided into 3 pieces in the repo - "base" (or src/), "ports" and "doc". Consider that division to be removed completely (by some mechanism to be discussed below), and look at FreeBSD as a collection of what CVS would call "modules". Examples of modules are as diverse as "uucp"(src/gnu/libexec/uucp), "ls"(src/bin/ls), "perl5"(src/contrib/perl5), "epic4"(ports/irc/epic4), "kernel"(src/sys), "randomdev"(src/sys/modules/random), "handbook"(doc/mumble/handbook) and so on. Some modules can almost "build themeselves" - autonomous ports and the ordinary BSD stuff like ls(1) or cat(2) are examples of this. Some modules need a little help - kernel modules require kernel source to build, most modules require a minimum toolchain, and some need specialised tools (like the kernel needs config(8) and doc/ needs tons of ports). So - doing a coarse sort of all the modules in freebsd, we end up with a selection of categories loosely looking like this: 1) "base" module currently in FreeBSD CVS repo. (eg: ls(1), cat(1)). 2) "contrib" module currently in FreeBSD CVS repo, externally maintained but "tightly bound" to FreeBSD (eg: perl5, gcc, kerberos, OpenSSH). 3) "KLD" kernel module. (eg: random.ko) 3a) "kernel" all of kernel and includes kernel modules. (src/sys/...) 4) "port" "external" software not built during a "make world". (eg: ports/games/gnuchess) 5) "doc" Documentation that needs SGML-work to be useful. (eg: "English handbook", "Japanese FAQ"). 6) "set" holds other modules (eg: src/bin/, secure/, sys/modules/, "Japanese docs" ports/shells/). I have no doubt missed some. More will crawl out of the woodwork as we work on this, and the borders and subclasses will get redefined. To work on that fine detail now is not useful. Now, we need an understanding of the relationship and use of these modules. Imagine a configuration tree (I am going to use an XML-like metalanguage here for illustration) that takes something like our current repository as input, and builds a tree four output. What that tree is, depends on who the user is and what they want. Example - for ls: ls man1/ls.1 - for emacs: emacs.tar.gz workdir/emacs/foo/bar.c.patch workdir/emacs/baz/qux.c.patch emacs info man1/emacs.1 emacs.info emacslisp.info emacs.help Each of these would have a radically different behaviour for a developer, and a substantially similar behaviour for an end user. For the end user, an "install this please" would simply mean installing the compiled binary and manual pages using the most expedient method. That could mean a download, or reading the relevant files off a CD. For a developer, however, the whole process may involve a CVS checkout/update and a build before installation for ls. Emacs would need a download, a verification, untar, patch, configuration and build (like current ports). A "clean up please" would do nothing for a user. For developers, It would blow away generated crap (.o's and so on) for ls, and the whole untarred build area for emacs. "Uninstall this please" would behave identically for the developer and the user - the relevant "installed bits" would get removed. The distinction between "developer" and "user" should not be taken overly seriously at this stage; kernel hackers may want a binary install of CURRENT to be done automatically - this needs to be possible. Containment (or "set") modules will be structured kinda like so: cat ls echo sh NOTE NOTE - this specifically allows the user to choose to compile what they want where they want. (EG: nothing prevents the "port" ports/shells/bash2 from being compiled as a part of /bin/*). Other possibilities will include the ability to not include certain parts in "MyBSD". Don't want Perl5? You don't have to include it in your build/install. This would require that the user types are profiled, and that common ones are made easily selectable. Types may include "user", "dialup user", "graphics user", "audio user", "Apache server", "MySQL server", "kernel hacker", "X/KDE hacker", "X/Gnome hacker", "[X]Emacs hacker", "Utils hacker", "Perl Hacker", "Crypto Hacker", "Kerberos Hacker", "Apache hacker" and so on (all of them tweakable, and some of them capable of sub or multiple categories). OK. End of this thought-dump. Who's coming to play? 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 Tue Feb 27 4:49:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id D1C5637B718; Tue, 27 Feb 2001 04:49:41 -0800 (PST) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id AA83118C91; Tue, 27 Feb 2001 06:49:39 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f1RCndt81557; Tue, 27 Feb 2001 06:49:39 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Tue, 27 Feb 2001 06:49:38 -0600 From: "Jacques A. Vidrine" To: Terry Lambert Cc: Kris Kennaway , arch@FreeBSD.ORG Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) Message-ID: <20010227064938.A81525@hamlet.nectar.com> References: <20010226211804.A44846@spawn.nectar.com> <200102270400.VAA11366@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102270400.VAA11366@usr05.primenet.com>; from tlambert@primenet.com on Tue, Feb 27, 2001 at 04:00:22AM +0000 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 27, 2001 at 04:00:22AM +0000, Terry Lambert wrote: > The 48 bit linear congruential algorithm is a defacto standard for > the implementation across UNIX platforms. Are you sure you're not confusing rand() with System V's drand48() and family? The latter _does_ have a well-defined algorithm. > While the standards do not specify this algorithm, in practice it is > there, just as, in practice, select() does not modify the contents > of timeval, even though the man page permits it to do so, since code > would break. Yes, this is a somewhat good analogy. Thanks for your support :-) Portable applications must assume that timeout is modified. Even our own man page points out that applications should assume this. > I would be much happier if you were to quote a platform standard > instead of a language standard to permit change. I already mentioned POSIX.1 and SUSv2. rand() is also defined in SVID, where it has no set algorithm either. [snip] > Can someone put forth a use for rand() which requires this change > to permit the use to employe rand() instead of its own code? I've already posted about two (non-crypto) applications that performed poorly when using rand(), but admirably when switched to random(). This was fun, but this will have to be my last post on the subject. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@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 Feb 27 9:58: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 3195437B71B; Tue, 27 Feb 2001 09:58:04 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id MAA52178; Tue, 27 Feb 2001 12:57:59 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010226204224.A91585@citusc17.usc.edu> References: <20010226090108.C42108@spawn.nectar.com> <200102270310.UAA09594@usr05.primenet.com> <20010226204224.A91585@citusc17.usc.edu> Date: Tue, 27 Feb 2001 12:57:58 -0500 To: Kris Kennaway , Terry Lambert From: Garance A Drosihn Subject: Re: cvs commit: ports/astro/xglobe/files patch-random Cc: "Jacques A. Vidrine" , Kris Kennaway , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 8:42 PM -0800 2/26/01, Kris Kennaway wrote: >On Tue, Feb 27, 2001 at 03:10:31AM +0000, Terry Lambert wrote: > > I am a scientist. Repeatability of experiments is important. > >As as scientist, you naturally care about your PRNG giving good >statistical randomness, so you don't get skewed results from your >simulation. It depends on what you are using rand() for. >rand() does not appear to give statistically random output - in >fact, visual inspection shows it to be patterned. As a good >scientist, you did TEST the properties of your PRNG before using >it as the foundation for your simulations, didn't you? There are plenty of good scientists at RPI. One of them on the same floor as me once spent WEEKS testing various pseudo-random algorithms to be sure the results were statistically random based on a variety of different criteria. He found one method that worked, and used that for the simulations where he needed that level of truly-random output. That does not mean he never uses rand(). It just depends on what the project is, and the reason you want a random bunch of numbers. Sometimes you DO want the same random numbers between multiple platforms, because you are trying to benchmark the platform, and not solve some statistical analysis. >By fixing the algorithm, we are preventing future generations >of scientists from making the same mistake, and thereby ensuring >that FreeBSD used as a research platform gives good science, not >bad science. Our children and children's children will thank us! >Onward, mighty FreeBSD, platform for the future!! There is a simple solution for this concern. It is called "the man page". Leave rand() alone, and simply document it's limitations. The man page already explicitly says: "rand, srand, rand_r - bad random number generator" and "These interfaces are obsoleted by random(3)" In my book, that means anyone interested in "true statistical randomness" has already been given a pretty clear warning. random(3) claims to have appeared in 4.2bsd (1993?), so people have had plenty of time change to a much better algorithm IF THEY NEED statistical randomness. Me, I don't do much with random numbers, so I don't really have a strong feeling if whether rand() should be changed. However, my gut feeling is that Terry's argument is valid, and we can address your valid concern without disrupting people who are using rand() for reasons different than what you are assuming they are using it for. Admittedly the standards I have seen for rand state that different implementations of rand MAY produce different sequences for a given seed. That does not mean that they MUST, and I don't see much advantage in changing rand() at this point in time, when there are already so many superior random-number generating routines defined. If you DO want to change rand(), then at least try to change it to match a "superior rand implementation" on some other platform, and don't just pull some brand new strategy out of thin air. People apparently recognized that rand() was not statistically random back in 1993, and yet they fixed that by providing a new routine instead of altering the current one. I see no reason to "fix" it now. So I say, leave the algorithm alone. The proper fix to the original bikeshed is to just change xglobe to stop using rand, if it really bothers people that much. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 10:30:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 2BD9637B71A; Tue, 27 Feb 2001 10:30:50 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA60644; Tue, 27 Feb 2001 13:30:48 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010226231515.B94159@citusc17.usc.edu> References: <20010226202701.A13175@hub.freebsd.org> <200102270622.XAA13867@usr05.primenet.com> <20010226231515.B94159@citusc17.usc.edu> Date: Tue, 27 Feb 2001 13:30:46 -0500 To: Kris Kennaway , Terry Lambert From: Garance A Drosihn Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) Cc: "Jacques A. Vidrine" , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:15 PM -0800 2/26/01, Kris Kennaway wrote: >There are really only two possibilities for addressing this: > >1) Change rand() to work better > >and/or > >2) Make rand() yell louder when people use it or 3) Assume the world will survive if we leave things the way they have been for the past eight years. No change necessary. >Some people are opposed to both solutions (mainly you for 1). It is not necessarily clear that -arch is a "statistically valid sampling" of people who use rand(). >Okay, now I'm annoyed. I just looked at glibc, and it already does >what is being discussed here, namely aliasing rand() to random() >(which appears to be the same algorithm we use for random()). Good, now we're all annoyed. Here is a routine which EXPLICITLY says "Hey, this is a routine which really sucks at generating random numbers", and people complain when they use it and get sucky random numbers. >There goes your "pseudo-standardization" argument out the window, >which means you obviously hadn't checked your facts and were just >describing the state of your internal fantasy universe. Thanks >for wasting everyone's time with this silly thread. I am aware of other people who live in the same fantasy universe, so I think this thread is spiraling downwards. A few of those people even ran tests to see if rand() produced the same results across the platforms they cared about, and once that was proven, they just assumed that would remain true (most of them are doing comparisons across time, though, not across platforms. Still, "across time" tends to become "across platforms", as hardware changes around here). It *is* interesting to find out that glibc does use the same algorithm as random(). Glibc hasn't been used much among the people I'm thinking of, but it's certainly getting used more as linux makes inroads on campus. Now I am also wondering if rand() still produces similar results across the other unix platforms we have on campus. I have not responded on this thread before now, because I really thought it was a silly thing for people to get worked up about and that it would die down and we'd get back to trivial issues, like SMPng or something. However, this thread now seems to be descending into inflammatory rubbish, and if we're all going to go up on flames on such a silly topic, then I think I'll be standing on Terry's side of the barbecue. Even if Terry didn't check glibc (that bastion of UNIX standardization) to prove his position, his position *is* one that others *have* had, and he isn't just bringing it up to annoy you folks. So maybe calm down a little bit. The checking of glibc was a good idea, and maybe we could do a bit more checking to see what other platforms are doing. We may very well find out that we're the odd one out because we HAVEN'T changed rand to = random, in which case we'll have a very good case to make the same change. But then we can do it based on facts, instead of getting upset and claiming people live in fantasy universes. As I said before, I don't really care which way it goes, but it is pretty silly that we can't figure out a calmer way to resolve this thread, instead of just ranting back and forth about it. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 10:34:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id A36F637B719 for ; Tue, 27 Feb 2001 10:34:11 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA77474; Tue, 27 Feb 2001 13:33:52 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010227144408.A34881@gurney.reilly.home> References: <20010226174852.B435@ringworld.oblivion.bg> <200102270317.UAA09690@usr05.primenet.com> <20010227144408.A34881@gurney.reilly.home> Date: Tue, 27 Feb 2001 13:33:50 -0500 To: "Andrew Reilly" , Terry Lambert From: Garance A Drosihn Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Cc: Peter Pentchev , "Andrey A. Chernov" , "Jacques A. Vidrine" , arch@FreeBSD.ORG, kris@obsecurity.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 2:44 PM +1100 2/27/01, Andrew Reilly wrote: >That sort of assumption is simply insane, and frankly I don't >believe you for a minute. (Well, OK: never underestimate >stupidity, I guess...) > >Sure, rand() should produce the same results after successive >calls to srand() with the same seed: that's what the spec says. >Nothing anywhere has ever said that these _sequences_ should be >portable between machines. However, it is reasonable to assume the sequences WILL be the the same across time on a single platform, and the proposed change will be breaking that. In fact, it is "simply insane" to claim that it is "fine" if the sequences are not repeatable over time on a given platform, because there would then be no reason at all to have a way to get a "repeatable sequence of random numbers". -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 10:40: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id F2D7737B739 for ; Tue, 27 Feb 2001 10:39:49 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA47230; Tue, 27 Feb 2001 13:39:40 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200102270317.UAA09690@usr05.primenet.com> References: <200102270317.UAA09690@usr05.primenet.com> Date: Tue, 27 Feb 2001 13:39:38 -0500 To: Terry Lambert , roam@orbitel.bg (Peter Pentchev) From: Garance A Drosihn Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) Cc: ache@nagual.pp.ru (Andrey A. Chernov), n@nectar.com (Jacques A. Vidrine), arch@FreeBSD.ORG, kris@obsecurity.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 3:17 AM +0000 2/27/01, Terry Lambert wrote: >I know of at least two games which depend on the random number >generator producing repeatable results in order to have maps >that are actually fully navigable. I rather doubt their vendors >will carry around their own working generators so that their >code will run on FreeBSD, if it runs on Linux without such hacks. As an aside, I wonder if this explains some games I have played in the past, which had a habit of producing "random maps" which were simply unwinnable for me... Still, for this specific point, any game-vendor who NEEDS a repeatable random-number sequence SHOULD implement their own random number generator. It would be pretty trivial to do, after all, and if I'm selling a game I don't think I would ask a variety of operating systems to produce random numbers, and then trust that all of those operating systems will give me the exact same list... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 10:58:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (node16292.a2000.nl [24.132.98.146]) by hub.freebsd.org (Postfix) with ESMTP id CCD4837B718 for ; Tue, 27 Feb 2001 10:58:29 -0800 (PST) (envelope-from adrian@roaming.cacheboy.net) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f1RDefA35890; Tue, 27 Feb 2001 14:40:42 +0100 (CET) (envelope-from adrian) Date: Tue, 27 Feb 2001 14:40:21 +0100 From: Adrian Chadd To: "Kenneth D. Merry" Cc: freebsd-arch@freebsd.org Subject: Re: sbufs in userland Message-ID: <20010227144021.A35833@roaming.cacheboy.net> References: <20010226003319.A19994@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010226003319.A19994@panzer.kdm.org>; from ken@kdm.org on Mon, Feb 26, 2001 at 12:33:19AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 26, 2001, Kenneth D. Merry wrote: > > As part of a re-write of the CAM error recovery code that Justin and I have > been working on, I have been re-doing the CAM error printing code. > > One of the things I'm working on is making the error printing code in the > kernel and in userland as similar as possible. > > I would like to use the sbuf(9) interface to do the string formatting, > since it is fairly superior to my current string formatting method (see > scsi_sense_string() in sys/cam/scsi/scsi_all.c). > > The problem is that the sbuf(9) code is kernel-only at the moment. So this > brings up two basic questions: > > 1. Should we put sbufs in userland? I think so. Wide-adoption of the sbuf code and perhaps some extra string manipulation routines to bring out the functionality would be a plus. *AND*, this being my favourite bit, it means we can possibly start abusing sbufs as a syscall interface. Perhaps. Very very perhaps. > So, what color should this bike shed be? Paint it white, give people coloured glasses. Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 10:58:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (node16292.a2000.nl [24.132.98.146]) by hub.freebsd.org (Postfix) with ESMTP id 92F5D37B719; Tue, 27 Feb 2001 10:58:31 -0800 (PST) (envelope-from adrian@roaming.cacheboy.net) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f1RDk7s35929; Tue, 27 Feb 2001 14:46:07 +0100 (CET) (envelope-from adrian) Date: Tue, 27 Feb 2001 14:46:00 +0100 From: Adrian Chadd To: Jonathan Lemon Cc: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/sys mount.h uio.h src/sys/kern kern_subr.c vfs_syscalls.c Message-ID: <20010227144600.A35908@roaming.cacheboy.net> References: <200102161431.f1GEVoa21701@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102161431.f1GEVoa21701@freefall.freebsd.org>; from jlemon@FreeBSD.org on Fri, Feb 16, 2001 at 06:31:50AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001, Jonathan Lemon wrote: > jlemon 2001/02/16 06:31:50 PST > > Modified files: > sys/sys mount.h uio.h > sys/kern kern_subr.c vfs_syscalls.c > Log: > Introduce copyinfrom and copyinstrfrom, which can copy data from either > user or kernel space. This will allow layering of os-compat (e.g.: linux) > system calls. Apply the changes to mount. > > Revision Changes Path > 1.100 +3 -1 src/sys/sys/mount.h > 1.12 +4 -1 src/sys/sys/uio.h > 1.42 +37 -1 src/sys/kern/kern_subr.c > 1.177 +14 -5 src/sys/kern/vfs_syscalls.c .. being a little behind on the CVS mail, I actually had a more far-reaching change scheduled to the mount interface. Specifically, I was going to take VFS_MOUNT() and change path to be a kernel string rather than a user string. I was then going to modify all the filesystem code to DTRT. Then, I was going to wrap mount() into domount(), much like unmount() and doumount() function. The next part of the change involves doing the same thing to flags and data, which is going to be a little tricker and require a hell of a lot more work. Does anyone have any problems with this? Adrian, always late.. :) -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 11:34: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D932737B71C; Tue, 27 Feb 2001 11:33:51 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA10274; Tue, 27 Feb 2001 11:33:52 -0800 Date: Tue, 27 Feb 2001 11:33:51 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: arch@FreeBSD.org Cc: John Baldwin , cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h In-Reply-To: <200102270041.f1R0fbd18655@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 26 Feb 2001, Warner Losh wrote: > OK. I've let the documentation on this languish a month. You can > find very rough drafts of the resource_query_stirng and > resource_int_value man pages at > http://people.freebsd.org/~imp/hint-doc.tar.gz > Please reply to arch@ with comments on the docs. The interface could > likely stand some work as well, but I'm less interested in > bikeshedding that than I am in polishing these docs. The man page is a good start- but it needs just a tad bit of cleanup. More! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 11:41: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 54A5C37B719 for ; Tue, 27 Feb 2001 11:41:07 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id MAA15754; Tue, 27 Feb 2001 12:37:57 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAvXaOME; Tue Feb 27 12:37:47 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA28715; Tue, 27 Feb 2001 12:40:49 -0700 (MST) From: Terry Lambert Message-Id: <200102271940.MAA28715@usr05.primenet.com> Subject: Re: sbufs in userland To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 27 Feb 2001 19:40:49 +0000 (GMT) Cc: bde@zeta.org.au (Bruce Evans), ken@kdm.org (Kenneth D. Merry), arch@FreeBSD.ORG In-Reply-To: <26415.983257037@critter> from "Poul-Henning Kamp" at Feb 27, 2001 07:57:17 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ ... kernel versus user space API's ... ] > strlen() comes to mind as an API where it can't use it. In the > kernel strlen should return an error code if it tries to access > non-accessible memory, rather than core-dumping as it does in > userland. That's just crazy talk. That's like saying invalid pointer dereferences shouldn't be fatal, just because someone was really, really, very, mucho grande, intolerably sloppy about calling a function on a pointer, without knowing what it pointed to before making the call. I would much rather have a panic, and have the kernel tell me "Hey moron! Fix your code, right here!". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 11:43:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 7D66B37B71A; Tue, 27 Feb 2001 11:43:12 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id MAA16408; Tue, 27 Feb 2001 12:40:02 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAA.FaWXF; Tue Feb 27 12:39:49 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id MAA29005; Tue, 27 Feb 2001 12:42:46 -0700 (MST) From: Terry Lambert Message-Id: <200102271942.MAA29005@usr05.primenet.com> Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) To: kris@FreeBSD.ORG (Kris Kennaway) Date: Tue, 27 Feb 2001 19:42:46 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), n@nectar.com (Jacques A. Vidrine), arch@FreeBSD.ORG In-Reply-To: <20010226231515.B94159@citusc17.usc.edu> from "Kris Kennaway" at Feb 26, 2001 11:15:15 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Okay, now I'm annoyed. I just looked at glibc, and it already does > what is being discussed here, namely aliasing rand() to random() > (which appears to be the same algorithm we use for random()). There > goes your "pseudo-standardization" argument out the window, which > means you obviously hadn't checked your facts and were just describing > the state of your internal fantasy universe. Thanks for wasting > everyone's time with this silly thread. Check your history. Linux made the same mistake you are proposing to make. The advent of glibc is relatively recent. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 11:53:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 3A7EA37B71A; Tue, 27 Feb 2001 11:53:25 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id LAA18051; Tue, 27 Feb 2001 11:53:08 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda18049; Tue Feb 27 11:53:02 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f1RJqvF29879; Tue, 27 Feb 2001 11:52:57 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdF29873; Tue Feb 27 11:52:29 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.2/8.9.1) id f1RJqSs35224; Tue, 27 Feb 2001 11:52:28 -0800 (PST) Message-Id: <200102271952.f1RJqSs35224@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdA34593; Tue Feb 27 11:51:29 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Garance A Drosihn Cc: Kris Kennaway , Terry Lambert , "Jacques A. Vidrine" , arch@FreeBSD.ORG Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) In-reply-to: Your message of "Tue, 27 Feb 2001 13:30:46 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Feb 2001 11:51:29 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: > At 11:15 PM -0800 2/26/01, Kris Kennaway wrote: > >There goes your "pseudo-standardization" argument out the window, > >which means you obviously hadn't checked your facts and were just > >describing the state of your internal fantasy universe. Thanks > >for wasting everyone's time with this silly thread. > > I am aware of other people who live in the same fantasy universe, > so I think this thread is spiraling downwards. A few of those > people even ran tests to see if rand() produced the same results > across the platforms they cared about, and once that was proven, > they just assumed that would remain true (most of them are doing > comparisons across time, though, not across platforms. Still, > "across time" tends to become "across platforms", as hardware > changes around here). It *is* interesting to find out that glibc > does use the same algorithm as random(). Glibc hasn't been > used much among the people I'm thinking of, but it's certainly > getting used more as linux makes inroads on campus. Now I am > also wondering if rand() still produces similar results across > the other unix platforms we have on campus. Just as with virtually everything else in this industry we have multiple standards (don't even get me started with the telecommunications and building industries). Some shops or developers may wish to integrate across platforms while others focus on FreeBSD/Linux. Could we not implement a solution similar to malloc()'s /etc/malloc.conf and MALLOC_OPTIONS? The default could be set to rand() calling random(), while setting the appropriate option would revert to the "old" behaviour. Or, #ifdef. Either way we satisfy both camps. Ideally, rand() is insecure and should be removed or should call random(), protecting clueless developers from themselves and more importantly protecting clueless end users from clueless developers. We three choices: 1. Status quo. 2. A more secure rand(). 3. A hybrid. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 12: 5:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id B70CB37B719 for ; Tue, 27 Feb 2001 12:05:23 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152C67AF; Tue, 27 Feb 2001 15:05:32 -0500 Reply-To: Randell Jesup To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: rand.c patch for review (was: Re: cvs commit: ports/astro/xglobe/files patch-random) References: <200102270317.UAA09690@usr05.primenet.com> From: Randell Jesup Date: 27 Feb 2001 15:06:44 -0500 In-Reply-To: Garance A Drosihn's message of "Tue, 27 Feb 2001 13:39:38 -0500" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn writes: >Still, for this specific point, any game-vendor who NEEDS a >repeatable random-number sequence SHOULD implement their own >random number generator. It would be pretty trivial to do, >after all, and if I'm selling a game I don't think I would >ask a variety of operating systems to produce random numbers, >and then trust that all of those operating systems will give >me the exact same list... You mean brand new games like, say, Nethack? (I could be wrong, but I do seem to remember it relying on that for saved games - and I think it saves and restores the seed.) -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 12:27:37 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 9E17D37B719 for ; Tue, 27 Feb 2001 12:27:34 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA78242; Tue, 27 Feb 2001 15:26:28 -0500 (EST) (envelope-from wollman) Date: Tue, 27 Feb 2001 15:26:28 -0500 (EST) From: Garrett Wollman Message-Id: <200102272026.PAA78242@khavrinen.lcs.mit.edu> To: Cy.Schubert@uumail.gov.bc.ca Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) In-Reply-To: <200102271952.f1RJqSs35224@cwsys.cwsent.com> References: Organization: MIT Laboratory for Computer Science Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200102271952.f1RJqSs35224@cwsys.cwsent.com> you write: >2. A more secure rand(). It is not rand's place to be secure. rand's only goal in life is to have reasonable statistical properties. Austin Group draft 5 makes the following requirement (inherited from X/Open): The rand( ) function shall compute a sequence of pseudo-random integers in the range 0 to {RAND_MAX} with a period of at least 232. There are other random-number generators which are intended to be secure. Applications which use random numbers in a security-sensitive context (e.g., key-generation or nonces) should not use this interface; there should probably be more explicit documentation to this effect. (Believe it or not, many real-world applications require only statistical randomness.) -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 Feb 27 13:43:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id AE9EA37B71B for ; Tue, 27 Feb 2001 13:43:24 -0800 (PST) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 30451DCA; Tue, 27 Feb 2001 13:43:22 -0800 (PST) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id NAA16668; Tue, 27 Feb 2001 13:43:19 -0800 (PST) Message-ID: <3A9C1F77.4A10CF30@cup.hp.com> Date: Tue, 27 Feb 2001 13:43:19 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: FreeBSD sources from 20000' References: <200102271136.f1RBa4R12865@gratis.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > > Some modules need a little help - kernel modules require kernel > source to build, most modules require a minimum toolchain, and some > need specialised tools (like the kernel needs config(8) and doc/ > needs tons of ports). > 3) "KLD" kernel module. > (eg: random.ko) > 3a) "kernel" all of kernel and includes kernel modules. It may help to view kernel modules as libraries or plug-ins, even to the extend of staticly "linking" a kernel module into the kernel. This may help to untangle the cross dependencies of kld and kernel. Just a thought... -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 13:52: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 1B95137B71B; Tue, 27 Feb 2001 13:52:03 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id QAA12138; Tue, 27 Feb 2001 16:50:42 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200102271952.f1RJqSs35224@cwsys.cwsent.com> References: <200102271952.f1RJqSs35224@cwsys.cwsent.com> Date: Tue, 27 Feb 2001 16:50:40 -0500 To: Cy Schubert - ITSD Open Systems Group From: Garance A Drosihn Subject: Re: rand(3) (was Re: cvs commit: ports/astro/xglobe/files patch-random) Cc: Kris Kennaway , Terry Lambert , "Jacques A. Vidrine" , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:51 AM -0800 2/27/01, Cy Schubert wrote: ><... putting my manager's hat on> >... Could we not implement a solution similar to malloc()'s >/etc/malloc.conf and MALLOC_OPTIONS? The default could be set to >rand() calling random(), while setting the appropriate option would >revert to the "old" behaviour. Or, #ifdef. Either way we satisfy >both camps. I suspect that is unworkable. If there is some security issue where it is important that rand = random, then you won't want that security diluted if someone setting an environment variable... (I might set the environment variable because of my simulation written in fortran, and have it then effect some other program which I am also running, where it is a security issue). Something #ifdef-ish might be workable to everyone's satisfaction. > >Ideally, rand() is insecure and should be removed or should call >random(), protecting clueless developers from themselves and more >importantly protecting clueless end users from clueless developers. > >We three choices: > >1. Status quo. >2. A more secure rand(). >3. A hybrid. Well, I've been trying to sit here and think of a good hybrid solution, but for the last hour I've been interrupted every 2 minutes with something or another. Perhaps some warning at compile time, except I can't quite think of how to do that. I can imagine something silly at link time, such that references to 'rand' generate an warning like mktemp. People who want statistically-random numbers would avoid that by changing the source so they get random instead of rand. People who want the historical rand behavior would '#define randold rand' (where randold is a duplicate of rand), thus avoiding the direct reference to rand at load time. Anything where calling 'rand' is a security risk is hopefully something that is compiled often enough that this would quickly address that issue. I can't stop today's interruptions long enough to tell if I really like the above idea, but at first blush it sounds plausible. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 13:52:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 68D6837B734; Tue, 27 Feb 2001 13:52:07 -0800 (PST) (envelope-from msinz@wgate.com) Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152C67YH; Tue, 27 Feb 2001 16:52:16 -0500 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.1/8.11.1) with ESMTP id f1RLpfk82881; Tue, 27 Feb 2001 16:51:52 -0500 (EST) (envelope-from msinz@wgate.com) Message-ID: <3A9C216D.11F2ABA7@wgate.com> Date: Tue, 27 Feb 2001 16:51:41 -0500 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ian Dowse Cc: Robert Watson , Randell Jesup , arch@FreeBSD.ORG, Alfred Perlstein , Bruce Bauman Subject: Re: ELF and diskless boot References: <200102251552.aa44515@salmon.maths.tcd.ie> Content-Type: multipart/mixed; boundary="------------A42168EE212B4B225B38F0C6" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------A42168EE212B4B225B38F0C6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian Dowse wrote: > > In message , Robe > rt Watson writes: > > > >I won't comment on the symbol stripping issue since I don't know > >much/anything about that, but I can comment that we're in the process of > >moving to using sysctl() for top and other kernel-grubbing utilities, when > >used on a live system. top has already been changed to do this on > >-CURRENT, and patches to systat/dmesg/vmstat/... are in the wings. While > > The reason that these utilities fail when not using loader(8) is > that they depend on being able to look up static variables within > the kernel using kldsym(). I think symbols declared as static end > up with debugging information, so are only made available through > some loader magic. This I have figured out - but the questions I have are mainly "Why?" That is, how did FreeBSD get to a point where non-exported interfaces (symbols) are depended on for base functionality. (I can understand kernel debugging, but swapon and top?) > It would be possible to go around the tree, removing the `static' > from all symbols that are used by libkvm utilities - I've tried > this, and it certainly fixes the problem with etherbooted kernels. > It might also be possible to hack libkvm to try the old-style symbol > lookup mechanism if kldsym fails to find a symbol. What I have done now is to make a patch to Etherboot (which I have submitted and have also attached here) that will also load the symbols for the kernel. It was a bit more work than I thought it would be due to some undocumented "value x goes here but we don't use it" type of things. (And bit y needs to be set but you only find out by looking at the code) :-) Anyway, the logic in the loader patch to Etherboot could also solve the problem with the FreeBSD gzip'ed kernel images (which currently don't work for the same reason) > However, the move towards using sysctl() instead of libkvm will > solve this problem completely. Thanks to Thomas Moestl and others > who have done the work to make this happen! I agree that moving to defined interfaces is the way to go. I would not have guessed that this problem had existed had I not run into it. BTW - I had a rather nasty hack that I did where the kernel kldsym used sysctl to find the kernel symbols if it did not find them using its current methods. However, it was nasty since it really is not a symbol entry and thus only worked for the libkvm users. (And, in fact, could cause problems with other users if they happened to go for one of those symbols) This is why I figured that we would just redo the BIOS for our systems. -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. --------------A42168EE212B4B225B38F0C6 Content-Type: text/plain; charset=us-ascii; name="osloader.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="osloader.c.patch" *** osloader.c.original Tue Feb 27 14:41:31 2001 --- osloader.c Tue Feb 27 14:49:12 2001 *************** *** 46,51 **** --- 46,57 ---- unsigned long bi_extmem; unsigned long bi_symtab; unsigned long bi_esymtab; + #ifdef IMAGE_FREEBSD + /* Note that these are in the FreeBSD headers but were not here... */ + unsigned long bi_kernend; /* end of kernel space */ + unsigned long bi_envp; /* environment */ + unsigned long bi_modulep; /* preloaded modules */ + #endif }; /* a.out */ *************** *** 133,138 **** --- 139,201 ---- Elf32_Size p_align; /* Alignment in memory and file. */ } Elf32_Phdr; + #ifdef IMAGE_FREEBSD + /* + * FreeBSD has this rather strange "feature" of its design. + * At some point in its evolution, FreeBSD started to rely + * externally on private/static/debug internal symbol information. + * That is, some of the interfaces that software uses to access + * and work with the FreeBSD kernel are made available not + * via the shared library symbol information (the .DYNAMIC section) + * but rather the debug symbols. This means that any symbol, not + * just publicly defined symbols can be (and are) used by system + * tools to make the system work. (such as top, swapinfo, swapon, + * etc) + * + * Even worse, however, is the fact that standard ELF loaders do + * not know how to load the symbols since they are not within + * an ELF PT_LOAD section. The kernel needs these symbols to + * operate so the following changes/additions to the boot + * loading of EtherBoot have been made to get the kernel to load. + * All of the changes are within IMAGE_FREEBSD such that the + * extra/changed code only compiles when FREEBSD support is + * enabled. + */ + + /* + * Section header for FreeBSD (debug symbol kludge!) support + */ + typedef struct { + Elf32_Word sh_name; /* Section name (index into the + section header string table). */ + Elf32_Word sh_type; /* Section type. */ + Elf32_Word sh_flags; /* Section flags. */ + Elf32_Addr sh_addr; /* Address in memory image. */ + Elf32_Off sh_offset; /* Offset in file. */ + Elf32_Size sh_size; /* Size in bytes. */ + Elf32_Word sh_link; /* Index of a related section. */ + Elf32_Word sh_info; /* Depends on section type. */ + Elf32_Size sh_addralign; /* Alignment in bytes. */ + Elf32_Size sh_entsize; /* Size of each entry in section. */ + } Elf32_Shdr; + + /* sh_type */ + #define SHT_SYMTAB 2 /* symbol table section */ + #define SHT_STRTAB 3 /* string table section */ + + /* + * Module information subtypes (for the metadata that we need to build) + */ + #define MODINFO_END 0x0000 /* End of list */ + #define MODINFO_NAME 0x0001 /* Name of module (string) */ + #define MODINFO_TYPE 0x0002 /* Type of module (string) */ + #define MODINFO_METADATA 0x8000 /* Module-specfic */ + + #define MODINFOMD_SSYM 0x0003 /* start of symbols */ + #define MODINFOMD_ESYM 0x0004 /* end of symbols */ + + #endif /* IMAGE_FREEBSD */ + /* The structure of a Multiboot 0.6 parameter block. */ struct multiboot_info { unsigned int flags; *************** *** 203,208 **** --- 266,280 ---- #ifdef ELF_IMAGE static Elf32_Phdr *phdr; + + #ifdef IMAGE_FREEBSD + static Elf32_Shdr *shdr; /* To support the FreeBSD kludge! */ + static Address symtab_load; + static Address symstr_load; + static int symtabindex; + static int symstrindex; + #endif + #endif #ifdef IMAGE_FREEBSD *************** *** 406,411 **** --- 478,544 ---- info.bsdinfo.bi_kernelname = kernel; info.bsdinfo.bi_nfs_diskless = NULL; info.bsdinfo.bi_size = sizeof(info.bsdinfo); + + /* Check if we have symbols loaded, and if so, + * made the meta_data needed to pass those to + * the kernel. */ + if ((symtab_load !=0) && (symstr_load != 0)) + { + unsigned long *t; + + info.bsdinfo.bi_symtab = symtab_load; + + /* End of symbols (long aligned...) */ + /* Assumes size of long is a power of 2... */ + info.bsdinfo.bi_esymtab = (symstr_load + + sizeof(long) + + *((long *)symstr_load) + + sizeof(long) - 1) & ~(sizeof(long) - 1); + + /* Where we will build the meta data... */ + t = (unsigned long *)info.bsdinfo.bi_esymtab; + + #ifdef DEBUG_ELF + printf("Metadata at %X\n",t); + #endif + + /* Set up the pointer to the memory... */ + info.bsdinfo.bi_modulep = (unsigned long)t; + + /* The metadata structure is an array of 32-bit + * words where we store some information about the + * system. This is critical, as FreeBSD now looks + * only for the metadata for the extended symbol + * information rather than in the bootinfo. + */ + /* First, do the kernel name and the kernel type */ + /* Note that this assumed x86 byte order... */ + + /* 'kernel\0\0' */ + *t++=MODINFO_NAME; *t++= 7; *t++=0x6E72656B; *t++=0x00006C65; + + /* 'elf kernel\0\0' */ + *t++=MODINFO_TYPE; *t++=11; *t++=0x20666C65; *t++=0x6E72656B; *t++ = 0x00006C65; + + /* Now the symbol start/end - note that they are + * here in local/physical address - the Kernel + * boot process will relocate the addresses. */ + *t++=MODINFOMD_SSYM | MODINFO_METADATA; *t++=sizeof(*t); *t++=info.bsdinfo.bi_symtab; + *t++=MODINFOMD_ESYM | MODINFO_METADATA; *t++=sizeof(*t); *t++=info.bsdinfo.bi_esymtab; + + *t++=MODINFO_END; *t++=0; /* end of metadata */ + + /* Since we have symbols we need to make + * sure that the kernel knows its own end + * of memory... It is not _end but after + * the symbols and the metadata... */ + info.bsdinfo.bi_kernend = (unsigned long)t; + + /* Signal locore.s that we have a valid bootinfo + * structure that was completely filled in. */ + freebsd_howto |= 0x80000000; + } + (*entry)(freebsd_howto, NODEV, 0, 0, 0, &info.bsdinfo, 0, 0, 0); longjmp(jmp_bootmenu, 2); } *************** *** 521,526 **** --- 654,670 ---- } memcpy((void *)curaddr, data+offset, toread); offset += toread; + #ifdef IMAGE_FREEBSD + /* Count the bytes read even for the last block + * as we will need to know where the last block + * ends in order to load the symbols correctly. + * (plus it could be useful elsewhere...) + * Note that we need to count the actual size, + * not just the end of the disk image size. + */ + curaddr += toread; + if (segment) curaddr += (phdr[segment].p_memsz - phdr[segment].p_filesz); + #endif toread = 0; } } *************** *** 547,552 **** --- 691,858 ---- segment = i; } if (phdr[segment].p_type != PT_LOAD) { + #ifdef IMAGE_FREEBSD + /* No more segments to be loaded - time to start the + * nasty state machine to support the loading of + * FreeBSD debug symbols due to the fact that FreeBSD + * uses/exports the kernel's debug symbols in order + * to make much of the system work! Amazing (arg!) + * + * We depend on the fact that for the FreeBSD kernel, + * there is only one section of debug symbols and that + * the section is after all of the loaded sections in + * the file. This assumes a lot but is somewhat required + * to make this code not be too annoying. (Where do you + * load symbols when the code has not loaded yet?) + * Since this function is actually just a callback from + * the network data transfer code, we need to be able to + * work with the data as it comes in. There is no chance + * for doing a seek other than forwards. + * + * The process we use is to first load the section + * headers. Once they are loaded (shdr != 0) we then + * look for where the symbol table and symbol table + * strings are and setup some state that we found + * them and fall into processing the first one (which + * is the symbol table) and after that has been loaded, + * we try the symbol strings. Note that the order is + * actually required as the memory image depends on + * the symbol strings being loaded starting at the + * end of the symbol table. The kernel assumes this + * layout of the image. + * + * At any point, if we get to the end of the load file + * or the section requested is earlier in the file than + * the current file pointer, we just end up falling + * out of this and booting the kernel without this + * information. + */ + + /* Make sure that the next address is long aligned... */ + /* Assumes size of long is a power of 2... */ + curaddr = (curaddr + sizeof(long) - 1) & ~(sizeof(long) - 1); + + /* If we have not yet gotten the shdr loaded, try that */ + if (shdr == 0) + { + toread = info.elf32.e_shnum * info.elf32.e_shentsize; + skip = info.elf32.e_shoff - (loc + offset); + if (toread) + { + #ifdef DEBUG_ELF + printf("shdr *, size %X, curaddr %X\n", toread, curaddr); + #endif + + /* Start reading at the curaddr and make that the shdr */ + shdr = (Elf32_Shdr *)curaddr; + + /* Start to read... */ + continue; + } + } + else + { + /* We have the shdr loaded, check if we have found + * the indexs where the symbols are supposed to be */ + if ((symtabindex == -1) && (symstrindex == -1)) + { + /* Make sure that the address is page aligned... */ + /* Symbols need to start in their own page(s)... */ + curaddr = (curaddr + 4095) & ~4095; + + /* Need to make new indexes... */ + for (i=0; i < info.elf32.e_shnum; i++) + { + if (shdr[i].sh_type == SHT_SYMTAB) + { + int j; + for (j=0; j < info.elf32.e_phnum; j++) + { + /* Check only for loaded sections */ + if ((phdr[i].p_type | 0x80) == (PT_LOAD | 0x80)) + { + /* Only the extra symbols */ + if ((shdr[i].sh_offset >= phdr[j].p_offset) && + ((shdr[i].sh_offset + shdr[i].sh_size) <= + (phdr[j].p_offset + phdr[j].p_filesz))) + { + shdr[i].sh_offset=0; + shdr[i].sh_size=0; + break; + } + } + } + if ((shdr[i].sh_offset != 0) && (shdr[i].sh_size != 0)) + { + symtabindex = i; + symstrindex = shdr[i].sh_link; + } + } + } + } + + /* Check if we have a symbol table index and have not loaded it */ + if ((symtab_load == 0) && (symtabindex >= 0)) + { + /* No symbol table yet? Load it first... */ + + /* This happens to work out in a strange way. + * If we are past the point in the file already, + * we will skip a *large* number of bytes which + * ends up bringing us to the end of the file and + * an old (default) boot. Less code and lets + * the state machine work in a cleaner way but this + * is a nasty side-effect trick... */ + skip = shdr[symtabindex].sh_offset - (loc + offset); + + /* And we need to read this many bytes... */ + toread = shdr[symtabindex].sh_size; + + if (toread) + { + #ifdef DEBUG_ELF + printf("db sym, size %X, curaddr %X\n", toread, curaddr); + #endif + /* Save where we are loading this... */ + symtab_load = curaddr; + + *((long *)curaddr) = toread; + curaddr += sizeof(long); + + /* Start to read... */ + continue; + } + } + else if ((symstr_load == 0) && (symstrindex >= 0)) + { + /* We have already loaded the symbol table, so + * now on to the symbol strings... */ + + + /* Same nasty trick as above... */ + skip = shdr[symstrindex].sh_offset - (loc + offset); + + /* And we need to read this many bytes... */ + toread = shdr[symstrindex].sh_size; + + if (toread) + { + #ifdef DEBUG_ELF + printf("db str, size %X, curaddr %X\n", toread, curaddr); + #endif + /* Save where we are loading this... */ + symstr_load = curaddr; + + *((long *)curaddr) = toread; + curaddr += sizeof(long); + + /* Start to read... */ + continue; + } + } + } + #endif /* IMAGE_FREEBSD */ + /* No more segments to be loaded, so just start the * kernel. This saves a lot of network bandwidth if * debug info is in the kernel but not loaded. */ *************** *** 659,664 **** --- 965,982 ---- loc = 0; skip = 0; toread = 0; + #ifdef IMAGE_FREEBSD + /* Make sure we have a null to start with... */ + shdr = 0; + + /* Clear the symbol index values... */ + symtabindex = -1; + symstrindex = -1; + + /* ...and the load addresses of the symbols */ + symtab_load = 0; + symstr_load = 0; + #endif } else #endif #ifdef TAGGED_IMAGE --------------A42168EE212B4B225B38F0C6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 13:59:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 70A3F37B71B for ; Tue, 27 Feb 2001 13:59:27 -0800 (PST) (envelope-from msinz@wgate.com) Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152C675J; Tue, 27 Feb 2001 16:59:37 -0500 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.1/8.11.1) with ESMTP id f1RLwrk83077; Tue, 27 Feb 2001 16:59:16 -0500 (EST) (envelope-from msinz@wgate.com) Message-ID: <3A9C231D.EA12570A@wgate.com> Date: Tue, 27 Feb 2001 16:58:53 -0500 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Duane H. Hesser" Cc: Randell Jesup , "(Bruce Bauman)" , Alfred Perlstein , arch@FreeBSD.ORG, bde@zeta.org.au Subject: Re: ELF and diskless boot References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Duane H. Hesser" wrote: > > On 23-Feb-01 Randell Jesup wrote: > > FYI, is there a reason that we've set up our kernel interface to top, etc > > to fail unless the kernel (in this case 4.x) is loaded with _debugging_ > > symbols? I.e. if you strip a kernel, top (and a bunch of other stuff) > > doesn't work because they can't find certain kernel structures. To make > > this worse, they also fail if you etherboot (because debug symbols aren't > > loaded). > > > > Is there a reason for this behavior? Perhaps some benefit we don't see? > > Any chance of getting this fixed? I believe this appears sometime since > > 3.x, i.e. after we'd already moved to ELF, but I'm not sure. > > > > (Note: I'm not the primary person investigating this; Mike is. I think > > he's looking at modding etherboot to work around the problem.) > > > > -- > > Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) > > rjesup@wgate.com > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-arch" in the body of the message > > > > Is the following pertinent? > (from the archives, almost a year ago...included without shifts) Not really - it was almost right except that Etherboot does not load the symbols (nor fill in that part of the bootinfo structure). The modified Etherboot now fills in the bootinfo structure *and* make the metadata array for the kernel so that no kernel patch is needed. It basically does a diskless boot that looks almost like the normal loader. (Not quite since the location of things is not exactly the same and there is no environment or preloaded modules included.) [etherboot patch has been submitted to the Etherboot project site on sourceforge and I included in another message here...] [...] > Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) > by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) with ESMTP id EAA76938 > for ; Tue, 14 Mar 2000 04:52:39 +0200 (EET) > (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.8.7/8.8.7) with ESMTP id NAA05065; > Tue, 14 Mar 2000 13:58:35 +1100 > Date: Tue, 14 Mar 2000 13:51:49 +1100 (EST) > From: Bruce Evans > X-Sender: bde@alphplex.bde.org > To: Ruslan Ermilov > cc: Jordan Hubbard , committers@FreeBSD.org > Subject: Re: [4.0-ERRATA candidate?] loader(8)/kvm(3) interoperability issue > In-Reply-To: <20000313194345.A52651@relay.ucb.crimea.ua> > Message-ID: > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Mon, 13 Mar 2000, Ruslan Ermilov wrote: > > > One thing that should IMHO be pointed out in the upcoming 4.0-RELEASE's > > ERRATA (or some more appropriate place), is the fact that the loader(8) > > is now a prerequisite for certain programs using kvm(3) interface. > > Obvious examples are top(1) and swapinfo(8). > > > > If you boot your kernel without loader(8), directly through bootblocks, > > these programs will not work. > > I don't user loader(8), and finally got around to fixing this. The > problem is that the kernel linker wants module data for the kernel. > It defaults to using incomplete data if none is present. The following > supplies slightly less incomplete data: [...] Note that the "using incomplete data" is not really correct. It uses complete data -- the dynamic section, aka the publicly defined symbols. The problem is that FreeBSD requires the debug symbols. -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 14:39: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C7BA737B719 for ; Tue, 27 Feb 2001 14:38:58 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA11208 for ; Tue, 27 Feb 2001 14:38:59 -0800 Date: Tue, 27 Feb 2001 14:38:58 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: arch@FreeBSD.org Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h In-Reply-To: <200102270041.f1R0fbd18655@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Other than this- I'd check 'em in. --- /usr/share/man/man9/resource_query_string.9 Tue Feb 27 14:38:06 2001 +++ ./resource_query_string.9 Tue Feb 27 14:31:32 2001 @@ -45,8 +45,7 @@ .Pp Fetches a string value from the hints mechanism. .Pp -.Fn resouce_query_string -is called to see enumerate all possible +.Fn resouce_query_string is called to see enumerate all possible strings. It returns the next one after num that is available, or -1 if nothing further is available. resource_query_name is passed the return of resource_query_string and returns its value. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 14:44:39 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 ED5DC37B71E for ; Tue, 27 Feb 2001 14:44:24 -0800 (PST) (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 f1RMekl87454; Tue, 27 Feb 2001 14:40:46 -0800 (PST) (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: Date: Tue, 27 Feb 2001 14:44:04 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Feb-01 Matthew Jacob wrote: > > Other than this- I'd check 'em in. > > --- /usr/share/man/man9/resource_query_string.9 Tue Feb 27 14:38:06 2001 > +++ ./resource_query_string.9 Tue Feb 27 14:31:32 2001 > @@ -45,8 +45,7 @@ > .Pp > Fetches a string value from the hints mechanism. > .Pp > -.Fn resouce_query_string > -is called to see enumerate all possible > +.Fn resouce_query_string is called to see enumerate all possible > strings. It returns the next one after num that is available, or -1 > if nothing further is available. resource_query_name is passed the > return of resource_query_string and returns its value. Eek, the current style in the tree would render this something more like: .Pp .Fn resource_query_string is called to enumerate all possible strings. It returns the next one after .Fa num that is available, or -1 if nothing further is available. .Fn resource_query_name is passed the returned value of .Fn resource_query_string and returns its value. I.e., each new sentence starts on a new line (to help with translation) and you mark up stuff. I'll try and look at this today or tomorrow for mdoc stuff. Though you probably want to send them off to ru, mpp, sheldonh, and/or asmodai as well. -- 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 Feb 27 14:45: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A285B37B720; Tue, 27 Feb 2001 14:45:03 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA11248; Tue, 27 Feb 2001 14:45:04 -0800 Date: Tue, 27 Feb 2001 14:45:02 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sure. But let's get them in the tree. Now. > > On 27-Feb-01 Matthew Jacob wrote: > > > > Other than this- I'd check 'em in. > > > > --- /usr/share/man/man9/resource_query_string.9 Tue Feb 27 14:38:06 2001 > > +++ ./resource_query_string.9 Tue Feb 27 14:31:32 2001 > > @@ -45,8 +45,7 @@ > > .Pp > > Fetches a string value from the hints mechanism. > > .Pp > > -.Fn resouce_query_string > > -is called to see enumerate all possible > > +.Fn resouce_query_string is called to see enumerate all possible > > strings. It returns the next one after num that is available, or -1 > > if nothing further is available. resource_query_name is passed the > > return of resource_query_string and returns its value. > > Eek, the current style in the tree would render this something more like: > > .Pp > .Fn resource_query_string > is called to enumerate all possible strings. > It returns the next one after > .Fa num > that is available, > or -1 if nothing further is available. > .Fn resource_query_name > is passed the returned value of > .Fn resource_query_string > and returns its value. > > I.e., each new sentence starts on a new line (to help with translation) and > you mark up stuff. I'll try and look at this today or tomorrow for mdoc > stuff. Though you probably want to send them off to ru, mpp, sheldonh, and/or > asmodai as well. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 14:50:31 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 6755637B71A for ; Tue, 27 Feb 2001 14:50:28 -0800 (PST) (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 f1RMkrl87719; Tue, 27 Feb 2001 14:46:53 -0800 (PST) (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: Date: Tue, 27 Feb 2001 14:50:10 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Feb-01 Matthew Jacob wrote: > > Sure. But let's get them in the tree. Now. *shrug* I usually let doc people review my stuff first for stuff like this. I have four manpages sitting in my public_html/patches/ dir on freefall right now for ktr, witness, and ithread that I'm waiting for review on... >> On 27-Feb-01 Matthew Jacob wrote: >> > >> > Other than this- I'd check 'em in. >> > >> > --- /usr/share/man/man9/resource_query_string.9 Tue Feb 27 14:38:06 >> > 2001 >> > +++ ./resource_query_string.9 Tue Feb 27 14:31:32 2001 >> > @@ -45,8 +45,7 @@ >> > .Pp >> > Fetches a string value from the hints mechanism. >> > .Pp >> > -.Fn resouce_query_string >> > -is called to see enumerate all possible >> > +.Fn resouce_query_string is called to see enumerate all possible >> > strings. It returns the next one after num that is available, or -1 >> > if nothing further is available. resource_query_name is passed the >> > return of resource_query_string and returns its value. >> >> Eek, the current style in the tree would render this something more like: >> >> .Pp >> .Fn resource_query_string >> is called to enumerate all possible strings. >> It returns the next one after >> .Fa num >> that is available, >> or -1 if nothing further is available. >> .Fn resource_query_name >> is passed the returned value of >> .Fn resource_query_string >> and returns its value. >> >> I.e., each new sentence starts on a new line (to help with translation) and >> you mark up stuff. I'll try and look at this today or tomorrow for mdoc >> stuff. Though you probably want to send them off to ru, mpp, sheldonh, >> and/or >> asmodai as well. >> >> > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- 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 Feb 27 16:48:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wally.eecs.harvard.edu (wally.eecs.harvard.edu [140.247.60.30]) by hub.freebsd.org (Postfix) with ESMTP id 3CBC537B71A for ; Tue, 27 Feb 2001 16:48:11 -0800 (PST) (envelope-from magoutis@eecs.harvard.edu) Received: (from magoutis@localhost) by wally.eecs.harvard.edu (8.10.0/8.10.0) id f1S0m9n09106; Tue, 27 Feb 2001 19:48:09 -0500 (EST) Date: Tue, 27 Feb 2001 19:48:09 -0500 (EST) Message-Id: <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> From: Kostas Magoutis To: freebsd-arch@freebsd.org Subject: Logical device instances Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am writing a device driver for a user-level networking card. User level code interacts with it via open, close, mmap, and ioctl. A separate logical instance of the device needs to be created each time a process opens the device (as in when a file is created when a vnode is opened). The device driver needs to have a way to find out on what logical instance of the device a system call is performed. It seems to me that at present (with either specfs or devfs), the device driver has no way to find out on what opened instance of the device an operation is performed. Am I missing something or the present device driver interfaces just don't support such functionality? Thanks, Kostas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 16:51: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 BB50137B71A for ; Tue, 27 Feb 2001 16:51:13 -0800 (PST) (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.2/8.11.2) with ESMTP id f1S0gq454788; Wed, 28 Feb 2001 00:44:07 GMT (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.2/8.11.2) with ESMTP id f1RI1oF00966; Tue, 27 Feb 2001 18:01:50 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102271801.f1RI1oF00966@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Mark Murray Cc: arch@FreeBSD.org, brian@Awfulhak.org Subject: Re: FreeBSD sources from 20000' In-Reply-To: Message from Mark Murray of "Tue, 27 Feb 2001 13:36:49 +0200." <200102271136.f1RBa4R12865@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Feb 2001 18:01:50 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > REMINDER REMINDER - The whole point of this exercise is NOT to > remove ANYTHING from FreeBSD. Effectively, FreeBSD will become a > grow-only system with the configuration and installation policies > placed in the hands of the owners or sysadmins. By "grow-only", I > do not mean we cannot throw out the trash; it just means that > arguments such as "please don't remove UUCP" or "please remove the > r-utils" are largely irrelevant. [.....] > OK. End of this thought-dump. Who's coming to play? IMHO this is quite an interesting idea - kind of like what Solaris does with it's packages only better. I don't think it'll work though :-) At the moment FreeBSD consists of the base system (we maintain two) and then a bunch of ``other things'' on top. Originally, they were all pretty much distinct/separate, although lately the ports have become quite complicated dependency-wise, and the doc & www trees have a lot of ports dependencies. What you're proposing is way too granular, and the whole dependency tree would be horrific. I believe that a better approach (which isn't radically different to what you're suggesting) would be to make a ``set'' mechanism for the ports - probably just a series of super-ports like docproj or kde. Then we can start pulling things like ``everything in contrib'' out into the ports hierarchy and making super-ports/sets out of them where this makes sense, and progress to system utilities that aren't vital in running a machine. I think the big problem with all of this however is that there's no easy way to keep the ports up-to-date. I know that work is underway here, but until I have a tool that will go into /var/db/pkg and to a ``make buildpackages'' so that I can subsequently ``make installpackages'', I'd be loath to move anything from contrib to ports. > M > -- > Mark Murray > Warning: this .sig is umop ap!sdn -- 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 Feb 27 18:13:30 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 A736937B71A for ; Tue, 27 Feb 2001 18:12:29 -0800 (PST) (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.2/8.11.2) with ESMTP id f1S0gq454788; Wed, 28 Feb 2001 00:44:07 GMT (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.2/8.11.2) with ESMTP id f1RI1oF00966; Tue, 27 Feb 2001 18:01:50 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102271801.f1RI1oF00966@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Mark Murray Cc: arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: FreeBSD sources from 20000' In-Reply-To: Message from Mark Murray of "Tue, 27 Feb 2001 13:36:49 +0200." <200102271136.f1RBa4R12865@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Feb 2001 18:01:50 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > REMINDER REMINDER - The whole point of this exercise is NOT to > remove ANYTHING from FreeBSD. Effectively, FreeBSD will become a > grow-only system with the configuration and installation policies > placed in the hands of the owners or sysadmins. By "grow-only", I > do not mean we cannot throw out the trash; it just means that > arguments such as "please don't remove UUCP" or "please remove the > r-utils" are largely irrelevant. [.....] > OK. End of this thought-dump. Who's coming to play? IMHO this is quite an interesting idea - kind of like what Solaris does with it's packages only better. I don't think it'll work though :-) At the moment FreeBSD consists of the base system (we maintain two) and then a bunch of ``other things'' on top. Originally, they were all pretty much distinct/separate, although lately the ports have become quite complicated dependency-wise, and the doc & www trees have a lot of ports dependencies. What you're proposing is way too granular, and the whole dependency tree would be horrific. I believe that a better approach (which isn't radically different to what you're suggesting) would be to make a ``set'' mechanism for the ports - probably just a series of super-ports like docproj or kde. Then we can start pulling things like ``everything in contrib'' out into the ports hierarchy and making super-ports/sets out of them where this makes sense, and progress to system utilities that aren't vital in running a machine. I think the big problem with all of this however is that there's no easy way to keep the ports up-to-date. I know that work is underway here, but until I have a tool that will go into /var/db/pkg and to a ``make buildpackages'' so that I can subsequently ``make installpackages'', I'd be loath to move anything from contrib to ports. > M > -- > Mark Murray > Warning: this .sig is umop ap!sdn -- 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 Feb 27 20:19:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 0E00A37B719 for ; Tue, 27 Feb 2001 20:19:37 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (i003-146.nv.iinet.net.au [203.59.3.146]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id MAA07379; Wed, 28 Feb 2001 12:19:28 +0800 Message-ID: <3A9C7C27.D29A06A1@elischer.org> Date: Tue, 27 Feb 2001 20:18:47 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Kostas Magoutis Cc: freebsd-arch@freebsd.org Subject: Re: Logical device instances References: <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kostas Magoutis wrote: > > I am writing a device driver for a user-level networking card. User > level code interacts with it via open, close, mmap, and ioctl. A > separate logical instance of the device needs to be created each time > a process opens the device (as in when a file is created when a vnode > is opened). The device driver needs to have a way to find out on what > logical instance of the device a system call is performed. It seems > to me that at present (with either specfs or devfs), the device driver > has no way to find out on what opened instance of the device an > operation is performed. Am I missing something or the present device > driver interfaces just don't support such functionality? > Thanks, > > Kostas > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message device drivers for networking don't use the open/close/read/write interface. they use sockets, so that different processs open differnt sockets which are multiplexed onto the device using a protocol. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 20:57:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wally.eecs.harvard.edu (wally.eecs.harvard.edu [140.247.60.30]) by hub.freebsd.org (Postfix) with ESMTP id E51CD37B718 for ; Tue, 27 Feb 2001 20:57:48 -0800 (PST) (envelope-from magoutis@eecs.harvard.edu) Received: (from magoutis@localhost) by wally.eecs.harvard.edu (8.10.0/8.10.0) id f1S4vYQ19924; Tue, 27 Feb 2001 23:57:34 -0500 (EST) Date: Tue, 27 Feb 2001 23:57:34 -0500 (EST) Message-Id: <200102280457.f1S4vYQ19924@wally.eecs.harvard.edu> From: Kostas Magoutis To: julian@elischer.org Cc: freebsd-arch@FreeBSD.ORG In-reply-to: <3A9C7C27.D29A06A1@elischer.org> (message from Julian Elischer on Tue, 27 Feb 2001 20:18:47 -0800) Subject: Re: Logical device instances References: <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> <3A9C7C27.D29A06A1@elischer.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The networking protocol in my case has to be in user space (this is not the usual kind of networking card, it is used to DMA directly to and from user space). So, sockets in their present form won't work for me as they can't be used to multiplex the device without an intermediate IP protocol. From: Julian Elischer device drivers for networking don't use the open/close/read/write interface. they use sockets, so that different processs open differnt sockets which are multiplexed onto the device using a protocol. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message Kostas Magoutis wrote: > > I am writing a device driver for a user-level networking card. User > level code interacts with it via open, close, mmap, and ioctl. A > separate logical instance of the device needs to be created each time > a process opens the device (as in when a file is created when a vnode > is opened). The device driver needs to have a way to find out on what > logical instance of the device a system call is performed. It seems > to me that at present (with either specfs or devfs), the device driver > has no way to find out on what opened instance of the device an > operation is performed. Am I missing something or the present device > driver interfaces just don't support such functionality? > Thanks, > > Kostas > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 21:35: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 17A5237B71D for ; Tue, 27 Feb 2001 21:34:59 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (i003-146.nv.iinet.net.au [203.59.3.146]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id NAA14210; Wed, 28 Feb 2001 13:34:51 +0800 Message-ID: <3A9C8DFA.ABC44BA1@elischer.org> Date: Tue, 27 Feb 2001 21:34:50 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Kostas Magoutis Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Logical device instances References: <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> <3A9C7C27.D29A06A1@elischer.org> <200102280457.f1S4vYQ19924@wally.eecs.harvard.edu> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kostas Magoutis wrote: > > The networking protocol in my case has to be in user space (this is > not the usual kind of networking card, it is used to DMA directly to > and from user space). So, sockets in their present form won't work > for me as they can't be used to multiplex the device without an > intermediate IP protocol. Neither of these two statements is actually true. When I was working for TRW we used a small kernel protocol to DMA directly 'from the wire' to a memory pool that was mmapped into the userspace. It requires a co-operating network driver, but then you must have that anyhow no matter what you are doing.. we had three drivers: 1/ network drivers that knew how to DMA packets to/from the special pool. 2/ A pseudo device that was used by user processes to mmap he pool and to free buffers when they were finished with them (via ioctls) 3/ A modified disk driver that also knew how to directly access the memory pool. Packets were sent out by writing the data from disk to the pool via DMA. The process got a cookie that represented those buffers. It then sent that cookie, plus a packet header to the network driver, which transmitted the header, followed by the buffers. We used 15.5KB payload.. (to allow up to 512 bytes of header). On receivce, you got the header from the socket, with a cookie (rcvmesg(2)) You could convert the cookie into buffer offsets with an ioctl, or just pass it on to the disk driver if you wanted to write it to disk without ever looking at it. Obviously there was more to it than that but thats the short version.. > > From: Julian Elischer > > device drivers for networking don't use the > open/close/read/write interface. > they use sockets, so that different processs open differnt sockets > which are multiplexed onto the device using a protocol. > > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000-2001 > ---> X_.---._/ > v > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > > Kostas Magoutis wrote: > > > > I am writing a device driver for a user-level networking card. User > > level code interacts with it via open, close, mmap, and ioctl. A > > separate logical instance of the device needs to be created each time > > a process opens the device (as in when a file is created when a vnode > > is opened). The device driver needs to have a way to find out on what > > logical instance of the device a system call is performed. It seems > > to me that at present (with either specfs or devfs), the device driver > > has no way to find out on what opened instance of the device an > > operation is performed. Am I missing something or the present device > > driver interfaces just don't support such functionality? > > Thanks, > > > > Kostas > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 21:56: 5 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 53ABC37B719 for ; Tue, 27 Feb 2001 21:56:03 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1S5twd14711; Tue, 27 Feb 2001 22:55:59 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102280555.f1S5twd14711@harmony.village.org> To: Kostas Magoutis Subject: Re: Logical device instances Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 27 Feb 2001 19:48:09 EST." <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> References: <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> Date: Tue, 27 Feb 2001 22:55:58 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> Kostas Magoutis writes: : I am writing a device driver for a user-level networking card. User : level code interacts with it via open, close, mmap, and ioctl. A Think minor numbers. Each instance is a different minor number. There's no way to know what "instance" was opened except by minor numbers. There's not a 1-1 correspondence between opens and closes even (think dup and/or not close on exec after a fork). If you have all of the "instances" share the same minor number, they are all the same device and are treated as such by the kernel. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 21:57: 5 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 CF4D637B71A for ; Tue, 27 Feb 2001 21:57:03 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1S5v1d17190; Tue, 27 Feb 2001 22:57:01 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102280557.f1S5v1d17190@harmony.village.org> To: mjacob@feral.com Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 27 Feb 2001 14:38:58 PST." References: Date: Tue, 27 Feb 2001 22:57:00 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : Other than this- I'd check 'em in. : : --- /usr/share/man/man9/resource_query_string.9 Tue Feb 27 14:38:06 2001 : +++ ./resource_query_string.9 Tue Feb 27 14:31:32 2001 : @@ -45,8 +45,7 @@ : .Pp : Fetches a string value from the hints mechanism. : .Pp : -.Fn resouce_query_string : -is called to see enumerate all possible : +.Fn resouce_query_string is called to see enumerate all possible I thought that .Fn lines broke after the argument that you want Fn'd. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 21:58:13 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 DD67337B718; Tue, 27 Feb 2001 21:58:09 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1S5w9d19167; Tue, 27 Feb 2001 22:58:09 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102280558.f1S5w9d19167@harmony.village.org> To: John Baldwin Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h Cc: Matthew Jacob , arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 27 Feb 2001 14:44:04 PST." References: Date: Tue, 27 Feb 2001 22:58:09 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : I.e., each new sentence starts on a new line (to help with translation) and : you mark up stuff. I'll try and look at this today or tomorrow for mdoc : stuff. Though you probably want to send them off to ru, mpp, sheldonh, and/or : asmodai as well. Actually, it occurred to me that doc@ might be a good place to send doc review requests, no? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 22: 2:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from devil1.arpnetworks.com (devil1.arpnetworks.com [206.171.92.96]) by hub.freebsd.org (Postfix) with SMTP id 08CF337B719 for ; Tue, 27 Feb 2001 22:02:12 -0800 (PST) (envelope-from root@devil1.arpnetworks.com) Received: (qmail 26089 invoked by uid 501); 28 Feb 2001 06:12:26 -0000 Date: 28 Feb 2001 06:12:26 -0000 Message-ID: <20010228061226.26088.qmail@devil1.arpnetworks.com> To: freebsd-arch@FreeBSD.org Subject: BSDSearch.Com - !New! Search Engine for BSD Users From: bsdjesus@bsdsearch.com X-Mailer: Postlister 1,16 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG BSDSearch.com http://www.bsdsearch.com is a new search engine for BSD Users around the Glove. It aims to be the largest indexed directory on the 'net for BSD Users. BSDSearch is by far the easiest way to find resources for iBSD, FreeBSD, NetBSD, OpenBSD and Anything Related to BSD. For more information contact bsdjesus@bsdsearch.com, webmaster@bsdsearch.com or reply to this e-mail. To be removed from the list,simply reply with remove in the subject head and we will remove your name. http://www.bsdsearch.com -- BSDSearch.com The Worlds Largest Directory and Search Engine for BSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 22: 6: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6261037B721 for ; Tue, 27 Feb 2001 22:06:00 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id WAA12744; Tue, 27 Feb 2001 22:05:58 -0800 Date: Tue, 27 Feb 2001 22:05:57 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h In-Reply-To: <200102280557.f1S5v1d17190@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Feb 2001, Warner Losh wrote: > In message Matthew Jacob writes: > : Other than this- I'd check 'em in. > : > : --- /usr/share/man/man9/resource_query_string.9 Tue Feb 27 14:38:06 2001 > : +++ ./resource_query_string.9 Tue Feb 27 14:31:32 2001 > : @@ -45,8 +45,7 @@ > : .Pp > : Fetches a string value from the hints mechanism. > : .Pp > : -.Fn resouce_query_string > : -is called to see enumerate all possible > : +.Fn resouce_query_string is called to see enumerate all possible > > I thought that .Fn lines broke after the argument that you want Fn'd. Oops- that's a reverse patch! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 22: 6:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3806137B71A; Tue, 27 Feb 2001 22:06:37 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id WAA12753; Tue, 27 Feb 2001 22:06:35 -0800 Date: Tue, 27 Feb 2001 22:06:34 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h In-Reply-To: <200102280558.f1S5w9d19167@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG However! Whatever! I've waited a month for these and want to see them integrated! Are they good to go for -stable as well? On Tue, 27 Feb 2001, Warner Losh wrote: > In message John Baldwin writes: > : I.e., each new sentence starts on a new line (to help with translation) and > : you mark up stuff. I'll try and look at this today or tomorrow for mdoc > : stuff. Though you probably want to send them off to ru, mpp, sheldonh, and/or > : asmodai as well. > > Actually, it occurred to me that doc@ might be a good place to send > doc review requests, no? > > Warner > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 22:13:26 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 E49A737B719 for ; Tue, 27 Feb 2001 22:13:22 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1S6D3d46907; Tue, 27 Feb 2001 23:13:06 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102280613.f1S6D3d46907@harmony.village.org> To: Mark Murray Subject: Re: FreeBSD sources from 20000' Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 27 Feb 2001 13:36:49 +0200." <200102271136.f1RBa4R12865@gratis.grondar.za> References: <200102271136.f1RBa4R12865@gratis.grondar.za> Date: Tue, 27 Feb 2001 23:13:03 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102271136.f1RBa4R12865@gratis.grondar.za> Mark Murray writes: : I don't think that the module should define what distribution it belongs to. sets should do that. This will allow many things. First, it will allow one to have modules belong to multiple sets, second it will allow users or those outside the system to define their own sets without hacking all the module lines. : Containment (or "set") modules will be structured kinda like so: : : : cat : ls : echo : sh : : I don't think that attribute should necessary be part of this. Of course, it would be nice when you want to build a 1 partition system with dynamic /bin and /sbin. It just seems not to fit. i'd like to be able to do something like the following: bin/chmod bin/cat bin/cp bin/csh bin/date bin/dd bin/df bin/echo bin/expr bin/hostname bin/kill bin/ln bin/ls bin/mkdir bin/mv bin/pwd bin/ps bin/rcp bin/rm bin/rmdir bin/sh bin/sleep bin/stty bin/sync bin/test gnu/lib/libregex gnu/lib/libreadline gnu/usr.bin/awk gnu/usr.bin/cpio gnu/usr.bin/diff gnu/usr.bin/diff3 gnu/usr.bin/grep gnu/usr.bin/gzip gnu/usr.bin/tar lib/libc lib/libstdc++ lib/libcrypt lib/libedit lib/libftpio lib/libipsec lib/libipx lib/libkvm lib/libmd lib/libnetgraph lib/libncurses lib/libpam lib/librpcsvc lib/libskey lib/libutil lib/libwrap lib/libz lib/msun libexec/ftpd libexec/getty libexec/rlogind libexec/rshd libexec/rtld-elf libexec/telnetd sbin/adjkerntz sbin/dhclient sbin/disklabel sbin/dmesg sbin/fsck sbin/i386/fdisk sbin/ifconfig sbin/init sbin/ipfw sbin/kldload sbin/kldstat sbin/kldunload sbin/ldconfig sbin/md5 sbin/mknod sbin/mount sbin/mount_null sbin/mount_nfs sbin/newfs sbin/ping sbin/reboot sbin/route sbin/swapon sbin/sysctl sbin/umount share/termcap sys/boot usr.bin/chflags usr.bin/du usr.bin/ee usr.bin/env usr.bin/ftp usr.bin/find usr.bin/head usr.bin/hexdump usr.bin/id usr.bin/login usr.bin/ldd usr.bin/less usr.bin/netstat usr.bin/objformat usr.bin/rsh usr.bin/rlogin usr.bin/sed usr.bin/su usr.bin/tail usr.bin/telnet usr.bin/top usr.bin/touch usr.bin/tty usr.bin/uname usr.bin/uptime usr.bin/vi usr.sbin/chown usr.sbin/cron usr.sbin/dev_mkdb usr.sbin/inetd usr.sbin/kbdcontrol usr.sbin/pkg_add usr.sbin/pwd_mkdb usr.sbin/syslogd usr.sbin/traceroute usr.sbin/vidcontrol usr.sbin/vipw Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 22:16:34 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 D385337B719; Tue, 27 Feb 2001 22:16:32 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1S6GUd58703; Tue, 27 Feb 2001 23:16:30 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102280616.f1S6GUd58703@harmony.village.org> To: mjacob@feral.com Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h Cc: John Baldwin , arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 27 Feb 2001 22:06:34 PST." References: Date: Tue, 27 Feb 2001 23:16:30 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : However! Whatever! I've waited a month for these and want to see them : integrated! : : Are they good to go for -stable as well? Almost. I've improved them somewhat since the versions that I posted. I'll run them by ru and/or doc and commit them by the end of the week if all goes well. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 22:22:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 29E1637B718; Tue, 27 Feb 2001 22:22:31 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id WAA12841; Tue, 27 Feb 2001 22:22:29 -0800 Date: Tue, 27 Feb 2001 22:22:28 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h In-Reply-To: <200102280616.f1S6GUd58703@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Actually what I mean to ask was whether resource hint stuff should work the same in -stable? On Tue, 27 Feb 2001, Warner Losh wrote: > In message Matthew Jacob writes: > : However! Whatever! I've waited a month for these and want to see them > : integrated! > : > : Are they good to go for -stable as well? > > Almost. I've improved them somewhat since the versions that I > posted. I'll run them by ru and/or doc and commit them by the end of > the week if all goes well. > > Warner > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 22:25:26 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 402B837B71B; Tue, 27 Feb 2001 22:25:24 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1S6PLd83859; Tue, 27 Feb 2001 23:25:21 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102280625.f1S6PLd83859@harmony.village.org> To: mjacob@feral.com Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h Cc: John Baldwin , arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 27 Feb 2001 22:22:28 PST." References: Date: Tue, 27 Feb 2001 23:25:21 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : Actually what I mean to ask was whether resource hint stuff should work the : same in -stable? Not yet. I have some patches in the local Timing Solutions tree, but haven't merged them back into the main FreeBSD stable sources yet. The functions exist in -stable, but the hints stuff doesn't integrate with them yet. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 22:28:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id F100237B71C; Tue, 27 Feb 2001 22:28:09 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id WAA12866; Tue, 27 Feb 2001 22:28:08 -0800 Date: Tue, 27 Feb 2001 22:28:07 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h In-Reply-To: <200102280625.f1S6PLd83859@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are you planning to do this for 4.3? The reason I ask is so I can decide whether to finish setting up the use of hints in fxp (and MFC it) as well as another driver or two. On Tue, 27 Feb 2001, Warner Losh wrote: > In message Matthew Jacob writes: > : Actually what I mean to ask was whether resource hint stuff should work the > : same in -stable? > > Not yet. I have some patches in the local Timing Solutions tree, but > haven't merged them back into the main FreeBSD stable sources yet. > The functions exist in -stable, but the hints stuff doesn't integrate > with them yet. > > Warner > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 22:30:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wally.eecs.harvard.edu (wally.eecs.harvard.edu [140.247.60.30]) by hub.freebsd.org (Postfix) with ESMTP id 9150637B71A for ; Tue, 27 Feb 2001 22:30:53 -0800 (PST) (envelope-from magoutis@eecs.harvard.edu) Received: (from magoutis@localhost) by wally.eecs.harvard.edu (8.10.0/8.10.0) id f1S6UoW07894; Wed, 28 Feb 2001 01:30:50 -0500 (EST) Date: Wed, 28 Feb 2001 01:30:50 -0500 (EST) Message-Id: <200102280630.f1S6UoW07894@wally.eecs.harvard.edu> From: Kostas Magoutis To: julian@elischer.org Cc: freebsd-arch@FreeBSD.ORG In-reply-to: <3A9C8DFA.ABC44BA1@elischer.org> (message from Julian Elischer on Tue, 27 Feb 2001 21:34:50 -0800) Subject: Re: Logical device instances References: <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> <3A9C7C27.D29A06A1@elischer.org> <200102280457.f1S4vYQ19924@wally.eecs.harvard.edu> <3A9C8DFA.ABC44BA1@elischer.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The card can take care of translating virtual to physical addresses and can DMA directly into user space, there's no need for mmap tricks. It also supports reading from a remote process virtual address space without involving the remote processor. In this setting, I don't see how to use sockets to have logical instances of the card. I would also like to avoid hacking the rest of the kernel, I'd like to contain everything in the driver. BTW, just to give you an idea of what I'd like to have, Linux passes the file structure as a parameter to device operations (along with the inode), and the file structure has a private data space that the driver is free to use for storing state associated with the opened "instance" of the device. In FreeBSD, it is only a specinfo * and the proc * that is passed, and I can't use this information alone to map to the "file". From: Julian Elischer Kostas Magoutis wrote: > > The networking protocol in my case has to be in user space (this is > not the usual kind of networking card, it is used to DMA directly to > and from user space). So, sockets in their present form won't work > for me as they can't be used to multiplex the device without an > intermediate IP protocol. Neither of these two statements is actually true. When I was working for TRW we used a small kernel protocol to DMA directly 'from the wire' to a memory pool that was mmapped into the userspace. It requires a co-operating network driver, but then you must have that anyhow no matter what you are doing.. we had three drivers: 1/ network drivers that knew how to DMA packets to/from the special pool. 2/ A pseudo device that was used by user processes to mmap he pool and to free buffers when they were finished with them (via ioctls) 3/ A modified disk driver that also knew how to directly access the memory pool. Packets were sent out by writing the data from disk to the pool via DMA. The process got a cookie that represented those buffers. It then sent that cookie, plus a packet header to the network driver, which transmitted the header, followed by the buffers. We used 15.5KB payload.. (to allow up to 512 bytes of header). On receivce, you got the header from the socket, with a cookie (rcvmesg(2)) You could convert the cookie into buffer offsets with an ioctl, or just pass it on to the disk driver if you wanted to write it to disk without ever looking at it. Obviously there was more to it than that but thats the short version.. > > From: Julian Elischer > > device drivers for networking don't use the > open/close/read/write interface. > they use sockets, so that different processs open differnt sockets > which are multiplexed onto the device using a protocol. > > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000-2001 > ---> X_.---._/ > v > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > > Kostas Magoutis wrote: > > > > I am writing a device driver for a user-level networking card. User > > level code interacts with it via open, close, mmap, and ioctl. A > > separate logical instance of the device needs to be created each time > > a process opens the device (as in when a file is created when a vnode > > is opened). The device driver needs to have a way to find out on what > > logical instance of the device a system call is performed. It seems > > to me that at present (with either specfs or devfs), the device driver > > has no way to find out on what opened instance of the device an > > operation is performed. Am I missing something or the present device > > driver interfaces just don't support such functionality? > > Thanks, > > > > Kostas > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 22:34:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wally.eecs.harvard.edu (wally.eecs.harvard.edu [140.247.60.30]) by hub.freebsd.org (Postfix) with ESMTP id EB67E37B719 for ; Tue, 27 Feb 2001 22:34:44 -0800 (PST) (envelope-from magoutis@eecs.harvard.edu) Received: (from magoutis@localhost) by wally.eecs.harvard.edu (8.10.0/8.10.0) id f1S6Ygq03513; Wed, 28 Feb 2001 01:34:42 -0500 (EST) Date: Wed, 28 Feb 2001 01:34:42 -0500 (EST) Message-Id: <200102280634.f1S6Ygq03513@wally.eecs.harvard.edu> From: Kostas Magoutis To: imp@harmony.village.org Cc: freebsd-arch@FreeBSD.ORG In-reply-to: <200102280555.f1S5twd14711@harmony.village.org> (message from Warner Losh on Tue, 27 Feb 2001 22:55:58 -0700) Subject: Re: Logical device instances References: <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> <200102280555.f1S5twd14711@harmony.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The minor number is still pretty static, isn't it? I can multiplex a single physical device but I can't create dynamic instances of it, e.g., the files corresponding to the vnode/devnode of the device. Date: Tue, 27 Feb 2001 22:55:58 -0700 From: Warner Losh In message <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> Kostas Magoutis writes: : I am writing a device driver for a user-level networking card. User : level code interacts with it via open, close, mmap, and ioctl. A Think minor numbers. Each instance is a different minor number. There's no way to know what "instance" was opened except by minor numbers. There's not a 1-1 correspondence between opens and closes even (think dup and/or not close on exec after a fork). If you have all of the "instances" share the same minor number, they are all the same device and are treated as such by the kernel. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 22:36:56 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 5300837B71A for ; Tue, 27 Feb 2001 22:36:54 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1S6apd02466; Tue, 27 Feb 2001 23:36:51 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102280636.f1S6apd02466@harmony.village.org> To: Kostas Magoutis Subject: Re: Logical device instances Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 28 Feb 2001 01:34:42 EST." <200102280634.f1S6Ygq03513@wally.eecs.harvard.edu> References: <200102280634.f1S6Ygq03513@wally.eecs.harvard.edu> <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> <200102280555.f1S5twd14711@harmony.village.org> Date: Tue, 27 Feb 2001 23:36:51 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102280634.f1S6Ygq03513@wally.eecs.harvard.edu> Kostas Magoutis writes: : The minor number is still pretty static, isn't it? I can multiplex a : single physical device but I can't create dynamic instances of it, : e.g., the files corresponding to the vnode/devnode of the device. You can create all the dev nodes that you want. It is a simple mknod(). Also, you can encode the physical minor such that each one can have multiple logical minors. There's 24 bits of minor number to play with. In current with DEVFS you can instruct your driver to create new device nodes and they will appear in the tree. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 23:28: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id A076337B71B for ; Tue, 27 Feb 2001 23:28:01 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id AAA80880; Wed, 28 Feb 2001 00:27:37 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpd5Rmwya; Wed Feb 28 00:27:34 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id AAA19158; Wed, 28 Feb 2001 00:27:56 -0700 (MST) From: Terry Lambert Message-Id: <200102280727.AAA19158@usr05.primenet.com> Subject: Re: Logical device instances To: magoutis@eecs.harvard.edu (Kostas Magoutis) Date: Wed, 28 Feb 2001 07:27:56 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG In-Reply-To: <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> from "Kostas Magoutis" at Feb 27, 2001 07:48:09 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am writing a device driver for a user-level networking card. User > level code interacts with it via open, close, mmap, and ioctl. A > separate logical instance of the device needs to be created each time > a process opens the device (as in when a file is created when a vnode > is opened). The device driver needs to have a way to find out on what > logical instance of the device a system call is performed. It seems > to me that at present (with either specfs or devfs), the device driver > has no way to find out on what opened instance of the device an > operation is performed. Am I missing something or the present device > driver interfaces just don't support such functionality? Networking devices aren't really devices. What you want is a raw socket. As a general not, FreeBSD can't suport clonging devices because of the "struct fileops *" indirection. This is one of the reasons we can't run multiple copies of VMWare, since we can't create multiple instances of state from the one device, and since the VMWare code we have to run under emulation expects a cloning device, such as is supported by Linux. There was a long discussion about cloning devices on this list a while back, in which several approaches were suggested; mine was rejected, and the others weren't implemented. See the list archives for details. Personally, for your use, I don't believe you need a cloning device or to do as much work as Julian suggested; worst case, you could use BPF ("man bpf"). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 23:36:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id EF2C837B71A for ; Tue, 27 Feb 2001 23:36:55 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id AAA51784; Wed, 28 Feb 2001 00:36:33 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpd20_yaa; Wed Feb 28 00:36:25 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id AAA19304; Wed, 28 Feb 2001 00:36:46 -0700 (MST) From: Terry Lambert Message-Id: <200102280736.AAA19304@usr05.primenet.com> Subject: Re: rand(3): enough already! To: drosih@rpi.edu (Garance A Drosihn) Date: Wed, 28 Feb 2001 07:36:46 +0000 (GMT) Cc: arch@freebsd.org Reply-To: /dev/null@primenet.com In-Reply-To: from "Garance A Drosihn" at Feb 27, 2001 04:50:40 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A bit of a stretch, but... Could we just teach people to type "rand()" when they wanted "rand()", and "random()" when they wanted "random()"? I know, I know, this is like expecting people to type something other than "read()" when they want to output data; still, it might be worth considering. "Oh dear, my parcheesi program which uses "read()" to do output on Linux isn't working on FreeBSD! Let's fix libc!". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 27 23:49:18 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 7FF2437B718 for ; Tue, 27 Feb 2001 23:49:14 -0800 (PST) (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 SAA32245; Wed, 28 Feb 2001 18:48:56 +1100 Date: Wed, 28 Feb 2001 18:48:49 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Michael Sinz Cc: "Duane H. Hesser" , Randell Jesup , "(Bruce Bauman)" , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: ELF and diskless boot In-Reply-To: <3A9C231D.EA12570A@wgate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Feb 2001, Michael Sinz wrote: > > On Mon, 13 Mar 2000, Ruslan Ermilov wrote: > > > > > One thing that should IMHO be pointed out in the upcoming 4.0-RELEASE's > > > ERRATA (or some more appropriate place), is the fact that the loader(8) > > > is now a prerequisite for certain programs using kvm(3) interface. > > > Obvious examples are top(1) and swapinfo(8). > > > > > > If you boot your kernel without loader(8), directly through bootblocks, > > > these programs will not work. > > [I wrote] > > I don't user loader(8), and finally got around to fixing this. The > > problem is that the kernel linker wants module data for the kernel. > > It defaults to using incomplete data if none is present. The following > > supplies slightly less incomplete data: > > [...] > > Note that the "using incomplete data" is not really correct. It uses > complete data -- the dynamic section, aka the publicly defined symbols. > The problem is that FreeBSD requires the debug symbols. It's the module data that is incomplete. My hack doesn't completely fix this. It only supplies enough data for the kernel linker to see all the sections that have been loaded. No debugging symbols are required, only some static ones. This is because utilities require almost all symbols to be visible so that they can be hacked on via kmem (if the kmem hack is used at all). The publicness of symbols via the kmem hack has very little to do with their publicness (external linkage) as C symbols or how the symbol table is organized. It just happens that a.out format made access to all symbols equally easy. ELF raised the bar, and nonstandard loaders still haven't all jumped it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 2:36:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (node16292.a2000.nl [24.132.98.146]) by hub.freebsd.org (Postfix) with ESMTP id 87A1C37B719; Wed, 28 Feb 2001 02:35:52 -0800 (PST) (envelope-from adrian@roaming.cacheboy.net) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f1SAaiO39313; Wed, 28 Feb 2001 11:36:44 +0100 (CET) (envelope-from adrian) Date: Wed, 28 Feb 2001 11:36:44 +0100 From: Adrian Chadd To: freebsd-fs@freebsd.org Cc: freebsd-arch@freebsd.org Subject: mount fixes, part 1 Message-ID: <20010228113644.A39251@roaming.cacheboy.net> 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 X-Loop: FreeBSD.ORG Hi, I'm running through and tidying up the mount interface, as promised. My first set of patches aren't yet complete (there is at least one documented strncpy() I have to fix up). I am attempting to rework the VFS_MOUNT() vfsop to take kernel pointers, rather than userland pointers. This will reduce the complexity by removing the copyin*() functions and allow "other" syscall interfaces to be used (eg linux, osf/1..) jlemon did some initial work on this, but I've gone and redone his work. I've moved the bulk of the mount process into a function called vfs_mount(). mount() and the linux mount() use this function to mount a filesystem. It is up to the syscall itself to worry about copyin*()ing. Note that the mount data pointer is still a user pointer - fixing this will require a *lot* more work, possibly by replacing it by a set of sbufs or a set of attrib=value strings. It is my hope that eventually vfs_mount() and VFS_MOUNT() will not use copyin*() at all. Comments are welcome. I'd like to commit this in the next couple of days so I can continue with my VFS tidyups. You can find my patch at http://people.freebsd.org/~adrian/mount.diff . Note that I _will_ get to fixing the umount issues raised by mbr and rwatson, but I want to get this set fixed first. Thanks! Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 2:38:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id F262837B718; Wed, 28 Feb 2001 02:38:27 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1SAcfM34069; Wed, 28 Feb 2001 11:38:41 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Adrian Chadd Cc: freebsd-fs@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: mount fixes, part 1 In-Reply-To: Your message of "Wed, 28 Feb 2001 11:36:44 +0100." <20010228113644.A39251@roaming.cacheboy.net> Date: Wed, 28 Feb 2001 11:38:40 +0100 Message-ID: <34067.983356720@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010228113644.A39251@roaming.cacheboy.net>, Adrian Chadd writes: >I am attempting to rework the VFS_MOUNT() vfsop to take kernel pointers, >rather than userland pointers. struct uio ? -- 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 Feb 28 3:48:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9EA0037B718 for ; Wed, 28 Feb 2001 03:48:22 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA74944; Wed, 28 Feb 2001 12:48:14 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Kenneth D. Merry" Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland References: <20010226003319.A19994@panzer.kdm.org> <20010226143035.A25402@panzer.kdm.org> From: Dag-Erling Smorgrav Date: 28 Feb 2001 12:48:13 +0100 In-Reply-To: "Kenneth D. Merry"'s message of "Mon, 26 Feb 2001 14:30:35 -0700" Message-ID: Lines: 9 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Kenneth D. Merry" writes: > It is using vnsprintf() instead of kvprintf. Diffs for that, and the > userland conversion are attached. Please send unified diffs. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 4:37:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 896C537B71A for ; Wed, 28 Feb 2001 04:37:23 -0800 (PST) (envelope-from msinz@wgate.com) Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152C7CBW; Wed, 28 Feb 2001 07:37:33 -0500 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.1/8.11.1) with ESMTP id f1SCbJk07004; Wed, 28 Feb 2001 07:37:21 -0500 (EST) (envelope-from msinz@wgate.com) Message-ID: <3A9CF0FF.804199EE@wgate.com> Date: Wed, 28 Feb 2001 07:37:19 -0500 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: "Duane H. Hesser" , Randell Jesup , "(Bruce Bauman)" , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: ELF and diskless boot References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > > On Tue, 27 Feb 2001, Michael Sinz wrote: > > > > On Mon, 13 Mar 2000, Ruslan Ermilov wrote: > > > > > > > One thing that should IMHO be pointed out in the upcoming 4.0-RELEASE's > > > > ERRATA (or some more appropriate place), is the fact that the loader(8) > > > > is now a prerequisite for certain programs using kvm(3) interface. > > > > Obvious examples are top(1) and swapinfo(8). > > > > > > > > If you boot your kernel without loader(8), directly through bootblocks, > > > > these programs will not work. > > > > [I wrote] > > > I don't user loader(8), and finally got around to fixing this. The > > > problem is that the kernel linker wants module data for the kernel. > > > It defaults to using incomplete data if none is present. The following > > > supplies slightly less incomplete data: > > > > [...] > > > > Note that the "using incomplete data" is not really correct. It uses > > complete data -- the dynamic section, aka the publicly defined symbols. > > The problem is that FreeBSD requires the debug symbols. > > It's the module data that is incomplete. My hack doesn't completely fix > this. It only supplies enough data for the kernel linker to see all the > sections that have been loaded. > > No debugging symbols are required, only some static ones. This is > because utilities require almost all symbols to be visible so that > they can be hacked on via kmem (if the kmem hack is used at all). > The publicness of symbols via the kmem hack has very little to do with > their publicness (external linkage) as C symbols or how the symbol > table is organized. It just happens that a.out format made access to > all symbols equally easy. ELF raised the bar, and nonstandard loaders > still haven't all jumped it. The "static" ones are only in the debugging sections (for obvious reasons of the fact that they are not public) The fix you had only works if the kernel has a way to load itself. This does not work for things like Etherboot which does not load the debug symbols (it does load the Elf DYNAMIC section, but that does not have symbols that are not exported) As far as Elf raising the bar goes, it does a better job of separating external vs internal symbols. Making the loaders provide access to all symbols is not the correct solution. The correct solution is to have any symbols that are defined for "external access" to be defined as such. BTW - there is little to prevent a compiler from doing nasty optimizations with variables that are marked "static" since it has full knowledge of the scope of thos variables (or at least it thinks it does since it has been told so in the source) But this is a different issue and does not currently affect GCC/x86 systems for various reasons. -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 6:11:28 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 B73CC37B719 for ; Wed, 28 Feb 2001 06:11:25 -0800 (PST) (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 14Y7K8-0000RT-0V; Wed, 28 Feb 2001 14:11:24 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f1SEBO135968; Wed, 28 Feb 2001 14:11:24 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 28 Feb 2001 14:11:24 +0000 (GMT) From: Doug Rabson To: Kostas Magoutis Cc: Subject: Re: Logical device instances In-Reply-To: <200102280048.f1S0m9n09106@wally.eecs.harvard.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 27 Feb 2001, Kostas Magoutis wrote: > I am writing a device driver for a user-level networking card. User > level code interacts with it via open, close, mmap, and ioctl. A > separate logical instance of the device needs to be created each time > a process opens the device (as in when a file is created when a vnode > is opened). The device driver needs to have a way to find out on what > logical instance of the device a system call is performed. It seems > to me that at present (with either specfs or devfs), the device driver > has no way to find out on what opened instance of the device an > operation is performed. Am I missing something or the present device > driver interfaces just don't support such functionality? Until yesterday, I thought that there was no way to do this (I wanted to do this when porting a Linux device driver). As it turns out, there is a cunning trick which you can use to generate a new 'struct file' with your own ops table and private data. Check out sys/dev/streams/streams.c and see what it does at the end of streamsopen(). -- 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 Wed Feb 28 7:34: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C69EA37B71A for ; Wed, 28 Feb 2001 07:34:01 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id KAA02215 for ; Wed, 28 Feb 2001 10:34:00 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.2/8.9.1) id f1SFWjZ12832; Wed, 28 Feb 2001 10:32:45 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15005.6685.789581.544314@grasshopper.cs.duke.edu> Date: Wed, 28 Feb 2001 10:32:45 -0500 (EST) To: freebsd-arch@freebsd.org Subject: Please review: moving vm_page_array[] X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FreeBSD currently panic's at boot on alpha UP1x00s with a lot of memory (> 512MB) with the message "isa_dmainit: unable to create dma map" The UP1x00 is the only alpha platform to use bounce buffers, and it is panicing because the contigmalloc in alloc_bounce_pages() is failing. Here's why: The vm_page_array[] (and vm_page_buckets) are currently carved out of the front of the largest chunk of physical memory. This isn't a problem on a PC, because there is typically 636k in a smaller chunk (starting at 4k) that the bounce buffers can be allocated from. There is typically no usable smaller chunk on alphas; in fact, the UP1000 family has only one chunk. Given that the vm_page_array[] entries for an alpha with 1 GB of ram consumes 13MB of memory, we need to allocate this structure at the end of memory, not at the start. The following patch moves vm_page_array[] and vm_page_buckets[] to the end of memory. This fixes the UP1000 isa_dmainit panics & appears to cause no harm on the other alphas and PCs I've tested it on. I'd really appreciate it if somebody could review this, as I'd like to get it committed & MFC'ed in time for 4.3 Thanks! Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 Index: vm_page.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_page.c,v retrieving revision 1.156 diff -u -r1.156 vm_page.c --- vm_page.c 2000/12/26 19:41:38 1.156 +++ vm_page.c 2001/02/26 16:02:58 @@ -185,14 +185,14 @@ register vm_offset_t mapped; register struct vm_page **bucket; vm_size_t npages, page_range; - register vm_offset_t new_start; + register vm_offset_t new_end; int i; vm_offset_t pa; int nblocks; - vm_offset_t first_managed_page; + vm_offset_t last_pa; /* the biggest memory array is the second group of pages */ - vm_offset_t start; + vm_offset_t end; vm_offset_t biggestone, biggestsize; vm_offset_t total; @@ -219,7 +219,7 @@ total += size; } - start = phys_avail[biggestone]; + end = phys_avail[biggestone+1]; /* * Initialize the queue headers for the free queue, the active queue @@ -255,13 +255,11 @@ /* * Validate these addresses. */ - - new_start = start + vm_page_bucket_count * sizeof(struct vm_page *); - new_start = round_page(new_start); + new_end = end - vm_page_bucket_count * sizeof(struct vm_page *); + new_end = trunc_page(new_end); mapped = round_page(vaddr); - vaddr = pmap_map(mapped, start, new_start, + vaddr = pmap_map(mapped, new_end, end, VM_PROT_READ | VM_PROT_WRITE); - start = new_start; vaddr = round_page(vaddr); bzero((caddr_t) mapped, vaddr - mapped); @@ -280,8 +278,9 @@ page_range = phys_avail[(nblocks - 1) * 2 + 1] / PAGE_SIZE - first_page; npages = (total - (page_range * sizeof(struct vm_page)) - - (start - phys_avail[biggestone])) / PAGE_SIZE; + (end - new_end)) / PAGE_SIZE; + end = new_end; /* * Initialize the mem entry structures now, and put them in the free * queue. @@ -292,12 +291,10 @@ /* * Validate these addresses. */ - new_start = round_page(start + page_range * sizeof(struct vm_page)); - mapped = pmap_map(mapped, start, new_start, - VM_PROT_READ | VM_PROT_WRITE); - start = new_start; - first_managed_page = start / PAGE_SIZE; + new_end = trunc_page(end - page_range * sizeof(struct vm_page)); + mapped = pmap_map(mapped, new_end, end, + VM_PROT_READ | VM_PROT_WRITE); /* * Clear all of the page structures @@ -314,11 +311,12 @@ cnt.v_page_count = 0; cnt.v_free_count = 0; for (i = 0; phys_avail[i + 1] && npages > 0; i += 2) { + pa = phys_avail[i]; if (i == biggestone) - pa = ptoa(first_managed_page); + last_pa = new_end; else - pa = phys_avail[i]; - while (pa < phys_avail[i + 1] && npages-- > 0) { + last_pa = phys_avail[i + 1]; + while (pa < last_pa && npages-- > 0) { vm_add_new_page(pa); pa += PAGE_SIZE; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 7:52:58 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 0F95E37B719 for ; Wed, 28 Feb 2001 07:52:54 -0800 (PST) (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 14Y8uK-000Pfk-0B; Wed, 28 Feb 2001 15:52:52 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f1SFqq136492; Wed, 28 Feb 2001 15:52:52 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 28 Feb 2001 15:52:52 +0000 (GMT) From: Doug Rabson To: Andrew Gallatin Cc: Subject: Re: Please review: moving vm_page_array[] In-Reply-To: <15005.6685.789581.544314@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Feb 2001, Andrew Gallatin wrote: > > FreeBSD currently panic's at boot on alpha UP1x00s with a lot of > memory (> 512MB) with the message "isa_dmainit: unable to create dma > map" > > The UP1x00 is the only alpha platform to use bounce buffers, and it is > panicing because the contigmalloc in alloc_bounce_pages() is failing. > Here's why: > > The vm_page_array[] (and vm_page_buckets) are currently carved out of > the front of the largest chunk of physical memory. This isn't a > problem on a PC, because there is typically 636k in a smaller chunk > (starting at 4k) that the bounce buffers can be allocated from. There > is typically no usable smaller chunk on alphas; in fact, the UP1000 > family has only one chunk. Given that the vm_page_array[] entries for > an alpha with 1 GB of ram consumes 13MB of memory, we need to allocate > this structure at the end of memory, not at the start. > > The following patch moves vm_page_array[] and vm_page_buckets[] to the > end of memory. This fixes the UP1000 isa_dmainit panics & appears to > cause no harm on the other alphas and PCs I've tested it on. I'd > really appreciate it if somebody could review this, as I'd like to get > it committed & MFC'ed in time for 4.3 Sorry about the delay in looking at this - I've had other things distracting me. The patch looks correct to me. I'm not sure what would happen if the last chunk wasn't large enough for the various data structures but then the old code didn't cope with this situation either. -- 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 Wed Feb 28 7:57:51 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 5BC2C37B71A for ; Wed, 28 Feb 2001 07:57:37 -0800 (PST) (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 CAA29889; Thu, 1 Mar 2001 02:57:23 +1100 Date: Thu, 1 Mar 2001 02:57:15 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Michael Sinz Cc: "Duane H. Hesser" , Randell Jesup , "(Bruce Bauman)" , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: ELF and diskless boot In-Reply-To: <3A9CF0FF.804199EE@wgate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Feb 2001, Michael Sinz wrote: > Bruce Evans wrote: > > No debugging symbols are required, only some static ones. This is > > because utilities require almost all symbols to be visible so that > > they can be hacked on via kmem (if the kmem hack is used at all). > > The publicness of symbols via the kmem hack has very little to do with > > their publicness (external linkage) as C symbols or how the symbol > > table is organized. It just happens that a.out format made access to > > all symbols equally easy. ELF raised the bar, and nonstandard loaders > > still haven't all jumped it. > > The "static" ones are only in the debugging sections (for obvious reasons > of the fact that they are not public) Normal kernels don't have any debugging symbols. I define "debugging symbols" as ones not stripped by strip --debug. However, static symbols are required debugger using ddb (the internal kernel debugger). > The fix you had only works if the kernel has a way to load itself. This > does not work for things like Etherboot which does not load the debug > symbols (it does load the Elf DYNAMIC section, but that does not have > symbols that are not exported) This is a bug in Etherboot. All loaders should load all the symbols that are available, at least optionally, to support internal debugging It's easier to load all sections that have debugging information of any kind (not restricted by the above definition) than to provide options to load them. You can use strip or objcopy to delete the information that you don't want. Line numbers may be useful in ddb. I think line numbers are also required (together with other information) for basic block profiling. I'm not sure if basic block profiling still works. > As far as Elf raising the bar goes, it does a better job of separating > external vs internal symbols. Making the loaders provide access to all > symbols is not the correct solution. The correct solution is to have > any symbols that are defined for "external access" to be defined as such. I disagree. Exporting bits of the kernel using linker symbols isn't the correct solution for anything except possibly for examining dead kernels, but it's easy to use. Loaders need to support all symbols for other reasons. > BTW - there is little to prevent a compiler from doing nasty optimizations > with variables that are marked "static" since it has full knowledge of the > scope of thos variables (or at least it thinks it does since it has been > told so in the source) But this is a different issue and does not currently > affect GCC/x86 systems for various reasons. Similarly for all symbols if the linker is part of the compiler and understands the scope of everything. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 8:17:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 3452B37B718 for ; Wed, 28 Feb 2001 08:17:44 -0800 (PST) (envelope-from msinz@wgate.com) Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152C7DS9; Wed, 28 Feb 2001 11:17:53 -0500 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.1/8.11.1) with ESMTP id f1SGGhk14012; Wed, 28 Feb 2001 11:16:50 -0500 (EST) (envelope-from msinz@wgate.com) Message-ID: <3A9D246B.D254796B@wgate.com> Date: Wed, 28 Feb 2001 11:16:43 -0500 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: "Duane H. Hesser" , Randell Jesup , "(Bruce Bauman)" , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: ELF and diskless boot References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > > On Wed, 28 Feb 2001, Michael Sinz wrote: > > > Bruce Evans wrote: > > > No debugging symbols are required, only some static ones. This is > > > because utilities require almost all symbols to be visible so that > > > they can be hacked on via kmem (if the kmem hack is used at all). > > > The publicness of symbols via the kmem hack has very little to do with > > > their publicness (external linkage) as C symbols or how the symbol > > > table is organized. It just happens that a.out format made access to > > > all symbols equally easy. ELF raised the bar, and nonstandard loaders > > > still haven't all jumped it. > > > > The "static" ones are only in the debugging sections (for obvious reasons > > of the fact that they are not public) > > Normal kernels don't have any debugging symbols. I define "debugging > symbols" as ones not stripped by strip --debug. However, static symbols > are required debugger using ddb (the internal kernel debugger). > > > The fix you had only works if the kernel has a way to load itself. This > > does not work for things like Etherboot which does not load the debug > > symbols (it does load the Elf DYNAMIC section, but that does not have > > symbols that are not exported) > > This is a bug in Etherboot. All loaders should load all the symbols > that are available, at least optionally, to support internal debugging > It's easier to load all sections that have debugging information of > any kind (not restricted by the above definition) than to provide > options to load them. You can use strip or objcopy to delete the > information that you don't want. Line numbers may be useful in ddb. > I think line numbers are also required (together with other information) > for basic block profiling. I'm not sure if basic block profiling still > works. That is a reasonable request and desire. It would depend on getting all kernels (FreeBSD/Linux/QNX/etc) to agree the way in which they find non-PT_LOAD loaded data (there is no pointer to it somewhere) The real issue, however, is that external tools are using internal symbols rather than public interfaces. sysctl is the real way to do this but even without sysctl, public interfaces for things like top/etc. should be somehow designated as "public" or even "semi-public". As it is, if two source files happen to have the same named static variable (which is perfectly legal and part of what static keyword provides) the lookup will "randomly" return one of them. (Randomly in this case depends on the link order) Just like function prototypes and other such things, externally defined interfaces should be known and not just "anything that we have a symbol for" BTW - I agree that the ddb kernel needs its internal symbols. But that is debugging and not operational behavior. If you issue the command: strip kernel The end result should work just as well for production use as a non-stripped kernel. (Yes, debugging is not as good, but that is not what we are talking about) > > As far as Elf raising the bar goes, it does a better job of separating > > external vs internal symbols. Making the loaders provide access to all > > symbols is not the correct solution. The correct solution is to have > > any symbols that are defined for "external access" to be defined as such. > > I disagree. Exporting bits of the kernel using linker symbols isn't > the correct solution for anything except possibly for examining dead > kernels, but it's easy to use. Loaders need to support all symbols > for other reasons. The linker symbols (external ones) are the way shared libraries link to each other. This is the defined mechanism. Now, it is not the best for "black box" work (sysctl and object-oriented mechanisms are much better albeit with some overhead) but it is much worse to just have "any variable" be accessable rather than just the defined subset that are part of the design. > > BTW - there is little to prevent a compiler from doing nasty optimizations > > with variables that are marked "static" since it has full knowledge of the > > scope of thos variables (or at least it thinks it does since it has been > > told so in the source) But this is a different issue and does not currently > affect GCC/x86 systems for various reasons. > > Similarly for all symbols if the linker is part of the compiler and > understands the scope of everything. I agree (and have worked with compilers that do that) which is even more reason to define which objects/symbols/etc are part of the public interface and which are internal use only. The current (4.x) system does not provide any way of doing so and has tools (top/vmstat/etc) that depend on access to a variety of symbols that are not obviously exported for direct access. (And sometimes even have comments saying that they should not be, as in FSCALE... That is, if I read that comment correctly.) -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 8:56:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 6B46337B718 for ; Wed, 28 Feb 2001 08:56:08 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id JAA41529; Wed, 28 Feb 2001 09:56:00 -0700 (MST) (envelope-from ken) Date: Wed, 28 Feb 2001 09:56:00 -0700 From: "Kenneth D. Merry" To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: sbufs in userland Message-ID: <20010228095600.A41509@panzer.kdm.org> References: <20010226003319.A19994@panzer.kdm.org> <20010226143035.A25402@panzer.kdm.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from des@ofug.org on Wed, Feb 28, 2001 at 12:48:13PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 28, 2001 at 12:48:13 +0100, Dag-Erling Smorgrav wrote: > "Kenneth D. Merry" writes: > > It is using vnsprintf() instead of kvprintf. Diffs for that, and the > > userland conversion are attached. > > Please send unified diffs. Attached. Ken -- Kenneth Merry ken@kdm.org --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="subr_sbuf.c.20010226.unified" ==== //depot/FreeBSD-adaptec/src/sys/kern/subr_sbuf.c#1 - /a/ken/perforce/FreeBSD-adaptec/src/sys/kern/subr_sbuf.c ==== --- /tmp/tmp.81267.0 Wed Feb 28 09:54:42 2001 +++ /a/ken/perforce/FreeBSD-adaptec/src/sys/kern/subr_sbuf.c Wed Feb 14 15:33:36 2001 @@ -29,14 +29,20 @@ */ #include +#include + +#ifdef _KERNEL #include #include -#include #include - #include +#else /* _KERNEL */ +#include +#endif /* _KERNEL */ +#ifdef _KERNEL MALLOC_DEFINE(M_SBUF, "sbuf", "string buffers"); +#endif /* _KERNEL */ /* * Predicates @@ -52,32 +58,38 @@ #define SBUF_SETFLAG(s, f) do { (s)->s_flags |= (f); } while (0) #define SBUF_CLEARFLAG(s, f) do { (s)->s_flags &= ~(f); } while (0) +#ifdef _KERNEL +#define SBASSERT(e, m) KASSERT(e, m) +#else /* _KERNEL */ +#define SBASSERT(e, m) +#endif /* _KERNEL */ + /* * Debugging support */ -#ifdef INVARIANTS +#if defined(_KERNEL) && defined(INVARIANTS) static void assert_sbuf_integrity(struct sbuf *s) { - KASSERT(s != NULL, + SBASSERT(s != NULL, (__FUNCTION__ " called with a NULL sbuf pointer")); - KASSERT(s->s_buf != NULL, + SBASSERT(s->s_buf != NULL, (__FUNCTION__ " called with unitialized or corrupt sbuf")); - KASSERT(s->s_len < s->s_size, + SBASSERT(s->s_len < s->s_size, ("wrote past end of sbuf (%d >= %d)", s->s_len, s->s_size)); } static void assert_sbuf_state(struct sbuf *s, int state) { - KASSERT((s->s_flags & SBUF_FINISHED) == state, + SBASSERT((s->s_flags & SBUF_FINISHED) == state, (__FUNCTION__ " called with %sfinished or corrupt sbuf", (state ? "un" : ""))); } -#else +#else /* _KERNEL && INVARIANTS */ #define assert_sbuf_integrity(s) do { } while (0) #define assert_sbuf_state(s, i) do { } while (0) -#endif +#endif /* _KERNEL && INVARIANTS */ /* * Initialize an sbuf. @@ -87,11 +99,11 @@ int sbuf_new(struct sbuf *s, char *buf, int length, int flags) { - KASSERT(length >= 0, + SBASSERT(length >= 0, ("attempt to create an sbuf of negative length (%d)", length)); - KASSERT(flags == 0, + SBASSERT(flags == 0, (__FUNCTION__ " called with non-zero flags")); - KASSERT(s != NULL, + SBASSERT(s != NULL, (__FUNCTION__ " called with a NULL sbuf pointer")); bzero(s, sizeof *s); @@ -100,7 +112,11 @@ s->s_buf = buf; return (0); } +#ifdef _KERNEL s->s_buf = malloc(s->s_size, M_SBUF, M_WAITOK); +#else /* _KERNEL */ + s->s_buf = (char *)malloc(s->s_size); +#endif /* _KERNEL */ if (s->s_buf == NULL) return (-1); SBUF_SETFLAG(s, SBUF_DYNAMIC); @@ -130,9 +146,9 @@ assert_sbuf_integrity(s); assert_sbuf_state(s, 0); - KASSERT(pos >= 0, + SBASSERT(pos >= 0, ("attempt to seek to a negative position (%d)", pos)); - KASSERT(pos < s->s_size, + SBASSERT(pos < s->s_size, ("attempt to seek past end of sbuf (%d >= %d)", pos, s->s_size)); if (pos < 0 || pos > s->s_len) @@ -175,6 +191,7 @@ return (sbuf_cat(s, str)); } +#if 0 /* * PCHAR function for sbuf_printf() */ @@ -193,6 +210,7 @@ else SBUF_SETFLAG(s, SBUF_OVERFLOWED); } +#endif /* * Format the given arguments and append the resulting string to an sbuf. @@ -206,17 +224,26 @@ assert_sbuf_integrity(s); assert_sbuf_state(s, 0); - KASSERT(fmt != NULL, + SBASSERT(fmt != NULL, (__FUNCTION__ " called with a NULL format string")); if (SBUF_HASOVERFLOWED(s)) return (-1); +#if 0 va_start(ap, fmt); len = kvprintf(fmt, _sbuf_pchar, s, 10, ap); va_end(ap); +#endif + va_start(ap, fmt); + len = vsnprintf(&s->s_buf[s->s_len], s->s_size - s->s_len, fmt, ap); + va_end(ap); + + s->s_len += len; + if (!SBUF_HASROOM(s)) + SBUF_SETFLAG(s, SBUF_OVERFLOWED); - KASSERT(s->s_len < s->s_size, + SBASSERT(s->s_len < s->s_size, ("wrote past end of sbuf (%d >= %d)", s->s_len, s->s_size)); if (SBUF_HASOVERFLOWED(s)) @@ -303,6 +330,10 @@ /* don't care if it's finished or not */ if (SBUF_ISDYNAMIC(s)) +#ifdef _KERNEL free(s->s_buf, M_SBUF); +#else /* _KERNEL */ + free(s->s_buf); +#endif /* _KERNEL */ bzero(s, sizeof *s); } --d6Gm4EdcadzBjdND-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 10:13:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4BC0A37B718 for ; Wed, 28 Feb 2001 10:13:15 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA15079 for ; Wed, 28 Feb 2001 10:13:11 -0800 Date: Wed, 28 Feb 2001 10:13:08 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: arch@freebsd.org Subject: lossage of a sort with using device hints... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm converting a driver over to using device hints instead of getenv_*, and one thing has stubbed my toe. The current resource types are: /* * Resources from config(8). */ typedef enum { RES_INT, RES_STRING, RES_LONG } resource_type; But I've been happily using a getenv_quad for a 64 bit WWN override. It strikes me that RES_INT and RES_LONG are too vague (as well as useless). How hard would it be to change these to RES_INT32 and RES_INT64? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 10:13:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (node16292.a2000.nl [24.132.98.146]) by hub.freebsd.org (Postfix) with ESMTP id CFA0A37B719; Wed, 28 Feb 2001 10:13:17 -0800 (PST) (envelope-from adrian@roaming.cacheboy.net) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f1SI96g40524; Wed, 28 Feb 2001 19:09:06 +0100 (CET) (envelope-from adrian) Date: Wed, 28 Feb 2001 19:09:06 +0100 From: Adrian Chadd To: Poul-Henning Kamp Cc: freebsd-fs@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: mount fixes, part 1 Message-ID: <20010228190906.B40480@roaming.cacheboy.net> References: <20010228113644.A39251@roaming.cacheboy.net> <34067.983356720@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <34067.983356720@critter>; from phk@critter.freebsd.dk on Wed, Feb 28, 2001 at 11:38:40AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 28, 2001, Poul-Henning Kamp wrote: > In message <20010228113644.A39251@roaming.cacheboy.net>, Adrian Chadd writes: > > >I am attempting to rework the VFS_MOUNT() vfsop to take kernel pointers, > >rather than userland pointers. > > struct uio ? Why would you bother with uio'ing path? :-) Perhaps the user data pointer could be uio'ed, but I haven't decided upon the best method to do this yet. I might rework the mount -p stuff.. Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 11: 1:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 494D937B718 for ; Wed, 28 Feb 2001 11:01:17 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA15272 for ; Wed, 28 Feb 2001 11:01:14 -0800 Date: Wed, 28 Feb 2001 11:01:07 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: arch@FreeBSD.ORG Subject: Re: lossage of a sort with using device hints... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It's actually worse for me.... setting hint.isp.0.portwnn="0x50000000aaaa0000" hint.isp.0.nodewnn="0x50000000aaaa0001" guarantees me to be broken in that this will be forced to be type 'int' or type 'long'- and neither will correctly convert- and I can't even coerce this directly to a string- so I have to do something like: hint.isp.0.portwnn="w50000000aaaa0000" hint.isp.0.nodewnn="w50000000aaaa0001" in order to get the string so I can then do a kernel strtouq on the portion past the 'w'... *phppptttttt* > > I'm converting a driver over to using device hints instead of > getenv_*, and one thing has stubbed my toe. The current resource types are: > > > /* > * Resources from config(8). > */ > typedef enum { > RES_INT, RES_STRING, RES_LONG > } resource_type; > > > > But I've been happily using a getenv_quad for a 64 bit WWN override. > > It strikes me that RES_INT and RES_LONG are too vague (as well as useless). > How hard would it be to change these to RES_INT32 and RES_INT64? > > -matt > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 11:44:30 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 757F237B71B for ; Wed, 28 Feb 2001 11:44:28 -0800 (PST) (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 f1SJeHl21989; Wed, 28 Feb 2001 11:40:17 -0800 (PST) (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: <200102280558.f1S5w9d19167@harmony.village.org> Date: Wed, 28 Feb 2001 11:43:49 -0800 (PST) From: John Baldwin To: Warner Losh Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h Cc: arch@FreeBSD.org, Matthew Jacob Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 28-Feb-01 Warner Losh wrote: > In message John Baldwin writes: >: I.e., each new sentence starts on a new line (to help with translation) and >: you mark up stuff. I'll try and look at this today or tomorrow for mdoc >: stuff. Though you probably want to send them off to ru, mpp, sheldonh, >: and/or >: asmodai as well. > > Actually, it occurred to me that doc@ might be a good place to send > doc review requests, no? Yes. > Warner -- 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 Feb 28 11:56:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (node16292.a2000.nl [24.132.98.146]) by hub.freebsd.org (Postfix) with ESMTP id 9657D37B71A; Wed, 28 Feb 2001 11:56:28 -0800 (PST) (envelope-from adrian@roaming.cacheboy.net) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f1SJvK040795; Wed, 28 Feb 2001 20:57:21 +0100 (CET) (envelope-from adrian) Date: Wed, 28 Feb 2001 20:57:20 +0100 From: Adrian Chadd To: freebsd-fs@FreeBSD.ORG Cc: freebsd-arch@FreeBSD.ORG Subject: Re: mount fixes, part 1 Message-ID: <20010228205720.A40748@roaming.cacheboy.net> References: <20010228113644.A39251@roaming.cacheboy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010228113644.A39251@roaming.cacheboy.net>; from adrian@FreeBSD.ORG on Wed, Feb 28, 2001 at 11:36:44AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 28, 2001, Adrian Chadd wrote: > > Hi, > > I'm running through and tidying up the mount interface, as promised. > My first set of patches aren't yet complete (there is at least one > documented strncpy() I have to fix up). Ok, I've updated the patch again. http://people.freebsd.org/~adrian/mount.diff I plan on committing it in the next day or so. Thanks! Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 12:54:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id DDC9E37B719; Wed, 28 Feb 2001 12:54:14 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id NAA26639; Wed, 28 Feb 2001 13:47:50 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAhKai.X; Wed Feb 28 13:45:30 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA05663; Wed, 28 Feb 2001 13:51:44 -0700 (MST) From: Terry Lambert Message-Id: <200102282051.NAA05663@usr05.primenet.com> Subject: Re: mount fixes, part 1 To: adrian@FreeBSD.ORG (Adrian Chadd) Date: Wed, 28 Feb 2001 20:51:43 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG In-Reply-To: <20010228113644.A39251@roaming.cacheboy.net> from "Adrian Chadd" at Feb 28, 2001 11:36:44 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It is my hope that eventually vfs_mount() and VFS_MOUNT() will not > use copyin*() at all. > > Comments are welcome. I'd like to commit this in the next couple of days > so I can continue with my VFS tidyups. Took a quick peek... I assume that this is to allow user space and kernel space code to be equivalent, for developing in user space? This works particularly well, because of descriptor calling for VOPs, less so for VFSOPs. Probably you will want to descriptorize the VFS switch entry points, and pass descriptors. Descriptors would have to be internalized, but that would happen outside the code, so it would eliminate "copyin*()" (I guess that sopinstr() is the worst of these, which is why you aren't using uio instead, even though uio in user space would take more work?). For this to work, you will need to seperate the mount creating a mounted file system list instance from the vnode covering, or you will find yourself unable to develop anything other than "VFS on top, VFS on bottom" modules in user space, and unable to mount more than one stacking layer deep. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 13:47:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 3CB1B37B71B for ; Wed, 28 Feb 2001 13:47:05 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f1SLkxm20678 for ; Wed, 28 Feb 2001 13:46:59 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: Unicode, command line options, and configuration files, oh my! Date: Wed, 28 Feb 2001 13:48:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How much change would be needed to have a Unicode-capable FreeBSD system? Supposing the variable-length encoding is used, all existing text output, filenames, and string-based kernel interfaces should be compliant (although not capable of understanding multiple-byte-char input/output); would command line options be passed as byte-strings by a Unicode-capable shell? There doesn't seem to be any impetus to systematically adopt Unicode (especially the fixed-two-bytes-per-char variant, which for most cases would simply double the storage/bandwidth requirement), although there are user-applications which operate on multibyte text. I am sure that by now admins and programmers in country XYZ are used to working with ASCII and pseudo-English (no matter how inconvenient it might be to generate from their keyboards). Presently, every program that has a configuration file has its own ad-hoc syntax (and code for twiddling it). People have often suggested using XML documents for configuration files (and some have even gone on to do so). Presumably the DTD would be inline or located according to some standard, so that a generic structured-editing-tool could be used to allow viewing/modification/syntax-checking without having to roll your own utilities. XML documents are allowed to use a number of character encodings (including variable and two-byte Unicode). XML parsers are widely available, although the truly compliant ones are several megabytes of code. The parser can either build you a tree-structure of the document, which you traverse, or, more sensibly, can traverse the tree implicitly for you as it parses, using callbacks you supply. You can also get text as ISO-whatever single-byte or multibyte. A subset of the XML standard would definitely suffice to fulfill existing needs, and it would be nice to have every program that has an XML configuration file using a shared library, which would ease any eventually addition of Unicode capability. However, there is a one-time cost (which I have not yet paid) in learning how to use XML instead of whatever you're used to (lex/yacc, or ad-hoc code), which is responsible for the reign of the status quo. I'm sure we all agree that there is no need to use XML, or even a subset of it, except to capitalize on existing parsers and editors. What is really needed is an easy-to-specify metadata format which can allow for structured editing of documents, and generation of parsers and syntax descriptions. Parsing of command line options (and positional parameters) is also largely ad-hoc. Looking through /usr/src, I see that for the most case, it consists of a getopt loop with hand-coded cases, a hand-written usage string, and a hand-written man-page-usage. Much like the XML DTD, it would make sense to generically specify (to the extent possible, and with user-defined code to the extent not) the syntax and semantics, and generate variable definitions, parsing/checking code, usage(), man page synopsis ... While it would be possible to have an expressive grammar for command line options, typically the -opts are order-independent, and there are only a few positional parameters (or else you put the mess into a configuration file). There are a variety of packages out there, which I am seeking opinions on, not having tried any of them: autoopts (part of autogen, sort of m4+scheme?, everything and the kitchen sink, environment variables/simple-config-files as well as command-line-options) at http://autogen.sourceforge.net/autoopts/ gengetopt (GNU, uses getopt_long - which we don't have in FreeBSD because getopt_long isn't LGPL? (Not that I think getopt_long is that brilliant, nor had I even noticed the lack of --recursive in my cp command ;) at http://www.gnu.org/software/gengetopt/gengetopt.html and ports/devel/gengetopt (generated code, including getopt_long, isn't restricted by any license?) genparse at http://genparse.sourceforge.net/ mkcmd (does manpage/usage/options) at ports/devel/mkcmd any others? ifconfig seemed to have one of the more enlightened-looking option parsers (an array of parameter information processed in a loop, rather than a bunch of hard-coded cases) out of several FreeBSD programs I examined ... are there any other good examples? It's also amusing to see how many different ways various servers in the tree can open a configuration file (path read from command line), write a pid file (path read from command line), daemonize, read an IP address/hostname and port (read from command line) and listen there, mask nonfatal signals, relinquish priveleges - although I appreciate that different servers want to do things slightly differently. Naturally, each of us is easily able to reuse our own code (preferably by libraries/macros/#include rather than copy/paste), but I think that there is a lot of common configuration/command-line code that could be coalesced behind a good-enough-extensible interface that we could reuse code on a larger scale. -- Jonathan Graehl email: jonathan@graehl.org web: http://jonathan.graehl.org/ phone: 858-642-7562 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 14: 8:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by hub.freebsd.org (Postfix) with ESMTP id 5D39B37B718 for ; Wed, 28 Feb 2001 14:08:23 -0800 (PST) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id OAA22216 for ; Wed, 28 Feb 2001 14:08:23 -0800 (PST) Received: from btc.btc.adaptec.com (btc.btc.adaptec.com [162.62.64.10]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id OAA22500 for ; Wed, 28 Feb 2001 14:00:39 -0800 (PST) Received: from btcexc01.btc.adaptec.com (btcexc01 [162.62.147.10]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id PAA25883 for ; Wed, 28 Feb 2001 15:08:20 -0700 (MST) Received: by btcexc01.btc.adaptec.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 15:08:21 -0700 Message-ID: From: "Long, Scott" To: "'freebsd-arch@freebsd.org'" Subject: Arch question for a UDF FS driver Date: Wed, 28 Feb 2001 15:08:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've starting writing a UDF FS driver for FreeBSD, and am coming to a decision point. UDF is somewhat similar to ufs in that a File Entry is analogous to an inode, so I'd like to implement the filesystem using the vget vfsop. Problem is that vget uses ino_t which is a uint32_t, while the Unique Id (aka inode number) for UDF is a uint64_t. Unique Id's are numbered sequentially starting at 16 (0 is the root dir, 1-15 are reserved), and may be sparse. So what color should I paint the bikeshed? Pink: Just pretend the UniqueId is 32 bits. If it is ever more than 32 bits, panic. Advantage: it's pretty hard to roll over 32 bits on a CD or DVD. Disadvantage: it's a gross hack. Muave: Don't implemenet it with vget. Advantage: no need to worry about the UniqueId. Disadvantage: harder to support some of the filesystem features, like hardlinks, once write support is done. Orange: Get ino_t bumped up to a uint64_t and modify all the other filesystems to deal with it accordingly. Advantage: no hackery needed for UDF. Disadvantage: may be the mother of all bikesheds. I prefer orange. Thanks for the advice. Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 14:35:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (node16292.a2000.nl [24.132.98.146]) by hub.freebsd.org (Postfix) with ESMTP id 2346F37B718 for ; Wed, 28 Feb 2001 14:35:28 -0800 (PST) (envelope-from adrian@roaming.cacheboy.net) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.1/8.11.1) id f1SMUiE41262; Wed, 28 Feb 2001 23:30:44 +0100 (CET) (envelope-from adrian) Date: Wed, 28 Feb 2001 23:30:44 +0100 From: Adrian Chadd To: "Long, Scott" Cc: "'freebsd-arch@freebsd.org'" Subject: Re: Arch question for a UDF FS driver Message-ID: <20010228233044.A41245@roaming.cacheboy.net> 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 scott_long@btc.adaptec.com on Wed, Feb 28, 2001 at 03:08:21PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Feb 28, 2001, Long, Scott wrote: > I've starting writing a UDF FS driver for FreeBSD, and am coming to a > decision point. UDF is somewhat similar to ufs in that a File Entry is > analogous to an inode, so I'd like to implement the filesystem using the > vget vfsop. Problem is that vget uses ino_t which is a uint32_t, while the > Unique Id (aka inode number) for UDF is a uint64_t. Unique Id's are > numbered sequentially starting at 16 (0 is the root dir, 1-15 are reserved), > and may be sparse. So what color should I paint the bikeshed? Orange. I like blue better, but you didn't give a blue option :) Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 17:11:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 1ED7F37B718 for ; Wed, 28 Feb 2001 17:11:17 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.1/8.11.1) with ESMTP id f211A3J01588; Wed, 28 Feb 2001 17:10:03 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.1/8.11.0) id f211A2843934; Wed, 28 Feb 2001 17:10:02 -0800 (PST) (envelope-from jdp) Date: Wed, 28 Feb 2001 17:10:02 -0800 (PST) Message-Id: <200103010110.f211A2843934@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Reply-To: arch@freebsd.org Cc: scott_long@btc.adaptec.com Subject: Re: Arch question for a UDF FS driver In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Long, Scott wrote: > I've starting writing a UDF FS driver for FreeBSD, and am coming to a > decision point. UDF is somewhat similar to ufs in that a File Entry is > analogous to an inode, so I'd like to implement the filesystem using the > vget vfsop. Problem is that vget uses ino_t which is a uint32_t, while the > Unique Id (aka inode number) for UDF is a uint64_t. Unique Id's are > numbered sequentially starting at 16 (0 is the root dir, 1-15 are reserved), > and may be sparse. So what color should I paint the bikeshed? [...] > Orange: Get ino_t bumped up to a uint64_t and modify all the other > filesystems to deal with it accordingly. Advantage: no hackery needed for > UDF. Disadvantage: may be the mother of all bikesheds. Unfortunately, values of type ino_t are passed from kernel to userland via the stat(2) family of system calls. So if you change the size of ino_t, it will change the shape of the stat structure. This would introduce binary compatibility problems. There would have to be yet another flavor of struct stat (we already have 3 of them in ), and some new system calls for the new versions of stat(), fstat(), and lstat(). I.e., you can't just change the existing system calls without totally breaking old binaries. It's not a total show-stopper, but it does make that shade of orange look kind of, er, puke colored. :-) John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 18: 3:32 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 C610637B719 for ; Wed, 28 Feb 2001 18:03:28 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id VAA94652; Wed, 28 Feb 2001 21:01:55 -0500 (EST) (envelope-from wollman) Date: Wed, 28 Feb 2001 21:01:55 -0500 (EST) From: Garrett Wollman Message-Id: <200103010201.VAA94652@khavrinen.lcs.mit.edu> To: scott_long@btc.adaptec.com Subject: Re: Arch question for a UDF FS driver X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: Organization: MIT Laboratory for Computer Science Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >Problem is that vget uses ino_t which is a uint32_t, while the >Unique Id (aka inode number) for UDF is a uint64_t. Hash the Unique Id into 31 bits (e.g., u_id % 2147483647). Renumber any collisions into the space above 2**31. You would still need to keep some state when there is a collision, but if the Ids are assigned sequentially then you are likely to win most of the time. I don't see what this has to do with vget(), however. -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 Wed Feb 28 20: 0:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by hub.freebsd.org (Postfix) with ESMTP id D102237B718 for ; Wed, 28 Feb 2001 20:00:23 -0800 (PST) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id TAA11797; Wed, 28 Feb 2001 19:59:49 -0800 (PST) Received: from btc.btc.adaptec.com (btc.btc.adaptec.com [162.62.64.10]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id TAA05590; Wed, 28 Feb 2001 19:52:05 -0800 (PST) Received: from btcexc01.btc.adaptec.com (btcexc01 [162.62.147.10]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id UAA28638; Wed, 28 Feb 2001 20:59:45 -0700 (MST) Received: by btcexc01.btc.adaptec.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 20:59:46 -0700 Message-ID: From: "Long, Scott" To: "'Garrett Wollman'" Cc: arch@freebsd.org Subject: RE: Arch question for a UDF FS driver Date: Wed, 28 Feb 2001 20:59:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hash the Unique Id into 31 bits (e.g., u_id % 2147483647). Renumber > any collisions into the space above 2**31. You would still need to > keep some state when there is a collision, but if the Ids are > assigned sequentially then you are likely to win most of the time. Interesting idea. Like I said, consuming 32 bits within the life of the filesystem is going to be pretty hard. > I don't see what this has to do with vget(), however. not vget() itself, the vget vfsop. Unless I'm totally clueless here, the vget vfsop is supposed to return the vnode that repesents the passed in ino_t. Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 20:32: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 51A2337B719 for ; Wed, 28 Feb 2001 20:32:27 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f214WNd45265; Wed, 28 Feb 2001 21:32:23 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103010432.f214WNd45265@harmony.village.org> To: mjacob@feral.com Subject: Re: lossage of a sort with using device hints... Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 28 Feb 2001 10:13:08 PST." References: Date: Wed, 28 Feb 2001 21:32:23 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : /* : * Resources from config(8). : */ : typedef enum { : RES_INT, RES_STRING, RES_LONG : } resource_type; : : : : But I've been happily using a getenv_quad for a 64 bit WWN override. : : It strikes me that RES_INT and RES_LONG are too vague (as well as useless). : How hard would it be to change these to RES_INT32 and RES_INT64? I think this is a great idea, in theory, and will take a look at changing them in the affacted places. I'll let you know how hard it turns out to be. Also, in my original "hints" implementation, numbers had to be preceeded by a # sign. I'll see what can be done to preserve values here. It might make sense to grab all numbers as 64 bit quantities with strtoll[u]. Or maybe it makes sense to just store everything as a string and have the resource_*_value function tease a meaning out of the string when called. There's not a performance hit for doing that since most values are querried only once or twice... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 20:45:12 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 B1C9437B71B for ; Wed, 28 Feb 2001 20:45:07 -0800 (PST) (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 PAA07197; Thu, 1 Mar 2001 15:44:50 +1100 Date: Thu, 1 Mar 2001 15:44:38 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Michael Sinz Cc: "Duane H. Hesser" , Randell Jesup , "(Bruce Bauman)" , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: ELF and diskless boot In-Reply-To: <3A9D246B.D254796B@wgate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Feb 2001, Michael Sinz wrote: > The real issue, however, is that external tools are using internal symbols > rather than public interfaces. sysctl is the real way to do this but > even without sysctl, public interfaces for things like top/etc. should > be somehow designated as "public" or even "semi-public". As it is, if two Sysctl just doesn't work for dead kernels. The symbols must be in the kernel executable (or somewhere) so that ps, etc. can find them. (top is not in "etc." here because it doesn't support dead kernels, and since its main purpose is presenting a real-time display, making it work on dead kernels wouldn't be very useful. Similarly for systat.) All symbols, including fully debugging symbols, must be available somewhere for debugging dead kernels. > source files happen to have the same named static variable (which is > perfectly legal and part of what static keyword provides) the lookup will > "randomly" return one of them. (Randomly in this case depends on the link > order) Good point, but again support for debugging makes it moot. Kernel symbols should be unique so that they can be distinguished by simple debuggers like ddb and types easily in full debuggers. > BTW - I agree that the ddb kernel needs its internal symbols. But that is > debugging and not operational behavior. If you issue the command: > > strip kernel > > The end result should work just as well for production use as a non-stripped > kernel. (Yes, debugging is not as good, but that is not what we are talking > about) There's no reason that should work better than stripping the text section. The kernel Makefile issues all the strip commands that can be done easily and are safe. It's just not worth the effort to strip more. The extras just waste 5c worth of disk space and a few msec of booting time. > > > As far as Elf raising the bar goes, it does a better job of separating > > > external vs internal symbols. Making the loaders provide access to all > > > symbols is not the correct solution. The correct solution is to have > > > any symbols that are defined for "external access" to be defined as such. > > > > I disagree. Exporting bits of the kernel using linker symbols isn't > > the correct solution for anything except possibly for examining dead > > kernels, but it's easy to use. Loaders need to support all symbols > > for other reasons. > > The linker symbols (external ones) are the way shared libraries link to > each other. This is the defined mechanism. Now, it is not the best for Don't get me started on the evilness of shared libraries :-). > > > BTW - there is little to prevent a compiler from doing nasty optimizations > > > with variables that are marked "static" since it has full knowledge of the > > > scope of thos variables (or at least it thinks it does since it has been > > > told so in the source) But this is a different issue and does not currently > > affect GCC/x86 systems for various reasons. > > > > Similarly for all symbols if the linker is part of the compiler and > > understands the scope of everything. > > I agree (and have worked with compilers that do that) which is even more > reason to define which objects/symbols/etc are part of the public interface > and which are internal use only. The current (4.x) system does not provide > any way of doing so and has tools (top/vmstat/etc) that depend on access > to a variety of symbols that are not obviously exported for direct access. Regrading to 2.x would bring back support for symbols.raw which is supposed to list all "public" symbols. This file rotted before 2.x. > (And sometimes even have comments saying that they should not be, as in > FSCALE... That is, if I read that comment correctly.) I think that comment is mostly out of date now. ps uses only the kern.fscale sysctl. However, this seems to weaken ps's support for dead kernels. There are some even more cryptically exported symbols for supporting gdb on dead kernels. Some of them are in symbols.raw, but the easiest way to find out about them is to try removing them. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 21:11:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 5E88B37B719 for ; Wed, 28 Feb 2001 21:11:21 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id WAA10662; Wed, 28 Feb 2001 22:04:57 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAKSayJt; Wed Feb 28 22:03:48 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA16907; Wed, 28 Feb 2001 22:10:06 -0700 (MST) From: Terry Lambert Message-Id: <200103010510.WAA16907@usr05.primenet.com> Subject: Re: Arch question for a UDF FS driver To: scott_long@btc.adaptec.com (Long, Scott) Date: Thu, 1 Mar 2001 05:10:06 +0000 (GMT) Cc: wollman@khavrinen.lcs.mit.edu ('Garrett Wollman'), arch@FreeBSD.ORG In-Reply-To: from "Long, Scott" at Feb 28, 2001 08:59:46 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Hash the Unique Id into 31 bits (e.g., u_id % 2147483647). Renumber > > any collisions into the space above 2**31. You would still need to > > keep some state when there is a collision, but if the Ids are > > assigned sequentially then you are likely to win most of the time. > > Interesting idea. Like I said, consuming 32 bits within the life of the > filesystem is going to be pretty hard. > > > I don't see what this has to do with vget(), however. > > not vget() itself, the vget vfsop. Unless I'm totally clueless here, the > vget vfsop is supposed to return the vnode that repesents the passed in > ino_t. The question to ask yourself is "under what circumstances do I care about the ino_t?". My personal take would be to appeal to the Apple people here, since they have already implemented one of these things, and know how they did it, and the technical reasons why. My gut reaction would be to give ownership of the vnodes to the FS itself, and ignore the problem (search for the string "TFS" in the FS releated kernel code to see what I mean). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 21:22: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from syncopation-01.iinet.net.au (syncopation-01.iinet.net.au [203.59.24.37]) by hub.freebsd.org (Postfix) with SMTP id 3E7A937B71C for ; Wed, 28 Feb 2001 21:22:06 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 7099 invoked by uid 666); 1 Mar 2001 05:33:06 -0000 Received: from i074-222.nv.iinet.net.au (HELO elischer.org) (203.59.74.222) by mail.m.iinet.net.au with SMTP; 1 Mar 2001 05:33:06 -0000 Message-ID: <3A9DDC76.3B749D83@elischer.org> Date: Wed, 28 Feb 2001 21:21:58 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Long, Scott" Cc: "'freebsd-arch@freebsd.org'" Subject: Re: Arch question for a UDF FS driver References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Long, Scott" wrote: I already have some UDF work. let's talk.. > > I've starting writing a UDF FS driver for FreeBSD, and am coming to a > decision point. UDF is somewhat similar to ufs in that a File Entry is > analogous to an inode, so I'd like to implement the filesystem using the > vget vfsop. Problem is that vget uses ino_t which is a uint32_t, while the > Unique Id (aka inode number) for UDF is a uint64_t. Unique Id's are > numbered sequentially starting at 16 (0 is the root dir, 1-15 are reserved), > and may be sparse. So what color should I paint the bikeshed? > > Pink: Just pretend the UniqueId is 32 bits. If it is ever more than 32 > bits, panic. Advantage: it's pretty hard to roll over 32 bits on a CD or > DVD. Disadvantage: it's a gross hack. > > Muave: Don't implemenet it with vget. Advantage: no need to worry about > the UniqueId. Disadvantage: harder to support some of the filesystem > features, like hardlinks, once write support is done. > > Orange: Get ino_t bumped up to a uint64_t and modify all the other > filesystems to deal with it accordingly. Advantage: no hackery needed for > UDF. Disadvantage: may be the mother of all bikesheds. > > I prefer orange. Thanks for the advice. > > Scott > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 21:41:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id E9C9137B719 for ; Wed, 28 Feb 2001 21:41:39 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id WAA01644; Wed, 28 Feb 2001 22:36:25 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAIraOcd; Wed Feb 28 22:36:11 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA17385; Wed, 28 Feb 2001 22:41:22 -0700 (MST) From: Terry Lambert Message-Id: <200103010541.WAA17385@usr05.primenet.com> Subject: Re: Unicode, command line options, and configuration files, oh my! To: jonathan@graehl.org (Jonathan Graehl) Date: Thu, 1 Mar 2001 05:41:22 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG (freebsd-Arch) In-Reply-To: from "Jonathan Graehl" at Feb 28, 2001 01:48:49 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ ... Unicode ... ] UTF encoded data is not fixed length in size. POSIX specifies that file names can be up to 256 characters. 256 characters UTF-8 encoded can vary from 256 to 1280 characters. In general, this means that for Unicode data stored for directory entries would require that a directory entry block would have to be 512b, whereas for UTF-8, we are talking 2048b (2k). If the same approach is used as the current UFS code uses, then these operations will need to be directory entry block atomic. FS stuff aside, most programs should use internal encoding. For FS storage, fixed data records are also a problem, when using UTF-8 encoding. The same goes for the ability to store fixed size input forms field data in databases, which like constraints set on record sizes. > There doesn't seem to be any impetus to systematically adopt > Unicode (especially the fixed-two-bytes-per-char variant, > which for most cases would simply double the storage/bandwidth > requirement), although there are user-applications which > operate on multibyte text. UTF-8 is one character per byte for US ASCII, two bytes for the high page (128 characters) of ISO 8859-1, and three or more bytes for anything else. The idea that storage requirements increase is U.S. centric; all other character sets are penalized at least as much as if it were directly encoded instead of multibyte encoded, and the vast majority more penalized. On top of that, we have Microsoft and Java interoperability to consider, distasteful as that may be to some. There's an interesting list of Unicode resources available at: http://www.unicode.org/unicode/onlinedat/products.html Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 21:59:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id B7BC537B718; Wed, 28 Feb 2001 21:59:19 -0800 (PST) (envelope-from keichii@peorth.iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id 445625955B; Wed, 28 Feb 2001 23:59:25 -0600 (CST) Date: Wed, 28 Feb 2001 23:59:25 -0600 From: "Michael C . Wu" To: Jonathan Graehl Cc: freebsd-Arch , i18n@freebsd.org Subject: Re: Unicode, command line options, and configuration files, oh my! Message-ID: <20010228235925.B4359@peorth.iteration.net> Reply-To: "Michael C . Wu" Mail-Followup-To: "Michael C . Wu" , Jonathan Graehl , freebsd-Arch , i18n@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 jonathan@graehl.org on Wed, Feb 28, 2001 at 01:48:49PM -0800 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG People, there is an freebsd-i18n@freebsd.org for a reason. On Wed, Feb 28, 2001 at 01:48:49PM -0800, Jonathan Graehl scribbled: | How much change would be needed to have a Unicode-capable FreeBSD system? A lot. and a lot more. | Supposing the variable-length encoding is used, all existing text output, | filenames, and string-based kernel interfaces should be compliant (although not No, they are not that easy. | capable of understanding multiple-byte-char input/output); would command line | options be passed as byte-strings by a Unicode-capable shell? No. | There doesn't seem to be any impetus to systematically adopt Unicode (especially | the fixed-two-bytes-per-char variant, which for most cases would simply double | the storage/bandwidth requirement), although there are user-applications which Not that easy :) Trust me. | operate on multibyte text. I am sure that by now admins and programmers in | country XYZ are used to working with ASCII and pseudo-English (no matter how | inconvenient it might be to generate from their keyboards). It is the "assuming" part that got us in this I18N dilemma. | [snip XML] I really do not think using XML is the way to go, too much crud. The K.I.S.S. principle should prevail here, especially in kernelland. | Parsing of command line options (and positional parameters) is also largely | ad-hoc. Looking through /usr/src, I see that for the most case, it consists of | a getopt loop with hand-coded cases, a hand-written usage string, and a | hand-written man-page-usage. Much like the XML DTD, it would make sense to | generically specify (to the extent possible, and with user-defined code to the | extent not) the syntax and semantics, and generate variable definitions, | parsing/checking code, usage(), man page synopsis ... While it would be Do you realize that this means a rewrite for the 300mb of the src/ that we have now? | possible to have an expressive grammar for command line options, typically | the -opts are order-independent, and there are only a few positional parameters | (or else you put the mess into a configuration file). There are a variety of | packages out there, which I am seeking opinions on, not having tried any of | them: | [snip *freshmeat* stuff] I have looked at those, not suitable, and they are GPL. | any others? | | ifconfig seemed to have one of the more enlightened-looking option parsers (an | array of parameter information processed in a loop, rather than a bunch of Because it needs to parse many many things. But why do you need so called "smart" parsers when you only have one or two options to parse? | hard-coded cases) out of several FreeBSD programs I examined ... are there any | other good examples? ipfilter. | It's also amusing to see how many different ways various servers in the tree can | open a configuration file (path read from command line), write a pid file (path | read from command line), daemonize, read an IP address/hostname and port (read | from command line) and listen there, mask nonfatal signals, relinquish It happens in a large code base. However, to rewrite all of that takes many many man-hours. I really do not think we are up to that. | priveleges - although I appreciate that different servers want to do things | slightly differently. Naturally, each of us is easily able to reuse our own | code (preferably by libraries/macros/#include rather than copy/paste), but I | think that there is a lot of common configuration/command-line code that could | be coalesced behind a good-enough-extensible interface that we could reuse code Glad to hear that people care about I18N. -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 22: 2: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id AE32C37B719; Wed, 28 Feb 2001 22:02:01 -0800 (PST) (envelope-from keichii@peorth.iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id 96CE85955B; Thu, 1 Mar 2001 00:02:07 -0600 (CST) Date: Thu, 1 Mar 2001 00:02:07 -0600 From: "Michael C . Wu" To: Terry Lambert Cc: Jonathan Graehl , freebsd-Arch , i18n@freebsd.org Subject: Re: Unicode, command line options, and configuration files, oh my! Message-ID: <20010301000207.C4359@peorth.iteration.net> Reply-To: "Michael C . Wu" Mail-Followup-To: "Michael C . Wu" , Terry Lambert , Jonathan Graehl , freebsd-Arch , i18n@freebsd.org References: <200103010541.WAA17385@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103010541.WAA17385@usr05.primenet.com>; from tlambert@primenet.com on Thu, Mar 01, 2001 at 05:41:22AM +0000 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Use -i18n please. ") On Thu, Mar 01, 2001 at 05:41:22AM +0000, Terry Lambert scribbled: | [ ... Unicode ... ] | | UTF encoded data is not fixed length in size. | | POSIX specifies that file names can be up to 256 characters. | | 256 characters UTF-8 encoded can vary from 256 to 1280 | characters. | | In general, this means that for Unicode data stored for | directory entries would require that a directory entry | block would have to be 512b, whereas for UTF-8, we are | talking 2048b (2k). | | If the same approach is used as the current UFS code uses, | then these operations will need to be directory entry block | atomic. In short, we can save the file name that the user sees with the file data. The filesystem and the kernel sees some other naming scheme determined by the FS/kernel. | FS stuff aside, most programs should use internal encoding. | | For FS storage, fixed data records are also a problem, when | using UTF-8 encoding. The same goes for the ability to | store fixed size input forms field data in databases, which | like constraints set on record sizes. | | | > There doesn't seem to be any impetus to systematically adopt | > Unicode (especially the fixed-two-bytes-per-char variant, | > which for most cases would simply double the storage/bandwidth | > requirement), although there are user-applications which | > operate on multibyte text. | | UTF-8 is one character per byte for US ASCII, two bytes for | the high page (128 characters) of ISO 8859-1, and three or more | bytes for anything else. Bad design. period. | The idea that storage requirements increase is U.S. centric; | all other character sets are penalized at least as much as if | it were directly encoded instead of multibyte encoded, and | the vast majority more penalized. Yup, bad design. :) | On top of that, we have Microsoft and Java interoperability to | consider, distasteful as that may be to some. M$ has a pretty good implementation here. Java I18N sucks really bad. | There's an interesting list of Unicode resources available at: | http://www.unicode.org/unicode/onlinedat/products.html -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 22:45:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from areilly.bpc-users.org (CPE-144-132-234-126.nsw.bigpond.net.au [144.132.234.126]) by hub.freebsd.org (Postfix) with SMTP id 8DA3537B71A for ; Wed, 28 Feb 2001 22:45:14 -0800 (PST) (envelope-from areilly@bigpond.net.au) Received: (qmail 65096 invoked by uid 1000); 1 Mar 2001 06:45:13 -0000 From: "Andrew Reilly" Date: Thu, 1 Mar 2001 17:45:13 +1100 To: "Michael C . Wu" Cc: Terry Lambert , Jonathan Graehl , freebsd-Arch , i18n@FreeBSD.ORG Subject: Re: Unicode, command line options, and configuration files, oh my! Message-ID: <20010301174513.A65013@gurney.reilly.home> References: <200103010541.WAA17385@usr05.primenet.com> <20010301000207.C4359@peorth.iteration.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010301000207.C4359@peorth.iteration.net>; from keichii@iteration.net on Thu, Mar 01, 2001 at 12:02:07AM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 01, 2001 at 12:02:07AM -0600, Michael C . Wu wrote: > Terry wrote: > | In general, this means that for Unicode data stored for > | directory entries would require that a directory entry > | block would have to be 512b, whereas for UTF-8, we are > | talking 2048b (2k). It would still have to be larger than 512b using a 16-bit encoding, wouldn't it? > | If the same approach is used as the current UFS code uses, > | then these operations will need to be directory entry block > | atomic. > > In short, we can save the file name that the user sees > with the file data. The filesystem and the kernel sees > some other naming scheme determined by the FS/kernel. How do you propose to do that and still maintain Unix inode/link semantics? There isn't (necessarily) only one file name that the user sees, but there _is_ only one lump of file data. > | On top of that, we have Microsoft and Java interoperability to > | consider, distasteful as that may be to some. > > M$ has a pretty good implementation here. > Java I18N sucks really bad. Could you give a quick description of why one of these is good and the other bad, for the bennefit of someone who knows neither? -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 23:21: 5 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 0924937B719 for ; Wed, 28 Feb 2001 23:21:01 -0800 (PST) (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 SAA25445; Thu, 1 Mar 2001 18:20:54 +1100 Date: Thu, 1 Mar 2001 18:20:50 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Matthew Jacob Cc: arch@FreeBSD.ORG Subject: Re: lossage of a sort with using device hints... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Feb 2001, Matthew Jacob wrote: > It's actually worse for me.... > > setting > > hint.isp.0.portwnn="0x50000000aaaa0000" > hint.isp.0.nodewnn="0x50000000aaaa0001" > > guarantees me to be broken in that this will be forced to be type 'int' or > type 'long'- and neither will correctly convert- and I can't even coerce this > directly to a string- so I have to do something like: I think it is not fundamentally broken for type 'long' on machines with >=64 bit longs, but subr_bus.c:resource_find_hard() is missing support for longs. It uses strtoul() to convert the string to a number and then blindly assigns the number to an int. It also ignores range errors reported by strtoul(), of course. There may also be sign extension problems. There are no resource types for unsigned C types, so longs are abused to hold u_longs, etc. This probably works on 2's-complement machines. There are also problems with initializing the union in `struct config_resource'. We put `longval' first because C90 only supports initializing the first member of a union and we want to initialize as many bits as possible, but longs might be too small to represent pointers or too large to represent pointers as initializers (the gnu toolchain can't handle converting 32-bit pointers to 64-bit ints). I use the following "fix": --- Index: bus_private.h =================================================================== RCS file: /home/ncvs/src/sys/sys/bus_private.h,v retrieving revision 1.17 diff -c -1 -r1.17 bus_private.h *** bus_private.h 2000/11/09 10:21:23 1.17 --- bus_private.h 2000/11/10 09:57:19 *************** *** 68,70 **** union { ! long longval; int intval; --- 68,70 ---- union { ! intptr_t longval; /* sic */ int intval; --- > hint.isp.0.portwnn="w50000000aaaa0000" > hint.isp.0.nodewnn="w50000000aaaa0001" > > in order to get the string so I can then do a kernel strtouq on the portion > past the 'w'... *phppptttttt* Try changing resource_find_hard() to produce a RES_LONG instead of a RES_INT. > > > > I'm converting a driver over to using device hints instead of > > getenv_*, and one thing has stubbed my toe. The current resource types are: > > > > > > /* > > * Resources from config(8). > > */ > > typedef enum { > > RES_INT, RES_STRING, RES_LONG > > } resource_type; > > > > But I've been happily using a getenv_quad for a 64 bit WWN override. > > > > It strikes me that RES_INT and RES_LONG are too vague (as well as useless). > > How hard would it be to change these to RES_INT32 and RES_INT64? Fairly hard, and backwards. You would have to fix the abovementioned problems in the gnu toolchain for RES_INT64 to work right on i386's. Fixed-width types are even less appropriate than int/long in most places, including here. Non-vague types would be typedefed types like vm_offset_t for memory addresses, etc. I think we don't need fully typedefed types for hints (just use uintmax_t for all numeric values), but they might be worth it for resource_foo_t_value(). BTW, resource_long_value() isn't used anywhere. This is probably an i386ism (resource_long_value() is useless when sizeof(int) == sizeof(long)). This is a bug in "machine-independent" code link /sys/isa/isahint.c (it uses resource_int_value() for memory addresses...). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 28 23:27: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 952E037B71A for ; Wed, 28 Feb 2001 23:26:59 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA17712; Wed, 28 Feb 2001 23:26:48 -0800 Date: Wed, 28 Feb 2001 23:26:46 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: lossage of a sort with using device hints... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think it is not fundamentally broken for type 'long' on machines with > >=64 bit longs, but subr_bus.c:resource_find_hard() is missing support > for longs. It uses strtoul() to convert the string to a number and then > blindly assigns the number to an int. It also ignores range errors > reported by strtoul(), of course. But the main point here is that one doesn't really want longs- one wants the size one wants, or one wants the string. > > hint.isp.0.portwnn="w50000000aaaa0000" > > hint.isp.0.nodewnn="w50000000aaaa0001" > > > > in order to get the string so I can then do a kernel strtouq on the portion > > past the 'w'... *phppptttttt* > > Try changing resource_find_hard() to produce a RES_LONG instead of a > RES_INT. I don't believe this will help for anytihing but alpha, will it? > > > > > > I'm converting a driver over to using device hints instead of > > > getenv_*, and one thing has stubbed my toe. The current resource types are: > > > > > > > > > /* > > > * Resources from config(8). > > > */ > > > typedef enum { > > > RES_INT, RES_STRING, RES_LONG > > > } resource_type; > > > > > > But I've been happily using a getenv_quad for a 64 bit WWN override. > > > > > > It strikes me that RES_INT and RES_LONG are too vague (as well as useless). > > > How hard would it be to change these to RES_INT32 and RES_INT64? > > Fairly hard, and backwards. You would have to fix the abovementioned > problems in the gnu toolchain for RES_INT64 to work right on i386's. > Fixed-width types are even less appropriate than int/long in most places, > including here. Non-vague types would be typedefed types like > vm_offset_t for memory addresses, etc. I think we don't need fully > typedefed types for hints (just use uintmax_t for all numeric values), > but they might be worth it for resource_foo_t_value(). > > BTW, resource_long_value() isn't used anywhere. This is probably an > i386ism (resource_long_value() is useless when sizeof(int) == sizeof(long)). > This is a bug in "machine-independent" code link /sys/isa/isahint.c > (it uses resource_int_value() for memory addresses...). Memory addresses on ISA? Tsk... < 16MB... I'm now inclined to think that RES_INT (unsized) an RES_STRING is sufficient as long as you can coerce RES_STRING. The general usage of integers for hints will satisfy most drivers that will use this stuff. The strings can then be interpreted as need be- it's not really that bad in FreeBSD because there's a very rich set of C-library like functions. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 1:33:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id B75D437B71A for ; Thu, 1 Mar 2001 01:33:39 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id BAA24982; Thu, 1 Mar 2001 01:33:13 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda24980; Thu Mar 1 01:32:55 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f219WiW24625; Thu, 1 Mar 2001 01:32:44 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdi24623; Thu Mar 1 01:32:23 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.3/8.9.1) id f219WK781344; Thu, 1 Mar 2001 01:32:20 -0800 (PST) Message-Id: <200103010932.f219WK781344@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdR81241; Thu Mar 1 01:32:02 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: FreeBSD sources from 20000' In-reply-to: Your message of "Tue, 27 Feb 2001 13:36:49 +0200." <200102271136.f1RBa4R12865@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Mar 2001 01:32:01 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102271136.f1RBa4R12865@gratis.grondar.za>, Mark Murray writes: > Hello all. > > There was a pretty good response to my initial probe a few days > ago, so the time comes by to revive the discussion, and to slowly > begin on the path to an actual solution. > > REMINDER REMINDER - The whole point of this exercise is NOT to > remove ANYTHING from FreeBSD. Effectively, FreeBSD will become a > grow-only system with the configuration and installation policies > placed in the hands of the owners or sysadmins. By "grow-only", I > do not mean we cannot throw out the trash; it just means that > arguments such as "please don't remove UUCP" or "please remove the > r-utils" are largely irrelevant. You have some good ideas and I agree with you in principle. Regarding "trash", some of us may consider "r" commands or "UUCP" as trash, or more specifically "bloat". Bloat in the CVS tree doesn't necessarily equate to bloat in the resulting tree. What I may consider bloat at work, e.g. "r" commands, v.s. may not be bloat on my network at home. Separate configurations (XML or otherwise) would allow me, FreeBSD Inc., my employer, etc., to define FreeBSD what is installed. From a 11,000 metre (35,000 ft.) level, I think you're on the mark. As we get down to the 1.5 metre (5 ft.) level we may find that the concept might not work well in practice as we like, e.g. the line needs to be drawn somewhere otherwise we will continually define what we intend to do yet not accomplish anything or the project is so big it will take 400 years to complete. Please continue to flesh out your idea. If we (the Royal We) debate this objectively, I'm sure we (the Royal We) can develop a plan that would satisfy the majority (70-70%) of the FreeBSD community, assuming we techies (this is the manager in me speaking) try not to "develop" or even "design" it before we define what it is that this is supposed to look like. This is a promising idea, therefore I'd like to suggest that a group of people, no more than 5, 10, or even 20, work on this together. The group will be able to come to consensus more quicly and easily than the hundreds that are subscribed to this list, fleshing out a definition and subsequently design, which will have considered more angles than just one person and be defended by the team of individuals who has developed the idea (as opposed to what usually happens on this list) when it is presented to this list for final discussion and approval. I don't want to see this go down in flames due to arguing about the colour of the bikeshed. So far so good. I like what I see. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 1:46:39 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 5AEC137B718 for ; Thu, 1 Mar 2001 01:46:35 -0800 (PST) (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 UAA03617; Thu, 1 Mar 2001 20:46:28 +1100 Date: Thu, 1 Mar 2001 20:46:23 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Matthew Jacob Cc: arch@FreeBSD.ORG Subject: Re: lossage of a sort with using device hints... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Feb 2001, Matthew Jacob wrote: [bde wrote] > > I think it is not fundamentally broken for type 'long' on machines with > > >=64 bit longs, but subr_bus.c:resource_find_hard() is missing support > > for longs. It uses strtoul() to convert the string to a number and then > > blindly assigns the number to an int. It also ignores range errors > > reported by strtoul(), of course. > > But the main point here is that one doesn't really want longs- one wants the > size one wants, or one wants the string. One also wants error checking. The main point of having central handling of the conversion instead of making everything convert the string is to centralize the error handling. > > > hint.isp.0.portwnn="w50000000aaaa0000" > > > hint.isp.0.nodewnn="w50000000aaaa0001" > > > > > > in order to get the string so I can then do a kernel strtouq on the portion > > > past the 'w'... *phppptttttt* > > > > Try changing resource_find_hard() to produce a RES_LONG instead of a > > RES_INT. > > I don't believe this will help for anytihing but alpha, will it? No. i386's currently just don't support resource values with size > 32 bits. You mentioned a need for 128 bits in other mail. This would have to be handled as a string. Perhaps the same for > 32 bits or at least for > sizeof(long) bytes. > > BTW, resource_long_value() isn't used anywhere. This is probably an > > i386ism (resource_long_value() is useless when sizeof(int) == sizeof(long)). > > This is a bug in "machine-independent" code link /sys/isa/isahint.c > > (it uses resource_int_value() for memory addresses...). > > Memory addresses on ISA? Tsk... < 16MB... Is there a standard for isa memory addresses? They could be mapped anywhere. Another problem with resource_*_value() is that resource_long_value() doesn't return "int" resources although it could. The caller has to know the type. > I'm now inclined to think that RES_INT (unsized) an RES_STRING is sufficient > as long as you can coerce RES_STRING. The general usage of integers for hints > will satisfy most drivers that will use this stuff. The strings can then be > interpreted as need be- it's not really that bad in FreeBSD because there's a > very rich set of C-library like functions. I agree. The set is too rich :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 3: 3:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 525BC37B71A for ; Thu, 1 Mar 2001 03:03:40 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id DAA25363; Thu, 1 Mar 2001 03:03:13 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda25361; Thu Mar 1 03:02:57 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f21B2pY56572; Thu, 1 Mar 2001 03:02:51 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdM56462; Thu Mar 1 03:02:27 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.3/8.9.1) id f21B2N621253; Thu, 1 Mar 2001 03:02:23 -0800 (PST) Message-Id: <200103011102.f21B2N621253@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdQ20986; Thu Mar 1 03:01:45 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: /dev/null@primenet.com Cc: drosih@rpi.edu (Garance A Drosihn), arch@FreeBSD.ORG Subject: Re: rand(3): enough already! In-reply-to: Your message of "Wed, 28 Feb 2001 07:36:46 GMT." <200102280736.AAA19304@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Mar 2001 03:01:45 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200102280736.AAA19304@usr05.primenet.com>, Terry Lambert writes: > A bit of a stretch, but... > > Could we just teach people to type "rand()" when they wanted > "rand()", and "random()" when they wanted "random()"? If I put my manager's hat on, yes this sounds reasonable. However both of use know better, clueless users use software written by clueless developers. I'm not adverse to keeping rand() as long as we have a secure default and those who want to configure their systems like traditional UNIX systems do so knowing full well what they are doing, and that we've addressed bloat (see the thread entitled " FreeBSD sources from 20000" by Mark Murray . [Like a fine wine I'm mellowing with age, oops I don't have my security administrator's hat on. :) ] > > I know, I know, this is like expecting people to type something > other than "read()" when they want to output data; still, it > might be worth considering. > > "Oh dear, my parcheesi program which uses "read()" to do output > on Linux isn't working on FreeBSD! Let's fix libc!". Sometimes management solutions work, sometimes they don't. If I put my manager's hat on, I might just agree with you (or just not understand you), however putting my propeller hat on, I think you're overreacting in these last two paragraphs. Management solutions, e.g. teaching or hiding our heads in the sand, don't always work -- I don't think they will work here either. If removing rand() or having rand() call random() is not politically feasible I might understand you from a management or political (selling FreeBSD to the Linux and NT masses) perspective but from a purely technical perspective your arguments don't make sense. (God, I hate wearing so many hats). Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 5: 7:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id DA46A37B718 for ; Thu, 1 Mar 2001 05:07:32 -0800 (PST) (envelope-from msinz@wgate.com) Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152C7MWG; Thu, 1 Mar 2001 08:07:42 -0500 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.1/8.11.1) with ESMTP id f21D7Sk46548; Thu, 1 Mar 2001 08:07:29 -0500 (EST) (envelope-from msinz@wgate.com) Message-ID: <3A9E4990.ACE5EF50@wgate.com> Date: Thu, 01 Mar 2001 08:07:28 -0500 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: "Duane H. Hesser" , Randell Jesup , "(Bruce Bauman)" , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: ELF and diskless boot References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > > On Wed, 28 Feb 2001, Michael Sinz wrote: > > > The real issue, however, is that external tools are using internal symbols > > rather than public interfaces. sysctl is the real way to do this but > > even without sysctl, public interfaces for things like top/etc. should > > be somehow designated as "public" or even "semi-public". As it is, if two > > Sysctl just doesn't work for dead kernels. The symbols must be in > the kernel executable (or somewhere) so that ps, etc. can find them. > (top is not in "etc." here because it doesn't support dead kernels, > and since its main purpose is presenting a real-time display, making > it work on dead kernels wouldn't be very useful. Similarly for systat.) > All symbols, including fully debugging symbols, must be available > somewhere for debugging dead kernels. Like I said elsewhere - debugging (and debugging a dead kernel would fall into that catagory) is very different than the act of handling active systems. You seem to be very caught up on the "debugging dead kernels" which, while very important when kernel hacking (of which I have done my fair share, past and present) I do not see how that relates to operational use of a system. Plus, there is nothing that states that ps/top/etc can not have access to some public symbol that is the sysctl list when the kernel is dead. However, depending on such "open kemono" system structures for operational use (ps is an operational tool more so than a debug dead kernel tool) just begs for problems as the system grows and evolves. > > source files happen to have the same named static variable (which is > > perfectly legal and part of what static keyword provides) the lookup will > > "randomly" return one of them. (Randomly in this case depends on the link > > order) > > Good point, but again support for debugging makes it moot. Kernel > symbols should be unique so that they can be distinguished by simple > debuggers like ddb and types easily in full debuggers. So, in a large project I would need to make sure that I never use a name for a static symbol that some other file has already used? How does that get solved long term? It would seem to me that > > > BTW - I agree that the ddb kernel needs its internal symbols. But that is > > debugging and not operational behavior. If you issue the command: > > > > strip kernel > > > > The end result should work just as well for production use as a non-stripped > > kernel. (Yes, debugging is not as good, but that is not what we are talking > > about) > > There's no reason that should work better than stripping the text section. > The kernel Makefile issues all the strip commands that can be done easily > and are safe. It's just not worth the effort to strip more. The extras > just waste 5c worth of disk space and a few msec of booting time. It has nothing to do with boot time/disk space/memory (albeit some may have issues with these but that is not the reasoning I am presenting) The issue is how one defines the interfaces into a system. It usually is not one of "whatever code there is, feel free to call it" but rather "these are the defined functions we provide - all other code is internal and used to provide these defined functions and may change with the next revision as we extend/enhance/fix things." When I use "functions" above, that does not mean just function calls like open() or malloc() but rather all interfaces, including variables and other defined access points and values. As it is now, there is nothing that would suggest to someone hacking at a tool that using, for example, the bpf_iflist symbol is not a valid action to take. (Or ihashtbl or any of the other static variables...) Maybe the answer is that the sysctl list is what the public interface is. And note that it is very easy to walk the sysctl list yourself in a dead kernel - even the as yet unregisted sets as they are in a simple array linked off of a public symbol that happens to be in a very standard format and thus lets you find them by just looking for symbols of that form. But, again, there is a difference between debugging the kernel and operational work. (Except for when kernel hacking is what you do, at which point operational work is debugging the kernel - and at that time, I know I am very glad to have symbols but I also know that I build with symbols.) > > > > As far as Elf raising the bar goes, it does a better job of separating > > > > external vs internal symbols. Making the loaders provide access to all > > > > symbols is not the correct solution. The correct solution is to have > > > > any symbols that are defined for "external access" to be defined as such. > > > > > > I disagree. Exporting bits of the kernel using linker symbols isn't > > > the correct solution for anything except possibly for examining dead > > > kernels, but it's easy to use. Loaders need to support all symbols > > > for other reasons. > > > > The linker symbols (external ones) are the way shared libraries link to > > each other. This is the defined mechanism. Now, it is not the best for > > Don't get me started on the evilness of shared libraries :-). Yes, there are problems and lets not go there... > > > > BTW - there is little to prevent a compiler from doing nasty optimizations > > > > with variables that are marked "static" since it has full knowledge of the > > > > scope of thos variables (or at least it thinks it does since it has been > > > > told so in the source) But this is a different issue and does not currently > > > affect GCC/x86 systems for various reasons. > > > > > > Similarly for all symbols if the linker is part of the compiler and > > > understands the scope of everything. > > > > I agree (and have worked with compilers that do that) which is even more > > reason to define which objects/symbols/etc are part of the public interface > > and which are internal use only. The current (4.x) system does not provide > > any way of doing so and has tools (top/vmstat/etc) that depend on access > > to a variety of symbols that are not obviously exported for direct access. > > Regrading to 2.x would bring back support for symbols.raw which is supposed > to list all "public" symbols. This file rotted before 2.x. > > > (And sometimes even have comments saying that they should not be, as in > > FSCALE... That is, if I read that comment correctly.) > > I think that comment is mostly out of date now. ps uses only the > kern.fscale sysctl. However, this seems to weaken ps's support for > dead kernels. Again, there should be no reason for ps not to have some kernel grubbing mode but is that the way the normal case should be? > There are some even more cryptically exported symbols for supporting > gdb on dead kernels. Some of them are in symbols.raw, but the easiest > way to find out about them is to try removing them. Yum... (oh, sorry, just ate a good bunch of symbols for breakfast :-) -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 5:24:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 54EC037B718 for ; Thu, 1 Mar 2001 05:24:14 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA80065; Thu, 1 Mar 2001 14:24:06 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Michael Sinz Cc: Bruce Evans , "Duane H. Hesser" , Randell Jesup , "(Bruce Bauman)" , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: ELF and diskless boot References: <3A9E4990.ACE5EF50@wgate.com> From: Dag-Erling Smorgrav Date: 01 Mar 2001 14:24:05 +0100 In-Reply-To: Michael Sinz's message of "Thu, 01 Mar 2001 08:07:28 -0500" Message-ID: Lines: 10 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael Sinz writes: > Plus, there is nothing that states that ps/top/etc can not have access > to some public symbol that is the sysctl list when the kernel is dead. Please show me how you would do 'sysctl vm.zone' on a dead kernel without duplicating the code in sys/vm/vm_zone.c. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 5:44:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B388D37B718 for ; Thu, 1 Mar 2001 05:44:44 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f21DiUh65507; Thu, 1 Mar 2001 08:44:31 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 1 Mar 2001 08:44:30 -0500 (EST) From: Robert Watson Reply-To: Robert Watson To: Terry Lambert Cc: "Long, Scott" , "'Garrett Wollman'" , arch@FreeBSD.ORG Subject: Re: Arch question for a UDF FS driver In-Reply-To: <200103010510.WAA16907@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 1 Mar 2001, Terry Lambert wrote: > > > Hash the Unique Id into 31 bits (e.g., u_id % 2147483647). Renumber > > > any collisions into the space above 2**31. You would still need to > > > keep some state when there is a collision, but if the Ids are > > > assigned sequentially then you are likely to win most of the time. > > > > Interesting idea. Like I said, consuming 32 bits within the life of the > > filesystem is going to be pretty hard. > > > > > I don't see what this has to do with vget(), however. > > > > not vget() itself, the vget vfsop. Unless I'm totally clueless here, the > > vget vfsop is supposed to return the vnode that repesents the passed in > > ino_t. > > The question to ask yourself is "under what circumstances do I care > about the ino_t?". > > My personal take would be to appeal to the Apple people here, > since they have already implemented one of these things, and > know how they did it, and the technical reasons why. > > My gut reaction would be to give ownership of the vnodes to the > FS itself, and ignore the problem (search for the string "TFS" > in the FS releated kernel code to see what I mean). > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 5:54:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5AA5837B71B for ; Thu, 1 Mar 2001 05:54:44 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f21Dsah65621; Thu, 1 Mar 2001 08:54:36 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 1 Mar 2001 08:54:36 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert Cc: "Long, Scott" , "'Garrett Wollman'" , arch@FreeBSD.ORG Subject: Re: Arch question for a UDF FS driver In-Reply-To: <200103010510.WAA16907@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry about that blank e-mail -- here's the real thing :-) On Thu, 1 Mar 2001, Terry Lambert wrote: > > > Hash the Unique Id into 31 bits (e.g., u_id % 2147483647). Renumber > > > any collisions into the space above 2**31. You would still need to > > > keep some state when there is a collision, but if the Ids are > > > assigned sequentially then you are likely to win most of the time. > > > > Interesting idea. Like I said, consuming 32 bits within the life of the > > filesystem is going to be pretty hard. > > > > > I don't see what this has to do with vget(), however. > > > > not vget() itself, the vget vfsop. Unless I'm totally clueless here, the > > vget vfsop is supposed to return the vnode that repesents the passed in > > ino_t. > > The question to ask yourself is "under what circumstances do I care > about the ino_t?". So my temptation here is the same as Terry's -- the concept of an "inode number" is fairly dated in that it applies poorly, if at all, to modern file systems (even 1980's file systems). There are, unfortunately, a few apps that make use of the inode number returned by stat -- generally to try and detect hard links (I think tar does this). You should be able to use a hash to prevent most collisions. Really, these applications should be fixed not to use the inode number where possible. In the past I've proposed addressing this by introducing a fsamefile(int fd1, int fd2) interface that would allow an application to determine if two open file descriptors pointed to the same "file" from the perspective of the current file system. Depending on your semantics, I suspect a perfectly acceptable implementation would simply compare the two vnode pointers (let Terry comment on aliasing here). In the past, it has been pointed out to me that this dramatically increases the cost of hard link detection -- as such, maintaining a moderately unique ino_t with effectively constant value (hashed from something fairly constant in the underlying file system) and letting the userland application generate hashes using that field, then resolve hash collisions using fsamefile() would be appropriate. I have an implementation of fsamefile() I've been using here with a fair amount of success, although I haven't adapted any third-party applications to use it. Note that on some platforms (including Linux, last I checked), the ino_t uniqueness property is fundamental to the design of their VFS, and collisions can have *very* nasty affects. In FreeBSD, from the kernel perspective, only the uniqueness of the vnode pointer matters, which is what I try to leverage in the fsamefile() interface (and also samefile() based on paths). As for vfs_vget() -- many of our file systems simple fall back on vfs_stdvget() which just returns EOPNOTSUPP. This is perfectly acceptable. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 6:13:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (unknown [194.128.198.234]) by hub.freebsd.org (Postfix) with ESMTP id B096E37B71C for ; Thu, 1 Mar 2001 06:13:32 -0800 (PST) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.1/8.11.1) id f21E0Df02993; Thu, 1 Mar 2001 14:00:13 GMT (envelope-from nik) Date: Thu, 1 Mar 2001 14:00:13 +0000 From: Nik Clayton To: Mark Murray Cc: arch@freebsd.org Subject: Re: FreeBSD sources from 20000' Message-ID: <20010301140013.A2969@canyon.nothing-going-on.org> References: <200102271136.f1RBa4R12865@gratis.grondar.za> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102271136.f1RBa4R12865@gratis.grondar.za>; from mark@grondar.za on Tue, Feb 27, 2001 at 01:36:49PM +0200 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 27, 2001 at 01:36:49PM +0200, Mark Murray wrote: > There was a pretty good response to my initial probe a few days > ago, so the time comes by to revive the discussion, and to slowly > begin on the path to an actual solution. What can we learn from other projects? In particular, the Debian apt/dpkg system seems to get high praise from all comers. N --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjqeVewACgkQk6gHZCw343XoywCeJKmwymc9sIbIz4dP/G7tzRR+ /BkAn08PSuMiPbcmT+X/aS5CojkHGMLu =Twqx -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 6:14:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 1201B37B718 for ; Thu, 1 Mar 2001 06:14:43 -0800 (PST) (envelope-from msinz@wgate.com) Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152C7NCY; Thu, 1 Mar 2001 09:14:53 -0500 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.1/8.11.1) with ESMTP id f21EDdk48360; Thu, 1 Mar 2001 09:13:58 -0500 (EST) (envelope-from msinz@wgate.com) Message-ID: <3A9E5913.A2815557@wgate.com> Date: Thu, 01 Mar 2001 09:13:39 -0500 From: Michael Sinz Organization: WorldGate Communications Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: Bruce Evans , "Duane H. Hesser" , Randell Jesup , "(Bruce Bauman)" , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: ELF and diskless boot References: <3A9E4990.ACE5EF50@wgate.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > Michael Sinz writes: > > Plus, there is nothing that states that ps/top/etc can not have access > > to some public symbol that is the sysctl list when the kernel is dead. > > Please show me how you would do 'sysctl vm.zone' on a dead kernel > without duplicating the code in sys/vm/vm_zone.c. Ugh... not easy... Again, system debugging (and dead kernel debugging) has a lot of dependancies on the exact kernel that you are running. And these types of operations are thus very tied to internal structures for the specific version of the kernel. What does this have to do with commands that are used in normal operation of the system? Sometimes it is nice to be able to get a ps of a dead system. This is a useful and powerful tool for debugging. It is also useful to be able to look at any structure and memory item and examine stack and even CPU registers. I have done all of that. But why would the facilities needed for kernel debugging be what are used (or required) for normal operation. Maybe others are different, but I fully expect that 99%+ of the times I run "ps" or "top" or "vmstat" that I do so on a live system. All of this is moot in that I solved the problem by having Etherboot handle the symbols, but the question I keep coming back to is: Is this the right way to build a system? Maybe the answer is yes, but I currently do not feel so. The exposure of information for tools that are used during normal operation of the system should (and must) be better controlled than just having access to the debug symbols. In fact, as systems scale to more complex setups (multiple threads, multiple CPUs, etc) such system structures can not be just looked at without very careful arbitration (or even communications on non-SMP based clusters). The debugging of such systems also gets noticeably more complex (been there, done that) such that the tools for that end of the process are usually not the normal operational tools. It is nice to only have a single tool (such as ps) that works in both cases, but I do not feel that doing so at the expense of general exposure of symbols is a good thing. -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. http://www.sinz.org/Michael.Sinz/ Ex-Amiga OS Kernel Engineer, Ex-Scala, Ex-NextBus, Blackdown JDK, WorldGate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 6:21: 5 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 4DBAE37B71B; Thu, 1 Mar 2001 06:21:03 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id JAA00305; Thu, 1 Mar 2001 09:20:59 -0500 (EST) (envelope-from wollman) Date: Thu, 1 Mar 2001 09:20:59 -0500 (EST) From: Garrett Wollman Message-Id: <200103011420.JAA00305@khavrinen.lcs.mit.edu> To: rwatson@FreeBSD.ORG Subject: Re: Arch question for a UDF FS driver X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >There are, unfortunately, a few apps that make use of the inode >number returned by stat -- generally to try and detect hard links (I >think tar does this). As I have pointed out before, it is a requirement of POSIX that distinct files have distinct (device, inode) pairs. The individual st_dev and st_ino values are not required to have any particular meaning except when used together in this way. (So, it's possible to treat the pair of members as a single 64-bit quantity, should that be desired, provided that uniqueness can be guaranteed.) -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 Thu Mar 1 6:28:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rapier.smartspace.co.za (rapier.smartspace.co.za [66.8.25.34]) by hub.freebsd.org (Postfix) with SMTP id 8401D37B719 for ; Thu, 1 Mar 2001 06:28:08 -0800 (PST) (envelope-from nbm@rapier.smartspace.co.za) Received: (qmail 3717 invoked by uid 1001); 1 Mar 2001 14:27:53 -0000 Date: Thu, 1 Mar 2001 16:27:53 +0200 From: Neil Blakey-Milner To: Nik Clayton Cc: Mark Murray , arch@freebsd.org Subject: Re: FreeBSD sources from 20000' Message-ID: <20010301162753.A2990@rapier.smartspace.co.za> References: <200102271136.f1RBa4R12865@gratis.grondar.za> <20010301140013.A2969@canyon.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010301140013.A2969@canyon.nothing-going-on.org>; from nik@freebsd.org on Thu, Mar 01, 2001 at 02:00:13PM +0000 Organization: Building Intelligence X-Operating-System: FreeBSD 4.2-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu 2001-03-01 (14:00), Nik Clayton wrote: > On Tue, Feb 27, 2001 at 01:36:49PM +0200, Mark Murray wrote: > > There was a pretty good response to my initial probe a few days > > ago, so the time comes by to revive the discussion, and to slowly > > begin on the path to an actual solution. > > What can we learn from other projects? > > In particular, the Debian apt/dpkg system seems to get high praise from > all comers. In addition, libdpkg version 2 is going to be LGPL. I think this is a great opportunity; I've got dpkg and apt to work on FreeBSD before, and even installed nawk via it, and ran it fine. Of course, it did put it in /usr/bin. Personally, I'd prefer to work with the Debian people in this area, as they seem to have the most clue, and the best reputation. An LGPL'd library should be sufficient for most comers in my opinion, and it has callback capability to extend to whatever actual format we wish to use. I'm sure if we seriously asked about libapt, they'd go for LGPL, and then we can help them out by having a real live secondary implementation of what is possibly the best package version graph implementation to date (available in usable source format). The more generic the backend gets, the less LGPL code we're relying on, and if anyone does indeed wish to provide a BSD-licensed version, it should be easy to implement. LGPL will mean that any changes we make to the library itself will have to be made available (or simply a pointer to an ftp site), but the callback mechanisms should allow extensibility for a BSD-licensed package backend, and BSD-licensed package fetchers, and so forth. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 6:52:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ohm.physics.purdue.edu (ohm.physics.purdue.edu [128.210.146.32]) by hub.freebsd.org (Postfix) with ESMTP id D160737B71D; Thu, 1 Mar 2001 06:52:04 -0800 (PST) (envelope-from will@physics.purdue.edu) Received: (from will@localhost) by ohm.physics.purdue.edu (8.11.2/8.9.3) id f21EqgV18088; Thu, 1 Mar 2001 09:52:42 -0500 (EST) (envelope-from will@physics.purdue.edu) X-Authentication-Warning: ohm.physics.purdue.edu: will set sender to will@physics.purdue.edu using -f Date: Thu, 1 Mar 2001 09:52:42 -0500 From: Will Andrews To: FreeBSD Architecture Cc: n@nectar.com, bde@zeta.org.au, obrien@nuxi.com, nate@yogotech.com Subject: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 src/gnu/usr.bin/binutils/ld Makefile src/gnu/usr.bin/binutils/ranlib Makefile Message-ID: <20010301095242.C17292@ohm.physics.purdue.edu> Reply-To: Will Andrews Mail-Followup-To: Will Andrews , FreeBSD Architecture , n@nectar.com, bde@zeta.org.au, obrien@nuxi.com, nate@yogotech.com References: <20010228103817.C20637@dragon.nuxi.com> <20010301064454.A57115@spawn.nectar.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Y5rl02BVI9TCfPar" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010301064454.A57115@spawn.nectar.com>; from n@nectar.com on Thu, Mar 01, 2001 at 06:44:54AM -0600 X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --Y5rl02BVI9TCfPar Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ moved to -arch ] On Thu, Mar 01, 2001 at 06:44:54AM -0600, Jacques A. Vidrine wrote: > Ugh, I wondered what DEFSHELL was for, and now that I've looked I feel > kind of ill. Does anyone actually use csh for make? Can we kill this > misfeature? >=20 > If we can't take it out back and shoot it in the head, can we at least: >=20 > #if !defined(DEFSHELL) > #define DEFSHELL 1 > #endif I'd like to note this was added by green so he could use ksh with make. I myself consider it a bug, and don't really see how we can claim POSIX(2) compliance with it included (because of SHELL's significance). --=20 wca --Y5rl02BVI9TCfPar Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6nmI5F47idPgWcsURArKDAJ9yu6AJDxDNfemER3L56TcS60XV9QCfYOuQ +1Mo9bDF9uNMtiy2r17BCNk= =8/S+ -----END PGP SIGNATURE----- --Y5rl02BVI9TCfPar-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 8:35:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 8B8EA37B71A; Thu, 1 Mar 2001 08:35:42 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p04-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.69]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id BAA23249; Fri, 2 Mar 2001 01:35:27 +0900 (JST) Message-ID: <3A9E79A1.C56F93DF@newsguy.com> Date: Fri, 02 Mar 2001 01:32:33 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Garrett Wollman Cc: rwatson@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Arch question for a UDF FS driver References: <200103011420.JAA00305@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garrett Wollman wrote: > > >There are, unfortunately, a few apps that make use of the inode > >number returned by stat -- generally to try and detect hard links (I > >think tar does this). > > As I have pointed out before, it is a requirement of POSIX that > distinct files have distinct (device, inode) pairs. The individual > st_dev and st_ino values are not required to have any particular > meaning except when used together in this way. (So, it's possible to > treat the pair of members as a single 64-bit quantity, should that be > desired, provided that uniqueness can be guaranteed.) And as have been answered before, that POSIX requirement is not viable with some modern distributed filesystems. Some have identifiers greater than 64 bits. And some do not have identifiers that uniquely identify a file at all (you'd have to compare each new identifier acquired with all cached identifiers to check for uniqueness). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.obscure.bsdconspiracy.net I think you are delusional, but that is OK. Its part of your natural charm! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 8:49: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2AF9537B71A; Thu, 1 Mar 2001 08:49:02 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p04-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.69]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id BAA26137; Fri, 2 Mar 2001 01:48:50 +0900 (JST) Message-ID: <3A9E7CC4.B4A9C43C@newsguy.com> Date: Fri, 02 Mar 2001 01:45:56 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Neil Blakey-Milner Cc: Nik Clayton , Mark Murray , arch@FreeBSD.ORG Subject: Re: FreeBSD sources from 20000' References: <200102271136.f1RBa4R12865@gratis.grondar.za> <20010301140013.A2969@canyon.nothing-going-on.org> <20010301162753.A2990@rapier.smartspace.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Neil Blakey-Milner wrote: > > LGPL will mean that any changes we make to the library itself will have > to be made available (or simply a pointer to an ftp site), but the > callback mechanisms should allow extensibility for a BSD-licensed > package backend, and BSD-licensed package fetchers, and so forth. Notice that an LGPLed installer would be unacceptable to some FreeBSD users. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.obscure.bsdconspiracy.net I think you are delusional, but that is OK. Its part of your natural charm! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 8:50: 3 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 7AF7137B71A for ; Thu, 1 Mar 2001 08:49:59 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA01350; Thu, 1 Mar 2001 11:49:47 -0500 (EST) (envelope-from wollman) Date: Thu, 1 Mar 2001 11:49:47 -0500 (EST) From: Garrett Wollman Message-Id: <200103011649.LAA01350@khavrinen.lcs.mit.edu> To: dcs@newsguy.com Subject: Re: Arch question for a UDF FS driver X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: Organization: MIT Laboratory for Computer Science Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >And as have been answered before, that POSIX requirement is not viable >with some modern distributed filesystems. Too bad, since it's not going to be changed. -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 Thu Mar 1 8:55:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 08AF337B71A for ; Thu, 1 Mar 2001 08:55:23 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p04-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.69]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id BAA27320; Fri, 2 Mar 2001 01:55:18 +0900 (JST) Message-ID: <3A9E7E48.D8A874A0@newsguy.com> Date: Fri, 02 Mar 2001 01:52:24 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Garrett Wollman Cc: arch@freebsd.org Subject: Re: Arch question for a UDF FS driver References: <200103011649.LAA01350@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garrett Wollman wrote: > > In article you write: > > >And as have been answered before, that POSIX requirement is not viable > >with some modern distributed filesystems. > > Too bad, since it's not going to be changed. Yes! Long live the standards! To hell with usability! -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.obscure.bsdconspiracy.net I think you are delusional, but that is OK. Its part of your natural charm! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 13: 0:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 9554437B719; Thu, 1 Mar 2001 12:59:58 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id NAA76472; Thu, 1 Mar 2001 13:59:35 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdem4Fqa; Thu Mar 1 13:59:24 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id NAA05439; Thu, 1 Mar 2001 13:59:43 -0700 (MST) From: Terry Lambert Message-Id: <200103012059.NAA05439@usr05.primenet.com> Subject: Re: Unicode, command line options, and configuration files, oh my! To: areilly@bigpond.net.au (Andrew Reilly) Date: Thu, 1 Mar 2001 20:59:43 +0000 (GMT) Cc: keichii@peorth.iteration.net (Michael C . Wu), tlambert@primenet.com (Terry Lambert), jonathan@graehl.org (Jonathan Graehl), freebsd-arch@FreeBSD.ORG (freebsd-Arch), i18n@FreeBSD.ORG In-Reply-To: <20010301174513.A65013@gurney.reilly.home> from "Andrew Reilly" at Mar 01, 2001 05:45:13 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > | In general, this means that for Unicode data stored for > > | directory entries would require that a directory entry > > | block would have to be 512b, whereas for UTF-8, we are > > | talking 2048b (2k). > > It would still have to be larger than 512b using a 16-bit > encoding, wouldn't it? Yes; 1024b; sorry about that, it was an error. The point was supposed to be that, if you go look at the directory entry code, it would be a lot easier to implement 1k instead of 2k (we did this before when we ported the FreeBSD VFS to Windows 95 and supported both the 256 character Unicode and the 8.3 namespaces simultaneously). > > | If the same approach is used as the current UFS code uses, > > | then these operations will need to be directory entry block > > | atomic. > > > > In short, we can save the file name that the user sees > > with the file data. The filesystem and the kernel sees > > some other naming scheme determined by the FS/kernel. > > How do you propose to do that and still maintain Unix inode/link > semantics? There isn't (necessarily) only one file name that > the user sees, but there _is_ only one lump of file data. How do hard links work at all today, under the same conditions? The directory entry is just a reference to the inode; this is not like ISO or VFAT, where the directory entry _is_ the inode. > > | On top of that, we have Microsoft and Java interoperability to > > | consider, distasteful as that may be to some. > > > > M$ has a pretty good implementation here. > > Java I18N sucks really bad. > > Could you give a quick description of why one of these is good > and the other bad, for the bennefit of someone who knows > neither? My take on this, which may not be the same as his, is that the Microsoft implementation uses the processing representation as the storage representation, whereas Java uses UTF-8 for the storage representation. Java also deals in strings composed of "bytes" instead of strings composed of "characters", which makes string processing problematic, if the string is an I18N string; consider that it has no functions similar to XPG/4 mbtowc() or other interning/externing functions that it would use to deal with them. It's kind of like the problem with Java letting you instance objects without a default constructor being required to make them valid; the JavaMail API is rife with examples of this type of thing. You can see it pretty easily, when you try to write those same interfaces in C++, since C++ doesn't permit that sort of thing to happen (instancing without initialization is not possible in C++; there is *always* a default constructor). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 13:46:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 78C4B37B718; Thu, 1 Mar 2001 13:46:11 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14YatL-000NAM-00; Thu, 01 Mar 2001 21:45:43 +0000 Date: Thu, 1 Mar 2001 21:45:43 +0000 From: Tony Finch To: Robert Watson Cc: Terry Lambert , "Long, Scott" , 'Garrett Wollman' , arch@FreeBSD.ORG Subject: Re: Arch question for a UDF FS driver Message-ID: <20010301214543.D483@hand.dotat.at> References: <200103010510.WAA16907@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: > >So my temptation here is the same as Terry's -- the concept of an "inode >number" is fairly dated in that it applies poorly, if at all, to modern >file systems (even 1980's file systems). There are, unfortunately, a few >apps that make use of the inode number returned by stat -- generally to >try and detect hard links (I think tar does this). Another use for the inode number is to uniquely identify files on the system: Apache uses this to generate Etags (i.e. entity tags). Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at MALIN HEBRIDES: EAST OR SOUTHEAST, BUT CYCLONIC IN MALIN AT FIRST, 3 INCREASING 4 OR 5. SNOW SHOWERS. MAINLY GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 13:50:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 9059C37B719 for ; Thu, 1 Mar 2001 13:50:57 -0800 (PST) (envelope-from nectar@nectar.com) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 373F318C91; Thu, 1 Mar 2001 15:50:55 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.2/8.9.3) id f21Lotw21213; Thu, 1 Mar 2001 15:50:55 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Thu, 1 Mar 2001 15:50:55 -0600 From: "Jacques A. Vidrine" To: Will Andrews , FreeBSD Architecture , bde@zeta.org.au, obrien@nuxi.com, nate@yogotech.com Subject: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 src/gnu/usr.bin/binutils/ld Makefile src/gnu/usr.bin/binutils/ranlib Makefile Message-ID: <20010301155055.F20983@hamlet.nectar.com> References: <20010228103817.C20637@dragon.nuxi.com> <20010301064454.A57115@spawn.nectar.com> <20010301095242.C17292@ohm.physics.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010301095242.C17292@ohm.physics.purdue.edu>; from will@physics.purdue.edu on Thu, Mar 01, 2001 at 09:52:42AM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Mar 01, 2001 at 09:52:42AM -0500, Will Andrews wrote: > I'd like to note this was added by green so he could use ksh with > make. I think the better way to accomplish that is to replace /bin/sh with ksh93 :-) But I'm not volunteering to update /etc/rc* at this time, no matter how trivial the required modifications appear to be. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 14:48:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from balzac.cybercable.fr (balzac.cybercable.fr [212.198.0.198]) by hub.freebsd.org (Postfix) with SMTP id 6377437B719 for ; Thu, 1 Mar 2001 14:48:31 -0800 (PST) (envelope-from clefevre@poboxes.com) Received: (qmail 26391076 invoked from network); 1 Mar 2001 22:48:20 -0000 Received: from d165.dhcp212-231.cybercable.fr (HELO gits.dyndns.org) ([212.198.231.165]) (envelope-sender ) by balzac.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 1 Mar 2001 22:48:20 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.2/8.11.2) id f21Mm8f66669; Thu, 1 Mar 2001 23:48:09 +0100 (CET) (envelope-from clefevre@poboxes.com) To: "Daniel C. Sobral" Cc: Neil Blakey-Milner , Nik Clayton , Mark Murray , arch@FreeBSD.ORG Subject: pkgtools (was Re: FreeBSD sources from 20000') References: <200102271136.f1RBa4R12865@gratis.grondar.za> <20010301140013.A2969@canyon.nothing-going-on.org> <20010301162753.A2990@rapier.smartspace.co.za> <3A9E7CC4.B4A9C43C@newsguy.com> X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C In-Reply-To: "Daniel C. Sobral"'s message of "Fri, 02 Mar 2001 01:45:56 +0900" From: Cyrille Lefevre Reply-To: clefevre@poboxes.com Mail-Copies-To: never Date: 01 Mar 2001 23:48:04 +0100 Message-ID: Lines: 99 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" writes: > Neil Blakey-Milner wrote: > > > > LGPL will mean that any changes we make to the library itself will have > > to be made available (or simply a pointer to an ftp site), but the > > callback mechanisms should allow extensibility for a BSD-licensed > > package backend, and BSD-licensed package fetchers, and so forth. > > Notice that an LGPLed installer would be unacceptable to some FreeBSD > users. I'm currently asking Ronald J. Record at SCO about the license status of the pkgtools. I'm also asking the openpackages team about these tools. you probably have comments in favor or against these tools ? --------========-------- forwarded message --------========-------- To: op-tech@openpackages.org Subject: pkgtools From: Cyrille Lefevre Date: 01 Mar 2001 05:08:52 +0100 Hi, some days ago, it was a discussion on freebsd-arch (as I remember) about providing some part of the FreeBSD userland (almost all contrib stuffs) as some sort of module (even ports !). an interesting link to SVR4 packaging tools was posted (details below). so, I've take a look at the code and it needs some work to be ported to BSD platforms. since the license isn't clear, I'm asking SCO about the status of this open source software. before to go forward, I'm asking you if you're interested by such tools which seems to be almost the same as the one found under Solaris ? below is the question and the first (fast) answer from Ronald J. Record and before to answer him, I would like your opinion ? thanks in advance. --------========-------- forwarded message --------========-------- Date: Wed, 28 Feb 2001 13:53:32 -0800 From: Ronald Joe Record To: clefevre@poboxes.com cc: skunkware@sco.com Subject: Re: pkgtools Hi Cyrille, The release of the pkgtools source was initiated at the behest of the 86Open group (http://www.telly.org/86open/86open-faq.html). The subsequent, uh, dissolution of this project (or transformation into lxrun/LKP) resulted in an unfinished release of these tools. I would concur that a BSD license would be appropriate but i'll need to obtain approval and find the time. It might help me speed things along if you were able to tell me why these tools are important for the *BSD systems. At any rate, i would recommend against putting any effort into a port until i get the license situation straightened out. -rr- re: Cyrille Lefevre wrote: > > Hi, > > I've just discovered the pkgtools at "SCO Skunkware: Open Source Software" > (http://www.sco.com/skunkware/devtools/) which seems to be the packaging > software used under SVR4 like OSes (UnixWare, Solaris, etc.). > > do you know the author of the original version of these tools ? > are they really Open Source ? are you working for SCO ? > > I've asked vit@auriga.ru (I found his email address in the source > code.) w/o any answer from him. > > I'm interested to porting these tools to *BSD and before to do any > efforts, I would like to be fixed about the license status of these > tools. > > The best thing would be, of course, to add a BSD like license to > the source code or at the top level of the distribution found at : > > http://www.sco.com/skunkware/src/sysadmin/pkg-15.1-src.tar.gz > > thanks in advance for your response. -- Ronald Joe Record, Open Source Architect, The Santa Cruz Operation WWW: http://www.ocston.org/rr http://www.sco.com/skunkware E-mail: rr@sco.com Voice: 831-427-7604 FAX: 831-427-5417 USPS: 400 Encinal Street, Santa Cruz, California 95061 Cyrille. -- home: mailto:clefevre@poboxes.com UNIX is user-friendly; it's just particular work: mailto:Cyrille.Lefevre@edf.fr about who it chooses to be friends with. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 15:23:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by hub.freebsd.org (Postfix) with SMTP id DF6FE37B71A for ; Thu, 1 Mar 2001 15:23:12 -0800 (PST) (envelope-from clefevre@poboxes.com) Received: (qmail 2985998 invoked from network); 1 Mar 2001 23:23:10 -0000 Received: from d165.dhcp212-231.cybercable.fr (HELO gits.dyndns.org) ([212.198.231.165]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 1 Mar 2001 23:23:10 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.2/8.11.2) id f21NN8s66711; Fri, 2 Mar 2001 00:23:08 +0100 (CET) (envelope-from clefevre@poboxes.com) To: arch@FreeBSD.ORG Cc: scott_long@btc.adaptec.com Subject: Re: Arch question for a UDF FS driver References: <200103010110.f211A2843934@vashon.polstra.com> X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C In-Reply-To: John Polstra's message of "Wed, 28 Feb 2001 17:10:02 -0800 (PST)" From: Cyrille Lefevre Reply-To: clefevre@poboxes.com Mail-Copies-To: never Date: 02 Mar 2001 00:23:05 +0100 Message-ID: Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra writes: > Long, Scott wrote: > [...] > > Orange: Get ino_t bumped up to a uint64_t and modify all the other > > filesystems to deal with it accordingly. Advantage: no hackery needed for > > UDF. Disadvantage: may be the mother of all bikesheds. > > Unfortunately, values of type ino_t are passed from kernel to userland > via the stat(2) family of system calls. So if you change the size > of ino_t, it will change the shape of the stat structure. This > would introduce binary compatibility problems. There would have > to be yet another flavor of struct stat (we already have 3 of them > in ), and some new system calls for the new versions > of stat(), fstat(), and lstat(). I.e., you can't just change the > existing system calls without totally breaking old binaries. how about implementing transition xxx64() syscalls like solaris do ? http://www.freebsd.org/cgi/man.cgi?query=lfcompile64&sektion=5&apropos=0&manpath=SunOS+5.8 http://www.freebsd.org/cgi/man.cgi?query=lf64&sektion=5&apropos=0&manpath=SunOS+5.8 Cyrille. -- home: mailto:clefevre@poboxes.com UNIX is user-friendly; it's just particular work: mailto:Cyrille.Lefevre@edf.fr about who it chooses to be friends with. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 16:16: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 892BB37B719 for ; Thu, 1 Mar 2001 16:16:45 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id TAA05234; Thu, 1 Mar 2001 19:16:32 -0500 (EST) (envelope-from wollman) Date: Thu, 1 Mar 2001 19:16:32 -0500 (EST) From: Garrett Wollman Message-Id: <200103020016.TAA05234@khavrinen.lcs.mit.edu> To: clefevre@poboxes.com Subject: Re: Arch question for a UDF FS driver X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: Organization: MIT Laboratory for Computer Science Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >how about implementing transition xxx64() syscalls like solaris do ? Those are for Large File Summit support (a hackish way to claim POSIX support while still having sizeof(off_t) > sizeof(unsigned long)). Effectively they do the same thing as FreeBSD does with `COMPAT' syscalls, except that the ``old'' calls are still made available in certain compilation environments. FreeBSD never supported (this particular expansion of) LFS; 4.4BSD came with large file support built-in and simply ignored the POSIX/C89 issue for the most part. -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 Thu Mar 1 16:38:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mb2i0.ns.pitt.edu (mb2i0.ns.pitt.edu [136.142.186.36]) by hub.freebsd.org (Postfix) with ESMTP id C66A237B71A for ; Thu, 1 Mar 2001 16:38:10 -0800 (PST) (envelope-from pfg1+@pitt.edu) Received: from pitt.edu ("port 1146"@[136.142.89.21]) by pitt.edu (PMDF V5.2-32 #41462) with ESMTP id <01K0OZVJRMI400J6U2@mb2i0.ns.pitt.edu> for arch@FreeBSD.ORG; Thu, 1 Mar 2001 19:38:09 EST Date: Thu, 01 Mar 2001 19:54:26 -0500 From: "Pedro F. Giffuni" Subject: Re: pkgtools (was Re: FreeBSD sources from 20000') To: clefevre@poboxes.com Cc: arch@FreeBSD.ORG, Ronald Joe Record Message-id: <3A9EEF42.2743EE8F@pitt.edu> Organization: University of Pittsburgh MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (Win98; U) Content-type: multipart/mixed; boundary="------------2BF13D408367AADD312A2F8B" X-Accept-Language: en,pdf,es-CO References: <200102271136.f1RBa4R12865@gratis.grondar.za> <20010301140013.A2969@canyon.nothing-going-on.org> <20010301162753.A2990@rapier.smartspace.co.za> <3A9E7CC4.B4A9C43C@newsguy.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------2BF13D408367AADD312A2F8B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think this was discussed long ago, my posting with the same URL must be somewhere in the archives. Back then the license was not considered a show stopper, but no one got to port it because the functionality of those tools is very similar to the ones already in FreeBSD. I would like to see this simply because they are sort of a standard for UNIX and we don't claim to be non-UNIX. In those days Ronald Record was also trying to free a bigger set of C++ tools. I have used the installer on SCO's Unixware and it's very nice, but that's IMHO. Packaging tools can be the root of another religious war. Unfortunately the 86open effort died miserably with a "Linux seems quite popular" comment after a long silence. Pedro. Cyrille Lefevre wrote: > > "Daniel C. Sobral" writes: > > > Neil Blakey-Milner wrote: > > > > > > LGPL will mean that any changes we make to the library itself will have > > > to be made available (or simply a pointer to an ftp site), but the > > > callback mechanisms should allow extensibility for a BSD-licensed > > > package backend, and BSD-licensed package fetchers, and so forth. > > > > Notice that an LGPLed installer would be unacceptable to some FreeBSD > > users. > > I'm currently asking Ronald J. Record at SCO about the license status > of the pkgtools. I'm also asking the openpackages team about these tools. > you probably have comments in favor or against these tools ? > > --------========-------- forwarded message --------========-------- > To: op-tech@openpackages.org > Subject: pkgtools > From: Cyrille Lefevre > Date: 01 Mar 2001 05:08:52 +0100 > > Hi, > > some days ago, it was a discussion on freebsd-arch (as I remember) > about providing some part of the FreeBSD userland (almost all contrib > stuffs) as some sort of module (even ports !). an interesting link to > SVR4 packaging tools was posted (details below). so, I've take a look > at the code and it needs some work to be ported to BSD platforms. > since the license isn't clear, I'm asking SCO about the status of this > open source software. before to go forward, I'm asking you if you're > interested by such tools which seems to be almost the same as the one > found under Solaris ? > > below is the question and the first (fast) answer from Ronald > J. Record and before to answer him, I would like your opinion ? > > thanks in advance. > > --------========-------- forwarded message --------========-------- > Date: Wed, 28 Feb 2001 13:53:32 -0800 > From: Ronald Joe Record > To: clefevre@poboxes.com > cc: skunkware@sco.com > Subject: Re: pkgtools > > Hi Cyrille, > > The release of the pkgtools source was initiated at the behest > of the 86Open group (http://www.telly.org/86open/86open-faq.html). > The subsequent, uh, dissolution of this project (or transformation > into lxrun/LKP) resulted in an unfinished release of these tools. > > I would concur that a BSD license would be appropriate but i'll > need to obtain approval and find the time. It might help me speed > things along if you were able to tell me why these tools are > important for the *BSD systems. > > At any rate, i would recommend against putting any effort into a > port until i get the license situation straightened out. > -rr- > > re: > > Cyrille Lefevre wrote: > > > > Hi, > > > > I've just discovered the pkgtools at "SCO Skunkware: Open Source Software" > > (http://www.sco.com/skunkware/devtools/) which seems to be the packaging > > software used under SVR4 like OSes (UnixWare, Solaris, etc.). > > > > do you know the author of the original version of these tools ? > > are they really Open Source ? are you working for SCO ? > > > > I've asked vit@auriga.ru (I found his email address in the source > > code.) w/o any answer from him. > > > > I'm interested to porting these tools to *BSD and before to do any > > efforts, I would like to be fixed about the license status of these > > tools. > > > > The best thing would be, of course, to add a BSD like license to > > the source code or at the top level of the distribution found at : > > > > http://www.sco.com/skunkware/src/sysadmin/pkg-15.1-src.tar.gz > > > > thanks in advance for your response. > > -- > Ronald Joe Record, Open Source Architect, The Santa Cruz Operation > WWW: http://www.ocston.org/rr http://www.sco.com/skunkware > E-mail: rr@sco.com Voice: 831-427-7604 FAX: 831-427-5417 > USPS: 400 Encinal Street, Santa Cruz, California 95061 > > Cyrille. > -- > home: mailto:clefevre@poboxes.com UNIX is user-friendly; it's just particular > work: mailto:Cyrille.Lefevre@edf.fr about who it chooses to be friends with. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message --------------2BF13D408367AADD312A2F8B Content-Type: text/x-vcard; charset=us-ascii; name="pfg1.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Pedro F. Giffuni Content-Disposition: attachment; filename="pfg1.vcf" begin:vcard n:Giffuni;Pedro tel;fax:1 (360) 343-0501 tel;home:(412) 665 2956 tel;work:(412) 624-9862 x-mozilla-html:FALSE url:http://www.geocities.com/giffunip/ org:University of Pittsburgh;Industrial Engineering adr:;;5820 Elwood St. Apt. 34;Pittsburgh;PA;15232;USA version:2.1 email;internet:giffunip@asme.org title:Teaching Assistant fn:Pedro F. Giffuni end:vcard --------------2BF13D408367AADD312A2F8B-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 18:11:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from camus.cybercable.fr (camus.cybercable.fr [212.198.0.200]) by hub.freebsd.org (Postfix) with SMTP id AED0437B719 for ; Thu, 1 Mar 2001 18:11:09 -0800 (PST) (envelope-from root@gits.dyndns.org) Received: (qmail 16850619 invoked from network); 2 Mar 2001 02:11:07 -0000 Received: from d165.dhcp212-231.cybercable.fr (HELO gits.dyndns.org) ([212.198.231.165]) (envelope-sender ) by camus.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 2 Mar 2001 02:11:07 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.2/8.11.2) id f222B4Z70068; Fri, 2 Mar 2001 03:11:04 +0100 (CET) (envelope-from root) From: Cyrille Lefevre Message-Id: <200103020211.f222B4Z70068@gits.dyndns.org> Subject: Re: pkgtools In-Reply-To: <3A9EEF42.2743EE8F@pitt.edu> "from Pedro F. Giffuni at Mar 1, 2001 07:54:26 pm" To: "Pedro F. Giffuni" Date: Fri, 2 Mar 2001 03:11:03 +0100 (CET) Cc: arch@FreeBSD.ORG, Ronald Joe Record , op-tech@openpackages.org Reply-To: clefevre@poboxes.com Organization: ACME X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Pedro F. Giffuni wrote: > > I think this was discussed long ago, my posting with the same URL must > be somewhere in the archives. for instance, I got the URL from Terry Lambert in the (big) Moving Things thread some days ago. > Back then the license was not considered a show stopper, but no one > got to port it because the functionality of those tools is very > similar to the ones already in FreeBSD. I would like to see this similar but not so powerfull. there is no file conflict checking, no auditing tool, file size/owner/group/permission/etc. aren't recorded anywhere, and more. and if we want to go in a modularized base system, we need something enough powerfull to handle those cases. > simply because they are sort of a standard for UNIX and we don't claim > to be non-UNIX. of course, we are, aren't we ? > In those days Ronald Record was also trying to free a bigger set of > C++ tools. I have used the installer on SCO's Unixware and it's very > nice, but that's IMHO. Packaging tools can be the root of another > religious war. what a pity if that happen (again?). we have to take the best from other systems, even SYSV and don't denigrate such tools because it came from SVR4 (or whatever). > Unfortunately the 86open effort died miserably with a "Linux seems > quite popular" comment after a long silence. RIP CC openpackages Cyrille. -- home: mailto:clefevre@poboxes.com UNIX is user-friendly; it's just particular work: mailto:Cyrille.Lefevre@edf.fr about who it chooses to be friends with. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 19:21: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 19A1137B718 for ; Thu, 1 Mar 2001 19:21:04 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id UAA29509; Thu, 1 Mar 2001 20:15:17 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAAuBaaG5; Thu Mar 1 20:15:07 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA17730; Thu, 1 Mar 2001 20:20:38 -0700 (MST) From: Terry Lambert Message-Id: <200103020320.UAA17730@usr05.primenet.com> Subject: Re: Arch question for a UDF FS driver To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Fri, 2 Mar 2001 03:20:38 +0000 (GMT) Cc: dcs@newsguy.com, arch@FreeBSD.ORG In-Reply-To: <200103011649.LAA01350@khavrinen.lcs.mit.edu> from "Garrett Wollman" at Mar 01, 2001 11:49:47 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >And as have been answered before, that POSIX requirement is not viable > >with some modern distributed filesystems. > > Too bad, since it's not going to be changed. So, we going to go back to using "long" instead of "off_t" in some of the fd using system calls? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 19:24:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 7F1D537B71B for ; Thu, 1 Mar 2001 19:24:37 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id UAA04208; Thu, 1 Mar 2001 20:24:13 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdGzF2ia; Thu Mar 1 20:24:09 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA17826; Thu, 1 Mar 2001 20:24:30 -0700 (MST) From: Terry Lambert Message-Id: <200103020324.UAA17826@usr05.primenet.com> Subject: Re: Arch question for a UDF FS driver To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Fri, 2 Mar 2001 03:24:30 +0000 (GMT) Cc: clefevre@poboxes.com, arch@FreeBSD.ORG In-Reply-To: <200103020016.TAA05234@khavrinen.lcs.mit.edu> from "Garrett Wollman" at Mar 01, 2001 07:16:32 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >how about implementing transition xxx64() syscalls like solaris do ? > > Those are for Large File Summit support (a hackish way to claim POSIX > support while still having sizeof(off_t) > sizeof(unsigned long)). > Effectively they do the same thing as FreeBSD does with `COMPAT' > syscalls, except that the ``old'' calls are still made available in > certain compilation environments. FreeBSD never supported (this > particular expansion of) LFS; 4.4BSD came with large file support > built-in and simply ignored the POSIX/C89 issue for the most part. Consider my previous question resolved, now that there is a historical precedent for ignoring POSIX semantics under some circumstances, in favor of usability. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 19:35:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 1DA7737B71A; Thu, 1 Mar 2001 19:35:55 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id UAA04772; Thu, 1 Mar 2001 20:32:43 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAzcairj; Thu Mar 1 20:32:34 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id UAA18058; Thu, 1 Mar 2001 20:35:43 -0700 (MST) From: Terry Lambert Message-Id: <200103020335.UAA18058@usr05.primenet.com> Subject: Re: Arch question for a UDF FS driver To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Fri, 2 Mar 2001 03:35:43 +0000 (GMT) Cc: rwatson@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: <200103011420.JAA00305@khavrinen.lcs.mit.edu> from "Garrett Wollman" at Mar 01, 2001 09:20:59 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >There are, unfortunately, a few apps that make use of the inode > >number returned by stat -- generally to try and detect hard links (I > >think tar does this). > > As I have pointed out before, it is a requirement of POSIX that > distinct files have distinct (device, inode) pairs. The individual > st_dev and st_ino values are not required to have any particular > meaning except when used together in this way. (So, it's possible to > treat the pair of members as a single 64-bit quantity, should that be > desired, provided that uniqueness can be guaranteed.) I like the idea of treating the 64 bit value as opaque, though there could be collision issues with actual device identifiers. I think the way Solaris dealt with this was to start using the address vector instead of the major number for the dev_t; this also saves a hash lookup on an NFS vonverion of file handles to structure pointers. For the DVD case (UDFFS) in question, this number will be zero, if it's considered as the high order bits, so avoiding zero might be necessary. I think that you could probably argue that the {st_dev,st_ino} set are unique only for that pair, and that there might be yet another value required on top of that to guarantee that you can uniquely idenitfy a file (e.g. {st_uniqueid,st_dev,st_ino}, with the type of st_uniqueid being bit packed, with the high bit as a continuation bit, or otherwise including an st_stat_version or whatever). I think that off_t being assumed to be 64 bits (long was used, for only 32 bits) is also kind of a lame restriction. INRE: the use of the inode to generate entity id's: I'm not too familiar with how they are used architecturally (only that they exist); is there support for handling has collisions (e.g. the id is treated as a hash instead of a uniqueid), or otherwise changing the calculation used? This would seem to me to be a big limitation in papches, allowing a single server to only support MAX(ino_t) entities. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 20: 4:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id A1F7637B71B; Thu, 1 Mar 2001 20:04:17 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (i087-112.nv.iinet.net.au [203.59.87.112]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id MAA23051; Fri, 2 Mar 2001 12:04:04 +0800 Message-ID: <3A9F1BAC.B4AE48FD@elischer.org> Date: Thu, 01 Mar 2001 20:03:56 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Terry Lambert Cc: Garrett Wollman , rwatson@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Arch question for a UDF FS driver References: <200103020335.UAA18058@usr05.primenet.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > >There are, unfortunately, a few apps that make use of the inode > > >number returned by stat -- generally to try and detect hard links (I > > >think tar does this). > > > > As I have pointed out before, it is a requirement of POSIX that > > distinct files have distinct (device, inode) pairs. The individual > > st_dev and st_ino values are not required to have any particular > > meaning except when used together in this way. (So, it's possible to > > treat the pair of members as a single 64-bit quantity, should that be > > desired, provided that uniqueness can be guaranteed.) > > I like the idea of treating the 64 bit value as opaque, though > there could be collision issues with actual device identifiers. > > I think the way Solaris dealt with this was to start using the > address vector instead of the major number for the dev_t; this > also saves a hash lookup on an NFS vonverion of file handles to > structure pointers. > > For the DVD case (UDFFS) in question, this number will be zero, > if it's considered as the high order bits, so avoiding zero > might be necessary. Under UDF Version 1.0 the "Inodes" are in the same space as the data, but starting with UDF 1.5 the "inodes" are in a separate 'virtual' address space so their block numbers are always low, no matter what the number of data blocks on the medium. Using this virtual block number as an address will give a number that is small enough to fit in a 32 bit field unless you have about 4 billion files on the media. They use one block per 'inode'. UDF 1.0 is only really used now for DVDs so they will never have 4 billion blocks of data either. (so we can just use the raw block number) I do however think it would be a good idea to shift the value of inode # in stat to 64 bits some time in the future. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 1 23:42:55 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 9B86337B71A; Thu, 1 Mar 2001 23:42:53 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f227gjd55137; Fri, 2 Mar 2001 00:42:45 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200103020742.f227gjd55137@harmony.village.org> To: mjacob@feral.com Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h Cc: John Baldwin , arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 27 Feb 2001 22:28:07 PST." References: Date: Fri, 02 Mar 2001 00:42:45 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : Are you planning to do this for 4.3? : : The reason I ask is so I can decide whether to finish setting up the : use of hints in fxp (and MFC it) as well as another driver or two. I don't think that I'm going to have time to get this merged before 4.3. I do plan on MFCing it, but I'll not have the time I need to test this before 4.3. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 2 2:14:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 189E137B720; Fri, 2 Mar 2001 02:14:32 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14YmZ8-0000h8-00; Fri, 02 Mar 2001 10:13:38 +0000 Date: Fri, 2 Mar 2001 10:13:38 +0000 From: Tony Finch To: Terry Lambert Cc: Garrett Wollman , rwatson@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Arch question for a UDF FS driver Message-ID: <20010302101338.B412@hand.dotat.at> References: <200103011420.JAA00305@khavrinen.lcs.mit.edu> <200103020335.UAA18058@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103020335.UAA18058@usr05.primenet.com> Organization: Covalent Technologies, Inc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > >INRE: the use of the inode to generate entity id's: I'm not too >familiar with how they are used architecturally (only that they >exist); is there support for handling has collisions (e.g. the >id is treated as a hash instead of a uniqueid), or otherwise >changing the calculation used? This would seem to me to be a >big limitation in papches, allowing a single server to only >support MAX(ino_t) entities. The resource identified by a URL can be one of many entities, depending on the Accept-Language and Accept-Charset headers, etc. The Etag is used (by caches etc.) to distinguish between them. I think a limit of 2^64 entities isn't going to be a big problem. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at THAMES DOVER: NORTH OR NORTHWEST 3 OR 4 VEERING NORTHEAST 5, OCCASIONALLY 6. OCCASIONAL SLEET. MODERATE OR GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 2 5:23:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id AD04C37B71B for ; Fri, 2 Mar 2001 05:23:26 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 3514 invoked by uid 1000); 2 Mar 2001 13:23:02 -0000 Date: Fri, 2 Mar 2001 15:23:02 +0200 From: Peter Pentchev To: arch@FreeBSD.org Subject: pw(8) patch: add -H encpass option to set the pw_passwd field Message-ID: <20010302152302.C2609@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, A post to -hackers got me thinking about adding a PAM authentication module, which uses Blowfish encryption and authenticates against passwd(5). The one major obstacle with this scheme (at least as far as I could see) is that there would be no way to set or change the user passwords, apart from frobbing the /etc/{s,}pwd.db files (which is impolite in the extreme), or the /etc/{master.,}passwd files (which is basically just as bad, not to mention having to invoke pwd_mkdb(8) afterwards). So.. what would be so bad about the attached patch, which lets a program or a script invoke pw(8) with a 'usermod -H new-encrypted-password' and have pw(8) store that password as-is in the user's pw_passwd field? The password is already encrypted, so there'd be no big security risks of someone watching the process table or something. G'luck, Peter -- This sentence is false. Index: src/usr.sbin/pw/pw.8 =================================================================== RCS file: /home/ncvs/src/usr.sbin/pw/pw.8,v retrieving revision 1.21 diff -u -r1.21 pw.8 --- src/usr.sbin/pw/pw.8 2001/02/01 16:43:57 1.21 +++ src/usr.sbin/pw/pw.8 2001/03/02 13:15:37 @@ -101,6 +101,7 @@ .Op Fl s Ar shell .Op Fl L Ar class .Op Fl h Ar fd +.Op Fl H Ar encpass .Op Fl N .Op Fl P .Op Fl Y @@ -456,6 +457,15 @@ See .Xr passwd 5 for details. +.It Fl H Ar encpass +Set the +.Em passwd +field in the user's passwd record. +This option assumes that +.Ar encpass +is an already-encrypted password, providing a hook for adding new +.Xr passwd 5 +encryption algorithms. .It Fl h Ar fd This option provides a special interface by which interactive scripts can set an account password using Index: src/usr.sbin/pw/pw.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/pw/pw.c,v retrieving revision 1.23 diff -u -r1.23 pw.c --- src/usr.sbin/pw/pw.c 2000/12/29 18:04:49 1.23 +++ src/usr.sbin/pw/pw.c 2001/03/02 13:15:37 @@ -106,18 +106,18 @@ static const char *opts[W_NUM][M_NUM] = { { /* user */ - "V:C:qn:u:c:d:e:p:g:G:mk:s:oL:i:w:h:Db:NPy:Y", + "V:C:qn:u:c:d:e:p:g:G:mk:s:oL:i:w:h:H:Db:NPy:Y", "V:C:qn:u:rY", - "V:C:qn:u:c:d:e:p:g:G:ml:k:s:w:L:h:FNPY", + "V:C:qn:u:c:d:e:p:g:G:ml:k:s:w:L:h:H:FNPY", "V:C:qn:u:FPa7", "V:C:q", "V:C:q", "V:C:q" }, { /* grp */ - "V:C:qn:g:h:M:pNPY", + "V:C:qn:g:h:H:M:pNPY", "V:C:qn:g:Y", - "V:C:qn:g:l:h:FM:m:NPY", + "V:C:qn:g:l:h:H:FM:m:NPY", "V:C:qn:g:FPa", "V:C:q" } Index: src/usr.sbin/pw/pw_group.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/pw/pw_group.c,v retrieving revision 1.13 diff -u -r1.13 pw_group.c --- src/usr.sbin/pw/pw_group.c 2000/06/22 16:48:41 1.13 +++ src/usr.sbin/pw/pw_group.c 2001/03/02 13:15:38 @@ -158,6 +158,12 @@ * software. */ + if ((getarg(args, 'h') != NULL) && (getarg(args, 'H') != NULL)) + err(EX_DATAERR, "-h and -H cannot be used simultaneously"); + + if ((arg = getarg(args, 'H')) != NULL) + grp->gr_passwd = arg->val; + if ((arg = getarg(args, 'h')) != NULL) { if (strcmp(arg->val, "-") == 0) grp->gr_passwd = "*"; /* No access */ Index: src/usr.sbin/pw/pw_user.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/pw/pw_user.c,v retrieving revision 1.44 diff -u -r1.44 pw_user.c --- src/usr.sbin/pw/pw_user.c 2000/12/29 18:04:49 1.44 +++ src/usr.sbin/pw/pw_user.c 2001/03/02 13:15:39 @@ -602,6 +602,14 @@ } } + if ((getarg(args, 'h') != NULL) && (getarg(args, 'H') != NULL)) + errx(EX_DATAERR, "-h and -H cannot be used simultaneously"); + + if ((arg = getarg(args, 'H')) != NULL) { + pwd->pw_passwd = arg->val; + edited = 1; + } + if ((arg = getarg(args, 'h')) != NULL) { if (strcmp(arg->val, "-") == 0) { if (!pwd->pw_passwd || *pwd->pw_passwd != '*') { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 2 9:27:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0F5F537B71A; Fri, 2 Mar 2001 09:27:52 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA24151; Fri, 2 Mar 2001 09:24:40 -0800 Date: Fri, 2 Mar 2001 09:24:38 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci if_fxp.c if_fxpvar.h In-Reply-To: <200103020742.f227gjd55137@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Okay. On Fri, 2 Mar 2001, Warner Losh wrote: > In message Matthew Jacob writes: > : Are you planning to do this for 4.3? > : > : The reason I ask is so I can decide whether to finish setting up the > : use of hints in fxp (and MFC it) as well as another driver or two. > > I don't think that I'm going to have time to get this merged before > 4.3. I do plan on MFCing it, but I'll not have the time I need to > test this before 4.3. > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 2 18:20:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-158.dsl.lsan03.pacbell.net [63.207.60.158]) by hub.freebsd.org (Postfix) with ESMTP id 5503237B719 for ; Fri, 2 Mar 2001 18:20:15 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C5ADB66F07; Fri, 2 Mar 2001 18:20:13 -0800 (PST) Date: Fri, 2 Mar 2001 18:20:13 -0800 From: Kris Kennaway To: Peter Pentchev Cc: arch@FreeBSD.org Subject: Re: pw(8) patch: add -H encpass option to set the pw_passwd field Message-ID: <20010302182013.A18150@mollari.cthul.hu> References: <20010302152302.C2609@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010302152302.C2609@ringworld.oblivion.bg>; from roam@orbitel.bg on Fri, Mar 02, 2001 at 03:23:02PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 02, 2001 at 03:23:02PM +0200, Peter Pentchev wrote: > Hi, >=20 > A post to -hackers got me thinking about adding a PAM authentication modu= le, > which uses Blowfish encryption and authenticates against passwd(5). Wrong solution. libcrypt is the thing which knows about UNIX passwords in /etc/master.passwd and exports access via crypt(), pam_unix is the PAM module which knows about crypt() Kris --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6oFTdWry0BWjoQKURAi3tAJ4n+B7tRndkIy/VXDtlyBNR01uM0wCg8Rqe Tz1TF5rIuNw0HBLt6bDrQb8= =6cWl -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 2 22: 5:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.dyndns.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 213D437B718; Fri, 2 Mar 2001 22:05:29 -0800 (PST) (envelope-from green@FreeBSD.org) Received: from localhost (dwfwsf@localhost [127.0.0.1]) by green.dyndns.org (8.11.2/8.11.1) with ESMTP id f23645V91572; Sat, 3 Mar 2001 01:04:07 -0500 (EST) (envelope-from green@FreeBSD.org) Message-Id: <200103030604.f23645V91572@green.dyndns.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Jacques A. Vidrine" Cc: Will Andrews , FreeBSD Architecture , bde@zeta.org.au, obrien@nuxi.com, nate@yogotech.com Subject: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 src/gnu/usr.bin/binutils/ld Makefile src/gnu/usr.bin/binutils/ranlib Makefile In-Reply-To: Message from "Jacques A. Vidrine" of "Thu, 01 Mar 2001 15:50:55 CST." <20010301155055.F20983@hamlet.nectar.com> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Mar 2001 01:04:04 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jacques A. Vidrine" wrote: > On Thu, Mar 01, 2001 at 09:52:42AM -0500, Will Andrews wrote: > > I'd like to note this was added by green so he could use ksh with > > make. > > I think the better way to accomplish that is to replace /bin/sh with > ksh93 :-) But I'm not volunteering to update /etc/rc* at this time, > no matter how trivial the required modifications appear to be. The change was made so that I could gain a good 10% speed increase on make world by using a better shell. Using ksh93 as an option would be good, too... may as well test that out and add it. As far as csh being an option, it really must be to be consistent with the source containing that ability already. I don't oppose a "default" DEFSHELL so it isn't necessary to be set by the Makefile or whatever. As far as making rc compatible with ksh... ksh is a _super_set of the POSIX shell, not a completely, totally new language. This means in all but the most esoteric cases, it will act exactly the same (or better, but compatibly so). I tested replacing /bin/sh with pdksh and it worked perfectly with every single shell script I have or is in the system; I'm certain ksh93 will also be just as fine (probably better, but having switched over yet ;) -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 3 7:20: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id EBE4737B71F; Sat, 3 Mar 2001 07:19:58 -0800 (PST) (envelope-from nectar@nectar.com) Received: by gw.nectar.com (Postfix, from userid 1001) id 68D2418C98; Sat, 3 Mar 2001 09:19:58 -0600 (CST) Date: Sat, 3 Mar 2001 09:19:58 -0600 From: "Jacques A. Vidrine" To: "Brian F. Feldman" Cc: Will Andrews , FreeBSD Architecture , bde@zeta.org.au, obrien@nuxi.com, nate@yogotech.com Subject: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 src/gnu/usr.bin/binutils/ld Makefile src/gnu/usr.bin/binutils/ranlib Makefile Message-ID: <20010303091958.A68223@spawn.nectar.com> References: <200103030604.f23645V91572@green.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103030604.f23645V91572@green.dyndns.org>; from green@FreeBSD.org on Sat, Mar 03, 2001 at 01:04:04AM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Mar 03, 2001 at 01:04:04AM -0500, Brian F. Feldman wrote: > As far as making rc compatible with ksh... ksh is a _super_set of the POSIX > shell, not a completely, totally new language. This means in all but the > most esoteric cases, it will act exactly the same (or better, but compatibly > so). I already tried dropping ksh93 into /bin/sh and booting with it. Two issues came up immediately: the `local' command, and some business with signal handlers (can't recall exact details at the moment). I don't think these would be hard to fix, though. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 3 8:51:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 3F19C37B71B; Sat, 3 Mar 2001 08:51:15 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA03303; Sat, 3 Mar 2001 08:51:11 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda03301; Sat Mar 3 08:51:10 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f23Gp4N67019; Sat, 3 Mar 2001 08:51:04 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdX67017; Sat Mar 3 08:50:33 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.3/8.9.1) id f23GoWS12086; Sat, 3 Mar 2001 08:50:32 -0800 (PST) Message-Id: <200103031650.f23GoWS12086@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdM12081; Sat Mar 3 08:50:13 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: "Jacques A. Vidrine" Cc: "Brian F. Feldman" , Will Andrews , FreeBSD Architecture , bde@zeta.org.au, obrien@nuxi.com, nate@yogotech.com Subject: ksh93 (was: Re: cvs commit: src/gnu/usr.bin/binutils/ar ...) In-reply-to: Your message of "Sat, 03 Mar 2001 09:19:58 CST." <20010303091958.A68223@spawn.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Mar 2001 08:50:13 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010303091958.A68223@spawn.nectar.com>, "Jacques A. Vidrine" write s: > On Sat, Mar 03, 2001 at 01:04:04AM -0500, Brian F. Feldman wrote: > > As far as making rc compatible with ksh... ksh is a _super_set of the POSIX > > > shell, not a completely, totally new language. This means in all but the > > most esoteric cases, it will act exactly the same (or better, but compatibl > y > > so). > > I already tried dropping ksh93 into /bin/sh and booting with it. Two > issues came up immediately: the `local' command, and some business > with signal handlers (can't recall exact details at the moment). > I don't think these would be hard to fix, though. I can see a problem with replacing ash with ksh. Sure ksh is a superset of sh, it is that superset that could be a problem for some users. For example one may have an application (binary, perl or shell script) in /usr/local/bin, let's take print for example. Once ash has been replaced by ksh, /usr/local/bin/print will no longer be executed in favour of the builtin ksh print. There is a reason why most of the major vendors ship both sh and ksh. That is because they are not 100% compatible in all cases. Sure, comparing features that are common to both they are 100% compatible, however the extensions to the language could cause problems for some applications. In the the case of the ksh extensions only (ignoring the common features), they are 0% compatible, see my print builtin example above, why because ksh would use the builtin print while sh would use print as found in the PATH, e.g. /usr/local/bin/print, which in my example might be more like printf, logger, or something that is not like ksh print. If we are going to make ksh the default shell, the following needs to be done: 1. Default disabling of all ksh builtins that could conflict with applications built by the end user, or 2. Modifying ksh to support /etc/kshrc and ~/.kshrc similar to bash tcsh (csh) where a user could disable conflicting builtins -- I think this is a hack, or 3. Give the FreeBSD community a very long lead time, at least a year to allow users to find and modify scripts that may have problems with the change, then replace ash -- I'm not enamoured with this option, or 4. Maintain both shells, then make ksh default boot shell after some lead time (I would think not as much lead time as #2 above), while still maintaining sh. This is what most of the major UNIX vendors do and with good reason, see print example above. 4a. Option 4 however ksh has a hard link of sh pointing to it and sh is renamed ash. Once again, after a good amount of lead time to allow the FreeBSD community to prepare for the change. If we are going to import ksh93 into the source tree, which I think is a good thing, my vote is # 4 or # 4a. For something as critical as a shell that is used virtually everywhere I think 100% backward compatibility must be maintained and therefore we should keep ash in FreeBSD. Boot scripts can reference #!/bin/ksh a short while after notifying people on -stable (a plan would be nice). /bin/sh should be renamed to /bin/ash with a /bin/sh hard link linked to it. Later we can change the /bin/sh hard link to /bin/ksh, while keeping /bin/ash for backward compatibility (if anyone has forgotten my point about compatibility by now see my print example above). Hopefully I covered it all. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 3 11:15:26 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 3DC6B37B71F; Sat, 3 Mar 2001 11:15:17 -0800 (PST) (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 GAA11226; Sun, 4 Mar 2001 06:15:13 +1100 Date: Sun, 4 Mar 2001 06:15:07 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: "Brian F. Feldman" Cc: "Jacques A. Vidrine" , Will Andrews , FreeBSD Architecture , obrien@nuxi.com, nate@yogotech.com Subject: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 src/gnu/usr.bin/binutils/ld Makefile src/gnu/usr.bin/binutils/ranlib Makefile In-Reply-To: <200103030604.f23645V91572@green.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 3 Mar 2001, Brian F. Feldman wrote: > "Jacques A. Vidrine" wrote: > > On Thu, Mar 01, 2001 at 09:52:42AM -0500, Will Andrews wrote: > > > I'd like to note this was added by green so he could use ksh with > > > make. > > > > I think the better way to accomplish that is to replace /bin/sh with > > ksh93 :-) But I'm not volunteering to update /etc/rc* at this time, > > no matter how trivial the required modifications appear to be. > > The change was made so that I could gain a good 10% speed increase on make > world by using a better shell. Using ksh93 as an option would be good, This seems unlikely. You are doing something wrong if shells take more than 1% of the time for makeworld. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message