From owner-freebsd-arch Sun Oct 20 23:53:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAC9E37B401 for ; Sun, 20 Oct 2002 23:53:30 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B45B43E7B for ; Sun, 20 Oct 2002 23:53:12 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g9L6puw16321; Mon, 21 Oct 2002 09:51:56 +0300 (EEST) (envelope-from ru) Date: Mon, 21 Oct 2002 09:51:56 +0300 From: Ruslan Ermilov To: "Andrey A. Chernov" Cc: Terry Lambert , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty Message-ID: <20021021065156.GB14584@sunbay.com> References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> <20021018.094801.123456703.imp@bsdimp.com> <3DB06A8B.E40B3004@mindspring.com> <20021018201919.GA15100@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline In-Reply-To: <20021018201919.GA15100@nagual.pp.ru> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --V0207lvV8h4k8FAm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 19, 2002 at 12:19:19AM +0400, Andrey A. Chernov wrote: > On Fri, Oct 18, 2002 at 13:09:47 -0700, Terry Lambert wrote: > >=20 > > > : So we must either fix syscons(4) or to somehow tell grotty(1) to > > > : emit old sequences to print bold and italic characters. > >=20 > > Fixing Grotty to use the termcap ("TermCap" -- Terminal Capabilities) > > database is the correct approach, in almost all cases. >=20 > I agree. Grotty should get termcap color capabilities using TERM env. =20 > variable, if output isatty(). That is termcap purpose. >=20 It is almost never isatty(), because the most typical scenario is to pass the output through a pipe to ${PAGER}, or to a compressor. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --V0207lvV8h4k8FAm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD4DBQE9s6QMUkv4P6juNwoRAlShAJUSl9nh0y1LJPDXQbewce4TtzdoAKCA47B6 2YOra/Wl/HnJrqPdfSpgOg== =x09x -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 0: 6:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 009F537B401; Mon, 21 Oct 2002 00:06:17 -0700 (PDT) Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.203.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 582CC43E3B; Mon, 21 Oct 2002 00:06:16 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1]) by orthanc.ab.ca (8.12.6/8.12.6) with ESMTP id g9L75t88021005; Mon, 21 Oct 2002 01:05:55 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200210210705.g9L75t88021005@orthanc.ab.ca> To: Ruslan Ermilov Cc: "Andrey A. Chernov" , Terry Lambert , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty In-Reply-To: Message from Ruslan Ermilov of "Mon, 21 Oct 2002 09:51:56 +0300." <20021021065156.GB14584@sunbay.com> X-Mailer: mh-e 6.1+cvs; nmh 1.0.4; Emacs 21.2 Date: Mon, 21 Oct 2002 01:05:55 -0600 From: Lyndon Nerenberg Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov writes: >> I agree. Grotty should get termcap color capabilities using TERM env. =20 >> variable, if output isatty(). That is termcap purpose. >>=20 >It is almost never isatty(), because the most typical scenario is >to pass the output through a pipe to ${PAGER}, or to a compressor. The default output format for nroff (and grotty) must continue to be for a dumb, overstriking, hardcopy printer. Changing this breaks too many things. If the GNU folks insist on having color printing on their ANSI terminals they should create a groansi, use 'groff -Tansi', and leave nroff alone. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 0:16:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A1B537B401; Mon, 21 Oct 2002 00:16:08 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5AB243E97; Mon, 21 Oct 2002 00:16:02 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0060.cvx21-bradley.dialup.earthlink.net ([209.179.192.60] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 183Wn5-0002VV-00; Mon, 21 Oct 2002 00:15:56 -0700 Message-ID: <3DB3A962.9F26FCA0@mindspring.com> Date: Mon, 21 Oct 2002 00:14:42 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: "Andrey A. Chernov" , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> <20021018.094801.123456703.imp@bsdimp.com> <3DB06A8B.E40B3004@mindspring.com> <20021018201919.GA15100@nagual.pp.ru> <20021021065156.GB14584@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov wrote: > > > > : So we must either fix syscons(4) or to somehow tell grotty(1) to > > > > : emit old sequences to print bold and italic characters. > > > > > > Fixing Grotty to use the termcap ("TermCap" -- Terminal Capabilities) > > > database is the correct approach, in almost all cases. > > > > I agree. Grotty should get termcap color capabilities using TERM env. > > variable, if output isatty(). That is termcap purpose. > > It is almost never isatty(), because the most typical scenario is > to pass the output through a pipe to ${PAGER}, or to a compressor. Pagers can't tell the difference between an escape sequence that results in characters which are not displayable without the escape sequence (and therefore take a character cell on the screen) and those which manipulate display attributes (and therefore do not take any screen space) from those which do cursor positioning in place of "CR/LF" (e.g. "delete line" at the top of the page is equivalent to scrolling) vs. those which do nothing apparent. Therefore, it's unreasonable to run processed data through a pager, if the results of that processing include terminal implementation dependent escape sequences.. The way this is normally dealt with is to use "_^HX" for underscore, "X^HX" for bold, etc., utilizing "overstrike", and have the pager convert it based on the pager's knowledge of the terminal display sequences from the termcap. Note that, so long as ASCII (0x08) is backspace, and moves the cursor one to the left, in the absence of additional terminal interpretation, the resulting data will be displayed as readable text, minus the attributes (e.g. even if the second character replaces, rather than overstriking the first, the text will end up being the same, without any display attributes at all). I guess a lot of kids these days have grown up without having to use real tty or terminal hardware, so they don't understand all the work that has already gone into finding the correct way to deal with these issues... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 0:29:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3D6C37B401 for ; Mon, 21 Oct 2002 00:29:19 -0700 (PDT) Received: from straylight.ringlet.net (office.sbnd.net [217.75.140.130]) by mx1.FreeBSD.org (Postfix) with SMTP id A0E7843E75 for ; Mon, 21 Oct 2002 00:29:16 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 4311 invoked by uid 1000); 21 Oct 2002 07:28:55 -0000 Date: Mon, 21 Oct 2002 10:28:55 +0300 From: Peter Pentchev To: Lyndon Nerenberg Cc: Ruslan Ermilov , "Andrey A. Chernov" , Terry Lambert , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty Message-ID: <20021021072855.GD389@straylight.oblivion.bg> Mail-Followup-To: Lyndon Nerenberg , Ruslan Ermilov , "Andrey A. Chernov" , Terry Lambert , "M. Warner Losh" , arch@FreeBSD.ORG References: <20021021065156.GB14584@sunbay.com> <200210210705.g9L75t88021005@orthanc.ab.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w7PDEPdKQumQfZlR" Content-Disposition: inline In-Reply-To: <200210210705.g9L75t88021005@orthanc.ab.ca> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 21, 2002 at 01:05:55AM -0600, Lyndon Nerenberg wrote: > Ruslan Ermilov writes: >=20 > >> I agree. Grotty should get termcap color capabilities using TERM env. = =3D20 > >> variable, if output isatty(). That is termcap purpose. > >>=20 > >It is almost never isatty(), because the most typical scenario is > >to pass the output through a pipe to ${PAGER}, or to a compressor. I was trying to stay out of this discussion, so I did not post this yesterday - the first thing that came to my mind when Andrey suggested isatty() was the PAGER pipe. So, no, isatty() would not work indeed. > The default output format for nroff (and grotty) must continue to be for > a dumb, overstriking, hardcopy printer. Changing this breaks too many > things. If the GNU folks insist on having color printing on their ANSI > terminals they should create a groansi, use 'groff -Tansi', and leave > nroff alone. Seconded, strongly. This would be the best approach IMHO. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am not the subject of this sentence. --w7PDEPdKQumQfZlR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE9s6y37Ri2jRYZRVMRAmIIAJ4rcca/xhjl9SHWyezmvm/xzv1D4QCcCrIL +d9K4i5CBZhy+fX2rETALmY= =aq8F -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 0:42: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC0EC37B401 for ; Mon, 21 Oct 2002 00:41:58 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7D8543E3B for ; Mon, 21 Oct 2002 00:41:51 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g9L7eul25786; Mon, 21 Oct 2002 10:40:56 +0300 (EEST) (envelope-from ru) Date: Mon, 21 Oct 2002 10:40:56 +0300 From: Ruslan Ermilov To: Terry Lambert Cc: "Andrey A. Chernov" , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty Message-ID: <20021021074056.GE14584@sunbay.com> References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> <20021018.094801.123456703.imp@bsdimp.com> <3DB06A8B.E40B3004@mindspring.com> <20021018201919.GA15100@nagual.pp.ru> <20021021065156.GB14584@sunbay.com> <3DB3A962.9F26FCA0@mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f61P+fpdnY2FZS1u" Content-Disposition: inline In-Reply-To: <3DB3A962.9F26FCA0@mindspring.com> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --f61P+fpdnY2FZS1u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 21, 2002 at 12:14:42AM -0700, Terry Lambert wrote: > Ruslan Ermilov wrote: > > > > > : So we must either fix syscons(4) or to somehow tell grotty(1) to > > > > > : emit old sequences to print bold and italic characters. > > > > > > > > Fixing Grotty to use the termcap ("TermCap" -- Terminal Capabilitie= s) > > > > database is the correct approach, in almost all cases. > > > > > > I agree. Grotty should get termcap color capabilities using TERM env. > > > variable, if output isatty(). That is termcap purpose. > >=20 > > It is almost never isatty(), because the most typical scenario is > > to pass the output through a pipe to ${PAGER}, or to a compressor. >=20 > Pagers can't tell the difference between an escape sequence that > results in characters which are not displayable without the > escape sequence (and therefore take a character cell on the screen) > and those which manipulate display attributes (and therefore do not > take any screen space) from those which do cursor positioning in > place of "CR/LF" (e.g. "delete line" at the top of the page is > equivalent to scrolling) vs. those which do nothing apparent. >=20 Look at the -R option of less(1). The point I was trying to make is that the use of isatty(3) is no help here, because even if grotty(1) took the libtermcap(3) approach, the output would almost never be a TTY. > Therefore, it's unreasonable to run processed data through a > pager, if the results of that processing include terminal > implementation dependent escape sequences.. >=20 > The way this is normally dealt with is to use "_^HX" for underscore, > "X^HX" for bold, etc., utilizing "overstrike", and have the pager > convert it based on the pager's knowledge of the terminal display > sequences from the termcap. >=20 This only covers _attributes_, but not color sequences, which are the Subject: here. While we can still use an old scheme to produce device-independent sequences for attributes, we lose the color support completely: FreeBSD's man(1) will be black-n-white forever. > Note that, so long as ASCII (0x08) is backspace, and moves > the cursor one to the left, in the absence of additional terminal > interpretation, the resulting data will be displayed as readable > text, minus the attributes (e.g. even if the second character > replaces, rather than overstriking the first, the text will end > up being the same, without any display attributes at all). >=20 >=20 > I guess a lot of kids these days have grown up without having to > use real tty or terminal hardware, so they don't understand all > the work that has already gone into finding the correct way to > deal with these issues... >=20 Definitely not me. I have been involved into the development of the at386 compatible terminal back in early 90's. I also worked on Esprit 400 terminals which were vt100 based. So far nobody told me what would be the correct alternative way to support colors in grotty(1). I tried the isatty() + libtermcap approach first, but it died horribly because the output is almost never a TTY. It became apparent to me that grotty(1) cannot use libtermcap, because it never knows what TERM it will be displayed on -- quite often the grotty(1) output is saved for future reference (e.g., in the form of catpages). Such an alternative would be to write a filter (similar to or extending the functionality of ul(1)) that would be capable of parsing the ANSI SGR attribute/color sequences and translate them to the right sequences for a given output device, or to strip them off completely. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --f61P+fpdnY2FZS1u Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9s6+IUkv4P6juNwoRAhFdAJ0dzOt13VcOpXOyQA49pHyP0cuNoQCfYzuX Ad5Rf79O8bOLs52m6JRtasU= =VQ0N -----END PGP SIGNATURE----- --f61P+fpdnY2FZS1u-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 1:16: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21FB437B401; Mon, 21 Oct 2002 01:16:08 -0700 (PDT) Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.203.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 133AE43E97; Mon, 21 Oct 2002 01:16:07 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1]) by orthanc.ab.ca (8.12.6/8.12.6) with ESMTP id g9L8Fx88081707; Mon, 21 Oct 2002 02:15:59 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200210210815.g9L8Fx88081707@orthanc.ab.ca> To: Ruslan Ermilov Cc: Terry Lambert , "Andrey A. Chernov" , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty In-Reply-To: Message from Ruslan Ermilov of "Mon, 21 Oct 2002 10:40:56 +0300." <20021021074056.GE14584@sunbay.com> X-Mailer: mh-e 6.1+cvs; nmh 1.0.4; Emacs 21.2 Date: Mon, 21 Oct 2002 02:15:58 -0600 From: Lyndon Nerenberg Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >This only covers _attributes_, but not color sequences, which are >the Subject: here. While we can still use an old scheme to produce >device-independent sequences for attributes, we lose the color >support completely: FreeBSD's man(1) will be black-n-white forever. That's right. It will, forever, have to support printing manual pages on output devices that do not support colour. But this is far from the point. As Terry mentioned, the notion of the nroff "tty" device as a monochromatic, sometimes overstriking, printer is firmly entrenched. And the format, by the nature of its simplicity, is universal. The idea of changing it now tells me that the groff maintainers need to learn some history, lest they repeat it. Haven't we learned a lesson from HTML? The unreadable colour combinations are bad enough there. The *LAST* thing I need is man pages with unreadable colour markup. What possible purpose can colour output from nroff serve, other than to satisfy someones craving for more blinkenlitz? We're knocking on the door of the twilight zone here, folks. As an aside, I'm about 1/4 of the way through bringing the 4.4BSD ditroff into the current millenium. I think it's time to up the priority on this project. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 3:51: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05BD737B401; Mon, 21 Oct 2002 03:51:00 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A27643E6E; Mon, 21 Oct 2002 03:50:58 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.6/8.12.6) with ESMTP id g9LAomOD022409; Mon, 21 Oct 2002 14:50:48 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.6/8.12.6/Submit) id g9LAolnR022408; Mon, 21 Oct 2002 14:50:47 +0400 (MSD) (envelope-from ache) Date: Mon, 21 Oct 2002 14:50:47 +0400 From: "Andrey A. Chernov" To: Ruslan Ermilov Cc: Terry Lambert , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty Message-ID: <20021021105047.GA22255@nagual.pp.ru> References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> <20021018.094801.123456703.imp@bsdimp.com> <3DB06A8B.E40B3004@mindspring.com> <20021018201919.GA15100@nagual.pp.ru> <20021021065156.GB14584@sunbay.com> <3DB3A962.9F26FCA0@mindspring.com> <20021021074056.GE14584@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <20021021074056.GE14584@sunbay.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 21, 2002 at 10:40:56 +0300, Ruslan Ermilov wrote: > So far nobody told me what would be the correct alternative way to > support colors in grotty(1). I tried the isatty() + libtermcap > approach first, but it died horribly because the output is almost > never a TTY. It became apparent to me that grotty(1) cannot use > libtermcap, because it never knows what TERM it will be displayed > on -- quite often the grotty(1) output is saved for future reference > (e.g., in the form of catpages). Such an alternative would be to > write a filter (similar to or extending the functionality of ul(1)) > that would be capable of parsing the ANSI SGR attribute/color > sequences and translate them to the right sequences for a given > output device, or to strip them off completely. I already tell correct alternative in my other mail to this thread,=20 without isatty, I mean Message-ID: <20021019135038.GA37956@nagual.pp.ru> =46rom it you can see how grotty _can_ use libtermcap without isatty, if=20 final device is known beforehead. --=20 Andrey A. Chernov=20 http://ache.pp.ru/ --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iQCVAwUBPbPcB+JgpPLZnQjrAQH2dwP/TGZIielN/8AVG5u5q0qnG1p6O5aEN5EO UCFyQGnBE4ZuwdyXwSzAJDdfG8BhxQz39rlQbBpjN581fKwWcGewTDpDK+AOt58u hKveG1dx7lym/YRNfuzITFBp+t5i5cuS1q9R49q8e2IxaSjP/+VwQvCVHph/lZaH 7DnPLzzSwxs= =aaWn -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 4:49: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6085F37B401 for ; Mon, 21 Oct 2002 04:49:02 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABF3943E4A for ; Mon, 21 Oct 2002 04:48:56 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g9LBlwe73724; Mon, 21 Oct 2002 14:47:58 +0300 (EEST) (envelope-from ru) Date: Mon, 21 Oct 2002 14:47:58 +0300 From: Ruslan Ermilov To: "Andrey A. Chernov" Cc: Terry Lambert , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty Message-ID: <20021021114758.GB66084@sunbay.com> References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> <20021018.094801.123456703.imp@bsdimp.com> <3DB06A8B.E40B3004@mindspring.com> <20021018201919.GA15100@nagual.pp.ru> <20021021065156.GB14584@sunbay.com> <3DB3A962.9F26FCA0@mindspring.com> <20021021074056.GE14584@sunbay.com> <20021021105047.GA22255@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TakKZr9L6Hm6aLOc" Content-Disposition: inline In-Reply-To: <20021021105047.GA22255@nagual.pp.ru> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 21, 2002 at 02:50:47PM +0400, Andrey A. Chernov wrote: > On Mon, Oct 21, 2002 at 10:40:56 +0300, Ruslan Ermilov wrote: >=20 > > So far nobody told me what would be the correct alternative way to > > support colors in grotty(1). I tried the isatty() + libtermcap > > approach first, but it died horribly because the output is almost > > never a TTY. It became apparent to me that grotty(1) cannot use > > libtermcap, because it never knows what TERM it will be displayed > > on -- quite often the grotty(1) output is saved for future reference > > (e.g., in the form of catpages). Such an alternative would be to > > write a filter (similar to or extending the functionality of ul(1)) > > that would be capable of parsing the ANSI SGR attribute/color > > sequences and translate them to the right sequences for a given > > output device, or to strip them off completely. >=20 > I already tell correct alternative in my other mail to this thread,=20 > without isatty, I mean >=20 > Message-ID: <20021019135038.GA37956@nagual.pp.ru> >=20 > From it you can see how grotty _can_ use libtermcap without isatty, if=20 > final device is known beforehead. >=20 But it isn't. For a manpage, man(1) compresses and stores the output from grotty(1) in /usr/share/man/cat? cache, and later displays it on this or that terminal (which are unknown beforehand and may differ). Most of you (including me) seem to agree that there is no crime in "backspace" sequences representing boldness and underlining, yet you call them device-independent (DI) -- only because they're natural for a matrix printer and because classical filters like ul(1) and more(1) were capable of translating them to the right escapes. But these "backspace" sequences do not provide a way to manipulate a color, yet they are not nearly DI if you pass them directly to some terminals (outputting the character at the 80th position followed by a backspace won't necessarily return a cursor to a previous line). AT&T nroff(1) wasn't producing the device independent output, as the colcrt(1) and col(1) manpages may hint you. So please stop calling "nroff" output device-independent. OTOH, ANSI SGR sequences allow one to manipulate both attributes and colors. One day soon, less(1) will be "fixed" to map the ANSI SGR escapes back to the terminal's native, like it currently does for backspace sequences. It actually already semi-supports them through the -R option (in that sense that they are accounted for properly). Would you tell me the same if both less(1) and ul(1) were capable of handling ANSI SGR sequences by default using the terminal's hardware capabilities? I'm sorry, but I really fail to see why do you think that backspace sequences are safer/better than ANSI SGR? Please think about it before replying. Ancient backspace Modern ANSI SGR escapes escapes ----------------------- ----------------------- --------------- raw TTY printing no no require filtering yes yes attribute support yes yes color support no yes require s/w mods no yes Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9s+luUkv4P6juNwoRAmkyAJ9GiDmc3abIgG57cHPa38nKILGJAQCdEvLJ zkXWpsIphUKXUixBrqw4vvA= =jzDG -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 7:48:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A023837B401; Mon, 21 Oct 2002 07:48:24 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BEF143E77; Mon, 21 Oct 2002 07:48:23 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.6/8.12.6) with ESMTP id g9LEmHOD025213; Mon, 21 Oct 2002 18:48:17 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.6/8.12.6/Submit) id g9LEmGcL025212; Mon, 21 Oct 2002 18:48:16 +0400 (MSD) (envelope-from ache) Date: Mon, 21 Oct 2002 18:48:16 +0400 From: "Andrey A. Chernov" To: Ruslan Ermilov Cc: Terry Lambert , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty Message-ID: <20021021144816.GB24582@nagual.pp.ru> References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> <20021018.094801.123456703.imp@bsdimp.com> <3DB06A8B.E40B3004@mindspring.com> <20021018201919.GA15100@nagual.pp.ru> <20021021065156.GB14584@sunbay.com> <3DB3A962.9F26FCA0@mindspring.com> <20021021074056.GE14584@sunbay.com> <20021021105047.GA22255@nagual.pp.ru> <20021021114758.GB66084@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <20021021114758.GB66084@sunbay.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 21, 2002 at 14:47:58 +0300, Ruslan Ermilov wrote: > OTOH, ANSI SGR sequences allow one to manipulate both attributes and > colors. One day soon, less(1) will be "fixed" to map the ANSI SGR > escapes back to the terminal's native, like it currently does for > backspace sequences. It actually already semi-supports them through > the -R option (in that sense that they are accounted for properly). >=20 > Would you tell me the same if both less(1) and ul(1) were capable of > handling ANSI SGR sequences by default using the terminal's hardware > capabilities? In theory - I have nothing against SGR default if all less(1), ul(1), col(1), colcrt(1) (I hope I not forget something) will be able treat it properly. Moreover, upper level utilities like man(1) should be fixed to use new options for that case too. In practice - in its current form less -R can cause keyboard lock or other unpleasant effects for terminals which not understand SGR, so can't be=20 used for man(1) manpage displaying. --=20 Andrey A. Chernov http://ache.pp.ru/ --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iQCVAwUBPbQTsOJgpPLZnQjrAQFr4AQAmgk2y+XbAdrnu2VQ4SIclXpT+ZDogOZT akcH91xBbwFz3n/n4P8xgdYAW0mg0qQrOsldC1NK+65ulZBcmTJ9bJYuizJTiflQ fiGzOfQh5k0j9+lF9ztgGGvvIcx7Nu+uCrzYBucD+uPLOnOv6ii2CVbxbmt7nYg8 xKSAWF5Rb5E= =IJn6 -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 7:58:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3B3537B401; Mon, 21 Oct 2002 07:58:44 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6350443E4A; Mon, 21 Oct 2002 07:58:44 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.6/8.12.5) id g9LEwZTp094595; Mon, 21 Oct 2002 09:58:35 -0500 (CDT) (envelope-from dan) Date: Mon, 21 Oct 2002 09:58:35 -0500 From: Dan Nelson To: Lyndon Nerenberg Cc: Ruslan Ermilov , Terry Lambert , "Andrey A. Chernov" , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty Message-ID: <20021021145835.GA45316@dan.emsphone.com> References: <20021021074056.GE14584@sunbay.com> <200210210815.g9L8Fx88081707@orthanc.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210210815.g9L8Fx88081707@orthanc.ab.ca> X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Oct 21), Lyndon Nerenberg said: > Haven't we learned a lesson from HTML? The unreadable colour > combinations are bad enough there. The *LAST* thing I need is man > pages with unreadable colour markup. What possible purpose can > colour output from nroff serve, other than to satisfy someones > craving for more blinkenlitz? We're knocking on the door of the > twilight zone here, folks. I agree. I can't think of any manpages that would benefit from having a rainbow of colors available to them (except possibly vidcontrol). If what people really want is the ability to make "WARNING" or "BUGS" headers stand out, then that's markup, not colors. That sounds like the job of "grohtml" + user-generated CSS. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 8:44:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C666337B401; Mon, 21 Oct 2002 08:44:53 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECF6443E65; Mon, 21 Oct 2002 08:44:48 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9LFigpk083086; Mon, 21 Oct 2002 09:44:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 21 Oct 2002 09:44:15 -0600 (MDT) Message-Id: <20021021.094415.49434942.imp@bsdimp.com> To: ache@nagual.pp.ru Cc: ru@FreeBSD.ORG, tlambert2@mindspring.com, arch@FreeBSD.ORG Subject: Re: color, again, in grotty From: "M. Warner Losh" In-Reply-To: <20021021144816.GB24582@nagual.pp.ru> References: <20021021105047.GA22255@nagual.pp.ru> <20021021114758.GB66084@sunbay.com> <20021021144816.GB24582@nagual.pp.ru> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20021021144816.GB24582@nagual.pp.ru> "Andrey A. Chernov" writes: : On Mon, Oct 21, 2002 at 14:47:58 +0300, Ruslan Ermilov wrote: : > OTOH, ANSI SGR sequences allow one to manipulate both attributes and : > colors. One day soon, less(1) will be "fixed" to map the ANSI SGR : > escapes back to the terminal's native, like it currently does for : > backspace sequences. It actually already semi-supports them through : > the -R option (in that sense that they are accounted for properly). : > : > Would you tell me the same if both less(1) and ul(1) were capable of : > handling ANSI SGR sequences by default using the terminal's hardware : > capabilities? : : In theory - I have nothing against SGR default if all less(1), ul(1), : col(1), colcrt(1) (I hope I not forget something) will be able treat it : properly. Moreover, upper level utilities like man(1) should be fixed to : use new options for that case too. : : In practice - in its current form less -R can cause keyboard lock or other : unpleasant effects for terminals which not understand SGR, so can't be : used for man(1) manpage displaying. My big problem with SGR is that all the other utilities in the chain don't grok it. When they do, and if they do the right thing, then maybe we can revisit this. Right now more does the wrong thing, for example, out of the box. Also, we need to be careful not to break other people's uses of it. So I think that we're all in agreement: don't generate the SGR sequences at this time unless specifically commanded to (either by an option on the command line, or a different command). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 10:40:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A330437B401; Mon, 21 Oct 2002 10:40:18 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25CA743E6E; Mon, 21 Oct 2002 10:40:18 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0274.cvx21-bradley.dialup.earthlink.net ([209.179.193.19] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 183gX6-0006gB-00; Mon, 21 Oct 2002 10:40:04 -0700 Message-ID: <3DB43BAD.AAB55A1A@mindspring.com> Date: Mon, 21 Oct 2002 10:38:53 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: "Andrey A. Chernov" , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> <20021018.094801.123456703.imp@bsdimp.com> <3DB06A8B.E40B3004@mindspring.com> <20021018201919.GA15100@nagual.pp.ru> <20021021065156.GB14584@sunbay.com> <3DB3A962.9F26FCA0@mindspring.com> <20021021074056.GE14584@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov wrote: > > Pagers can't tell the difference between an escape sequence that > > results in characters which are not displayable without the > > escape sequence (and therefore take a character cell on the screen) > > and those which manipulate display attributes (and therefore do not > > take any screen space) from those which do cursor positioning in > > place of "CR/LF" (e.g. "delete line" at the top of the page is > > equivalent to scrolling) vs. those which do nothing apparent. > > Look at the -R option of less(1). The point I was trying to make is > that the use of isatty(3) is no help here, because even if grotty(1) > took the libtermcap(3) approach, the output would almost never be a > TTY. That's easy: you can not interpose a pager between you and the terminal. If you impose a pager, you are screwed. That leaves you the option of not paging, or integrating the pager into grotty. > > Therefore, it's unreasonable to run processed data through a > > pager, if the results of that processing include terminal > > implementation dependent escape sequences.. > > > > The way this is normally dealt with is to use "_^HX" for underscore, > > "X^HX" for bold, etc., utilizing "overstrike", and have the pager > > convert it based on the pager's knowledge of the terminal display > > sequences from the termcap. > > This only covers _attributes_, but not color sequences, which are > the Subject: here. While we can still use an old scheme to produce > device-independent sequences for attributes, we lose the color > support completely: FreeBSD's man(1) will be black-n-white forever. That's exactly right: you don't get color, unless your termcap 'standout', 'underline' or other attribute is set to a color escape sequence. I think what you are complaining about here is that your termcap interpretation is not indirected through another layer that does mapping of attributes to foreground/background/attribute tuples. Frankly, if you want to implement this, the place to do it is in your cgetcap(3) implementation. > Definitely not me. I have been involved into the development of > the at386 compatible terminal back in early 90's. I also worked > on Esprit 400 terminals which were vt100 based. > > So far nobody told me what would be the correct alternative way to > support colors in grotty(1). 1) Integrate your pager as an option in grotty(1). 2) Support attribute mapping in the pager, and make grotty put out the standard overstrike sequences, which a pager then interprets via an attribute mapping table, due to the base implementation of cgetent returing colors or anything else you map them to for 'standaout', 'underline', etc. 3) Don't support color. > It became apparent to me that grotty(1) cannot use > libtermcap, because it never knows what TERM it will be displayed > on -- quite often the grotty(1) output is saved for future reference > (e.g., in the form of catpages). Then I guess it doesn't get color, since termcap is the only legal method of obtaining color. > Such an alternative would be to > write a filter (similar to or extending the functionality of ul(1)) > that would be capable of parsing the ANSI SGR attribute/color > sequences and translate them to the right sequences for a given > output device, or to strip them off completely. Both ul(1) and colcrt(1) are moderately bogus, in this regard, unless they are treated as output filters for a pager, rather than input. The yardstick one should use here is "Can I use it with 'vi'?"; that very quickly identifies what you should and should not be considering as solutions. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 10:42:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87F2537B401; Mon, 21 Oct 2002 10:42:55 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42A6C43E77; Mon, 21 Oct 2002 10:42:55 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0274.cvx21-bradley.dialup.earthlink.net ([209.179.193.19] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 183gZk-00036g-00; Mon, 21 Oct 2002 10:42:48 -0700 Message-ID: <3DB43C51.5ABE4F79@mindspring.com> Date: Mon, 21 Oct 2002 10:41:37 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lyndon Nerenberg Cc: Ruslan Ermilov , "Andrey A. Chernov" , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty References: <200210210815.g9L8Fx88081707@orthanc.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Lyndon Nerenberg wrote: > Haven't we learned a lesson from HTML? The unreadable colour > combinations are bad enough there. The *LAST* thing I need is man pages > with unreadable colour markup. What possible purpose can colour output > from nroff serve, other than to satisfy someones craving for more > blinkenlitz? We're knocking on the door of the twilight zone here, > folks. Now *there's* an idea: output to html, because you are guaranteed that the rendering will Do The Right Thing(tm) for color. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 11:18:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5026B37B401; Mon, 21 Oct 2002 11:18:10 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D75C943E65; Mon, 21 Oct 2002 11:18:09 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0274.cvx21-bradley.dialup.earthlink.net ([209.179.193.19] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 183h7t-0000Sr-00; Mon, 21 Oct 2002 11:18:05 -0700 Message-ID: <3DB44495.6D7EE682@mindspring.com> Date: Mon, 21 Oct 2002 11:16:53 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Andrey A. Chernov" Cc: Ruslan Ermilov , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> <20021018.094801.123456703.imp@bsdimp.com> <3DB06A8B.E40B3004@mindspring.com> <20021018201919.GA15100@nagual.pp.ru> <20021021065156.GB14584@sunbay.com> <3DB3A962.9F26FCA0@mindspring.com> <20021021074056.GE14584@sunbay.com> <20021021105047.GA22255@nagual.pp.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Andrey A. Chernov" wrote: > From it you can see how grotty _can_ use libtermcap without isatty, if > final device is known beforehead. A terminal type command line option works. The problem with it is that you can not necessarily jam the output through a pager, though, without the pager stripping the escape sequences, so that it can control the arrangement of data on a page -- which is what a pager does. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 11:28:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A006337B401; Mon, 21 Oct 2002 11:28:08 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0536543E6A; Mon, 21 Oct 2002 11:28:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0274.cvx21-bradley.dialup.earthlink.net ([209.179.193.19] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 183hHa-0000io-00; Mon, 21 Oct 2002 11:28:07 -0700 Message-ID: <3DB446F0.486F9CAC@mindspring.com> Date: Mon, 21 Oct 2002 11:26:56 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: "Andrey A. Chernov" , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: color, again, in grotty References: <20021017.101833.110719994.imp@bsdimp.com> <20021018095026.GA3386@sunbay.com> <20021018.094801.123456703.imp@bsdimp.com> <3DB06A8B.E40B3004@mindspring.com> <20021018201919.GA15100@nagual.pp.ru> <20021021065156.GB14584@sunbay.com> <3DB3A962.9F26FCA0@mindspring.com> <20021021074056.GE14584@sunbay.com> <20021021105047.GA22255@nagual.pp.ru> <20021021114758.GB66084@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov wrote: > > From it you can see how grotty _can_ use libtermcap without isatty, if > > final device is known beforehead. > > But it isn't. For a manpage, man(1) compresses and stores the output > from grotty(1) in /usr/share/man/cat? cache, and later displays it on > this or that terminal (which are unknown beforehand and may differ). Then you don't get color. Try delaying rendering, instead. > Most of you (including me) seem to agree that there is no crime in > "backspace" sequences representing boldness and underlining, yet you > call them device-independent (DI) -- only because they're natural for > a matrix printer and because classical filters like ul(1) and more(1) > were capable of translating them to the right escapes. That's not the reason; ul(1) is completely bogus, IMO, since it can not be combined with a pager, unless you pipe the pager output through it; this assumes certain explicit flushing behaviour by the pager, which is not normally present in stdio. The real reason is that ASCII defines the character, and, unlike almost all other characters, the ASCII character has a well known behaviour which can be exploited to imply trigraphs between a back end application and a front end pager, over a pipe. > But these "backspace" sequences do not provide a way to manipulate a > color, yet they are not nearly DI if you pass them directly to some > terminals (outputting the character at the 80th position followed by > a backspace won't necessarily return a cursor to a previous line). This is a bogus argument. Specifically, it relies on the idea that a DI rendering facility would ever use column 80 in the first place, because it was ignorant of the behaviour of column 80 not being DI. > AT&T nroff(1) wasn't producing the device independent output, as the > colcrt(1) and col(1) manpages may hint you. So please stop calling > "nroff" output device-independent. This bears repeating. Over and over, if necessary. It is an important point. > I'm sorry, but I really fail to see why do you think that backspace > sequences are safer/better than ANSI SGR? I think the best answer to this question is that pagers are not terminal emulators, and therefore their imput can not be escape sequences, if you expect their output to be visually similar on very different terminals. > Ancient backspace Modern ANSI SGR > escapes escapes > ----------------------- ----------------------- --------------- > raw TTY printing no no > require filtering yes yes no yes (by an emulator) > attribute support yes yes > color support no yes > require s/w mods no yes -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 11:44:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 987B337B401; Mon, 21 Oct 2002 11:44:39 -0700 (PDT) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E50C43E6A; Mon, 21 Oct 2002 11:44:39 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0274.cvx21-bradley.dialup.earthlink.net ([209.179.193.19] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 183hXO-0001Ia-00; Mon, 21 Oct 2002 11:44:26 -0700 Message-ID: <3DB44AC3.56EAA519@mindspring.com> Date: Mon, 21 Oct 2002 11:43:15 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: ache@nagual.pp.ru, ru@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: color, again, in grotty References: <20021021105047.GA22255@nagual.pp.ru> <20021021114758.GB66084@sunbay.com> <20021021144816.GB24582@nagual.pp.ru> <20021021.094415.49434942.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "M. Warner Losh" wrote: > My big problem with SGR is that all the other utilities in the chain > don't grok it. When they do, and if they do the right thing, then > maybe we can revisit this. Right now more does the wrong thing, for > example, out of the box. My big problem is that "_^H" for an underlined character and "^H" for a bold character is technically a trigraph, whereas an SGR escape sequence is an SGR escape sequence, and not a trigraph. > Also, we need to be careful not to break other people's uses of it. Escape sequences break things; trigraphs selected for their failure modes ability to display readable data do not. > So I think that we're all in agreement: don't generate the SGR > sequences at this time unless specifically commanded to (either by an > option on the command line, or a different command). I would go further, and say that it was the job of the pager to do this, no matter what, since you cannot provide escape sequence input to a pager which is not also a terminal emulator, and expect to get reasonable output. If the pager *is* a terminal emulator, then it must emulate a mutually agreed upon terminal, in which case output for some other terminal type, run through a pager, is broken. Specifically, what about: grotty | more | more on a Televideo terminal? While not quite reasonable to pipe more to more (those generally less reasonable to pipe grotty to more in the first place), you're breaking something that used to work. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 13:39:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4ED5937B401 for ; Mon, 21 Oct 2002 13:39:33 -0700 (PDT) Received: from walton.kettenis.dyndns.org (a169250.upc-a.chello.nl [62.163.169.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1C2A43E4A for ; Mon, 21 Oct 2002 13:39:31 -0700 (PDT) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.5/8.12.5) with ESMTP id g9LKdQMP000495; Mon, 21 Oct 2002 22:39:26 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id g9LKdQCg001119; Mon, 21 Oct 2002 22:39:26 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id g9LKdMjS001116; Mon, 21 Oct 2002 22:39:22 +0200 (CEST) Date: Mon, 21 Oct 2002 22:39:22 +0200 (CEST) Message-Id: <200210212039.g9LKdMjS001116@elgar.kettenis.dyndns.org> From: Mark Kettenis To: freebsd-arch@freebsd.org Cc: bsd-api-discuss@wasabisystems.com Subject: ptrace(2) and vector registers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ CC'd to bsd-api-discuss since it might interest folks there. ] For a while now, FreeBSD includes support for the SSE registers found on newer Intel and AMD processors. However up until now these registers haven't been exposed outside the kernel, neither via /proc nor via ptrace(2). Therefore, GDB doesn't support these registers on FreeBSD yet. Since I want to get this working, I'm willing to add the necessary bits to the kernel. Getting the purely technical bits right isn't terribly difficult and I'll manage it on my own. However, since the infrastructure for machine-specific ptrace(2) requests was minimalized not too long ago, I'm wondering if we shouldn't try to come up with a machine independent API for things like the ix86 SSE registers. The powerpc for instance has its AltiVec registers. NetBSD already has support for the SSE registers. There is `struct xmmregs' in and PT_GETXMMREGS & PT_SETXMMREGS reequests in . I have to say that I'm not terribly happy with `struct xmmregs', since it ends with an 's', where the other structs in (`struct reg' and `struct fpreg') don't. But the most inportant thing is that these names are tied to the x86. Since both SSE and AltiVec are some sort of vector registers I'd like to propose `struct vreg' and PT_GETVREGS & PT_SETVREGS as alternatives. NetBSD/powerpc already defines `struct vreg'. Mark Kettenis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 13:59: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8358A37B401 for ; Mon, 21 Oct 2002 13:59:05 -0700 (PDT) Received: from h132-197-179-27.gte.com (h132-197-179-27.gte.com [132.197.179.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5F6B43E6A for ; Mon, 21 Oct 2002 13:59:04 -0700 (PDT) (envelope-from ak03@gte.com) Received: from kanpc.gte.com (localhost [IPv6:::1]) by h132-197-179-27.gte.com (8.12.6/8.12.6) with ESMTP id g9LKwwkY078444; Mon, 21 Oct 2002 16:58:58 -0400 (EDT) (envelope-from ak03@kanpc.gte.com) Received: (from ak03@localhost) by kanpc.gte.com (8.12.6/8.12.6/Submit) id g9LKwvFq078443; Mon, 21 Oct 2002 16:58:57 -0400 (EDT) Date: Mon, 21 Oct 2002 16:58:57 -0400 From: Alexander Kabaev To: Mark Kettenis Cc: freebsd-arch@FreeBSD.ORG Subject: Re: ptrace(2) and vector registers Message-Id: <20021021165857.185716fb.ak03@gte.com> In-Reply-To: <200210212039.g9LKdMjS001116@elgar.kettenis.dyndns.org> References: <200210212039.g9LKdMjS001116@elgar.kettenis.dyndns.org> Organization: Verizon Data Services X-Mailer: Sylpheed version 0.8.5claws7 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 21 Oct 2002 22:39:22 +0200 (CEST) Mark Kettenis wrote: > s. > > NetBSD already has support for the SSE registers. There is `struct > xmmregs' in and PT_GETXMMREGS & PT_SETXMMREGS > reequests in . I have to say that I'm not terribly > happy with `struct xmmregs', since it ends with an 's', where the > other structs in (`struct reg' and `struct fpreg') > don't. But the most inportant thing is that these names are tied to > the x86. Since both SSE and AltiVec are some sort of vector registers > I'd like to propose `struct vreg' and PT_GETVREGS & PT_SETVREGS as > alternatives. NetBSD/powerpc already defines `struct vreg'. Please take a look at linux_ptrace.c. I tried to support Linux-specific PTRACE_{GET|SET}FPXREGS calls there. We might want to simply reuse that for FreeBSD syscall. -- Alexander Kabaev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 21 14: 9:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D245A37B401 for ; Mon, 21 Oct 2002 14:09:27 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3032E43E75 for ; Mon, 21 Oct 2002 14:09:27 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0018.cvx40-bradley.dialup.earthlink.net ([216.244.42.18] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 183jnf-0006Uy-00; Mon, 21 Oct 2002 14:09:24 -0700 Message-ID: <3DB46CA2.1798B6A6@mindspring.com> Date: Mon, 21 Oct 2002 14:07:46 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Kettenis Cc: freebsd-arch@freebsd.org, bsd-api-discuss@wasabisystems.com Subject: Re: ptrace(2) and vector registers References: <200210212039.g9LKdMjS001116@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mark Kettenis wrote: > NetBSD already has support for the SSE registers. There is `struct > xmmregs' in and PT_GETXMMREGS & PT_SETXMMREGS > reequests in . I have to say that I'm not terribly > happy with `struct xmmregs', since it ends with an 's', where the > other structs in (`struct reg' and `struct fpreg') > don't. But the most inportant thing is that these names are tied to > the x86. Since both SSE and AltiVec are some sort of vector registers > I'd like to propose `struct vreg' and PT_GETVREGS & PT_SETVREGS as > alternatives. NetBSD/powerpc already defines `struct vreg'. What do the NetBSD people say about making this change in their code, and getting rid of 'PT_GETXMMREGS' and 'PT_SETXMMREGS' in their x86 code? They may have good reasons for not doing this, which would also be good reasons for FreeBSD, or they might say "Cool! Let's switch!" and do all the GDB work for you, for free. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 22 18: 3:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8F2937B401 for ; Tue, 22 Oct 2002 18:03:49 -0700 (PDT) Received: from mailhost.nxad.com (lan.ext.nxad.com [66.250.180.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CB7843E7B for ; Tue, 22 Oct 2002 18:03:49 -0700 (PDT) (envelope-from sean@nxad.com) Received: from perrin.int.nxad.com (perrin.int.nxad.com [192.168.1.251]) by mailhost.nxad.com (Postfix) with ESMTP id 29B2F212EEB; Tue, 22 Oct 2002 18:03:39 -0700 (PDT) Received: by perrin.int.nxad.com (Postfix, from userid 1001) id DD98520F02; Tue, 22 Oct 2002 18:03:37 -0700 (PDT) Date: Tue, 22 Oct 2002 18:03:37 -0700 From: Sean Chittenden To: Bill Coutinho Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Jail subsystem + 802.1Q VLANs Message-ID: <20021023010337.GC33299@perrin.int.nxad.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-PGP-Key: finger seanc@FreeBSD.org X-PGP-Fingerprint: 6CEB 1B06 BFD3 70F6 95BE 7E4D 8E85 2E0A 5F5B 3ECB X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I've read about the Jail subsystem, and learned that each jailed > process is bound to an specific IP address ("ip_number" field in > "struct jail"). That's fine, but my question is: > > Is it possible to associate a jailed process to a VLAN number in a > 802.1Q enabled net interface? I believe with the patch posted by Marko Zec at http://www.tel.fer.hr/zec/BSD/vimage/ would make it possible. Are there other comments/thoughts about this patch? It basically lets you create multiple network stacks as virtual networks. A chump example would be a BSD system with four nics, and two nics in each virtual network. It'd be possible to do static routing on each of the virtual networks so that there would be two default routes on a single system. With my network admin hat on, this work is really interesting to me because it means I can cram a BSD router into broken network topologies where other products/os'es can't be wedged. Could the various net code guru's please review this? -sc -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 22 23:23:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8858D37B401; Tue, 22 Oct 2002 23:23:23 -0700 (PDT) Received: from axe-inc.co.jp (axegw.axe-inc.co.jp [61.199.217.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0921A43E65; Tue, 22 Oct 2002 23:23:22 -0700 (PDT) (envelope-from tanimura@axe-inc.co.jp) Received: from t-axegw.t.axe-inc.co.jp ([218.230.241.250]) by axe-inc.co.jp (8.9.3+3.2W/3.7W) with ESMTP id PAA10522; Wed, 23 Oct 2002 15:23:19 +0900 (JST) Received: from shojaku.t.axe-inc.co.jp ([192.168.6.103]) by t-axegw.t.axe-inc.co.jp (8.12.6/3.7W-Axe-Gwhost-Tokyo) with ESMTP id g9N6Mn14072417 ; Wed, 23 Oct 2002 15:22:49 +0900 (JST) Received: from shojaku.t.axe-inc.co.jp.t.axe-inc.co.jp (localhost [127.0.0.1]) by shojaku.t.axe-inc.co.jp (8.12.6/3.7W-Axe-Tokyo-NoARR) with ESMTP id g9N6MmoK065433 ; Wed, 23 Oct 2002 15:22:48 +0900 (JST) Message-Id: <200210230622.g9N6MmoK065433@shojaku.t.axe-inc.co.jp> Date: Wed, 23 Oct 2002 15:22:48 +0900 From: Seigo Tanimura To: arch@FreeBSD.org Cc: tanimura@axe-inc.co.jp, tanimura@FreeBSD.org Subject: Review Request (Re: Dynamic growth of the buffer and buffer page reclaim) In-Reply-To: <200210220949.g9M9nroK026750@shojaku.t.axe-inc.co.jp> References: <200210220949.g9M9nroK026750@shojaku.t.axe-inc.co.jp> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-1?Q?Kashiharajing=FE-mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: AXE, Inc. MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Could anyone interested please review my patch before I either commit it or proceed further? Possible Issues: 1. Fragmentation of the KVA space If fragmentation goes too bad, we have to reclaim the KVA space of the buffers in the clean queue. One solution: let a kernel thread (the page scanner? or the buffer daemon?) scan the buffers in the clean queue periodically. If there is a buffer where its first page is reclaimed(*), give up the KVA space of the buffer and move it to the EMPTYKVA queue. The unreclaimed pages of that buffer will hopefully stay cached in the backing VM object. (*) The address of the pages in a buffer must start at b_kvabase. 2. Lock of buffers and pages A buffer may need locked across vfs_{un,re}wirepages(). The page queue mutex locks the object and the pindex of a page in vfs_rewirepages(), so it should hopefully safe. (but not sure) TIA. On Tue, 22 Oct 2002 18:49:53 +0900, Seigo Tanimura said: tanimura> Introduction: tanimura> The I/O buffer of the kernel are currently allocated in buffer_map tanimura> sized statically upon boot, and never grows. This limits the scale of tanimura> I/O performance on a host with large physical memory. We used to tune tanimura> NBUF to cope with that problem. This workaround, however, results in tanimura> a lot of wired pages not available for user processes, which is not tanimura> acceptable for memory-bound applications. tanimura> In order to run both I/O-bound and memory-bound processes on the same tanimura> host, it is essential to achieve: tanimura> A) allocation of buffer from kernel_map to break the limit of a map tanimura> size, and tanimura> B) page reclaim from idle buffers to regulate the number of wired tanimura> pages. tanimura> The patch at: tanimura> http://people.FreeBSD.org/~tanimura/patches/dynamicbuf.diff.gz tanimura> implements buffer allocation from kernel_map and reclaim of buffer tanimura> pages. With this patch, make kernel-depend && make kernel completes tanimura> about 30-60 seconds faster on my PC. tanimura> Implementation in Detail: tanimura> A) is easy; first you need to do s/buffer_map/kernel_map/. Since an tanimura> arbitrary number of buffer pages can be allocated dynamically, buffer tanimura> headers (struct buf) should be allocated dynamically as well. Glue tanimura> them together into a list so that they can be traversed by boot() tanimura> et. al. tanimura> In order to accomplish B), we must find buffers both the filesystem tanimura> and I/O codes will not touch. The clean buffer queue holds such the tanimura> buffers. (exception: if the vnode associated with a clean buffer is tanimura> held by the namecache, it may access the buffer page.) Thus, we tanimura> should unwire the pages of a buffer prior to enqueuing it to the clean tanimura> queue, and rewire the pages down in bremfree() if the pages are not tanimura> reclaimed. tanimura> Although unwiring gives a page a chance of being reclaimed, we can go tanimura> further. In Solaris, it is known that file cache pages should be tanimura> reclaimed prior to the other kinds of pages (anonymous, executable, tanimura> etc.) for a better performance. Mainly due to a lack of time to work tanimura> on distinguishing the kind of a page to be unwired, I simply pass all tanimura> unwired pages to vm_page_dontneed(). This approach places most of the tanimura> unwired buffer pages at just one step to the cache queue. tanimura> Experimental Evaluation and Results: tanimura> The times taken to complete make kernel-depend && make kernel just tanimura> after booting into single-user mode have been measured on my ThinkPad tanimura> 600E (CPU: Pentium II 366MHz, RAM: 160MB) by time(1). The number tanimura> passed to the -j option of make(1) has been varied from 1 to 30 in tanimura> order to control the pressure of the memory demand for user processes. tanimura> The baseline is the kernel without my patch. tanimura> The following table shows the results. All of the times are in tanimura> seconds. tanimura> -j baseline w/ my patch tanimura> real user sys real user sys tanimura> 1 1608.21 1387.94 125.96 1577.88 1391.02 100.90 tanimura> 10 1576.10 1360.17 132.76 1531.79 1347.30 103.60 tanimura> 20 1568.01 1280.89 133.22 1509.36 1276.75 104.69 tanimura> 30 1923.42 1215.00 155.50 1865.13 1219.07 113.43 tanimura> Most of the improvements in the real times are accomplished by the tanimura> speedup of system calls. The hit ratio of getblk() may be increased, tanimura> but not examined yet. tanimura> Another interesting results are the numbers of swaps, shown below. tanimura> -j baseline w/ my patch tanimura> 1 0 0 tanimura> 10 0 0 tanimura> 20 141 77 tanimura> 30 530 465 tanimura> Since the baseline kernel does not free buffer pages at all(*), it may tanimura> be putting a pressure on the pages too much. tanimura> (*) bfreekva() is called only when the whole KVA is too fragmented. tanimura> Userland Interfaces: tanimura> The sysctl variable vfs.bufspace now reports the size of the pages tanimura> allocated for buffer, both wired and unwired. A new sysctl variable, tanimura> vfs.bufwiredspace tells the size of the buffer pages wired down. tanimura> vfs.bufkvaspace returns the size of the KVA space for buffer. tanimura> Future Works: tanimura> The handling of unwired pages can be improved by scanning only buffer tanimura> pages. In that case, we may have to run the vm page scanner more tanimura> frequently, as does Solaris. tanimura> vfs.bufspace does not track the buffer pages reclaimed by the page tanimura> scanner. They are counted when the buffer associated with those pages tanimura> are removed from the clean queue, which is too late. tanimura> Benchmark tools concentrating on disk I/O performance (bonnie, iozone, tanimura> postmark, etc) may be more suitable than make kernel for evaluation. tanimura> Comments and flames are welcome. Thanks a lot. tanimura> -- tanimura> Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 23 10:25:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 377F837B401; Wed, 23 Oct 2002 10:25:55 -0700 (PDT) Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F38143E42; Wed, 23 Oct 2002 10:25:49 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (zg04-116.dialin.iskon.hr [213.191.137.117]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g9NHOnE15127; Wed, 23 Oct 2002 19:24:53 +0200 (MEST) Message-ID: <3DB6DB7B.F1184FC@tel.fer.hr> Date: Wed, 23 Oct 2002 19:25:15 +0200 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Coutinho Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: BSD network stack virtualization + IEEE 802.1Q References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bill Coutinho wrote: > Sean Chittenden, in FreeBSD-Arch list, pointed me to your "BSD network stack > virtualization" site. > > What I'm trying to achieve is one box with many independent "virtual > servers" (using the Jail subsystem), but with each vistual server attached > to a different VLAN using the same physical NIC. This NIC should be > connected to a switch with the 802.1Q protocol. > > My question is: is it possible to associate a "virtual stack" to a VLAN > number in a 802.1Q enabled net interface, and combine it with the Jail > subsystem "struct jail"? Yes, you can do that with the virtualized network stack very easily, but without using jail(8). Here is a sample step-by-step example, which I hope accomplishes what you want: First, we have to create two new virtual images. Here we also set the hostnames for the new vimages, which is of course not the mandatory step, but makes things more comprehensible: tpx30# vimage -c my_virtual_node1 tpx30# vimage -c my_virtual_node2 tpx30# vimage my_virtual_node1 hostname node1 tpx30# vimage my_virtual_node2 hostname node2 We the create two vlan interfaces, and associate them with the physical ifc and vlan tags: tpx30# ifconfig vlan create vlan0 tpx30# ifconfig vlan create vlan1 tpx30# ifconfig vlan0 vlan 1001 vlandev fxp0 tpx30# ifconfig vlan1 vlan 1002 vlandev fxp0 tpx30# ifconfig fxp0: flags=8843 mtu 1500 inet 192.168.201.130 netmask 0xffffff00 broadcast 192.168.201.255 ether 00:09:6b:e0:d5:fc media: Ethernet autoselect (10baseT/UTP) status: active vlan0: flags=8842 mtu 1500 ether 00:09:6b:e0:d5:fc vlan: 1001 parent interface: fxp0 vlan1: flags=8842 mtu 1500 ether 00:09:6b:e0:d5:fc vlan: 1002 parent interface: fxp0 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 tpx30# Further, we move (reassign) the vlan interfaces to the appropriate virtual images. The vlan ifcs will disappear from the current (master) virtual image: tpx30# vimage -i my_virtual_node1 vlan0 tpx30# vimage -i my_virtual_node2 vlan1 tpx30# ifconfig fxp0: flags=8843 mtu 1500 inet 192.168.201.130 netmask 0xffffff00 broadcast 192.168.201.255 ether 00:09:6b:e0:d5:fc media: Ethernet autoselect (10baseT/UTP) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 tpx30# Now we spawn a new interactive shell in one of the created virtual images. We can now manage the interfaces in the usual way, start new processes/daemons, configure ipfw... tpx30# vimage my_virtual_node1 Switched to vimage my_virtual_node1 node1# ifconfig vlan0 1.2.3.4 node1# ifconfig vlan0: flags=8843 mtu 1500 inet 1.2.3.4 netmask 0xff000000 broadcast 1.255.255.255 ether 00:09:6b:e0:d5:fc vlan: 1001 parent interface: fxp0@master lo0: flags=8008 mtu 16384 node1# inetd node1# exit Note that you won`t be able to change the vlan tag and/or parent interface inside the virtual image where vlan interface resides, but only in the virtual image that contains the physical interface (that was the "master" vimage in this example). Finally, here is the summary output from vimage -l command issued in the master virtual image: tpx30# vimage -l "master": 37 processes, load averages: 0.00, 0.02, 0.00 CPU usage: 0.26% (0.26% user, 0.00% nice, 0.00% system) Nice level: 0, no CPU limit, no process limit, child limit: 15 2 network interfaces, 2 child vimages "my_virtual_node2": 0 processes, load averages: 0.00, 0.00, 0.00 CPU usage: 0.00% (0.00% user, 0.00% nice, 0.00% system) Nice level: 0, no CPU limit, no process limit 2 network interfaces, parent vimage: "master" "my_virtual_node1": 1 processes, load averages: 0.00, 0.00, 0.00 CPU usage: 0.24% (0.20% user, 0.00% nice, 0.04% system) Nice level: 0, no CPU limit, no process limit 2 network interfaces, parent vimage: "master" Hope this helps, Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 23 12:20: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDB0737B401 for ; Wed, 23 Oct 2002 12:20:02 -0700 (PDT) Received: from hotmail.com (f119.sea1.hotmail.com [207.68.163.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id A287343E4A for ; Wed, 23 Oct 2002 12:20:02 -0700 (PDT) (envelope-from kofikwame721@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 23 Oct 2002 12:20:02 -0700 Received: from 216.139.164.203 by sea1fd.sea1.hotmail.msn.com with HTTP; Wed, 23 Oct 2002 19:20:02 GMT X-Originating-IP: [216.139.164.203] From: "kofi kwame" To: Freebsd-arch@freebsd.org Subject: urgent Date: Wed, 23 Oct 2002 19:20:02 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Oct 2002 19:20:02.0470 (UTC) FILETIME=[2F8ED460:01C27AC9] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG TO WHOM IT MAY CONCERN GOOD DAY, MY NAME IS KOFI KWAME I WAS BORN IN LONDON ENGLAND MY PARENT ARE FROM GHANA AND LATER CAME TO GHANA FOR MY SECONDARY SCHOOL EDUCATION. IM 22YEARS OF AGE MY FATHER NAME IS KWAME ADJEYE AND MY MOTHER IS NANASI ADJEYE MY FATHER IS WELL KNOW INDUSRIALIST WHO HAVE MANY INDUSTRY IN EUROPE AND AFRICA. IT WAS A SAD DAY ON THE 10th OF JULY 2001 MY BOTH PARENT WAS ASSASINATED IN COLD BLOODED BY UNKNOW GUNMEN. LEFT MYSELF AND ALITTLE SISTER ORPHAN. LIFE AS NOT BEEN THE SAME AFTER THEN. MY PARENT RELATIVES AS TAKEN OVER MY DADDYS PROPERTY BELEVING I WAS YOUNG AN UNESPOSE EVEN WANTED TO ELIMINATE MYSELF AND YOUNGER SISTER THANK GOD FOR MY DADDYS LAWYER WHOM HAVE BEEN INTRODUCE TO AS THE FIRST AND ONLY SON OF THE FAMILY WHEN I WAS 15YEARS OF AGE . THE LAWYER AS BEEN PART OF US AND HAD REFUSE TO COPRATE WITH MY PARENT RELATIVES TO ELIMINATE US. THE LAWYER AS BRIEF ME ABOUT MY FATHER HUGE INVESTMENT AND ACCOUNT IN AND OUTSIDE THE CONTARY AND ADVICE ME TO SOLICIT FOR ELIGIBLE FOREING PATNER. WHO WE CAN TRANFER THE LARG SUM OF MONEY TO IS ACCOUNT AND CAN BE ABLE TO INVEST THE MONEY PROPERLY THAT IS WHY IM WRITING YOU AND I BELIVE YOU ARE REPUTABLE AND GOD FEARING PERSON AND MUST BE BETWEEN 35&60YEARS OF AGE PLEASE REPLY ME URGENTLY SO TO KNOW IF YOU CAN HELP OR TO FIND ANOTHER PERSON. HOPE TO EXPECT FROM YOU SOON. BEST REGARD. KOFI KWAME _________________________________________________________________ Unlimited Internet access -- and 2 months free!  Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 23 14:43:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACCA337B401 for ; Wed, 23 Oct 2002 14:43:51 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEB3443E42 for ; Wed, 23 Oct 2002 14:43:50 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id g9NLhou13315 for ; Wed, 23 Oct 2002 17:43:50 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 23 Oct 2002 17:43:50 -0400 (EDT) From: Jeff Roberson To: arch@freebsd.org Subject: KVAless IO and buffer cache changes Message-ID: <20021023165651.W22147-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG For some time now I have been discussing various ways that we might address some of our many buffer cache and vm related IO issues. I have been collecting problems from my experiences with FreeBSD in IO intensive large memory environments. Various people have given me feedback over time and based on this I have a design for fixing up our buffer cache. I'd like to bring my proposal to a wider audience now so I can avoid duplicated efforts with other poeple and so that I may get feedback from more than the few developers that I have contacted direcly. First, I'd like to cover some of the problems that I currently see. 1) VFS, VM, filesystems and the buffer cache have no clean layering. The dependencies, duplication of efforts, and call stacks can give anyone a headache. 2) The buf cache has some notion of related pages for IO purposes. This information is not shared with the VM so at pageout and fault time it has and ad-hoc method for doing clustered IO. This leads to different IO strategies depending on whether you're mmaping or doing normal file IO. It can also lead to conflicting efforts. ie, a poorly placed faults can lead to short clustering from vfs_cluster.c 3) In practice, bogus_page is used quite a bit more than you would expect. Again, this is because the vm does not know about related pages. When we free one page that constitutes a buf we should throw away his neighbors as well. In many systems you end up with lots of bufs that are partially free and require extra IO and bogus page replacement. If all pages were thrown away simultaneously when possible, you would end up with the same number of cached pages but a greater number of fully valid bufs. 4) All IO in the system requires KVA even when the kernel is not accessing the resulting memory through virtual addresses. This bogus requirement leads us to have things like pbufs. It also means our buffer cache must take up a big chunk of KVA. These two resources are deadlock prone and fragmentation prone. Also, maping and unmaping these things can be very expensive. Right now we map bufs in vfs_bio just so they can be unmapped again in bus dma. 5) msync and fsync are seperate operations that really could be merged. There is a duplication of efforts all over the vm and buf interfaces because we have two systems that are trying to achive similar effects. As you can see, there are very real performance penalties with the current arrangement. In addition, this code is overly complicated because it is not well abstracted. vfs_bio is trying to do too many things. I'm proposing the following: A vectorized, address space tagged bio with queue points for delayed IO. This will allow us to do IO to physical addresses. It would make bio look more like UIO, but instead of iovecs we might want to try bus dma segments. In addition to this, the delayed write layer should be a small module that deals only with bios. This would require making bio a real object to support the many users. Once this is done pbufs could go away entirely. The vm could do IO entirely through get/put pages directly to physical memory. The relationship of pages that comprise a block should be pushed into the vnode pager. This layer would take a request for an individual page and translate that into a group of pages that io could be done on. This way the clustering for vm fault and vm pageout would be explicit and on reasonable boundaries. It would also give you an oportunity to do read ahead and clustering from a centralized place. All IO to vnodes should go through this layer. Bufs would be reduced to kva containers and dependency trackers for file system metadata. They could be attached to a vnode pager block, anonymous memory, or malloced data just as they are now. For the latter two they would have an embedded bio that would use the delayed write interface. The vnode pager would have it's own bio for manging delayed writes. This change would have minimal impact on the filesystem. The currently use bread et all when dealing with metadata. They are already telling the buf system when they actually want to look at the contents of a buf. The filesystem read/write routines could then be modified to bypass this layer and talk directly to the vnode pager. I have many pages of design notes. If there is enough interest I could write up a formal design proposal. Any feedback is welcome. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 23 15: 8:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A68C37B401 for ; Wed, 23 Oct 2002 15:08:22 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED76643E42 for ; Wed, 23 Oct 2002 15:08:20 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9NM8An4047467; Thu, 24 Oct 2002 00:08:10 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Jeff Roberson Cc: arch@FreeBSD.ORG Subject: Re: KVAless IO and buffer cache changes In-Reply-To: Your message of "Wed, 23 Oct 2002 17:43:50 EDT." <20021023165651.W22147-100000@mail.chesapeake.net> Date: Thu, 24 Oct 2002 00:08:10 +0200 Message-ID: <47466.1035410890@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20021023165651.W22147-100000@mail.chesapeake.net>, Jeff Roberson wr ites: >A vectorized, address space tagged bio with queue points for delayed IO. Sold, as I just said, first ting after the next branch. >This will allow us to do IO to physical addresses. It would make bio look >more like UIO, but instead of iovecs we might want to try bus dma >segments. Sound right to me. >In addition to this, the delayed write layer should be a small >module that deals only with bios. This would require making bio a real >object to support the many users. It will take some convincing before you get me in on this one: bio is not and should not become an object, it is a communication protocol for disk-like I/O. [Various stuff which sounds right to me] >For the latter two they >would have an embedded bio that would use the delayed write interface. This is related to the above. I think we should loose the buf-embedded bio as soon as we can. The new_bio/clone_bio/delete_bio from GEOM should probably be pulled out to a more generic place and twisted to use UMA. >I have many pages of design notes. If there is enough interest I could >write up a formal design proposal. That would be very welcome! Just do me the favour of thinking of struct bio as a way to bundle up the parameters of an I/O request and nothing more. If you need a true object for mitigating access and keeping state, struct bio isn't the right place to do it, because GEOM and device drivers are not interested in that state, and they may create and spawn new bios using opaque methods and we will have no way to make sure the right, if even any, attributes get correctly mapped over. There _will_ be a VM interaction from GEOM/drivers because various GEOM classes or device drivers may need either physical or mapped access to the vector before/after access or modifications. -- 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 Oct 23 15:18:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B566837B401 for ; Wed, 23 Oct 2002 15:18:20 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 202C943E42 for ; Wed, 23 Oct 2002 15:18:20 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id g9NMIE628460; Wed, 23 Oct 2002 18:18:14 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 23 Oct 2002 18:18:14 -0400 (EDT) From: Jeff Roberson To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: KVAless IO and buffer cache changes In-Reply-To: <47466.1035410890@critter.freebsd.dk> Message-ID: <20021023181051.A22147-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 24 Oct 2002, Poul-Henning Kamp wrote: > In message <20021023165651.W22147-100000@mail.chesapeake.net>, Jeff Roberson wr > ites: > > >In addition to this, the delayed write layer should be a small > >module that deals only with bios. This would require making bio a real > >object to support the many users. > > It will take some convincing before you get me in on this one: bio > is not and should not become an object, it is a communication > protocol for disk-like I/O. > Well, the motivation for this is that we have many differnt memory containers that all want to do IO. For example, we have memory backed bufs, anonymous bufs, and the proposed vnode pager backed bufs. All of these things want delayed IO and they all will need a bio. The delayed IO bits could be kept seperate from the bio structure though. This would make it a very thin layer above bio that is not visible to the lower layers. I understand the aversion to the buf/bio tangle. > > [Various stuff which sounds right to me] > > >For the latter two they > >would have an embedded bio that would use the delayed write interface. > > This is related to the above. I think we should loose the buf-embedded > bio as soon as we can. Yes, definitely. That is a component of my approach. > > The new_bio/clone_bio/delete_bio from GEOM should probably be pulled > out to a more generic place and twisted to use UMA. > > >I have many pages of design notes. If there is enough interest I could > >write up a formal design proposal. > > That would be very welcome! > > Just do me the favour of thinking of struct bio as a way to bundle > up the parameters of an I/O request and nothing more. Duly noted. > > If you need a true object for mitigating access and keeping state, > struct bio isn't the right place to do it, because GEOM and device > drivers are not interested in that state, and they may create > and spawn new bios using opaque methods and we will have no way > to make sure the right, if even any, attributes get correctly > mapped over. > > There _will_ be a VM interaction from GEOM/drivers because various > GEOM classes or device drivers may need either physical or mapped > access to the vector before/after access or modifications. > Yes, I think this could be achieved through private, short term mapping functions for physical IO. It would be like pager bufs but of a much more limited use. Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 23 15:20: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 414C137B401 for ; Wed, 23 Oct 2002 15:20:08 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23EB743E97 for ; Wed, 23 Oct 2002 15:20:07 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.3/8.12.3) with ESMTP id g9NMJv59010962; Wed, 23 Oct 2002 15:19:58 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200210232219.g9NMJv59010962@beastie.mckusick.com> To: Jeff Roberson Subject: Re: KVAless IO and buffer cache changes Cc: arch@FreeBSD.ORG In-Reply-To: Your message of "Wed, 23 Oct 2002 17:43:50 EDT." <20021023165651.W22147-100000@mail.chesapeake.net> Date: Wed, 23 Oct 2002 15:19:57 -0700 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Overall I am in agreement with your plan. The devil of course is in getting the details right. I would welcome seeing more of your design notes. The breakout of the I/O portion of current bufs into a struct bio was the first (necessary) step in moving in the direction that I think you are proposing. The struct bio holds the I/O request while all the identity and related filesystem state remains in the struct buf. Whether it is sensible to continue keeping all this state in struct buf, or splitting struct buf into two distinct objects is still an open question in my mind. In any event, it is important that state not get pushed into the struct bio which should remain purely as an I/O work request. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 23 17:31:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D27337B401; Wed, 23 Oct 2002 17:31:27 -0700 (PDT) Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E5943E3B; Wed, 23 Oct 2002 17:31:25 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (zg05-053.dialin.iskon.hr [213.191.138.54]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g9O0UIE24123; Thu, 24 Oct 2002 02:30:21 +0200 (MEST) Message-ID: <3DB73F31.5F02609C@tel.fer.hr> Date: Thu, 24 Oct 2002 02:30:41 +0200 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: "J. 'LoneWolf' Mattsson" , freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: RFC: BSD network stack virtualization References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > I'm very impressed. I do however have some questions. > (I have not read the code yet, just the writeup) > > 1/ How do you cope with each machine expecting to have it's own loopback > interface? Is it sufficient to make lo1 lo2 lo3 etc. and attache them > to the appropriate VMs? The creation of "lo0" interface is done "automatically" at the time of creation of each new virtual image instance. The BSD networking code generally assumes the "lo0" interface exists all the times, so it just wouldn't be possible to create a network stack instance without a unique "lo" ifc. > 2/ How much would be gained (i.e. is it worth it) to combine this with > jail? Can you combine them? (does it work?) Does it make sense? Userland separation (hiding) between processes running in different virtual images is actually accomplished by reusing the jail framework. The networking work is completely free of jail legacy. Although I didn't test it, I'm 100% sure it should be possible to run multiple jails inside each of virtual images. For me it doesn't make too much sense though, that's why I didn't bother with testing... > 3/ You implemented this in 4.x which means that we need to reimplement > it in -current before it has any chance of being 'included'. Do you > think that would be abig problem? I must admit that I do not follow the development in -current, so it's hard to tell how much the network stacks have diverted in the areas affected by virtualization work. My initial intention was to "polish" the virtualization code on the 4.x platform - there are still some major chunks of coding yet to be done, such as removal of virtual images, and patching of IPv6 and IPSEC code. Hopefully this will be in sync with the release of 5.0, so than I can spend some time porting it to -current. However, if reasonable demand is created, I'm prepared to revise that approach... > 5/ Does inclusion of the virtualisation have any measurable effect on > throughputs for systems that are NOT using virtualisation. In other > words, does the non Virtualised code-path get much extra work? (doi you > have numbers?) (i.e. does it cost much for the OTHER users if we > incorporated this into FreeBSD?) The first thing in my pipeline is doing decent performance/throughput measurements, but these days I just cannot find enough spare time for doing that properly (I still have a daytime job...). The preliminary netperf tests show around 1-2% drop in maximum TCP throughput on loopback with 1500 bytes MTU, so in my opinion this is really a neglectable penalty. Of course, the applications limited by media speed won't experience any throughput degradation, except probably hardly measurable increase in CPU time spent in interrupt context. > 6/ I think that your ng_dummy node is cute.. > can I commit it separatly? (after porting it to -current..) Actually, this code is ugly, as I was stupid enough to invent my own queue management methods, instead of using the existing ones. However, from the user perspective the code seems to work without major problems, so if you want to commit it I would be glad... > 7/ the vmware image is a great idea. > > 8/ can you elaborate on the following: > * hiding of "foreign" filesystem mounts within chrooted virtual images Here is an self-explaining example of hiding "foreign" filesystem mounts: tpx30# vimage -c test1 chroot /opt/chrooted_vimage tpx30# mount /dev/ad0s1a on / (ufs, local, noatime) /dev/ad0s1g on /opt (ufs, local, noatime, soft-updates) /dev/ad0s1f on /usr (ufs, local, noatime, soft-updates) /dev/ad0s1e on /var (ufs, local, noatime, soft-updates) mfs:22 on /tmp (mfs, asynchronous, local, noatime) /dev/ad0s2 on /dos/c (msdos, local) /dev/ad0s5 on /dos/d (msdos, local) /dev/ad0s6 on /dos/e (msdos, local) procfs on /proc (procfs, local) procfs on /opt/chrooted_vimage/proc (procfs, local) /usr on /opt/chrooted_vimage/usr (null, local, read-only) tpx30# vimage test1 Switched to vimage test1 %mount procfs on /proc (procfs, local) /usr on /usr (null, local, read-only) % > 9/ how does VIPA differ from the JAIL address binding? Actually, VIPA feature should be considered completely independent of network stack virtualization work. The jail address is usually bound to an alias address configured on a physical interface. When this interface goes down, all the connections using this address drop dead instantly. VIPA is a loopback-type internal interface that will always remain up regardless of the physical network topology changes. If the system has multiple physical interfaces, and an alternative path can be established following an NIC or network route outage, the connections bound to VIPA will survive. Anyhow, the idea is borrowed from IBM's OS/390 TCP/IP implementation, so you can find more on this concept on http://www-1.ibm.com/servers/eserver/zseries/networking/vipa.html > 10/ could you use ng_eiface instead of if_ve? Most probably yes, but my system crashed each time when trying to configure ng_eiface, so I just took another path and constructed my own stub ethernet interface... > 11/ why was ng_bridge unsuitable for your use? Both the native and netgraph bridging code, I believe, were designed with the presumption that only one "upper" hook is really needed to establish the communication to kernel's single network stack. However, this concept doesn't hold on a kernel with multiple network stacks. I just picked the native bridging code first and extended it to support hooking to multiple "upper" hooks. The similar extensions have yet to be applied to ng_bridge, I just didn't have time to implement the same functionality in two different frameworks. > 12/ can you elaborate on the following: > # fix netgraph interface node naming > # fix the bugs in base networking code (statistics in > "native" bridging, additional logic for ng_bridge...) When the interface is moved to a different virtual image, it's unit number gets reassigned, so the interface that was named say "vlan3" in the master virtual image, will become "vlan0" when assigned to the child. The same thing happens when the child virtual image returns the interface back to its parent. The naming of netgraph nodes associated with interfaces (ng_iface, ng_ether) should be updated accordingly, which is currently not done. I also considered virtualizing a netgraph stack, this would be also very cool if each virtual image could manage its own netgraph tree. However, when weighting implementation priorities, I concluded that this was something that could wait for other more basic things to be reworked properly first. Therefore in the current implementation it is possible to manage the netgraph subsystem only from the "master" virtual image. Hope this was enough elaboration for actually testing the code :) Have fun, Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 23 18: 0:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF77537B401; Wed, 23 Oct 2002 18:00:14 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3727043E4A; Wed, 23 Oct 2002 18:00:14 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021024010013.DUCD24829.sccrmhc01.attbi.com@InterJet.elischer.org>; Thu, 24 Oct 2002 01:00:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA38117; Wed, 23 Oct 2002 17:43:46 -0700 (PDT) Date: Wed, 23 Oct 2002 17:43:45 -0700 (PDT) From: Julian Elischer To: Marko Zec Cc: "J. 'LoneWolf' Mattsson" , freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: RFC: BSD network stack virtualization In-Reply-To: <3DB73F31.5F02609C@tel.fer.hr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 24 Oct 2002, Marko Zec wrote: > Julian Elischer wrote: > > > > 11/ why was ng_bridge unsuitable for your use? > > Both the native and netgraph bridging code, I believe, were designed with > the presumption that only one "upper" hook is really needed to establish the > communication to kernel's single network stack. However, this concept > doesn't hold on a kernel with multiple network stacks. I just picked the > native bridging code first and extended it to support hooking to multiple > "upper" hooks. The similar extensions have yet to be applied to ng_bridge, I > just didn't have time to implement the same functionality in two different > frameworks. ng_bridge doesn't really distinguish between hooks to upper and lower detinations. it only knows wha tMAC addresses are seen to come from each hook and ensures that packets destined to those addresses are sent to those hooks.. you can have as many 'upper' hooks as you wish (and there are some uses for that). > > > 12/ can you elaborate on the following: > > # fix netgraph interface node naming > > # fix the bugs in base networking code (statistics in > > "native" bridging, additional logic for ng_bridge...) > > When the interface is moved to a different virtual image, it's unit number > gets reassigned, so the interface that was named say "vlan3" in the master > virtual image, will become "vlan0" when assigned to the child. The same > thing happens when the child virtual image returns the interface back to its > parent. The naming of netgraph nodes associated with interfaces (ng_iface, > ng_ether) should be updated accordingly, which is currently not done. > I also considered virtualizing a netgraph stack, this would be also very > cool if each virtual image could manage its own netgraph tree. However, when > weighting implementation priorities, I concluded that this was something > that could wait for other more basic things to be reworked properly first. > Therefore in the current implementation it is possible to manage the > netgraph subsystem only from the "master" virtual image. > > Hope this was enough elaboration for actually testing the code :) it's difficult because my test machines run -current (my 4.x machines are dedicated to production purposes though I may be able try with one.. > > Have fun, Thankyou.. p.s. I should drop down to Croatia next time I'm in Budapest. I'm told it's beautiful. p.p.s cute bear cubs on your site! > > Marko > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 24 9:17:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F23537B401 for ; Thu, 24 Oct 2002 09:17:45 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38B3543E6E for ; Thu, 24 Oct 2002 09:17:44 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g9OGHAOo084779 for ; Thu, 24 Oct 2002 12:17:10 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 24 Oct 2002 12:17:09 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Following my missing a commit to the lukemftpd Makefile yesterday, I took the opportunity to peruse its source code since it sounded like there was some movement in the direction of using lukemftpd by default in future versions of FreeBSD. I was deeploy concerned by the fact that I was unable to find any of the standard user context and login management code for FreeBSD in there, including no visible support for: - Pluggable Authentication Modules (PAM) in any form, meaning that support for any non-hard-coded authentication mechanisms is broken -- specifically, OPIE, hardware authentication tokens, smart card authentication, pam_ldap, etc. - Any login.conf features, including resources limits, per-user nologin file, personalized motd and license information, MAC. It seems to implement its own limit mechanism using a class set completely independent from login.conf, but doesn't support things like maximum file size, stack size, etc. Among other things, this means that documented mechanisms for preventing user login are broken, and system protections are not properly enforced. In the past, we've relied on those protections to reduce the impact of vulnerabilities -- for example, the use of resource limits to reduce the impact of the glob memory allocation vulnerabilities. cboss:/cboss/freebsd/commit/src/contrib/lukemftpd/src> grep -i PAM * cboss:/cboss/freebsd/commit/src/contrib/lukemftpd/src> grep -i usercontext * cboss:/cboss/freebsd/commit/src/contrib/lukemftpd/src> grep -i logincontext * Also, there seems to be some confusion regarding man pages: ftpd(8) is our native ftpd man page, but ftpd.conf implies that lukemftpd is the default. Given that lukemftpd is highly feature incomplete with regards to the default ftpd, I'd like to propose at least the following: (1) All references to lukemftpd as "the ftpd" be corrected to indicate lukemftpd is not the default. Most of these are leaked references from lukemftpd man pages that were not updated in the import. (2) Remove reference to lukemftpd in inetd.conf: it looks a little silly to have a warning there, and the only purpose of listing something in inetd.conf is if you plan to have it be the one users turn on. If we don't remove it, the warning should stay, but the entry should be shifted down to the bottom of the file. (3) The lukemftpd man pages should be updated to have a clear feature completeness warning using much the same language from my commit message. (4) The release notes indicating lukemftpd has been imported should be updated to indicate it is not the "default" and that it is feature incomplete. If there are plans to implement the missing features, then it may be reasonable to keep it in the tree. If there are no plans to fix these problems, it may make sense to remove it from the tree, or at least disconnect it from the build to prevent serious foot-shooting. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories ---------- Forwarded message ---------- Date: Thu, 24 Oct 2002 08:46:10 -0700 (PDT) From: Robert Watson To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/etc inetd.conf rwatson 2002/10/24 08:46:10 PDT Modified files: etc inetd.conf Log: # WARNING: lukemftpd does not support PAM, MAC, per-class nologin files, # or any login.conf resource limits or features; use it only if this is # appropriate for your environment. If you require these features, use # the regular FreeBSD ftpd below. Discourage users from using lukemftpd if they rely any of these standard FreeBSD features that are fully supported by our native ftpd. There may be other features that are not yet supported that I have not yet discovered. Revision Changes Path 1.59 +5 -0 src/etc/inetd.conf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 24 11:38:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEC9737B401 for ; Thu, 24 Oct 2002 11:38:53 -0700 (PDT) Received: from opiate.thirteenandtwo.org (CPE0030ab0ef2bb.cpe.net.cable.rogers.com [24.103.202.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id E33AD43E77 for ; Thu, 24 Oct 2002 11:38:46 -0700 (PDT) (envelope-from munish@opiate.thirteenandtwo.org) Received: from opiate.thirteenandtwo.org (munish@localhost.thirteenandtwo.org [127.0.0.1]) by opiate.thirteenandtwo.org (8.12.6/8.12.6) with ESMTP id g9OIcdG5004969 for ; Thu, 24 Oct 2002 14:38:40 -0400 (EDT) (envelope-from munish@opiate.thirteenandtwo.org) Received: (from munish@localhost) by opiate.thirteenandtwo.org (8.12.6/8.12.6/Submit) id g9OIcdNn004964 for arch@FreeBSD.ORG; Thu, 24 Oct 2002 14:38:39 -0400 (EDT) Date: Thu, 24 Oct 2002 14:38:39 -0400 From: Munish Chopra To: arch@FreeBSD.ORG Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Message-ID: <20021024183839.GB601@opiate.thirteenandtwo.org> Mail-Followup-To: arch@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-10-24 12:17 +0000, Robert Watson wrote: > [snip] > > If there are plans to implement the missing features, then it may be > reasonable to keep it in the tree. If there are no plans to fix these > problems, it may make sense to remove it from the tree, or at least > disconnect it from the build to prevent serious foot-shooting. > I actually shot myself in the foot pretty nicely some four or five months ago when I got wind of lukemftpd in the base system, and the fact that it was seemingly being touted as a replacement for our stock ftpd. After checking around a bit I was interested in a few of the features it offered and started playing around with it, only to find out that half of them didn't really work for various reasons, including those quoted in the parent to this thread. I tried to do what I could to start fixing things up (not PAM or anything though - I'm not exactly a coder), among others I had brief exchanges with David O'Brien and Yar Tikhiy, but nothing since then. I also contacted Luke Mewburn, who seemed very open to changes and enchancements, it seems like he just doesn't have time to do much with it himself at the moment. So this is just a heads-up to anyone with more clue than me, if you like lukemftpd the author is open to changes, so it wouldn't be a nightmare to maintain in base unlike if we resorted to a massive patchset. -- Munish Chopra To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 24 13:44:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8BB737B401 for ; Thu, 24 Oct 2002 13:44:48 -0700 (PDT) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 347FC43E65 for ; Thu, 24 Oct 2002 13:44:47 -0700 (PDT) (envelope-from keramida@FreeBSD.org) Received: (qmail 4332 invoked from network); 24 Oct 2002 20:37:36 -0000 Received: from upnet-dialinpool-7.upnet.gr (HELO LocalHost) (150.140.128.247) by nic.upatras.gr with SMTP; 24 Oct 2002 20:37:36 -0000 Message-ID: <004f01c27b9e$372647a0$f7808c96@LocalHost> From: "Giorgos Keramidas" To: "Munish Chopra" , References: <20021024183839.GB601@opiate.thirteenandtwo.org> Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Date: Thu, 24 Oct 2002 23:43:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Munish Chopra wrote: : On 2002-10-24 12:17 +0000, Robert Watson wrote: : > If there are plans to implement the missing features, then it may be : > reasonable to keep it in the tree. If there are no plans to fix = these : > problems, it may make sense to remove it from the tree, or at least : > disconnect it from the build to prevent serious foot-shooting. : [...] : I tried to do what I could to start fixing things up (not PAM or : anything though - I'm not exactly a coder), among others I had brief : exchanges with David O'Brien and Yar Tikhiy, but nothing since then. : I also contacted Luke Mewburn, who seemed very open to changes and : enchancements, it seems like he just doesn't have time to do much with : it himself at the moment. : : So this is just a heads-up to anyone with more clue than me, if you = like : lukemftpd the author is open to changes, so it wouldn't be a nightmare : to maintain in base unlike if we resorted to a massive patchset. Indeed... Luke Mewburn is a very nice fellow. All the email exchanges I've had with him, regarding NetBSD or other sources, have been polite, full of useful facts and information, and more importantly quick. I'm not exactly suggesting anything here (like someone jumping up and saying "I will"); just making sure that the author of lukemftp and lukemftpd is contacted before any decision is made. Giorgos. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 24 19:12:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF66637B401; Thu, 24 Oct 2002 19:12:19 -0700 (PDT) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7591D43E65; Thu, 24 Oct 2002 19:12:18 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 34632812EA; Fri, 25 Oct 2002 11:42:16 +0930 (CST) Date: Fri, 25 Oct 2002 11:42:16 +0930 From: Greg 'groggy' Lehey To: Giorgos Keramidas Cc: Munish Chopra , arch@FreeBSD.ORG Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Message-ID: <20021025021216.GE73214@wantadilla.lemis.com> References: <20021024183839.GB601@opiate.thirteenandtwo.org> <004f01c27b9e$372647a0$f7808c96@LocalHost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004f01c27b9e$372647a0$f7808c96@LocalHost> User-Agent: Mutt/1.4i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thursday, 24 October 2002 at 23:43:17 +0300, Giorgos Keramidas wrote: > Munish Chopra wrote: >> On 2002-10-24 12:17 +0000, Robert Watson wrote: >>> If there are plans to implement the missing features, then it may be >>> reasonable to keep it in the tree. If there are no plans to fix these >>> problems, it may make sense to remove it from the tree, or at least >>> disconnect it from the build to prevent serious foot-shooting. >> [...] >> I tried to do what I could to start fixing things up (not PAM or >> anything though - I'm not exactly a coder), among others I had brief >> exchanges with David O'Brien and Yar Tikhiy, but nothing since then. >> I also contacted Luke Mewburn, who seemed very open to changes and >> enchancements, it seems like he just doesn't have time to do much with >> it himself at the moment. >> >> So this is just a heads-up to anyone with more clue than me, if you like >> lukemftpd the author is open to changes, so it wouldn't be a nightmare >> to maintain in base unlike if we resorted to a massive patchset. > > Indeed... > > Luke Mewburn is a very nice fellow. All the email exchanges I've > had with him, regarding NetBSD or other sources, have been polite, > full of useful facts and information, and more importantly quick. Agreed. > I'm not exactly suggesting anything here (like someone jumping up > and saying "I will"); just making sure that the author of lukemftp > and lukemftpd is contacted before any decision is made. Luke is also very concerned about compatibility between the BSDs. It's understandable that lukemftpd (currently) doesn't support FreeBSD-specific features, but I'm sure that he'd be interested in maintaining the features in some form. Has anybody asked him? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 24 19:18:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67F3F37B401; Thu, 24 Oct 2002 19:18:23 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-165-226-88.dsl.lsan03.pacbell.net [64.165.226.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id D88BC43E6E; Thu, 24 Oct 2002 19:18:22 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 56E5066C7B; Thu, 24 Oct 2002 19:18:22 -0700 (PDT) Date: Thu, 24 Oct 2002 19:18:22 -0700 From: Kris Kennaway To: Greg 'groggy' Lehey Cc: Giorgos Keramidas , Munish Chopra , arch@FreeBSD.ORG Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Message-ID: <20021025021821.GA59875@xor.obsecurity.org> References: <20021024183839.GB601@opiate.thirteenandtwo.org> <004f01c27b9e$372647a0$f7808c96@LocalHost> <20021025021216.GE73214@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <20021025021216.GE73214@wantadilla.lemis.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 25, 2002 at 11:42:16AM +0930, Greg 'groggy' Lehey wrote: > Luke is also very concerned about compatibility between the BSDs. > It's understandable that lukemftpd (currently) doesn't support > FreeBSD-specific features, but I'm sure that he'd be interested in > maintaining the features in some form. Has anybody asked him? The issue here is not (yet) "Who will maintain this FreeBSD-specific code?" but "Who will write this FreeBSD-specific code?". Kris --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9uKntWry0BWjoQKURAtNnAKCU/wWfrx4mVM+2fpWUHBJLcyRY2ACg0nmE Dop9E5/UVpygaqkgNS4+aOM= =Fxoj -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 24 20:12:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE12F37B407 for ; Thu, 24 Oct 2002 20:12:23 -0700 (PDT) Received: from opiate.thirteenandtwo.org (CPE0030ab0ef2bb.cpe.net.cable.rogers.com [24.103.202.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCBB643E6E for ; Thu, 24 Oct 2002 20:12:11 -0700 (PDT) (envelope-from munish@opiate.thirteenandtwo.org) Received: from opiate.thirteenandtwo.org (munish@localhost.thirteenandtwo.org [127.0.0.1]) by opiate.thirteenandtwo.org (8.12.6/8.12.6) with ESMTP id g9P3BwG5060730 for ; Thu, 24 Oct 2002 23:12:00 -0400 (EDT) (envelope-from munish@opiate.thirteenandtwo.org) Received: (from munish@localhost) by opiate.thirteenandtwo.org (8.12.6/8.12.6/Submit) id g9P3Bwbx060729 for arch@FreeBSD.ORG; Thu, 24 Oct 2002 23:11:58 -0400 (EDT) Date: Thu, 24 Oct 2002 23:11:57 -0400 From: Munish Chopra To: arch@FreeBSD.ORG Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Message-ID: <20021025031157.GB5218@opiate.thirteenandtwo.org> Mail-Followup-To: arch@FreeBSD.ORG References: <20021024183839.GB601@opiate.thirteenandtwo.org> <004f01c27b9e$372647a0$f7808c96@LocalHost> <20021025021216.GE73214@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021025021216.GE73214@wantadilla.lemis.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-10-25 11:42 +0000, Greg 'groggy' Lehey wrote: > [....] > > Luke is also very concerned about compatibility between the BSDs. > It's understandable that lukemftpd (currently) doesn't support > FreeBSD-specific features, but I'm sure that he'd be interested in > maintaining the features in some form. Has anybody asked him? > From what I remember he seemed positively inclined to something like this. As Kris has noted in a reply to your mail Greg, it seems to be more of a question of who will send him initial patches. I have nothing against doing grunt work or helping out as much as I can if someone decides to take this up, but doing the entire thing is far beyond my current skill set. -- Munish Chopra To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 24 21:13:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB6CF37B401; Thu, 24 Oct 2002 21:13:10 -0700 (PDT) Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C39C43E4A; Thu, 24 Oct 2002 21:13:10 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g9P4D3RT032644; Fri, 25 Oct 2002 00:13:03 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20021025021216.GE73214@wantadilla.lemis.com> References: <20021024183839.GB601@opiate.thirteenandtwo.org> <004f01c27b9e$372647a0$f7808c96@LocalHost> <20021025021216.GE73214@wantadilla.lemis.com> Date: Fri, 25 Oct 2002 00:13:02 -0400 To: "Greg 'groggy' Lehey" From: Garance A Drosihn Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:42 AM +0930 10/25/02, Greg 'groggy' Lehey wrote: >On Thursday, 24 October 2002, Giorgos Keramidas wrote: > > I'm not exactly suggesting anything here (like someone jumping up >> and saying "I will"); just making sure that the author of lukemftp >> and lukemftpd is contacted before any decision is made. > >Luke is also very concerned about compatibility between the BSDs. >It's understandable that lukemftpd (currently) doesn't support >FreeBSD-specific features, but I'm sure that he'd be interested in >maintaining the features in some form. Has anybody asked him? All reports are that Luke is a nice guy, and willing to work with freebsd. The problem is finding someone in freebsd who is willing to work on comparing freebsd-ftp to lukemftpd. Philosophically I'm all for the idea, but I am another person who can't commit to doing any useful work on it at the moment. If we can't find someone on our side to do the necessary work, then we probably do have to "play down" lukemftpd for the upcoming 5.0 release. So we need to find that willing volunteer sometime soon, and someone who has the time right now... [at this point Garance shirks away, since he isn't volunteering] -- Garance Alistair Drosehn = gad@gilead.netel.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 Fri Oct 25 2:46: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85D7437B401; Fri, 25 Oct 2002 02:45:59 -0700 (PDT) Received: from premijer.tel.fer.hr (premijer.tel.fer.hr [161.53.19.221]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AD7143E6A; Fri, 25 Oct 2002 02:45:59 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (unknown [161.53.19.178]) by premijer.tel.fer.hr (Postfix) with ESMTP id 2B2AA1380; Fri, 25 Oct 2002 11:45:38 +0200 (MET DST) Message-ID: <3DB912CF.DF6F7B74@tel.fer.hr> Date: Fri, 25 Oct 2002 11:45:51 +0200 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: "J. 'LoneWolf' Mattsson" , freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: RFC: BSD network stack virtualization References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > On Thu, 24 Oct 2002, Marko Zec wrote: > > > Julian Elischer wrote: > > > > > > > 11/ why was ng_bridge unsuitable for your use? > > > > Both the native and netgraph bridging code, I believe, were designed with > > the presumption that only one "upper" hook is really needed to establish the > > communication to kernel's single network stack. However, this concept > > doesn't hold on a kernel with multiple network stacks. I just picked the > > native bridging code first and extended it to support hooking to multiple > > "upper" hooks. The similar extensions have yet to be applied to ng_bridge, I > > just didn't have time to implement the same functionality in two different > > frameworks. > > ng_bridge doesn't really distinguish between hooks to upper and lower > detinations. it only knows wha tMAC addresses are seen to come from each > hook and ensures that packets destined to those addresses are sent to > those hooks.. you can have as many > 'upper' hooks as you wish (and there are some uses for that). I just checked (only the functionality, not the ng_bridge code), and it doesn't work properly out of the box for bridging between the virtual network stacks. The inbound broadcast/multicast traffic seems to be delivered properly, but the outbound traffic doesn't pass the bridge when initiated outside the "master" virtual image. I'm just to lazy to dig into the code right now, maybe I'll check it more thoroughly later... Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 8:12:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55B3D37B401 for ; Fri, 25 Oct 2002 08:12:56 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DDC243E75 for ; Fri, 25 Oct 2002 08:12:50 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9PFCecF049792; Fri, 25 Oct 2002 16:12:41 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9PFCeH5072318; Fri, 25 Oct 2002 16:12:40 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9PFCenT072317; Fri, 25 Oct 2002 16:12:40 +0100 (BST) Date: Fri, 25 Oct 2002 16:12:40 +0100 (BST) From: Mark Valentine Message-Id: <200210251512.g9PFCenT072317@dotar.thuvia.org> In-Reply-To: <17783.1035552121@critter.freebsd.dk> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Poul-Henning Kamp Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_dis Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Poul-Henning Kamp > Date: Fri 25 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_dis [Recipient list trimmed, moved from cvs-all to -arch.] > In message <200210251307.g9PD7al6069458@dotar.thuvia.org>, Mark Valentine write > s: > >I guess we differ here in that I'm saying we *should* hide this implementation > >detail by default for consistency with other platforms, > > You're making quite an assumption here it seems: BSD disklabels may not > even be present on all platforms, and each partitioning scheme is free > to choose its own naming. Yes, I was assuming the presence of a BSD disklabel for the purposes of the discussion. I earlier made the point that if you don't have a BSD disklabel, the picture doesn't change substantially. The standard BSD device naming scheme can (and should) still be used. > GPT labels for instance seems to use "${disk}${unit}[sp]%d" This is an implementation detail. Certainly, if the native platform has its own partitioning scheme which is up to the task, there's no need to write a separate BSD disklabel to the disk. Whether or not you still present a disklabel API is a matter for consideration, but in any case the system should map the underlying structure onto the traditional scheme for POLA purposes. I see no reason not to *also* present an interface to the physical device structure (see separate posting on cvs-all), but the traditional scheme should be preserved, for example mapping da0a -> disk0p4. I certainly prefer no BSD disklabel to one hidden behind a representation of the native partitioning (the da0s4a stuff). If you make it allowable to have multiple BSD disklabels on a disk (for whatever reason), please don't obfuscate the common case to do it. In particular, the FreeBSD/i386 convention of using a _numbered_ "slice" is bogus; even if you consider the DOS partitioning scheme "native" (which it is not strictly speaking, since it's implemented entirely by DOS rather than the BIOS), it does not map directly onto the scheme DOS uses to identify partitions (by partition type then by its drive letter assignment algorithm). This is what causes /etc/fstab to become invalid if using hard-coded slice numbers after some non-FreeBSD tool re-arranges the order of the DOS partition table (which some tools indeed seem to be consider a valid thing to to; perhaps this is why QNX used a convention something like /dev/hd0t165). > And finally you overlook that we may have to forego both MBR and BSD > disklabels on any architecture where we want to use moderately large > storage devices (2^31 * 512 bytes, possibly twice that). What is a typical device naming scheme for such an architecture? > There simply isn't "any consistency with other platforms" to point to > here, if we disregard stuff from the antique hardware society. # uname -rms NetBSD 1.6 sparc # mount /dev/sd0a on / type ffs (local) /dev/sd0d on /var type ffs (local) /dev/sd0e on /usr type ffs (local) /dev/sd0g on /local type ffs (local) This is BSD present day reality; you have provided no justification why this shouldn't continue to work. > Now, this is a nice technicolor bikeshed we got here, but can we > get on with something of real importance, like, making a FreeBSD > 5.0-RELEASE ? Yup, time to try to coax my -CURRENT machine into booting again so I can play with this stuff... Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 8:23: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8480737B401 for ; Fri, 25 Oct 2002 08:23:08 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CFAD43E65 for ; Fri, 25 Oct 2002 08:23:07 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9PFN1rF019152; Fri, 25 Oct 2002 17:23:01 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Mark Valentine Cc: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_dis In-Reply-To: Your message of "Fri, 25 Oct 2002 16:12:40 BST." <200210251512.g9PFCenT072317@dotar.thuvia.org> Date: Fri, 25 Oct 2002 17:23:01 +0200 Message-ID: <19151.1035559381@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200210251512.g9PFCenT072317@dotar.thuvia.org>, Mark Valentine write s: >I earlier made the point that if you don't have a BSD disklabel, the >picture doesn't change substantially. The standard BSD device naming >scheme can (and should) still be used. Just how do you intend to use "standard BSD device naming" for a scheme which supports up to 16k partitions ? /dev/da0° /dev/da0± /dev/da0µ /dev/da0¹ /dev/da0² I think not... >> And finally you overlook that we may have to forego both MBR and BSD >> disklabels on any architecture where we want to use moderately large >> storage devices (2^31 * 512 bytes, possibly twice that). > >What is a typical device naming scheme for such an architecture? We don't know yet, but GPT seems like a strong contender. -- 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 Fri Oct 25 8:35:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1BA637B401 for ; Fri, 25 Oct 2002 08:35:35 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D7F143E42 for ; Fri, 25 Oct 2002 08:35:34 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9PFZUcF049869; Fri, 25 Oct 2002 16:35:30 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9PFZUH5072983; Fri, 25 Oct 2002 16:35:30 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9PFZTOD072982; Fri, 25 Oct 2002 16:35:29 +0100 (BST) Date: Fri, 25 Oct 2002 16:35:29 +0100 (BST) From: Mark Valentine Message-Id: <200210251535.g9PFZTOD072982@dotar.thuvia.org> In-Reply-To: <19151.1035559381@critter.freebsd.dk> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Poul-Henning Kamp Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_dis Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Poul-Henning Kamp > Date: Fri 25 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_dis > Just how do you intend to use "standard BSD device naming" for a > scheme which supports up to 16k partitions ? By mapping /dev/da0[a-z] onto partitions I will likely use. I am not precluding a new naming scheme to cope with new demands, simply stating that the existing scheme, which caters for 99% per cent of cases, should be preserved. Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 10:35:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5F8337B401 for ; Fri, 25 Oct 2002 10:35:13 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B57C43E75 for ; Fri, 25 Oct 2002 10:35:12 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9PHZ1cF050261; Fri, 25 Oct 2002 18:35:02 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9PHZ1H5075955; Fri, 25 Oct 2002 18:35:01 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9PHZ1sT075954; Fri, 25 Oct 2002 18:35:01 +0100 (BST) Date: Fri, 25 Oct 2002 18:35:01 +0100 (BST) From: Mark Valentine Message-Id: <200210251735.g9PHZ1sT075954@dotar.thuvia.org> In-Reply-To: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: phk@critter.freebsd.dk (Poul-Henning Kamp), "M. Warner Losh" Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: phk@critter.freebsd.dk (Poul-Henning Kamp) > Date: Fri 25 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c [Moved to -arch from cvs-all.] > The justification was given in ample amount 4+ years ago, but here > are the high-lights again: Thanks for this list, I think it's what some of us have been waiting to see. > 1: It confuses users. The reason why you don't hear much about > this now is that for four years we have installed systems > with consistent names by default. I'm not sure I agree with this. I've seen way too many conversations get bogged down in trying to distinguish between DOS partitions (they are not called "slices") and BSD partitions. The "compatibility" devices simplify this by abstracting to a single level of partitioning - this is currently the BSD partition table, but it doesn't have to be. As well as simplifying the i386 case, it brings disk partition names in line with other existing BSD platforms. > 2: It does not reflect what is on the disk, which adds > complexity and failure modes to our software, both userland > kernel and bootcode. This is completely the reverse of my experience. I use the "compatibility" devices to _prevent_ having to reach for the fixit floppy when the order of the partition table entries changes. The index into the table which we hard code into fstab does _not_ mirror how DOS and others use this table. The encoding of the partition table index in device names in /etc/fstab might therefore be considered a bug. It also makes it harder to dump and restore BSD partitions across disks which have and don't have an MBR partition table, or in which the 0xA5 partitions just happen to have different indexes in the table. > 3: Aliasing disk devices is a bad idea. You don't want people > to accidentally mount /dev/da0a and /dev/da0s1a at the same > time so you have to add complexity to your kernel side code > to prevent this. If this is really a problem, make the heirarchical names more obviously different (such as being in a sub-directory). > 4: /dev/da0a is the legitimate name for a disk which has _only_ > a BSD disklabel on it. It's also a perfectly good way to refer to a BSD partition within an 0xA5 partition, especially if the MBR partition table exists only to satisfy a broken BIOS, and especially when there is only one 0xA5 partition. > At typical failuremode here is: "My disk wont boot", "Right > is the FreeBSD slice active in the MBR ?", "There is no > MBR!", "Yes there is", "No there isn't!" etc etc. It seems like the job of sysinstall to warn the user if this is likely to happen (i.e. he didn't make the BSD partition bootable and didn't install booteasy). > 5: This entire thing is a bloody bikeshed! Nobody cares about > the fact that we get an Disk IO system which is multi-architecture, > modular, extensible, Giant-free etc etc, instead they focus > on the one little detail they _do_ understand, and make a lot > of noise, just to show how much they are "in the loop"! I'm sure we'll appreciate the progress you've made once we've seen what it gives us. We're simply asking why we have to sacrifice a traditional interface (and in my experience one which is more reliable) to buy into it. What is the cost of having both? Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 11:20:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0122E37B404 for ; Fri, 25 Oct 2002 11:20:08 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FDF443E3B for ; Fri, 25 Oct 2002 11:20:07 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021025182006.GQLH13658.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 25 Oct 2002 18:20:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA07025; Fri, 25 Oct 2002 11:05:05 -0700 (PDT) Date: Fri, 25 Oct 2002 11:05:04 -0700 (PDT) From: Julian Elischer To: Mark Valentine Cc: Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c In-Reply-To: <200210251735.g9PHZ1sT075954@dotar.thuvia.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 25 Oct 2002, Mark Valentine wrote: > > I'm sure we'll appreciate the progress you've made once we've seen what > it gives us. We're simply asking why we have to sacrifice a traditional > interface (and in my experience one which is more reliable) to buy into it. > > What is the cost of having both? You can't have both because the naming scheme gives a particular name to a partition because of how you get to it.. ad0a means: I openned the disk, found a disklabel and this is the first partition defined in that disklabel. We've been (except for Bruce, (often right, but not one to part with old ways)) moving towards doing this for the last 10 years.. Devfs and it's associated disk-recarving code have been postulated and prototyped singe 1993. We have made the default disk names installed the "new, reality based" ones since about 1996. If someone doesn't know what ad0s1a means yet then they haven't been paying attention. As new devices come and go in the new 'pluggable, wireless world' the old scheme of assigning for all eternity a particular set of limitted availability bits to a particular drive and part of that drive, has to give way to something else. Devfs is one possibility for this, but devfs cannot easily cope with the multiple ways that drive partitionning can be layered, without breaking away from the traditional fixed geometry<->minor-number/naming scheme. In the old scheme there is just NO WAY to describe some partitioning schemes, especially in the plug-in world where the drive may have been partitioned by some medical imaging system or a MAC or a SUN. Our hand is being forced. In the future I feel that the default names may eventually be over-ridden by semantically meaningfull names. e.g. You may partition a drive and give each partition a name which might be used instead of the default inherrited name.. e.g. ad0s1s2b (not a typo) may decide that it would rather be known "/dev/swap2" because the table entry has a field "swap%d" in it, or disk2 may decide that it wants to be known as "/dev/tunes". (A removable disk full of music) These things are possible with devfs. /dev/tunes-s1a would be a partition on that drive.. it's removable so when you replace it with the drive that calls itself "/dev/backups" the /dev/entries correct themselves. But that is all just potential at this stage. To address some of your concerns We COULD have a /dev/ad0sBa that always reflects the first BSD slice "a" partition. that would give the characteristics you have asked for.. and still abides by the naming convention.. (devfs could make a symlink or something..) but ad0a is already taken.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 11:24:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77D1B37B401 for ; Fri, 25 Oct 2002 11:24:38 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09DA143E77 for ; Fri, 25 Oct 2002 11:24:38 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 28086 invoked from network); 25 Oct 2002 18:24:43 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Oct 2002 18:24:43 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id g9PIOan5075981; Fri, 25 Oct 2002 14:24:36 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200210251535.g9PFZTOD072982@dotar.thuvia.org> Date: Fri, 25 Oct 2002 14:24:40 -0400 (EDT) From: John Baldwin To: Mark Valentine Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_dis Cc: freebsd-arch@freebsd.org, Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 25-Oct-2002 Mark Valentine wrote: >> From: Poul-Henning Kamp >> Date: Fri 25 Oct, 2002 >> Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_dis > >> Just how do you intend to use "standard BSD device naming" for a >> scheme which supports up to 16k partitions ? > > By mapping /dev/da0[a-z] onto partitions I will likely use. > > I am not precluding a new naming scheme to cope with new demands, simply > stating that the existing scheme, which caters for 99% per cent of cases, > should be preserved. This is about like asking someone to stick a propeller on the end of an F-22 and expect it to look and act like a Cessna. This is not realistic and is just a hack. We no longer work on Vaxes in the 1980's. Seriously. Trying to fit new paradigms into an old format that really isn't an abstraction but you are trying to turn into some kind of weird abstraction that most people don't actually use just makes no sense from a future perspective. Why would you want to design yourself into a hole that you already know isn't big enough for stuff that exists right now much less things in the future? I'm just amazed that people really think their i386 box uses the same disk layout as some VAX from the 1980's. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 12:10: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E825F37B401 for ; Fri, 25 Oct 2002 12:10:03 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59D2543E4A for ; Fri, 25 Oct 2002 12:10:02 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9PJ9ecF050645; Fri, 25 Oct 2002 20:09:40 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9PJ9dH5078509; Fri, 25 Oct 2002 20:09:39 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9PJ9d4F078508; Fri, 25 Oct 2002 20:09:39 +0100 (BST) Date: Fri, 25 Oct 2002 20:09:39 +0100 (BST) From: Mark Valentine Message-Id: <200210251909.g9PJ9d4F078508@dotar.thuvia.org> In-Reply-To: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Julian Elischer Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Cc: Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Julian Elischer > Date: Fri 25 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c > On Fri, 25 Oct 2002, Mark Valentine wrote: > > What is the cost of having both? > > You can't have both because the naming scheme gives a particular name to > a partition because of how you get to it.. Thaks for this explanation, Julian, I'm beginning to see some light... > ad0a means: > I openned the disk, found a disklabel and this is the first partition > defined in that disklabel. OK... That is a seriously incompatible change in the interpretation of this device name. It is useful only in the absence of an MBR partition, GPT table, or whatever. It is more of a physical representation of the disk than the current one, which is more of a logical interpretation. The current interpretation is more in line with how other i386 operating systems interpret the MBR partition table, which is why my systems are more likely to boot using this notation than your systems using a naming scheme with a hard-wired partition index which isn't guaranteed to remain constant. The GEOM naming scheme therefore removes my ability to specify the partition in the most natural way for this platform. > If someone doesn't know > what ad0s1a means yet then they haven't been paying attention. It doesn't mean what most people would want it to mean, i.e. their FreeBSD root partition, according to the conventions for the PC platform. > To address some of your concerns > We COULD have a /dev/ad0sBa that always reflects the first BSD slice > "a" partition. that would give the characteristics you have asked for.. > and still abides by the naming convention.. (devfs could make a symlink > or something..) but ad0a is already taken.. Hmm. How about if you use a different name space for the new naming scheme, and we can use the old names to symlink, e.g. da0a -> 0sBa? In actual fact I'm less fussy about using /dev/da0a forever than I am at having _some_ /dev/0a do the right thing (which is not /dev/0s1a). Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 12:39:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 339B437BD36 for ; Fri, 25 Oct 2002 12:39:26 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3D4943E42 for ; Fri, 25 Oct 2002 12:39:25 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.6/8.12.6) id g9PJcxUF033771; Fri, 25 Oct 2002 14:38:59 -0500 (CDT) (envelope-from dan) Date: Fri, 25 Oct 2002 14:38:59 -0500 From: Dan Nelson To: Julian Elischer Cc: Mark Valentine , Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Message-ID: <20021025193859.GA51818@dan.emsphone.com> References: <200210251735.g9PHZ1sT075954@dotar.thuvia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Oct 25), Julian Elischer said: > > In the future I feel that the default names may eventually be > over-ridden by semantically meaningfull names. e.g. You may partition a > drive and give each partition a name which might be used instead of the > default inherrited name.. e.g. ad0s1s2b (not a typo) may decide that it > would rather be known "/dev/swap2" because the table entry has a field > "swap%d" in it, or disk2 may decide that it wants to be known as > "/dev/tunes". (A removable disk full of music) Linux allows this, sort of. You can label disks with tune2fs, and mount can find disks based either the label or filesystem UUID. This lets you have an fstab that looks like LABEL=server1usr /usr ext2 defaults 1 1 devfs/GEOM could do something similar via a /dev/disk/label/ namespace. For people on SANs, a way to identify a device directly by serial number or WWN might be handy (maybe also enabling multipath access). -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 12:46: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2432837B401 for ; Fri, 25 Oct 2002 12:46:00 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A17AD43E3B for ; Fri, 25 Oct 2002 12:45:58 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g9PJibOo056582; Fri, 25 Oct 2002 15:44:37 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 25 Oct 2002 15:44:36 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dan Nelson Cc: Julian Elischer , Mark Valentine , Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c In-Reply-To: <20021025193859.GA51818@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 25 Oct 2002, Dan Nelson wrote: > In the last episode (Oct 25), Julian Elischer said: > > > > In the future I feel that the default names may eventually be > > over-ridden by semantically meaningfull names. e.g. You may partition a > > drive and give each partition a name which might be used instead of the > > default inherrited name.. e.g. ad0s1s2b (not a typo) may decide that it > > would rather be known "/dev/swap2" because the table entry has a field > > "swap%d" in it, or disk2 may decide that it wants to be known as > > "/dev/tunes". (A removable disk full of music) > > Linux allows this, sort of. You can label disks with tune2fs, and mount > can find disks based either the label or filesystem UUID. This lets you > have an fstab that looks like Gordon Tetlow and I have been discussing possibly reusing the superblock "last mounted on" field for volume label and uuid storage. Right now the "last mounted on" data is basically used for printfs, and often somewhat confusingly (the kernel will print the last mount point when reporting a mount error, which might not be where the user is trying to mount). It's 512 bytes of superblock space, so would provide lots of room for volume identifier information, if we decided to go that way. Anyone interested in this sort of thing should spend a fair amount of time looking at prior art, including at Apple's approach to volume name automounting. Also, Poul-Henning's comments on security are important: in some case, you may be less willing to trust the label on the media than others. Another important consideration relates to issues like removable media, and media from less trusted sources, as well as accidental collisions in the namespace. If anyone wants to take on this project seriously, GEOM and devfs provide a good starting point and many of the tools you need. Anyone giving it a try should go do a prior art search and document what they find, however. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 13: 0:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C002037B401 for ; Fri, 25 Oct 2002 13:00:17 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F8C743E8A for ; Fri, 25 Oct 2002 13:00:17 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021025200016.JKJL17494.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 25 Oct 2002 20:00:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA07534; Fri, 25 Oct 2002 12:46:26 -0700 (PDT) Date: Fri, 25 Oct 2002 12:46:24 -0700 (PDT) From: Julian Elischer To: Mark Valentine Cc: Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c In-Reply-To: <200210251909.g9PJ9d4F078508@dotar.thuvia.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 25 Oct 2002, Mark Valentine wrote: > > The GEOM naming scheme therefore removes my ability to specify the partition > in the most natural way for this platform. I dispute that. The install code has been using ad0s1a for about 5 years I think. Very few systems have ad0a in /etc/fstab as we specifically have been telling people to not do that for ages.. > > > If someone doesn't know > > what ad0s1a means yet then they haven't been paying attention. > > It doesn't mean what most people would want it to mean, i.e. their FreeBSD > root partition, according to the conventions for the PC platform. Most systems other than BSD and Linux only ever see their own partitions. We are trying to set things up so we can read anything anywhere any time. Anyway I had a machine where the -current root partition was ad1s4e. How does the old scheme help me? ad1s3 was also a BSD slice (FBSD3.x) > > > To address some of your concerns > > We COULD have a /dev/ad0sBa that always reflects the first BSD slice > > "a" partition. that would give the characteristics you have asked for.. > > and still abides by the naming convention.. (devfs could make a symlink > > or something..) but ad0a is already taken.. > > Hmm. How about if you use a different name space for the new naming > scheme, and we can use the old names to symlink, e.g. da0a -> 0sBa? > > In actual fact I'm less fussy about using /dev/da0a forever than I am > at having _some_ /dev/0a do the right thing (which is not > /dev/0s1a). the simplest you're likely to get is ad0s1a if you don't know where your root is you are in trouble. One scheme I played with was: /dev/ad0/whole /dev/ad0/s1 /dev/ad0/s1/a /dev/ad0/bsd0 --> s1 /dev/ad0/s1/whole /dev/ad0/s2 /dev/ad0/s2/whole /dev/ad0/s3 /dev/ad0/s3/whole /dev/ad0/s4 /dev/ad0/s4/whole so that /dev/ad0/bsd0/a would always be the root but I don't know if the new devfs can do that.. This had a lot of advantages but blew POLA right out the window :-) > > Cheers, > > Mark. > > -- > Mark Valentine, Thuvia Labs > "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses > "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD > -- > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 13: 4:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB1C237B4EE; Fri, 25 Oct 2002 13:04:11 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75A3C43E6E; Fri, 25 Oct 2002 13:04:11 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0348.cvx22-bradley.dialup.earthlink.net ([209.179.199.93] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 185Agh-0003g0-00; Fri, 25 Oct 2002 13:04:07 -0700 Message-ID: <3DB9A36F.A7A17CEE@mindspring.com> Date: Fri, 25 Oct 2002 13:02:55 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: Dan Nelson , Julian Elischer , Mark Valentine , Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: > Gordon Tetlow and I have been discussing possibly reusing the superblock > "last mounted on" field for volume label and uuid storage. Right now the > "last mounted on" data is basically used for printfs, and often somewhat > confusingly (the kernel will print the last mount point when reporting a > mount error, which might not be where the user is trying to mount). It's > 512 bytes of superblock space, so would provide lots of room for volume > identifier information, if we decided to go that way. Anyone interested > in this sort of thing should spend a fair amount of time looking at prior > art, including at Apple's approach to volume name automounting. Please do not do this. It is very easy to use this field to make arriving FS's not in fstab mount themselves to the right place automatically: 1) Device arrival 2) Paritition arrival 3) Disklabel arrival 4) FS arrival 5) Automount Without this field, you have to have an fstab entry for everything you want to mount, even if you don't know about it, and it's on removable media. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 13:48:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C717937B401 for ; Fri, 25 Oct 2002 13:48:20 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCDA743E75 for ; Fri, 25 Oct 2002 13:48:19 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id GAA08920; Sat, 26 Oct 2002 06:47:58 +1000 Date: Sat, 26 Oct 2002 06:59:09 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: Mark Valentine , Poul-Henning Kamp , "M. Warner Losh" , Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c In-Reply-To: Message-ID: <20021026064258.W5345-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 25 Oct 2002, Julian Elischer wrote: > On Fri, 25 Oct 2002, Mark Valentine wrote: > > > The GEOM naming scheme therefore removes my ability to specify the partition > > in the most natural way for this platform. > I dispute that. > The install code has been using ad0s1a for about 5 years I think. > Very few systems have ad0a in /etc/fstab as we specifically have been > telling people to not do that for ages.. I haven't been using the install code for about 10 years now :-). > Anyway I had a machine where the -current root partition was ad1s4e. > How does the old scheme help me? ad1s3 was also a BSD slice (FBSD3.x) Run fdisk to temporarily change ad1s3 to non-BSD. ad0[a-h] in /etc/fstab for the s4 slice then starts referring to that slice. I have used this to boot backups of partitions (cp /dev/ad0s3 /dev/ad0s4; this invalidates any s3 numbers in the copy of /etc/fstab on the s4 slice, so booting the s4 partition later doesn't work if there are any such numbers, but everything works perfectlyf ad[0-h] is used. At least with my versions of the boot blocks. The switch to using sN in fstab started with changing the boot blocks to pass sN in an incompatible way; I had already fixed the boot blocks in a compatible way and didn't like this or most subsequent changes in this area so I didn't use them. > One scheme I played with was: > /dev/ad0/whole > /dev/ad0/s1 > /dev/ad0/s1/a > /dev/ad0/bsd0 --> s1 > /dev/ad0/s1/whole > /dev/ad0/s2 > /dev/ad0/s2/whole > /dev/ad0/s3 > /dev/ad0/s3/whole > /dev/ad0/s4 > /dev/ad0/s4/whole > > so that /dev/ad0/bsd0/a would always be the root > but I don't know if the new devfs can do that.. > > This had a lot of advantages but blew POLA right out the window :-) Encoding the disk structure in the directory tree would be another mistake. Fotrunately this mistake has already been made, so we know not to repeat it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 14:12:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE23A37B401 for ; Fri, 25 Oct 2002 14:12:24 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C95D43E42 for ; Fri, 25 Oct 2002 14:12:23 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9PLAtcF051110; Fri, 25 Oct 2002 22:10:55 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9PLAsH5081666; Fri, 25 Oct 2002 22:10:54 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9PLAsxP081665; Fri, 25 Oct 2002 22:10:54 +0100 (BST) Date: Fri, 25 Oct 2002 22:10:54 +0100 (BST) From: Mark Valentine Message-Id: <200210252110.g9PLAsxP081665@dotar.thuvia.org> In-Reply-To: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Julian Elischer Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Cc: Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Julian Elischer > Date: Fri 25 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c > On Fri, 25 Oct 2002, Mark Valentine wrote: > > The GEOM naming scheme therefore removes my ability to specify the partition > > in the most natural way for this platform. > > I dispute that. > The install code has been using ad0s1a for about 5 years I think. That doesn't make it correct. I fix it when it bites me. > Very few systems have ad0a in /etc/fstab as we specifically have been > telling people to not do that for ages.. My fstab is the way it is because otherwise I have problems, due to a mismatch between the way FreeBSD sees the MBR partition table and the way the rest of the world does. There is currently a mechanism for making FreeBSD play ball better with the systems it shares a disk with. GEOM in its current state removes this mechanism, with no replacement. > Most systems other than BSD and Linux only ever see their own > partitions. We are trying to set things up so we can > read anything anywhere any time. > > Anyway I had a machine where the -current root partition was ad1s4e. > How does the old scheme help me? ad1s3 was also a BSD slice (FBSD3.x) You're simply describing the obscure usage I mentioned earlier. Modulo the 8 partition limit, there's nothing here a single disklabel can't do; in fact that's all we have on most BSD platforms. > if you don't know where your root is you are in trouble. I know where my root is - it's BSD partition 'a' on the MBR partition of type 0xa5. There is no guarantee as to which partition table entry might refer to that partition at any given time. That is not my choice, it's based on the assumptions made by DOS (which originally implemented the MBR partition table). All I need is a way to tell the system where it is so that my FreeBSD systems will continue to boot. Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 14:40:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D80AC37B401 for ; Fri, 25 Oct 2002 14:40:08 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1570E43E65 for ; Fri, 25 Oct 2002 14:40:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021025214006.PRHR3104.sccrmhc02.attbi.com@InterJet.elischer.org>; Fri, 25 Oct 2002 21:40:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA08094; Fri, 25 Oct 2002 14:26:53 -0700 (PDT) Date: Fri, 25 Oct 2002 14:26:52 -0700 (PDT) From: Julian Elischer To: Mark Valentine Cc: Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c In-Reply-To: <200210252110.g9PLAsxP081665@dotar.thuvia.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 25 Oct 2002, Mark Valentine wrote: > > From: Julian Elischer > > Date: Fri 25 Oct, 2002 > > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c > > > On Fri, 25 Oct 2002, Mark Valentine wrote: > > > The GEOM naming scheme therefore removes my ability to specify the partition > > > in the most natural way for this platform. > > > > I dispute that. > > The install code has been using ad0s1a for about 5 years I think. > > That doesn't make it correct. I fix it when it bites me. > > > Very few systems have ad0a in /etc/fstab as we specifically have been > > telling people to not do that for ages.. > > My fstab is the way it is because otherwise I have problems, due to a > mismatch between the way FreeBSD sees the MBR partition table and the > way the rest of the world does. In other words, you ignored the warnings for 5 years and instead of explaining teh problem to people that could think about what is needed, you just covered it up using somethign we've been telling you not to do. Ok, so, better late than never.. exactly WHY do you need to use ad0a (or whatever)? I can't think of any reasons for keeping that old compat stuff other than giving people more time to fix their fstabs. Enlighten me.. > > There is currently a mechanism for making FreeBSD play ball better with > the systems it shares a disk with. > > GEOM in its current state removes this mechanism, with no replacement. I fail to see how using ad0a makes it play better with other systems. > > > Most systems other than BSD and Linux only ever see their own > > partitions. We are trying to set things up so we can > > read anything anywhere any time. > > > > Anyway I had a machine where the -current root partition was ad1s4e. > > How does the old scheme help me? ad1s3 was also a BSD slice (FBSD3.x) > > You're simply describing the obscure usage I mentioned earlier. Modulo > the 8 partition limit, there's nothing here a single disklabel can't do; > in fact that's all we have on most BSD platforms. in which case it's correct naming would be ad0a ad0b ad0c ad0d etc. and GEOM isn't going to change that. > > > if you don't know where your root is you are in trouble. > > I know where my root is - it's BSD partition 'a' on the MBR partition of > type 0xa5. There is no guarantee as to which partition table entry might > refer to that partition at any given time. That is not my choice, it's > based on the assumptions made by DOS (which originally implemented the > MBR partition table). If you are going to repartition your disk, then fix the fstab before you reboot for goodness' sake! It's not so complicated! It still doesn't help you to have the shortcut if you decide to reuse an earlier partition as extra BSD storage. > > All I need is a way to tell the system where it is so that my FreeBSD > systems will continue to boot. it's on ad0s3a or where-ever you put it. If you can't remember where you put it, well, that's not something we are going to break a good abstraction for. This is a case that will happen 4 times a year in the entire world in my opinion. Once with you and 3 times with bruce because he will want to prove it's a problem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 15:16: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5CE837B404 for ; Fri, 25 Oct 2002 15:16:03 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 190B743E7B for ; Fri, 25 Oct 2002 15:16:02 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9PMFlcF051304; Fri, 25 Oct 2002 23:15:48 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9PMFlH5083245; Fri, 25 Oct 2002 23:15:47 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9PMFlBO083244; Fri, 25 Oct 2002 23:15:47 +0100 (BST) Date: Fri, 25 Oct 2002 23:15:47 +0100 (BST) From: Mark Valentine Message-Id: <200210252215.g9PMFlBO083244@dotar.thuvia.org> In-Reply-To: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Julian Elischer Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Cc: Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Julian Elischer > Date: Fri 25 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c > In other words, you ignored the warnings for 5 years and instead of > explaining teh problem to people that could think about what is needed, > you just covered it up using somethign we've been telling you not to do. I guess I didn't expect the "compatibility slice" to ever go away... > Ok, so, better late than never.. exactly WHY do you need to use > ad0a (or whatever)? I can't think of any reasons for keeping that > old compat stuff other than giving people more time to fix their > fstabs. Enlighten me.. > > There is currently a mechanism for making FreeBSD play ball better with > > the systems it shares a disk with. > > > > GEOM in its current state removes this mechanism, with no replacement. > > I fail to see how using ad0a makes it play better with other systems. Because DOS doesn't refer to its partition by its index in the MBR partition table, and apparently some tools therefore feel free to reorder the table on a whim. /dev/ad0a results in a method of locating the partition which is closer to the DOS algorithm, and therefore survives this. /dev/ad0s1a makes an incorrect assumption about the MBR partition table index being fixed, and therefore blows up. > > You're simply describing the obscure usage I mentioned earlier. Modulo > > the 8 partition limit, there's nothing here a single disklabel can't do; > > in fact that's all we have on most BSD platforms. > > in which case it's correct naming would be > ad0a ad0b ad0c ad0d etc. > and GEOM isn't going to change that. Apparently it is, even for DD mode. > > > if you don't know where your root is you are in trouble. > > > > I know where my root is - it's BSD partition 'a' on the MBR partition of > > type 0xa5. There is no guarantee as to which partition table entry might > > refer to that partition at any given time. That is not my choice, it's > > based on the assumptions made by DOS (which originally implemented the > > MBR partition table). > > If you are going to repartition your disk, then fix the fstab before you > reboot for goodness' sake! It's not so complicated! I'm not repartitioning in any way which should affect FreeBSD. It doesn't sound complicated in this scenario, but when you consider the partition table index embedded in backups and in scripts, it's another matter. > It still doesn't help you to have the shortcut if you decide > to reuse an earlier partition as extra BSD storage. I can choose betwen hardwiring partition table indexes or using a single disklabel (is it still possible to refer to the area outside the partition containing the BSD disklabel in disklabel entries?). But basically I just don't do this. Does GEOM improve anything here? > > All I need is a way to tell the system where it is so that my FreeBSD > > systems will continue to boot. > > it's on ad0s3a or where-ever you put it. ad0s3a is effectively a random place. > If you can't remember where you put it, well, that's not something we > are going to break a good abstraction for. I have to figure out where some tool left it, because FreeBSD with GEOM doesn't provide a way to specify it which matches how DOS sees it. An abstraction is lacking if it can't cope with the behaviour of the underlying system. > This is a case that will happen 4 times a year in the entire world > in my opinion. Once with you and 3 times with bruce because he will want > to prove it's a problem. Sure, it's only an occasional nuisance. However, it reflects a flaw in the system, and is not its only manifestation (see my point about scripts and backups). Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 16: 3:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B921D37B414 for ; Fri, 25 Oct 2002 16:03:19 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 7E7AB43E42 for ; Fri, 25 Oct 2002 16:03:19 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 73991 invoked by uid 1000); 25 Oct 2002 23:03:21 -0000 Date: Fri, 25 Oct 2002 16:03:20 -0700 (PDT) From: Nate Lawson To: Mark Valentine Cc: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c In-Reply-To: <200210252215.g9PMFlBO083244@dotar.thuvia.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Perhaps we can end this overly long thread with a simple request for someone to build a GEOM module that uniquely identifies media (how/wherever it may attach) and maps it to the proper place. Failing that, it would be great for someone to implement a "compat-oldbsd" GEOM module that scans the MBR for type == 0xa5 and creates the da0x aliases. Sometimes, the best way forward is through. Thanks, -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 16:26:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EE1437B401 for ; Fri, 25 Oct 2002 16:26:23 -0700 (PDT) Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 016D343E3B for ; Fri, 25 Oct 2002 16:26:18 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0553.cvx21-bradley.dialup.earthlink.net ([209.179.194.43] helo=mindspring.com) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 185Dq0-0004cf-00; Fri, 25 Oct 2002 16:25:59 -0700 Message-ID: <3DB9D2A6.5FBF0CE9@mindspring.com> Date: Fri, 25 Oct 2002 16:24:22 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Valentine Cc: Julian Elischer , Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c References: <200210252215.g9PMFlBO083244@dotar.thuvia.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mark Valentine wrote: > > I fail to see how using ad0a makes it play better with other systems. > > Because DOS doesn't refer to its partition by its index in the MBR partition > table, and apparently some tools therefore feel free to reorder the table on > a whim. > > /dev/ad0a results in a method of locating the partition which is closer to > the DOS algorithm, and therefore survives this. > > /dev/ad0s1a makes an incorrect assumption about the MBR partition table index > being fixed, and therefore blows up. OK, say we buy this. How does the DOS algorithm distiguisch between partitions, if not by the order in the table? Specifically, if I have two partitions that are identical in all ways, other than a date stamp on one file way down in the FS on the partition, and one is "D" and the other is "E", other than the partition table order, how does it get the "D" and "E" assigend to the correspondingly correct devices? Does it key off the date stamp? > > If you are going to repartition your disk, then fix the fstab before you > > reboot for goodness' sake! It's not so complicated! > > I'm not repartitioning in any way which should affect FreeBSD. > > It doesn't sound complicated in this scenario, but when you consider > the partition table index embedded in backups and in scripts, it's > another matter. What you are saying is that you have some magic way to distinguish partitions. What I actually think you mean is that the partition table entries are reordered, and you want them to be distinguished gy the partition type IS (e.g. "165"), even though there are possibly multiple entries with identical partition type IDs. So the way that you are quietly and carefully not disclosing is to use something that isn't sufficiently unique. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 16:28: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E176637B401 for ; Fri, 25 Oct 2002 16:28:03 -0700 (PDT) Received: from stash.attlabs.att.com (mpfg.attlabs.net [12.106.35.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D486C43E6E for ; Fri, 25 Oct 2002 16:28:02 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from stash.attlabs.att.com (localhost [IPv6:::1]) by stash.attlabs.att.com (8.12.6/8.12.6) with ESMTP id g9PNRuHZ001127 for ; Fri, 25 Oct 2002 16:27:56 -0700 (PDT) (envelope-from fenner@stash.attlabs.att.com) Received: (from fenner@localhost) by stash.attlabs.att.com (8.12.6/8.12.6/Submit) id g9PNRtUw001126 for arch@freebsd.org; Fri, 25 Oct 2002 16:27:55 -0700 (PDT) (envelope-from fenner) Date: Fri, 25 Oct 2002 16:27:55 -0700 (PDT) From: Bill Fenner Message-Id: <200210252327.g9PNRtUw001126@stash.attlabs.att.com> To: arch@freebsd.org Subject: Renumbering IPPROTO_DIVERT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'd like to move IPPROTO_DIVERT out of the legitimate space of IP protocol numbers. Here's the patch: Index: in.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/in.h,v retrieving revision 1.72 diff -u -r1.72 in.h --- in.h 21 Oct 2002 20:40:02 -0000 1.72 +++ in.h 25 Oct 2002 21:13:20 -0000 @@ -236,12 +236,12 @@ #define IPPROTO_PIM 103 /* Protocol Independent Mcast */ #define IPPROTO_PGM 113 /* PGM */ /* 255: Reserved */ -/* BSD Private, local use, namespace incursion */ -#define IPPROTO_DIVERT 254 /* divert pseudo-protocol */ #define IPPROTO_MAX 256 /* last return value of *_input(), meaning "all job for this pkt is done". */ #define IPPROTO_DONE 257 + +#define IPPROTO_DIVERT 258 /* divert pseudo-protocol */ /* * Local port number conventions: Yup, it Just Works. Even better, with a patch to raw_ip.c, divert-using applications can now get an error from their socket() call when DIVERT isn't compiled in, as opposed to the current behavior where socket() would succeed but provide the normal raw IP semantics. Now, the backwards compatability question: applications using the old DIVERT interface will now start getting real raw IP sockets with protocol 254. This will generally cause silent failures, or possibly unexpected behavior (just like if DIVERT wasn't compiled into the kernel). Should there be e.g. a kernel printf when an application uses the old divert number, warning that an application is using the old divert interface and needs to be recompiled? Or is it OK to fail silently, as there are few DIVERT consumers and it's the same failure mode as if DIVERT isn't present in the kernel? Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 16:55:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CBBB37B401 for ; Fri, 25 Oct 2002 16:55:30 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAD0E43E4A for ; Fri, 25 Oct 2002 16:55:28 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id JAA19960; Sat, 26 Oct 2002 09:55:03 +1000 Date: Sat, 26 Oct 2002 10:06:14 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Mark Valentine , Julian Elischer , Poul-Henning Kamp , "M. Warner Losh" , Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c In-Reply-To: <3DB9D2A6.5FBF0CE9@mindspring.com> Message-ID: <20021026095818.B5924-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 25 Oct 2002, Terry Lambert wrote: > Mark Valentine wrote: > > > I fail to see how using ad0a makes it play better with other systems. > > > > Because DOS doesn't refer to its partition by its index in the MBR partition > > table, and apparently some tools therefore feel free to reorder the table on > > a whim. This is a bug in the tools, so they belong in the same bin as BIOSes that interpret the MBR. > > /dev/ad0a results in a method of locating the partition which is closer to > > the DOS algorithm, and therefore survives this. > > > > /dev/ad0s1a makes an incorrect assumption about the MBR partition table index > > being fixed, and therefore blows up. > > OK, say we buy this. > > How does the DOS algorithm distiguisch between partitions, if not by > the order in the table? Not. IIRC, it doesn't permit multiple primary DOS partitions, but logical drives just move around if you add one in the middle. Since DOS doesn't have anything like mount, you get to edit C: and D: in numerous config files instead of just in fstab when the drives move. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 17:12: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95D8F37B40E for ; Fri, 25 Oct 2002 17:12:03 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAECE43E91 for ; Fri, 25 Oct 2002 17:12:00 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0699.cvx21-bradley.dialup.earthlink.net ([209.179.194.189] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 185EYP-0007kS-00; Fri, 25 Oct 2002 17:11:49 -0700 Message-ID: <3DB9DD62.34A39BBE@mindspring.com> Date: Fri, 25 Oct 2002 17:10:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Mark Valentine , Julian Elischer , Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.cwrite_i386_disk.c write_pc98_disk.c References: <20021026095818.B5924-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > > OK, say we buy this. > > > > How does the DOS algorithm distiguisch between partitions, if not by > > the order in the table? > > Not. IIRC, it doesn't permit multiple primary DOS partitions, but logical > drives just move around if you add one in the middle. Since DOS doesn't > have anything like mount, you get to edit C: and D: in numerous config > files instead of just in fstab when the drives move. My Leading Edge PC MS-DOS 2.11 has no problem with multiple primary DOS partitions. This probably has something to do with the fact that extended DOS partitions were invented after it was released in 1986, and multiple primary DOS partitions were the only posible way to deal with big disks: "use multiple primary DOS partitions, or live without". The normal reason for moving partition table entries around is to screw with OS's other than yours, to make them not boot, and then blame the OS, rather than the tool that screwed things up. Since it's not valid to assume that there will only be one partition of a given ID, I'd still like to know how Mark suggests we identify disks whose order is important (without "editing numerous config files"). If "editing a config file" is an OK solution to the problem, well, /etc/fstab is "a config file". 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 17:20:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E184F37B401 for ; Fri, 25 Oct 2002 17:20:10 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6640743E6E for ; Fri, 25 Oct 2002 17:20:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021026002010.PSBZ13658.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sat, 26 Oct 2002 00:20:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA08785; Fri, 25 Oct 2002 17:18:10 -0700 (PDT) Date: Fri, 25 Oct 2002 17:18:09 -0700 (PDT) From: Julian Elischer To: Bill Fenner Cc: arch@freebsd.org Subject: Re: Renumbering IPPROTO_DIVERT In-Reply-To: <200210252327.g9PNRtUw001126@stash.attlabs.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hmmm seems fair.. I think though that there should be a "compat" shim that does the right thing but is VERY NOISY. On Fri, 25 Oct 2002, Bill Fenner wrote: > I'd like to move IPPROTO_DIVERT out of the legitimate space of IP protocol > numbers. Here's the patch: > > Index: in.h > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/in.h,v > retrieving revision 1.72 > diff -u -r1.72 in.h > --- in.h 21 Oct 2002 20:40:02 -0000 1.72 > +++ in.h 25 Oct 2002 21:13:20 -0000 > @@ -236,12 +236,12 @@ > #define IPPROTO_PIM 103 /* Protocol Independent Mcast */ > #define IPPROTO_PGM 113 /* PGM */ > /* 255: Reserved */ > -/* BSD Private, local use, namespace incursion */ > -#define IPPROTO_DIVERT 254 /* divert pseudo-protocol */ > #define IPPROTO_MAX 256 > > /* last return value of *_input(), meaning "all job for this pkt is done". */ > #define IPPROTO_DONE 257 > + > +#define IPPROTO_DIVERT 258 /* divert pseudo-protocol */ > > /* > * Local port number conventions: > > > Yup, it Just Works. Even better, with a patch to raw_ip.c, divert-using > applications can now get an error from their socket() call when DIVERT > isn't compiled in, as opposed to the current behavior where socket() > would succeed but provide the normal raw IP semantics. > > Now, the backwards compatability question: applications using the > old DIVERT interface will now start getting real raw IP sockets > with protocol 254. This will generally cause silent failures, or > possibly unexpected behavior (just like if DIVERT wasn't compiled > into the kernel). Should there be e.g. a kernel printf when an > application uses the old divert number, warning that an application > is using the old divert interface and needs to be recompiled? Or > is it OK to fail silently, as there are few DIVERT consumers and > it's the same failure mode as if DIVERT isn't present in the kernel? > > Bill > > 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 Oct 25 17:47:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA02A37B401 for ; Fri, 25 Oct 2002 17:47:47 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4565F43E42 for ; Fri, 25 Oct 2002 17:47:47 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 9A18D1E18D; Fri, 25 Oct 2002 20:47:46 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA28153; Fri, 25 Oct 2002 20:47:45 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id RAA01665; Fri, 25 Oct 2002 17:47:45 -0700 (PDT) Message-Id: <200210260047.RAA01665@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: julian@elischer.org Subject: Re: Renumbering IPPROTO_DIVERT Cc: arch@FreeBSD.ORG Date: Fri, 25 Oct 2002 17:47:44 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >I think though that there should be a "compat" shim that >does the right thing but is VERY NOISY. What's the right thing? I think the right thing is to open a real raw socket. If we are really feeling generous, print a message that someone used the old divert socket and if they meant to use the old divert socket they need to be recompiled. (Recall that this silent failure mode is the same behavior that a DIVERT-using application sees if it is run on a kernel without IPDIVERT, so people should be used to it.) Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 18: 0:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C01737B401 for ; Fri, 25 Oct 2002 18:00:41 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99F4943E6E for ; Fri, 25 Oct 2002 18:00:40 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021026010040.QOKU13658.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sat, 26 Oct 2002 01:00:40 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA09071; Fri, 25 Oct 2002 17:51:42 -0700 (PDT) Date: Fri, 25 Oct 2002 17:51:40 -0700 (PDT) From: Julian Elischer To: Bill Fenner Cc: arch@FreeBSD.ORG Subject: Re: Renumbering IPPROTO_DIVERT In-Reply-To: <200210260047.RAA01665@windsor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I think the right thing is to continue to steal the number for a transition period On Fri, 25 Oct 2002, Bill Fenner wrote: > > >I think though that there should be a "compat" shim that > >does the right thing but is VERY NOISY. > > What's the right thing? > > I think the right thing is to open a real raw socket. If we are really > feeling generous, print a message that someone used the old divert socket > and if they meant to use the old divert socket they need to be recompiled. > > (Recall that this silent failure mode is the same behavior that a > DIVERT-using application sees if it is run on a kernel without IPDIVERT, > so people should be used to it.) > > Bill > > 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 Oct 25 19:56:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE32137B408 for ; Fri, 25 Oct 2002 19:56:55 -0700 (PDT) Received: from edgemaster.zombie.org (edgemaster.creighton.edu [147.134.112.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 134D943E42 for ; Fri, 25 Oct 2002 19:56:55 -0700 (PDT) (envelope-from smkelly@zombie.org) Received: by edgemaster.zombie.org (Postfix, from userid 1001) id 6D85F414D0; Fri, 25 Oct 2002 21:56:54 -0500 (CDT) Date: Fri, 25 Oct 2002 21:56:54 -0500 From: Sean Kelly To: Mark Valentine Cc: Julian Elischer , Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Message-ID: <20021026025654.GA23034@edgemaster.zombie.org> References: <200210252215.g9PMFlBO083244@dotar.thuvia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210252215.g9PMFlBO083244@dotar.thuvia.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm going to put my two cents in even though I'm not a committer, but just a lowly user. On Fri, Oct 25, 2002 at 11:15:47PM +0100, Mark Valentine wrote: ... > I guess I didn't expect the "compatibility slice" to ever go away... I've used FreeBSD since 4.0. I did not know that your "compatibility slice" method even existed. I've managed to get along without for a long time. > > Ok, so, better late than never.. exactly WHY do you need to use > > ad0a (or whatever)? I can't think of any reasons for keeping that > > old compat stuff other than giving people more time to fix their > > fstabs. Enlighten me.. > > > > There is currently a mechanism for making FreeBSD play ball better with > > > the systems it shares a disk with. > > > > > > GEOM in its current state removes this mechanism, with no replacement. > > > > I fail to see how using ad0a makes it play better with other systems. > > Because DOS doesn't refer to its partition by its index in the MBR partition > table, and apparently some tools therefore feel free to reorder the table on > a whim. I've never come across any tool that did this. If it does, I would propose that it is seriously broken. Further, I believe DOS assigns disk letters by making C: equal the active drive that was booted from, while then labelling the rest of the drives based on partition table indexes. DOS supports 4 "primary" partitions. If this isn't enough, you can use the special "extended partition" and encapsulate more "logical partitions" inside of it. From my DOS days, i recall the ordering of these drives being the order they are lettered. I also propose that it is less important to talk about what "DOS" does/did, but more important to look at Windows NT/2000/XP, since it is the future fo the Microsoft PC world. We're trying to move ahead, not stay back in the 80s. > I can choose betwen hardwiring partition table indexes or using a single > disklabel (is it still possible to refer to the area outside the partition > containing the BSD disklabel in disklabel entries?). With DOS, you had to deal with AUTOEXEC.BAT, CONFIG.SYS, Windows 3.1/95, ... This was especially true if you put things on drive D: and not C:, since C: was assigned based on what you booted from. > ad0s3a is effectively a random place. It is almost frightening to me to think that your partition table changes that much and you aren't aware of what is being moved and to where it is moved. > > If you can't remember where you put it, well, that's not something we > > are going to break a good abstraction for. > > I have to figure out where some tool left it, because FreeBSD with GEOM > doesn't provide a way to specify it which matches how DOS sees it. Or, you could find a tool that isn't totally broken. > > This is a case that will happen 4 times a year in the entire world > > in my opinion. Once with you and 3 times with bruce because he will want > > to prove it's a problem. > > Sure, it's only an occasional nuisance. However, it reflects a flaw in > the system, and is not its only manifestation (see my point about scripts > and backups). What scripts do you need to modify? Once you mount a filesystem, the scripts refer to the files on it by path. Do you have scripts that play with the disk devices themselves? Once you modify /etc/fstab, there is little left that needs done. -- Sean Kelly | PGP KeyID: 77042C7B smkelly@zombie.org | http://www.zombie.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 20:47:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62D8837B401 for ; Fri, 25 Oct 2002 20:47:46 -0700 (PDT) Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F17F43E3B for ; Fri, 25 Oct 2002 20:47:45 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id g9Q3lU0N062583; Fri, 25 Oct 2002 20:47:30 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id g9Q3lUAS015399; Fri, 25 Oct 2002 20:47:30 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.6/8.12.6/Submit) id g9Q3lTmE015398; Fri, 25 Oct 2002 20:47:29 -0700 (PDT) Date: Fri, 25 Oct 2002 20:47:29 -0700 From: Marcel Moolenaar To: freebsd-arch@FreeBSD.org Cc: hiten@uk.FreeBSD.org Subject: RFC: DCE 1.1 compatible UUID support functions in libc Message-ID: <20021026034729.GA15295@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Rather long] Gang, In order to support immediate and future work, I'd like to commit the set of DCE 1.1 compatible UUID functions. For the impatient: http://www.xcllnt.net/~marcel/uuid.patch Credits: This work is mostly a joint effort between Hiten Pandya and me. Although I don't think we'd have a manpage without him :-) Rationale: UUIDs, or maybe better known as GUIDs, are playing an ever increasing role in hardware and software. It's hip, I guess :-) The source tree has two ia64 specific tools that need to operate on UUIDs, of which the GPT tool probably is a good one to mention given the lively discussion on partitioning and naming. Other people, among which Hiten, greatly benefit from heving the functions present for their porting work. Implementation decisions: One of the biggest problems with UUIDs from an implementation point of view is that they are ripped from their RPC context. This makes it impossible to be truely DCE 1.1 compliant. In this version, we had to address the following problems: 1. Where to put the functions? Multiple vendors have DCE implementations and they all seem to disagree in little things. But all of them share the fact that the UUID functions are part of the complete RPC implementation. This means that one needs to include and link with -ldce. For functions that havea high level of core visibility, this didn't seem right. SGI has implemented the functions in libc and Linux has put them in libuuid. On SGI one needs to include ; on Linux We decided that putting the functions in libc would not prohibit a full RPC implementation to work by including -ldce without some weird UUID specific library. We already have , but we decided that would better seperate userland from kernelland. Since uuid.h includes , we can freely move definitions and prototypes from one land to the other without causing breakages. A full DCE implementation can always provide a dummy that includes . 2. What to do with the silly status argument? The specification is typical. It's so typical that there's a strong desire to make its use more common. Hence, we decided that we would not make the status argument mandatory by allowing a NULL pointer to be passed. The only function that returns a status other than "uuid_s_ok", is uuid_from_string(). Compliant code will not make use of this feature. 3. We don't have a rpc_string_free() function. uuid_to_string() allocates the memory required for the string representation of an UUID. The specification states that this memory should be freed after use by calling rpc_string_free(). We decided that there's no problem. Any non-DCE code uses free() and as long as rpc_string_free() can be replaced with free(), nothing is broken. Review notes: 1. The manpage The manpage included in the patch is not the final version. Hiten is revising it currently. 2. src/lib/libc/Makefile.inc Not part of the big patch, but the one-liner required there is: Index: Makefile.inc =================================================================== RCS file: /home/ncvs/src/lib/libc/Makefile.inc,v retrieving revision 1.8 diff -u -r1.8 Makefile.inc --- Makefile.inc 15 May 2002 20:07:31 -0000 1.8 +++ Makefile.inc 20 Oct 2002 09:28:05 -0000 @@ -37,6 +37,7 @@ .include "${.CURDIR}/../libc/string/Makefile.inc" .include "${.CURDIR}/../libc/sys/Makefile.inc" .include "${.CURDIR}/../libc/rpc/Makefile.inc" +.include "${.CURDIR}/../libc/uuid/Makefile.inc" .include "${.CURDIR}/../libc/xdr/Makefile.inc" .if !defined(NO_YP_LIBC) CFLAGS+= -DYP So, let us know the verdict! -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 21:24:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9042C37B401 for ; Fri, 25 Oct 2002 21:24:49 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4FCE43E65 for ; Fri, 25 Oct 2002 21:24:48 -0700 (PDT) (envelope-from hiten@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (hiten@localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.5/8.12.1) with ESMTP id g9Q4OL2Y024492; Sat, 26 Oct 2002 00:24:21 -0400 (EDT) X-Authentication-Warning: angelica.unixdaemons.com: Host hiten@localhost.unixdaemons.com [127.0.0.1] claimed to be angelica.unixdaemons.com Received: (from hiten@localhost) by angelica.unixdaemons.com (8.12.5/8.12.1/Submit) id g9Q4OL8x024491; Sat, 26 Oct 2002 00:24:21 -0400 (EDT) (envelope-from hiten) Date: Sat, 26 Oct 2002 00:24:21 -0400 From: Hiten Pandya To: Marcel Moolenaar Cc: freebsd-arch@FreeBSD.ORG, hiten@uk.FreeBSD.org Subject: Re: RFC: DCE 1.1 compatible UUID support functions in libc Message-ID: <20021026002421.A22970@angelica.unixdaemons.com> References: <20021026034729.GA15295@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021026034729.GA15295@athlon.pn.xcllnt.net>; from marcel@xcllnt.net on Fri, Oct 25, 2002 at 08:47:29PM -0700 X-Operating-System: FreeBSD i386 X-Public-Key: http://www.pittgoth.com/~hiten/pubkey.asc X-URL: http://www.unixdaemons.com/~hiten X-PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Oct 25, 2002 at 08:47:29PM -0700, Marcel Moolenaar wrote the words in effect of: > [Rather long] > > Gang, > > In order to support immediate and future work, I'd like to commit > the set of DCE 1.1 compatible UUID functions. For the impatient: > > http://www.xcllnt.net/~marcel/uuid.patch > > Credits: > This work is mostly a joint effort between Hiten Pandya and > me. Although I don't think we'd have a manpage without him :-) > > [ ... ] Heh. Well, the manual page needs quite a lot of updating, and I would say, that, the current manual page (found at the above URL), should be left out, i.e. not committed, because it contains some pre-standard content, and we do not want unwanted doc PRs from users. :-) > Review notes: > 1. The manpage > The manpage included in the patch is not the final version. > Hiten is revising it currently. I will be looking at the manual page issue soon, because it is documentation season in my TODO list. :-) Cheers. -- Hiten Pandya http://www.unixdaemons.com/~hiten hiten@unixdaemons.com, hiten@uk.FreeBSD.org, hiten@softweyr.com PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 21:53: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1A8937B401 for ; Fri, 25 Oct 2002 21:53:05 -0700 (PDT) Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B2E243E6E for ; Fri, 25 Oct 2002 21:53:04 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id g9Q4qt0N062697; Fri, 25 Oct 2002 21:52:56 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id g9Q4tPmD001637; Fri, 25 Oct 2002 21:55:25 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id g9Q4tO2K001636; Fri, 25 Oct 2002 21:55:24 -0700 (PDT) (envelope-from marcel) Date: Fri, 25 Oct 2002 21:55:23 -0700 From: Marcel Moolenaar To: Hiten Pandya Cc: freebsd-arch@FreeBSD.ORG, hiten@uk.FreeBSD.org Subject: Re: RFC: DCE 1.1 compatible UUID support functions in libc Message-ID: <20021026045523.GA1609@dhcp01.pn.xcllnt.net> References: <20021026034729.GA15295@athlon.pn.xcllnt.net> <20021026002421.A22970@angelica.unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021026002421.A22970@angelica.unixdaemons.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Oct 26, 2002 at 12:24:21AM -0400, Hiten Pandya wrote: > On Fri, Oct 25, 2002 at 08:47:29PM -0700, Marcel Moolenaar wrote the words in effect of: > > [Rather long] > > > > Gang, > > > > In order to support immediate and future work, I'd like to commit > > the set of DCE 1.1 compatible UUID functions. For the impatient: > > > > http://www.xcllnt.net/~marcel/uuid.patch > > > > Credits: > > This work is mostly a joint effort between Hiten Pandya and > > me. Although I don't think we'd have a manpage without him :-) > > > > [ ... ] > > Heh. Well, the manual page needs quite a lot of updating, and I would > say, that, the current manual page (found at the above URL), should be > left out, i.e. not committed, because it contains some pre-standard > content, and we do not want unwanted doc PRs from users. :-) Agreed. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 25 22:20:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9CE037B401 for ; Fri, 25 Oct 2002 22:20:20 -0700 (PDT) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63D9D43E4A for ; Fri, 25 Oct 2002 22:20:20 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA10776; Fri, 25 Oct 2002 22:04:49 -0700 (PDT) Date: Fri, 25 Oct 2002 22:04:47 -0700 (PDT) From: Julian Elischer To: Marcel Moolenaar Cc: Hiten Pandya , freebsd-arch@FreeBSD.ORG, hiten@uk.FreeBSD.org Subject: Re: RFC: DCE 1.1 compatible UUID support functions in libc In-Reply-To: <20021026045523.GA1609@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG FreeBSd's libc is gettign REALLY BIG should we keep adding the kitchen sink into it? On Fri, 25 Oct 2002, Marcel Moolenaar wrote: > On Sat, Oct 26, 2002 at 12:24:21AM -0400, Hiten Pandya wrote: > > On Fri, Oct 25, 2002 at 08:47:29PM -0700, Marcel Moolenaar wrote the words in effect of: > > > [Rather long] > > > > > > Gang, > > > > > > In order to support immediate and future work, I'd like to commit > > > the set of DCE 1.1 compatible UUID functions. For the impatient: > > > > > > http://www.xcllnt.net/~marcel/uuid.patch > > > > > > Credits: > > > This work is mostly a joint effort between Hiten Pandya and > > > me. Although I don't think we'd have a manpage without him :-) > > > > > > [ ... ] > > > > Heh. Well, the manual page needs quite a lot of updating, and I would > > say, that, the current manual page (found at the above URL), should be > > left out, i.e. not committed, because it contains some pre-standard > > content, and we do not want unwanted doc PRs from users. :-) > > Agreed. > > -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net > > 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 Sat Oct 26 2: 6:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3D4D37B401 for ; Sat, 26 Oct 2002 02:06:32 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2179F43E65 for ; Sat, 26 Oct 2002 02:06:31 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9Q96FcF053049; Sat, 26 Oct 2002 10:06:15 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9Q96FH5098772; Sat, 26 Oct 2002 10:06:15 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9Q96CRx098771; Sat, 26 Oct 2002 10:06:12 +0100 (BST) Date: Sat, 26 Oct 2002 10:06:12 +0100 (BST) From: Mark Valentine Message-Id: <200210260906.g9Q96CRx098771@dotar.thuvia.org> In-Reply-To: <20021026095818.B5924-100000@gamplex.bde.org> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Bruce Evans , Terry Lambert Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Cc: Julian Elischer , Poul-Henning Kamp , "M. Warner Losh" , Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Bruce Evans > Date: Sat 26 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c > > > Because DOS doesn't refer to its partition by its index in the MBR partition > > > table, and apparently some tools therefore feel free to reorder the table on > > > a whim. > > This is a bug in the tools, so they belong in the same bin as BIOSes that > interpret the MBR. That's reassuring to know... (The behaviour seems evil to me, but I haven't seen anything so far which explicitly forbids it, and of course It Happens.) I'm less inclined to worry about workarounds for buggy tools, but I still feel there's a flaw here. By the way, FreeBSD doesn't seem to be consistent about which partition it uses, but I've never tried to figure out when it uses partition 1 and when it uses partition 4, though I've seen both occur on disks with only FreeBSD (is it DD mode that makes the difference?). > > OK, say we buy this. > > > > How does the DOS algorithm distiguisch between partitions, if not by > > the order in the table? > > Not. IIRC, it doesn't permit multiple primary DOS partitions, but logical > drives just move around if you add one in the middle. Indeed, you lose if you try to use this with multiple 0xA5 partitions without making one and only one of them "active" (or does that even make a difference?). That's DOS-compatible. Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 2:20:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 924E737B401 for ; Sat, 26 Oct 2002 02:20:39 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AA6243E4A for ; Sat, 26 Oct 2002 02:20:38 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9Q9JEcF053064; Sat, 26 Oct 2002 10:19:15 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9Q9JEH5098959; Sat, 26 Oct 2002 10:19:14 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9Q9JEK8098958; Sat, 26 Oct 2002 10:19:14 +0100 (BST) Date: Sat, 26 Oct 2002 10:19:14 +0100 (BST) From: Mark Valentine Message-Id: <200210260919.g9Q9JEK8098958@dotar.thuvia.org> In-Reply-To: <3DB9D2A6.5FBF0CE9@mindspring.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Terry Lambert Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Cc: Julian Elischer , Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Terry Lambert > Date: Fri 25 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c > What I actually think you mean is that the partition table entries > are reordered, and you want them to be distinguished gy the partition > type IS (e.g. "165"), even though there are possibly multiple entries > with identical partition type IDs. Spot on. It's a lousy algorithm, but it's what DOS seems to use, and is why DOS survives a reordering of the single primary partition it supports. QNX appears to try its best to echo the DOS behaviour, yet work around its limitations: # uname -rms QNX 6.2.0 x86pc # df /pkgs/base/public/l 0 0 0 100% / /dev/hd0t79 2779245 920357 1858888 34% / /boot/fs/qnxbase.qf 98785 98001 784 100% /pkgs/base/ /dev/hd1t12 39853760 6399680 33454080 17% /fs/hd1-dos/ /dev/hd0t6 208544 17904 190640 9% /fs/hd0-dos/ /dev/fd0 0 0 0 100% /dev/cd0 0 0 0 100% (/fs/cd0/) /dev/hd1 39876480 39876480 0 100% /dev/hd0 626472 626472 0 100% /dev/hd0t131.2 /dev/hd0 5108607 5108607 0 100% /dev/hd0t131.1 /dev/hd0 8177022 8177022 0 100% /dev/hd0t131 /dev/hd0 497952 497952 0 100% /dev/hd0t130 /dev/hd0 5108670 5108670 0 100% /dev/hd0t165 /dev/hd0 22510656 22510656 0 100% They must do this for a reason (the QNX folks are a bright bunch). Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 2:46:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E72F37B401 for ; Sat, 26 Oct 2002 02:46:48 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BD0843E4A for ; Sat, 26 Oct 2002 02:46:47 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9Q9jMcF053100; Sat, 26 Oct 2002 10:45:22 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9Q9jLH5099470; Sat, 26 Oct 2002 10:45:21 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9Q9jL0o099469; Sat, 26 Oct 2002 10:45:21 +0100 (BST) Date: Sat, 26 Oct 2002 10:45:21 +0100 (BST) From: Mark Valentine Message-Id: <200210260945.g9Q9jL0o099469@dotar.thuvia.org> In-Reply-To: <20021026025654.GA23034@edgemaster.zombie.org> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Sean Kelly Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Cc: Julian Elischer , Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Sean Kelly > Date: Fri 25 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c > On Fri, Oct 25, 2002 at 11:15:47PM +0100, Mark Valentine wrote: > ... > > I guess I didn't expect the "compatibility slice" to ever go away... > > I've used FreeBSD since 4.0. I did not know that your "compatibility slice" > method even existed. I've managed to get along without for a long time. "It works until it doesn't..." > > Because DOS doesn't refer to its partition by its index in the MBR partition > > table, and apparently some tools therefore feel free to reorder the table on > > a whim. > > I've never come across any tool that did this. If it does, I would propose > that it is seriously broken. I'll accept that. It was so long ago I can't even remember what did it; maybe I'll find out again when I'm forced to go back to hard coded partition indexes in my fstab. > > ad0s3a is effectively a random place. > > It is almost frightening to me to think that your partition table changes > that much and you aren't aware of what is being moved and to where it is > moved. Other systems on the disk survive it, however. > > Sure, it's only an occasional nuisance. However, it reflects a flaw in > > the system, and is not its only manifestation (see my point about scripts > > and backups). > > What scripts do you need to modify? Once you mount a filesystem, the > scripts refer to the files on it by path. Do you have scripts that play > with the disk devices themselves? Once you modify /etc/fstab, there is > little left that needs done. For myself, generally scripts (actually config files) related to backups; I don't pretend to know where others bury partition device names. Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 5:57:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D117837B401 for ; Sat, 26 Oct 2002 05:57:32 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59A1843E42 for ; Sat, 26 Oct 2002 05:57:31 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA08678; Sat, 26 Oct 2002 22:56:56 +1000 Date: Sat, 26 Oct 2002 23:08:09 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Mark Valentine Cc: Terry Lambert , Julian Elischer , Poul-Henning Kamp , "M. Warner Losh" , Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c In-Reply-To: <200210260906.g9Q96CRx098771@dotar.thuvia.org> Message-ID: <20021026225635.C7892-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 26 Oct 2002, Mark Valentine wrote: > > From: Bruce Evans > By the way, FreeBSD doesn't seem to be consistent about which partition it > uses, but I've never tried to figure out when it uses partition 1 and when > it uses partition 4, though I've seen both occur on disks with only FreeBSD > (is it DD mode that makes the difference?). It is consistent: the first slice with type 0xa5 is mapped to the compatibilty slice (except with GEOM of course). Extended partit^Wslice types are special. Otherwise, FreeBSD ignores the slice type as much as possible (sort of the opposite of what you say QNX does and you seem to want). Any type of slice may be labeled. Partitions of type 0xA5 may be left unlabeled, but this is warned about. > > > How does the DOS algorithm distiguisch between partitions, if not by > > > the order in the table? > > > > Not. IIRC, it doesn't permit multiple primary DOS partitions, but logical > > drives just move around if you add one in the middle. > > Indeed, you lose if you try to use this with multiple 0xA5 partitions without > making one and only one of them "active" (or does that even make a difference?). FreeBSD ignores the active partition flag. The numbers of slices only change if something moves the slice entries or if you use slices above the fourth (in extended partit^Wslices) and delete one in the middle. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 6:53:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3940937B401 for ; Sat, 26 Oct 2002 06:53:57 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id A627243E6E for ; Sat, 26 Oct 2002 06:53:55 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9QDqUcF053521; Sat, 26 Oct 2002 14:52:30 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9QDqTH5005262; Sat, 26 Oct 2002 14:52:29 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9QDqT4V005261; Sat, 26 Oct 2002 14:52:29 +0100 (BST) Date: Sat, 26 Oct 2002 14:52:29 +0100 (BST) From: Mark Valentine Message-Id: <200210261352.g9QDqT4V005261@dotar.thuvia.org> In-Reply-To: <20021026225635.C7892-100000@gamplex.bde.org> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Bruce Evans Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Cc: Terry Lambert , Julian Elischer , Poul-Henning Kamp , "M. Warner Losh" , Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Bruce Evans > Date: Sat 26 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c > On Sat, 26 Oct 2002, Mark Valentine wrote: > > By the way, FreeBSD doesn't seem to be consistent about which partition it > > uses, but I've never tried to figure out when it uses partition 1 and when > > it uses partition 4, though I've seen both occur on disks with only FreeBSD > > (is it DD mode that makes the difference?). > > It is consistent: the first slice with type 0xa5 is mapped to the > compatibilty slice (except with GEOM of course). Sorry, I wasn't talking about the compat slice stuff here, but which slice FreeBSD uses when you initialize a disk. Sysinstall will obviously use partition 1 when installing to the whole disk. In fact what I'm seeing is the "fake" partition table reported for my DD disks, which uses partition 4 for some reason. So if I were to replace my root disk with one which wasn't DD (and if I were using GEOM), I'd likely have to fix up my fstab after restoring the root file system; this seems gratuitous. I'm still a little unclear about the claims that, with GEOM, you can still use /dev/da0c etc. for DD disks (I'm thinking removable media such as Jaz disks here). How does the fake MBR partition table affect this? > FreeBSD ignores the active partition flag. OK. Would it do more harm than good to use this as a hint when locating the compatibility slice? Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 9:38:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3C5337B401 for ; Sat, 26 Oct 2002 09:38:22 -0700 (PDT) Received: from dr-evil.shagadelic.org (gw-wlan.shagadelic.org [208.176.2.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54D9643E42 for ; Sat, 26 Oct 2002 09:38:22 -0700 (PDT) (envelope-from thorpej@shagadelic.org) Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 7E1A19841; Sat, 26 Oct 2002 09:16:08 -0700 (PDT) Date: Sat, 26 Oct 2002 09:16:08 -0700 From: Jason R Thorpe To: Mark Kettenis Cc: freebsd-arch@freebsd.org, bsd-api-discuss@wasabisystems.com Subject: Re: ptrace(2) and vector registers Message-ID: <20021026091608.L19682@dhcp7.wlan.shagadelic.org> Mail-Followup-To: Jason R Thorpe , Mark Kettenis , freebsd-arch@freebsd.org, bsd-api-discuss@wasabisystems.com References: <200210212039.g9LKdMjS001116@elgar.kettenis.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: <200210212039.g9LKdMjS001116@elgar.kettenis.dyndns.org>; from kettenis@chello.nl on Mon, Oct 21, 2002 at 10:39:22PM +0200 Organization: Wasabi Systems, Inc. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Oct 21, 2002 at 10:39:22PM +0200, Mark Kettenis wrote: > NetBSD already has support for the SSE registers. There is `struct > xmmregs' in and PT_GETXMMREGS & PT_SETXMMREGS > reequests in . I have to say that I'm not terribly > happy with `struct xmmregs', since it ends with an 's', where the > other structs in (`struct reg' and `struct fpreg') > don't. But the most inportant thing is that these names are tied to > the x86. Since both SSE and AltiVec are some sort of vector registers > I'd like to propose `struct vreg' and PT_GETVREGS & PT_SETVREGS as > alternatives. NetBSD/powerpc already defines `struct vreg'. That "s" on the end is my fault -- guess I got a little carried away (it's certainly possible that my brain silently added the "s" without my knowledge every time I typed it :-) I suppose a "struct vreg" would be fine. I could certainly change NetBSD/i386 to use that name (keeping the "xmmregs" name around for backward compatibility). The danger is, of course, that at some point in the future, the XMM stuff will be extended yet again, leaving us with a useless generic name. In fact, NetBSD/arm already has this problem -- there are two distinct types of floating point register sets -- the FPA (old floating point accelerator available for e.g. ARM7) and VFP (the vector floating point defined by ARMv5). Don't let the "vector" in VFP fool you -- it is also used to plain old IEEE FP -- so in your world, would that be "fpreg" or "vreg"? -- -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 10:13:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ADDD37B401 for ; Sat, 26 Oct 2002 10:13:54 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1ADE43E65 for ; Sat, 26 Oct 2002 10:13:38 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9QHDYpk016484 for ; Sat, 26 Oct 2002 11:13:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 26 Oct 2002 11:13:12 -0600 (MDT) Message-Id: <20021026.111312.21077495.imp@bsdimp.com> To: arch@freebsd.org Subject: NO_WERROR and the kernel From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Is there a reason that NO_WERROR doesn't work with the kernel? Would there be a reason not to include the following patch? Warner Index: kern.pre.mk =================================================================== RCS file: /cache/ncvs/src/sys/conf/kern.pre.mk,v retrieving revision 1.19 diff -u -r1.19 kern.pre.mk --- kern.pre.mk 17 Sep 2002 09:07:06 -0000 1.19 +++ kern.pre.mk 26 Oct 2002 17:11:51 -0000 @@ -48,7 +48,11 @@ .endif .endif DEFINED_PROF= ${PROF} +.if !defined(NO_WERROR) WERROR?= -Werror +.else +WERROR?= +.endif # Put configuration-specific C flags last (except for ${PROF}) so that they # can override the others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 10:30:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FFCD37B408 for ; Sat, 26 Oct 2002 10:30:03 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6060043E65 for ; Sat, 26 Oct 2002 10:29:55 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9QGbApk016309 for ; Sat, 26 Oct 2002 10:37:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 26 Oct 2002 10:36:52 -0600 (MDT) Message-Id: <20021026.103652.66766445.imp@bsdimp.com> To: freebsd-arch@FreeBSD.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c From: "M. Warner Losh" In-Reply-To: References: <200210251909.g9PJ9d4F078508@dotar.thuvia.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Julian Elischer writes: : : : On Fri, 25 Oct 2002, Mark Valentine wrote: : : > : > The GEOM naming scheme therefore removes my ability to specify the partition : > in the most natural way for this platform. : I dispute that. : The install code has been using ad0s1a for about 5 years I think. : Very few systems have ad0a in /etc/fstab as we specifically have been : telling people to not do that for ages.. When this discussion began, it was not possible to recover from this error, short of booting a nonGEOM kernel. phk has fixed the -a code, which is what the kernel uses when it can't find the device specified in the fstab. At least you'd be able to get to single user and fix fstab now. So even if people had these, they would be able to fix them when they went old kernel -> new kernel (or back out to old kernel and fix them in multi-user). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 14: 0:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 684E437B404 for ; Sat, 26 Oct 2002 14:00:19 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id E18EB43E75 for ; Sat, 26 Oct 2002 14:00:16 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA45530; Sat, 26 Oct 2002 13:53:17 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9QKrHON036106; Sat, 26 Oct 2002 13:53:17 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9QKrHMd036105; Sat, 26 Oct 2002 13:53:17 -0700 (PDT) From: Archie Cobbs Message-Id: <200210262053.g9QKrHMd036105@arch20m.dellroad.org> Subject: Re: Renumbering IPPROTO_DIVERT In-Reply-To: <200210260047.RAA01665@windsor.research.att.com> "from Bill Fenner at Oct 25, 2002 05:47:44 pm" To: Bill Fenner Date: Sat, 26 Oct 2002 13:53:17 -0700 (PDT) Cc: julian@elischer.org, arch@FreeBSD.ORG 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bill Fenner writes: > >I think though that there should be a "compat" shim that > >does the right thing but is VERY NOISY. > > What's the right thing? How about just always returning an error? Sure, this will prevent non-divert applications that want to speak IP protocol #254 from working, but I don't think any really exist. If they do, they didn't work on many FreeBSD kernels (the ones with IPDIVERT) anyway. By the way, thanks for doing this. The original divert patch was written to be optimized for the shortest possible patchfile rather than the most elegant implementation, hence some of the dumb stuff like stealing an IP protocol number. It's my fault for not cleaning it up first before it got committed. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 14:15:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D655837B401 for ; Sat, 26 Oct 2002 14:15:15 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C3FF43E4A for ; Sat, 26 Oct 2002 14:15:15 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA45760; Sat, 26 Oct 2002 14:10:03 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9QLA2ON036251; Sat, 26 Oct 2002 14:10:02 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9QLA2p6036250; Sat, 26 Oct 2002 14:10:02 -0700 (PDT) From: Archie Cobbs Message-Id: <200210262110.g9QLA2p6036250@arch20m.dellroad.org> Subject: Re: Renumbering IPPROTO_DIVERT In-Reply-To: <200210262053.g9QKrHMd036105@arch20m.dellroad.org> "from Archie Cobbs at Oct 26, 2002 01:53:17 pm" To: Archie Cobbs Date: Sat, 26 Oct 2002 14:10:02 -0700 (PDT) Cc: Bill Fenner , julian@elischer.org, arch@FreeBSD.ORG 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Archie Cobbs writes: > > >I think though that there should be a "compat" shim that > > >does the right thing but is VERY NOISY. > > > > What's the right thing? > > How about just always returning an error? Sorry, should have been clearer. I meant that -current without the shim should return an error (for a transition period), to help flag programs that need to be updated. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 14:40:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB8CF37B401 for ; Sat, 26 Oct 2002 14:40:17 -0700 (PDT) Received: from stash.attlabs.att.com (mpfg.attlabs.net [12.106.35.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2990043E65 for ; Sat, 26 Oct 2002 14:40:17 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from stash.attlabs.att.com (localhost [IPv6:::1]) by stash.attlabs.att.com (8.12.6/8.12.6) with ESMTP id g9QLe0qx001360 for ; Sat, 26 Oct 2002 14:40:00 -0700 (PDT) (envelope-from fenner@stash.attlabs.att.com) Received: (from fenner@localhost) by stash.attlabs.att.com (8.12.6/8.12.6/Submit) id g9QLe08V001356 for arch@freebsd.org; Sat, 26 Oct 2002 14:40:00 -0700 (PDT) (envelope-from fenner) Date: Sat, 26 Oct 2002 14:40:00 -0700 (PDT) From: Bill Fenner Message-Id: <200210262140.g9QLe08V001356@stash.attlabs.att.com> To: arch@freebsd.org Subject: Re: Renumbering IPPROTO_DIVERT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Here's a diff that implements Archie's suggestion, with a sysctl to turn it off in case you have a real consumer of IP protocol 254. The rip_divertcompat code should go away in a couple of releases. "compat" isn't a very good name for it, since it's not compatible. The first new if in rip_attach() is a related bug that I found during this conversion; turns out that raw IP uses the third argument mod 256 as the IP protocol number, instead of returning an error for a protocol number that IP cannot support. Bill Index: in.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/in.h,v retrieving revision 1.72 diff -u -r1.72 in.h --- in.h 21 Oct 2002 20:40:02 -0000 1.72 +++ in.h 26 Oct 2002 21:35:01 -0000 @@ -236,12 +236,15 @@ #define IPPROTO_PIM 103 /* Protocol Independent Mcast */ #define IPPROTO_PGM 113 /* PGM */ /* 255: Reserved */ -/* BSD Private, local use, namespace incursion */ -#define IPPROTO_DIVERT 254 /* divert pseudo-protocol */ +/* BSD Private, local use, namespace incursion, no longer used */ +#define IPPROTO_OLD_DIVERT 254 /* OLD divert pseudo-proto */ #define IPPROTO_MAX 256 /* last return value of *_input(), meaning "all job for this pkt is done". */ #define IPPROTO_DONE 257 + +/* Only used internally, so can be outside the range of valid IP protocols. */ +#define IPPROTO_DIVERT 258 /* divert pseudo-protocol */ /* * Local port number conventions: Index: ip_divert.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_divert.c,v retrieving revision 1.69 diff -u -r1.69 ip_divert.c --- ip_divert.c 24 Oct 2002 09:58:50 -0000 1.69 +++ ip_divert.c 25 Oct 2002 23:39:04 -0000 @@ -136,8 +136,8 @@ } /* - * IPPROTO_DIVERT is not a real IP protocol; don't allow any packets - * with that protocol number to enter the system from the outside. + * IPPROTO_DIVERT is not in the real IP protocol number space; this + * function should never be called. Just in case, drop any packets. */ void div_input(struct mbuf *m, int off) Index: raw_ip.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.103 diff -u -r1.103 raw_ip.c --- raw_ip.c 20 Oct 2002 22:52:07 -0000 1.103 +++ raw_ip.c 26 Oct 2002 21:32:25 -0000 @@ -493,11 +493,14 @@ u_long rip_sendspace = RIPSNDQ; u_long rip_recvspace = RIPRCVQ; +int rip_divertcompat = 1; SYSCTL_INT(_net_inet_raw, OID_AUTO, maxdgram, CTLFLAG_RW, &rip_sendspace, 0, "Maximum outgoing raw IP datagram size"); SYSCTL_INT(_net_inet_raw, OID_AUTO, recvspace, CTLFLAG_RW, &rip_recvspace, 0, "Maximum incoming raw IP datagram size"); +SYSCTL_INT(_net_inet_raw, OID_AUTO, divertcompat, CTLFLAG_RW, + &rip_divertcompat, 0, "Return an error when creating an 'old' DIVERT socket"); static int rip_attach(struct socket *so, int proto, struct thread *td) @@ -510,6 +513,12 @@ panic("rip_attach"); if (td && (error = suser(td)) != 0) return error; + + if (proto >= IPPROTO_MAX || proto < 0) + return EPROTONOSUPPORT; + + if (rip_divertcompat && proto == IPPROTO_OLD_DIVERT) + return EPROTONOSUPPORT; error = soreserve(so, rip_sendspace, rip_recvspace); if (error) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 15: 5: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86DE437B401 for ; Sat, 26 Oct 2002 15:04:59 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 3487A43E8A for ; Sat, 26 Oct 2002 15:04:59 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 78687 invoked by uid 1000); 26 Oct 2002 22:05:00 -0000 Date: Sat, 26 Oct 2002 15:05:00 -0700 (PDT) From: Nate Lawson To: "M. Warner Losh" Cc: arch@freebsd.org Subject: Re: NO_WERROR and the kernel In-Reply-To: <20021026.111312.21077495.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 26 Oct 2002, M. Warner Losh wrote: > Is there a reason that NO_WERROR doesn't work with the kernel? Would > there be a reason not to include the following patch? > > Warner > > Index: kern.pre.mk > =================================================================== > RCS file: /cache/ncvs/src/sys/conf/kern.pre.mk,v > retrieving revision 1.19 > diff -u -r1.19 kern.pre.mk > --- kern.pre.mk 17 Sep 2002 09:07:06 -0000 1.19 > +++ kern.pre.mk 26 Oct 2002 17:11:51 -0000 > @@ -48,7 +48,11 @@ > .endif > .endif > DEFINED_PROF= ${PROF} > +.if !defined(NO_WERROR) > WERROR?= -Werror > +.else > +WERROR?= > +.endif > > # Put configuration-specific C flags last (except for ${PROF}) so that they > # can override the others. It used to be in there and was yanked on purpose (memory says phk but may be wrong). The idea is that too many were running with NO_WERROR=yes (especially since that was the recommended way of doing things for so long) and the only way to get things in shape was to remove it. You can get around it anyway when things are broken by doing WERROR= in /etc/make.conf -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 15:14:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B98537B401 for ; Sat, 26 Oct 2002 15:14:28 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30DB143E3B for ; Sat, 26 Oct 2002 15:14:28 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 814634D14A; Sat, 26 Oct 2002 18:14:27 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA05900; Sat, 26 Oct 2002 18:14:25 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA12021; Sat, 26 Oct 2002 15:14:25 -0700 (PDT) Message-Id: <200210262214.PAA12021@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: imp@bsdimp.com Subject: Re: NO_WERROR and the kernel Cc: arch@FreeBSD.ORG Date: Sat, 26 Oct 2002 15:14:23 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG That patch adds pretty much exactly what | Revision 1.16 / Mon Jul 22 00:15:01 2002 UTC (3 months ago) by peter | Changes since 1.15: +0 -5 lines | | The transition time for -Werror has been gone for a while. We are now | sufficiently clean that we can fix any new problems or mark individual | files as not being ready for -Werror. removed. I think that it was to handle the case where people still had NO_WERROR for userland but the kernel was warning-free and wanted to stay that way. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 16:40:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A891C37B401 for ; Sat, 26 Oct 2002 16:40:09 -0700 (PDT) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id F23FF43E77 for ; Sat, 26 Oct 2002 16:40:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA14625; Sat, 26 Oct 2002 16:24:39 -0700 (PDT) Date: Sat, 26 Oct 2002 16:24:38 -0700 (PDT) From: Julian Elischer To: Bill Fenner Cc: arch@freebsd.org Subject: Re: Renumbering IPPROTO_DIVERT In-Reply-To: <200210262140.g9QLe08V001356@stash.attlabs.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG looks fine to me, but I'd also spit an erro out on the console being very explicit about what is wrong.. something like "Old divert protocol called. recompile programs uding 'divert'". Maybe with a rate limitter. On Sat, 26 Oct 2002, Bill Fenner wrote: > Here's a diff that implements Archie's suggestion, with a sysctl > to turn it off in case you have a real consumer of IP protocol 254. > > The rip_divertcompat code should go away in a couple of releases. > > "compat" isn't a very good name for it, since it's not compatible. > > The first new if in rip_attach() is a related bug that I found during > this conversion; turns out that raw IP uses the third argument mod 256 > as the IP protocol number, instead of returning an error for a protocol > number that IP cannot support. > > Bill > > Index: in.h > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/in.h,v > retrieving revision 1.72 > diff -u -r1.72 in.h > --- in.h 21 Oct 2002 20:40:02 -0000 1.72 > +++ in.h 26 Oct 2002 21:35:01 -0000 > @@ -236,12 +236,15 @@ > #define IPPROTO_PIM 103 /* Protocol Independent Mcast */ > #define IPPROTO_PGM 113 /* PGM */ > /* 255: Reserved */ > -/* BSD Private, local use, namespace incursion */ > -#define IPPROTO_DIVERT 254 /* divert pseudo-protocol */ > +/* BSD Private, local use, namespace incursion, no longer used */ > +#define IPPROTO_OLD_DIVERT 254 /* OLD divert pseudo-proto */ > #define IPPROTO_MAX 256 > > /* last return value of *_input(), meaning "all job for this pkt is done". */ > #define IPPROTO_DONE 257 > + > +/* Only used internally, so can be outside the range of valid IP protocols. */ > +#define IPPROTO_DIVERT 258 /* divert pseudo-protocol */ > > /* > * Local port number conventions: > Index: ip_divert.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_divert.c,v > retrieving revision 1.69 > diff -u -r1.69 ip_divert.c > --- ip_divert.c 24 Oct 2002 09:58:50 -0000 1.69 > +++ ip_divert.c 25 Oct 2002 23:39:04 -0000 > @@ -136,8 +136,8 @@ > } > > /* > - * IPPROTO_DIVERT is not a real IP protocol; don't allow any packets > - * with that protocol number to enter the system from the outside. > + * IPPROTO_DIVERT is not in the real IP protocol number space; this > + * function should never be called. Just in case, drop any packets. > */ > void > div_input(struct mbuf *m, int off) > Index: raw_ip.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v > retrieving revision 1.103 > diff -u -r1.103 raw_ip.c > --- raw_ip.c 20 Oct 2002 22:52:07 -0000 1.103 > +++ raw_ip.c 26 Oct 2002 21:32:25 -0000 > @@ -493,11 +493,14 @@ > > u_long rip_sendspace = RIPSNDQ; > u_long rip_recvspace = RIPRCVQ; > +int rip_divertcompat = 1; > > SYSCTL_INT(_net_inet_raw, OID_AUTO, maxdgram, CTLFLAG_RW, > &rip_sendspace, 0, "Maximum outgoing raw IP datagram size"); > SYSCTL_INT(_net_inet_raw, OID_AUTO, recvspace, CTLFLAG_RW, > &rip_recvspace, 0, "Maximum incoming raw IP datagram size"); > +SYSCTL_INT(_net_inet_raw, OID_AUTO, divertcompat, CTLFLAG_RW, > + &rip_divertcompat, 0, "Return an error when creating an 'old' DIVERT socket"); > > static int > rip_attach(struct socket *so, int proto, struct thread *td) > @@ -510,6 +513,12 @@ > panic("rip_attach"); > if (td && (error = suser(td)) != 0) > return error; > + > + if (proto >= IPPROTO_MAX || proto < 0) > + return EPROTONOSUPPORT; > + > + if (rip_divertcompat && proto == IPPROTO_OLD_DIVERT) > + return EPROTONOSUPPORT; > > error = soreserve(so, rip_sendspace, rip_recvspace); > if (error) > > 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 Sat Oct 26 19:15:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08A4337B401 for ; Sat, 26 Oct 2002 19:15:57 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FDCA43E4A for ; Sat, 26 Oct 2002 19:15:56 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.6/8.12.2) with ESMTP id g9R2FunQ058454 for ; Sat, 26 Oct 2002 19:15:56 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.6/8.12.5/Submit) id g9R2Efep058449 for arch@FreeBSD.org; Sat, 26 Oct 2002 19:14:41 -0700 (PDT) Date: Sat, 26 Oct 2002 19:14:40 -0700 From: "David O'Brien" To: arch@FreeBSD.org Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Message-ID: <20021027021440.GB58312@dragon.nuxi.com> Reply-To: arch@FreeBSD.org Mail-Followup-To: David O'Brien , arch@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Oct 24, 2002 at 12:17:09PM -0400, Robert Watson wrote: > Given that lukemftpd is highly feature incomplete with regards to the > default ftpd, I'd like to propose at least the following: What "default" ftpd? We don't have one anymore. I consider it a HUGE feature that lukemftpd doesn't do PAM. Like the new "standards" headers, PAM has done nothing for me over what I had in pre-PAM'ized FreeBSD, but cause great pain. Yet another promiss of something the better and easier that has not turned out to be the case. Anyway, please do not do anything to lukemftpd until I return. -- David > (1) All references to lukemftpd as "the ftpd" be corrected to indicate > lukemftpd is not the default. Most of these are leaked references > from lukemftpd man pages that were not updated in the import. We typically don't rewrite contrib'ed vendor branch code. On some of my systems lukemftp is THE ftpd, so they do apply. > (2) Remove reference to lukemftpd in inetd.conf: it looks a little silly > to have a warning there, and the only purpose of listing something in > inetd.conf is if you plan to have it be the one users turn on. We do intend for people to turn it on. It should stay where it is. > (4) The release notes indicating lukemftpd has been imported should be > updated to indicate it is not the "default" and that it is feature > incomplete. It is not incomplete -- it has a fine set of functionalty. In fact it has larger functionality in that it is imperlious to PAM f*&king over To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 19:59:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF23B37B404 for ; Sat, 26 Oct 2002 19:59:37 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5F0E43E42 for ; Sat, 26 Oct 2002 19:59:36 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g9R2x2Oo081861 for ; Sat, 26 Oct 2002 22:59:03 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 26 Oct 2002 22:59:02 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) In-Reply-To: <20021027021440.GB58312@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 26 Oct 2002, David O'Brien wrote: > On Thu, Oct 24, 2002 at 12:17:09PM -0400, Robert Watson wrote: > > Given that lukemftpd is highly feature incomplete with regards to the > > default ftpd, I'd like to propose at least the following: > > What "default" ftpd? We don't have one anymore. I consider it a HUGE > feature that lukemftpd doesn't do PAM. Like the new "standards" > headers, PAM has done nothing for me over what I had in pre-PAM'ized > FreeBSD, but cause great pain. Yet another promiss of something the > better and easier that has not turned out to be the case. You seem to have ignored the remainder of my questions, including whether or not you plan to add support for login.conf to lukemftpd, which is required to support: - Process resource limits - Per-class login requirements, including per-class nologin file, per-class ignorenologin, per-class requirehome - Per-class umask - Per-class motd, copyright - MAC > Anyway, please do not do anything to lukemftpd until I return. My e-mail was a solicitation for advice on where we should take this. This is something we need to address before the release. Thus far, I've added the warning notice to inetd.conf to warn users away from it if their requirements include any of these standard and widely documented FreeBSD features. > > (1) All references to lukemftpd as "the ftpd" be corrected to indicate > > lukemftpd is not the default. Most of these are leaked references > > from lukemftpd man pages that were not updated in the import. > > We typically don't rewrite contrib'ed vendor branch code. On some of my > systems lukemftp is THE ftpd, so they do apply. If we choose to ship two ftp daemons on the same system, we need to carefully distinguish them. Since we install lukemftpd as lukemftpd, correctly documenting that is important. For example, if it's called lukemftpd, it should not be refered to as "ftpd" in the man pages, since "ftpd" is ftpd(8). The man page cross references are incorrect. In addition, the contributed daemons in the system, such as sendmail, provide native support for our login.conf management via setlogincontext()/setusercontext(). I'm all for bringing in cool new daemons, but if they don't support expected system features, such as centralized user classes, resource limits, authentication, logging and accounting, etc. If they do not, they need to be carefully documented as such. If we introduce new daemons, it's important that they be correctly documented, and that if we have two seperate sets of daemons that support largely identical services, they need to be carefully distinguished. For example, daemon configuration paths should be correct, cross references should be correct, etc. > > (2) Remove reference to lukemftpd in inetd.conf: it looks a little silly > > to have a warning there, and the only purpose of listing something in > > inetd.conf is if you plan to have it be the one users turn on. > > We do intend for people to turn it on. It should stay where it is. > > > (4) The release notes indicating lukemftpd has been imported should be > > updated to indicate it is not the "default" and that it is feature > > incomplete. > > It is not incomplete -- it has a fine set of functionalty. In fact it > has larger functionality in that it is imperlious to PAM f*&king over It is feature incomplete because it does not support: (1) FreeBSD's standard authentication mechanisms, including OPIE (2) FreeBSD's standard resource limits (3) FreeBSD's standard user login limits If the daemon remains in the tree, these facts must be carefully and clearly documented, since there is *great* potential for foot-shooting. All of the following scenarios are now possible: (1) Administrators rely on OPIE authentication to permit users to log in securely, but switching to lukemftpd does not permit users to log in as lukemftpd does not support OPIE, unlike every other authenticating daemon in the system. Administrators rely on PAM authentication modules to authenticate users using pam_ldap for distributed account management, but switching to lukemftpd does not allow users to log in. Administrators rely on a PAM configuration to specify the desired authentication order, trying local authentication first, then trying KerberosIV. Switching to lukemftpd requires use of the hard-coded authentication order in the source code. (2) Administrators rely on per-class resource limits to prevent the undue consumption of system memory, CPU, or file size. As a result of enabling lukemftpd, these limits are no longer enforced. (3) Administrators rely on per-class nologin in login.conf, and because they enabled lukemftpd, these restrictions are no longer enforced. There seem to be two basic classes of problems here: (a) lukemftpd doesn't use setlogincontext(), unlike every other base system daemon or tool managing user contexts (telnetd, login, sendmail, cron, ...). setlogincontext() provides centralized management of process credential state, resource limits, login limits, etc. (b) lukemftpd does not support the use of PAM, unlike every other base system authenticating daemon. While most of the base system tools support disabling PAM, they ship with PAM by default, providing access to OPIE and many other authentication types that are widely used. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 20:30:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A6A537B401 for ; Sat, 26 Oct 2002 20:30:39 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B62943E3B for ; Sat, 26 Oct 2002 20:30:38 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id OAA22687; Sun, 27 Oct 2002 14:30:06 +1100 Date: Sun, 27 Oct 2002 14:41:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Mark Valentine Cc: Terry Lambert , Julian Elischer , Poul-Henning Kamp , "M. Warner Losh" , Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c In-Reply-To: <200210261352.g9QDqT4V005261@dotar.thuvia.org> Message-ID: <20021027142156.R10013-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 26 Oct 2002, Mark Valentine wrote: > > From: Bruce Evans > > Date: Sat 26 Oct, 2002 > > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c > > > On Sat, 26 Oct 2002, Mark Valentine wrote: > > > By the way, FreeBSD doesn't seem to be consistent about which partition it > > > uses, but I've never tried to figure out when it uses partition 1 and when > > > it uses partition 4, though I've seen both occur on disks with only FreeBSD > > > (is it DD mode that makes the difference?). > > > > It is consistent: the first slice with type 0xa5 is mapped to the > > compatibilty slice (except with GEOM of course). > > Sorry, I wasn't talking about the compat slice stuff here, but which slice > FreeBSD uses when you initialize a disk. Sysinstall will obviously use > partition 1 when installing to the whole disk. This isn't very obvious. The standard partition table for zip disks is one undangerously dedicated slice covering the whole disk except the first (nominal) track. It uses partition^Wslice 4. Anyway, this choice should be optional. > In fact what I'm seeing is the "fake" partition table reported for my > DD disks, which uses partition 4 for some reason. So if I were to replace The dangerously dedicated slice uses slice 4 too. I'm no particiular reason. I'm not sure where sysinstall prefers to put undangerously dedicated slices. > my root disk with one which wasn't DD (and if I were using GEOM), I'd > likely have to fix up my fstab after restoring the root file system; > this seems gratuitous. Maybe not. > I'm still a little unclear about the claims that, with GEOM, you can > still use /dev/da0c etc. for DD disks (I'm thinking removable media > such as Jaz disks here). I think they would work. My test system has ata and a zip disk. GEOM broke "disklabel ad0" since ad0 is sliced normally, but not "disklabel afd0" since afd0 is DD. > How does the fake MBR partition table affect this? Don't know, but it should be detected as DD. > > FreeBSD ignores the active partition flag. > > OK. Would it do more harm than good to use this as a hint when locating > the compatibility slice? It would if the boot loader changes it to the boot slice. Some boot loaders have this bug, because some OSes won't boot from non-active slices. I use a boot loader that ignores active flags and boots its own idea of the boot slice. I leave the active flag set for a Windows partition and never set it for a FreeBSD partition. So using it more would be less than useful for me. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 26 21:34:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D62537B401 for ; Sat, 26 Oct 2002 21:34:16 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 567E843E42 for ; Sat, 26 Oct 2002 21:34:15 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g9R4XfOo011077 for ; Sun, 27 Oct 2002 00:33:41 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 27 Oct 2002 00:33:41 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) In-Reply-To: <20021027021440.GB58312@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 26 Oct 2002, David O'Brien wrote: > > (1) All references to lukemftpd as "the ftpd" be corrected to indicate > > lukemftpd is not the default. Most of these are leaked references > > from lukemftpd man pages that were not updated in the import. > > We typically don't rewrite contrib'ed vendor branch code. On some of my > systems lukemftp is THE ftpd, so they do apply. Just to make it completely clear what I'm talking about here: we do have a "the ftpd", because we install it as /usr/libexec/ftpd. Lukemftpd is installed as /usr/libexec/lukemftpd. Documentation should refer to the binaries and man pages correctly. One specific example of this is ftpd.conf(5), which incorrectly stats: NAME ftpd.conf - ftpd(8) configuration file It's not the configuration file for ftpd(8), it's the configuration file for lukemftpd(8). Likewise, the cross-references are wrong. Similarly, lukemftpd(8) refers to itself as ftpd(8) (which it's not), and the command as ftpd (which it's not). Incorrect man pages help no one: this action item was to correct the incorrect (and patently misleading) man pages. While there are many inaccuracies in our system man pages, we do try not to intentionally introduce them, and we also try to fix them when we find errors. > > (2) Remove reference to lukemftpd in inetd.conf: it looks a little silly > > to have a warning there, and the only purpose of listing something in > > inetd.conf is if you plan to have it be the one users turn on. > > We do intend for people to turn it on. It should stay where it is. The most basic implementation of a change here would consist of sorting ftpd above lukemftpd, and indicating it is available as an alternative. I believe ftpd should be listed first for a number of reasons, not all specious: (1) It's the ftpd we've shipped previously, and is "the" ftpd; putting it first increases the chances that a user looking for "the" ftpd with the behavior from earlier FreeBSD versions finds what they are looking for. It also makes it more clear that the warning applies only to lukemftpd. (2) "ftpd" sorts before "lukemftpd" by resonable notions of alphabetic (3) ftpd implements the standard authentication and user management frameworks for FreeBSD. In addition, from a backward compatibility perspective, lukemftpd counts as "shoot feet". > > (4) The release notes indicating lukemftpd has been imported should be > > updated to indicate it is not the "default" and that it is feature > > incomplete. > > It is not incomplete -- it has a fine set of functionalty. In fact it > has larger functionality in that it is imperlious to PAM f*&king over This addressed in previous e-mail. Note that in my e-mail (in a section you neatly trimmed), I suggested a spectrum of possible things we could do, ranging from "document it more clearly" (non-optional if it stays), to "remove it" in various forms. I'm not saying we do any particular one of these in a highly firm manner, but we do need to do at least one of them before the release. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message