From owner-freebsd-arch@FreeBSD.ORG Sun Feb 1 04:27:23 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 901D31065680; Sun, 1 Feb 2009 04:27:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB3C8FC1A; Sun, 1 Feb 2009 04:27:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n114Pe1i078896; Sat, 31 Jan 2009 21:25:40 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 31 Jan 2009 21:26:08 -0700 (MST) Message-Id: <20090131.212608.-1522433384.imp@bsdimp.com> To: obrien@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090131093130.GA17896@dragon.NUXI.org> References: <200901260947.32870.jhb@freebsd.org> <20090131093130.GA17896@dragon.NUXI.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jhb@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 04:27:23 -0000 In message: <20090131093130.GA17896@dragon.NUXI.org> "David O'Brien" writes: : At least for amd64, I'd like to see all the hints removed. We should : make these assumptions. We can't remove all hints, unless we require ACPI. The floppy drives don't enumerate properly without hints in the PNPBIOS case. I don't know if the floppies enumerate correctly for ACPI, but the code that's there seems to assume that enumerating via _FDE might fail sometimes and the fallback method is hints. This suggests that keeping the fd hints is a good thing. We also want hints to wire down uart0 and uart1 to their traditional COM1 and COM2 places. At least that's been an oft-reported bug when we don't. My current 'hints' file is thus: hint.fd.0.at="fdc0" hint.fd.0.drive="0" hint.fd.1.at="fdc0" hint.fd.1.drive="1" hint.sc.0.at="isa" hint.sc.0.flags="0x100" hint.uart.0.at="isa" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x10" hint.uart.1.at="isa" hint.uart.1.port="0x2F8" I'm too chicken to remove the hint.sc.0 hints, but maybe they can go. As for the i386 stuff, John and I realized we were being too grumpy, stopped grumping and worked it out later. Apart from some really minor tweaks, I believe John is going to go ahead and commit basically what he proposed. While one can run the above hints on x86 as well, we're not going to push things that far just yet. Maybe with 9 that will be the default and we'll have a 'LEGACY' kernel with all the gunk... or maybe we'll just let it die... For now, we'll keep the extra stuff I suggested removing since it means we can still have one kernel that boots the basics on non-enumerated systems. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Feb 1 04:44:10 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1695110656E4; Sun, 1 Feb 2009 04:44:10 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id E90F88FC19; Sun, 1 Feb 2009 04:44:09 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n114i2jQ095754; Sat, 31 Jan 2009 20:44:02 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n114i2FR095752; Sat, 31 Jan 2009 20:44:02 -0800 (PST) (envelope-from obrien) Date: Sat, 31 Jan 2009 20:44:02 -0800 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20090201044402.GA95647@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "M. Warner Losh" , jhb@FreeBSD.org, freebsd-arch@FreeBSD.org References: <200901260947.32870.jhb@freebsd.org> <20090131093130.GA17896@dragon.NUXI.org> <20090131.212608.-1522433384.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090131.212608.-1522433384.imp@bsdimp.com> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: jhb@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 04:44:10 -0000 On Sat, Jan 31, 2009 at 09:26:08PM -0700, M. Warner Losh wrote: > In message: <20090131093130.GA17896@dragon.NUXI.org> > "David O'Brien" writes: > : At least for amd64, I'd like to see all the hints removed. We should > : make these assumptions. > > We can't remove all hints, unless we require ACPI. For the most part we do for amd64. Is there reason not to? > The floppy drives > don't enumerate properly without hints in the PNPBIOS case. I don't > know if the floppies enumerate correctly for ACPI, but the code that's > there seems to assume that enumerating via _FDE might fail sometimes > and the fallback method is hints. This suggests that keeping the fd > hints is a good thing. > > We also want hints to wire down uart0 and uart1 to their traditional > COM1 and COM2 places. At least that's been an oft-reported bug when > we don't. > > My current 'hints' file is thus: > hint.fd.0.at="fdc0" > hint.fd.0.drive="0" > hint.fd.1.at="fdc0" > hint.fd.1.drive="1" > hint.sc.0.at="isa" > hint.sc.0.flags="0x100" > hint.uart.0.at="isa" > hint.uart.0.port="0x3F8" > hint.uart.0.flags="0x10" > hint.uart.1.at="isa" > hint.uart.1.port="0x2F8" That would be a great compromise hints file for amd64 given you are right - I have seen a few motherboards have issues with which com port is at which addresses. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Mon Feb 2 08:50:22 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAD0910656BE for ; Mon, 2 Feb 2009 08:50:22 +0000 (UTC) (envelope-from do-966-4030682-388168-12--freebsd-arch.freebsd.org@return.do06.net) Received: from pm49-96.do02.net (pm49-96.do02.net [80.118.49.96]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6228FC35 for ; Mon, 2 Feb 2009 08:50:21 +0000 (UTC) (envelope-from do-966-4030682-388168-12--freebsd-arch.freebsd.org@return.do06.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=dk; d=videobrokers.com; h=Message-Id:Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:List-Unsubscribe:From:To:Date:Subject; i=info@videobrokers.com; bh=Rr56N5RdnbMOgaDR3eknTUCP0qg=; b=hxXjAXlp1T+dd/SGCF0mnaz6FTMtgsSFjXA3ZmlVmCKKjgvnYaKwaaA2zKUPG1Q5jvnWTcJvPu/q ojKlDoXVuD6uC0V8vjNLlM1QfEzRzyJFzapBXXxsNSUNiFcGc5npPL1Q9yDUu+nmJpydVdCv758y RxxnhKHkJqvpuFKFd40= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=dk; d=videobrokers.com; b=VB3OIykDoNeD8OXWNmx+b1wbhjfEmG1EZiEXKi5YdgOrkDCjSnRUSNKfkZebKPjyiFjhcGPoyXZc 2YxUYMgh+r9IuCqYAMk30gOlVEBI8c2h0GT+TNIjNJNseuIldtPoWlAtQKAreiYo/Paif+A5z04o V+peT6MCanct2gmtAmQ=; Message-Id: Content-Transfer-Encoding: 8bit X-CAMPAIGN-ID: 966-4030682-388168 X-Mailer: DO v966.b4030682.c388168 From: "Video Brokers" To: freebsd-arch@freebsd.org Date: Mon, 02 Feb 2009 09:40:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Second hand video equipment for sale. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Video Brokers List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 08:50:23 -0000 [1]WWW.VIDEOBROKERS.COM WE BUY & SALE USED VIDEO/BROADCAST EQUIPMENTS! Hello, Please find bellow some details regarding the equipment we have for sale at the moment. Do not hesitate to get in touch with us if what you are looking for is not listed here, let us know as well what you have for sale. VISION MIXER's : Sony DVS2000, 10 SDI inputs @ 5.000 Euros Sony DVS2000, 16 SDI inputs @ 7.000 Euros Abekas A8150, SDI @ 3.000 Euros BTS DD20, specs on request @ 8.000 Euros BTS DD30, specs on request @ 10.000 Euros BTS DD35, specs on request @ 14.000 Euros GVG 1200, SDI @ 5.000 Euros GVG 4000, specs on request @ 4.000 Euros GVG Kayak DD1, full options @21.000 Euros GVG Kayak HD200 & HD300, specs on request @ contact us for a quote Sony DVS7250 & 7350, specs on request @ contact us for a quote VTR's : Panasonic AJ-D230H, 200 original drum hours @ 1.100 Euros Panasonic AJ-D650E, 2400 original drum hours @ 1.000 Euros Panasonic AJ-D650E, with SDI, new drum "0hrs" @ 2.500 Euros Panasonic AJ-D950E, 2500 original drum hours @ 6.000 Euros Panasonic AJ-D960E, 1000 drum hours @ 7.000 Euros Panasonic AJLT-75E, 1500 original drum hours @5.500 Euros Panasonic AJLT95, new drum "0hrs" @ 9.000 Euros Panasonic AJHD1200E, 1200 original drum hours @ 9.000 Euros Panasonic AJHD1400E, 280 original drum hours @ 16.500 Euros Sony UVW1200P, details on request @ from 400 Euros Sony UVW1600P, details on request @ from 700 Euros Sony UVW1800P, details on request @ from 1.000 Euros Sony PVW2600P, details on request @ from 800 Euros Sony PVW2650P, new drum "0hrs" @ 1.500 Euros Sony PVW2800P, serviced @ 2.000 Euros Sony BVW60P, details on request @ from 400 Euros Sony BVW65P, details on request @ from 400 Euros Sony BVW70P, details on request @ from 2.000 Euros Sony BVW70P with SDI, 800 drum hours @ 2.800 Euros Sony BVW75P, details on request @ from 2.000 Euros Sony BVWD75P, 310 drum hours @ 2.800 Euros Sony DSR1P, 59 original drum hours @ 1.900 Euros Sony DSR40P, 680 original drum hours @ 1.900 Euros Sony DSR45P, 800 original drum hours @ 2.500 Euros Sony DSR60P, 900 drum hours @ 600 Euros Sony DSR80P, with SDI, 2600 original drum hours @ 2.200 Euros Sony DSR85P, with SDI, new drum "0hrs" @ 3.500 Euros Sony DSR1500AP, with fire wire and YUV, 680 original drum hours @ 3.500 Euros Sony DSR1500AP, with SDI& fire wire, 400 original drum hours @ 4.000 Euros Sony DSR2000P, 2600 original drum hours @ 5.500 Euros Sony DSR2000P, new drum "hrs" @ 7.000 Euros Sony DNWA30P, 2000 original drum hours @ 1.500 Euros Sony DNWA65P, 3000 drum hours @ 1.800 Euros Sony DNWA75P, 3500 original drum hours @ 4.500 Euros Sony DNWA220P, 2500 drum hours @ 4.000 Euros Sony DNWA225P, 2200 drum hours @ 7.000 Euros Sony J1, betacam SP and SX player, low hours @ 1.200 Euros Sony J3A, 1200 original drum hours @ 3.900 Euros Sony DVW522P, low original drum hours @ 2.500 Euros Sony DVW510P S/N 11198, 3278 drum hours @ 4.500 Euros Sony DVWA510P, 2500 drum hours @ 6.000 Euros Sony DVW500P S/N 16243, 3587 drum hours @ 15.000 Euros Sony DVWA500P S/N 10520, fully serviced, new drum "0hrs" @ 19.000 Euros Sony DVWM2000P, 300 original drum hours @ 23.000 Euros Sony JH3, 150 original drum hours, with fire wire @ 13.000 Euros Sony HDWM2000P S/N 49298, EX-DEMO, 390 original drum hours @ 33.000 Euros Sony HDWM2000P, NEW IN THE BOX @ 36.000 Euros CAMERA's & CAMCORDER's : Sony HDC1500, complete camera chain, specs on request, 16 units available @ 50.000 Euros/ unit Thomson LDK8000, complete camera chain, specs on request, 6 units available @ make an offer Sony DXCD30P, camera head @ 1.600 Euros Sony DXCD35P, camera head @ 2.000 Euros Thomson TTV1657D (4/3-16:9) complete triax chain @ 16.000 Euros Thomson LDK23HS MKII complete chain @ 38.000 Euros Panasonic AJD800P, 1400 drum hours @ 1.600 Euros Panasonic AJD610WAE, 700 drum hours @ 3.600 Euros Panasonic AJ-SDC615E, 1300 original drum hours @ 4.500 Euros Panasonic AJD910WAE, low hours @ 5.000 Euros Panasonic AGHVX200, ex-demo, 0hrs @ 3.300 Euros Panasonic AJSDX900, with AJ-VF20WE, 2550 original drum hours @ 7.000 Euros Panasonic AJHDX900, with AJ-HVF21, 1150 original drum hours @13.000 Euros Panasonic HPX-2100E, ex-demo, 4 years warranty, with view finder and microphone @ 18.700 Euros Panasonic AJ-HDC27 (varicam), 800 original drum hours @ 15.000 Euros Sony BVWD600P S/N 40358, 233 drum hours @ 2.000 Euros Sony HVR-Z1E, around 700 original drum hours @ 2.000 Euros Sony HVR-Z5E, NEW @ 3.740 Euros Sony HVR-Z7E, NEW @ 4.680 Euros Sony PMW-EX3, NEW @ 6.870 Euros Sony PMW-700, NEW @ 21.840 Euros Sony DSRPD150P, battery charger @ 1.200 Euros Sony DSRPD170P, battery charger, wide angle converter @ 1.600 Euros Sony DSR370P S/N 42129, 383 original drum hours, including Canon YH19x6.7KRS @ 3.500 Euros Sony DSR400P S/N 43512, 50 original drum hours @ 4.000 Euros Sony DSR500WSP S/N 42925, 800 original drum hours @ 3.000 Euros Sony DSR570WSP S/N 46925, 1200 original drum hours @ 4.500 Euros Sony DSR450WSP S/N 42790, 550 original drum hours @ 7.500 Euros Sony DVW700P, details on request @ from 2.000 Euros Sony DVW707P, details on request @ from 2.500 Euros Sony DNW7P, details on request @ from 2.000 Euros Sony DNW9WSP, details on request @ from 4.000 Euros Sony DNW90WSP, details on request @ from 6.000 Euros Sony DVW709WSP S/N 40090, 1317 original drum hours @ 9.000 Euros Sony DVW709WSP S/N 40011, 399 original drum hours @ 10.000 Euros Sony DVW790WS S/N 40330, 55 drum hours @ 13.500 Euros Sony DVW790WSP S/N 41929, 516 drum hours @ 15.000 Euros Sony DVW790WSP S/N 42199, 601 original drum hours @ 17.000 Euros Sony PDW530P S/N 40538, 40 original lazer hours @ 14.000 Euros Sony PDW530P S/N 60394, 18 original lazer hours @ 15.000 Euros Sony HDW730S S/N 10192, 551 original drum hours, like new ! @ 16.000 Euros Sony HDW750P S/N 40113, 1513 original drum hours, with down converter @ 17.000 Euros Sony HDW750P S/N 40112, 1521 original drum hours, with down converter @ 17.000 Euros Sony HDW790P, 70 original drum hours @ 23.000 Euros Sony HDWF900/3 S/N 12474, 1519 original drum hours @ 20.000 Euros LENSES : Canon ZSD300 & FPD400, ex-demo @ 1.500 Euros Fujinon A16x9BERM @ 800 Euros Canon J15x8BIRS @ 1.500 Euros Fujinon A15x8BEVM @ 1.500 Euros Fujinon A8.5x5.5BEVM @ 3.000 Euros Canon YJ19x9KRS @ 1.000 Euros Canon YJ12x6.5IRS @ 3.000 Euros Canon J16x8BIRS @ 2.500 Euros Canon J8x6BKRS @ 1.800 Euros Canon J8x6BIRS @ 2.500 Euros Canon J9x5.2BIRS @ 5.000 Euros Canon J11x4.5BIRS @ 7.000 Euros Canon J22x7.6IAS @ 6.000 Euros Canon J33x15IRS with lens support + remotes @ 17.000 Euros Fujinon A10x4.8BEVM @ 6.000 Euros Fujinon A13x4.5BERD @ 8.000 Euros Fujinon HA13x4.5BERM, @ 12.000 Euros Fujinon HA13x4.5BERM, EX-DEMO @ 13.000 Euros Fujinon HA20x7.8BM10 @ 13.000 Euros Fujinon HA10x5BM10 @ 13.000 Euros Canon HJ11x4.7BIRSE, NEW @ 13.000 Euros Canon HJ21x7.8BIRSD @ 11.000 Euros Canon HJ22x7.6BIRSE, EX-DEMO @ 13.000 Euros Canon HJ22x7.6BIASE, NEW @ 14.000 Euros Fujinon HA42x , perfect condition @ contact us Canon J55super, with zoom and focus + lens support @ 19.000 Euros Canon PJ70 MK1 with zoom and focus + lens support @ 24.000 Euros Canon PJ70 MKII with zoom and focus + lens support @ 34.000 Euros Canon DIGI SUPER 86 XS with zoom and focus @ 78.000 Euros Fujinon HAe 10x10 M T1.8 @ 45.000 Euros Fujinon Super prime set @ 14.000 Euros, including : HAe F5-M10 T1.5 and HAe F8-M10 T1.5 and HAe F20-M10 T1.5 VARIOUS : Sony DME3000 @ 3.000 Euros Sony DME7000 @ 6.000 Euros Sony CA701 @ 2.000 Euros Sony RMM7G @ 700 Euros Sony CCUM5P @ 900 Euros Sony CCUM7P @ 1.000 Euros Sony CA537P @ 700 Euros Snell & Wilcox TBS24D @ 2.000 Euros Pinnacle DEKO 500 @ 3.000 Euros Pinnacle DEKO 2000 @ 9.000 Euros Sony DSC1024 @ 1.000 Euros Panasonic BTLH900E @ 2.350 Euros Panasonic BTLH1700E @ 1.480 Euros Sony BVF-VC10W @ 1.700 Euros Sony LMD 1420 @ 500 Euros Sony LMD 2020 @ 600 Euros Sony PVM9L2 @ 500 Euros Sony PVM20M2, ex-demo @ 600 Euros Sony PVM20M4 SDI @ 1.600 Euros Sony BVM2016P with SDI @ 1.500 Euros Sony BVM20G1E with SDI & BKM10R @ 4.000 Euros Sony BVMD20F1E with BKM11RR & BKM21D & BKM14L @ 6.000 Euros Sony BVM-F24E, HD/SDI, 4000 operation hours @ 19.000 Euros Sony RM450 @ 600 Euros Sony PVE500 @ 900 Euros Sony BVE9100 @ 1.500 Euros Sony BVE2000 @ 1.500 Euros Tektronix 1721/1731 @ 600 Euros Tektronix SPG110 @ 400 Euros Tektronix SPG271 @ 1.000 Euros Tektronix TSG111 @ 500 Euros Fora FA320, TBC @ 500 Euros Fora FA330, TBC @ 600 Euros Vinten Vision 10 @ 1.300 Euros Vinten Vision 11, carbon fiber @ 2.000 Euros Sachtler S18+ SBMLCF @ 3.900 Euros Tektronix WFM300 @ 800 Euros Tektronix WFM601A @ 2.500 Euros Tektronix WFM5000, ex-demo @ 4.250 Euros Sony DMXE2000 @ 1.500 Euros Sony DMXE3000 @ 2.500 Euros Sony PCM7030 @ 600 Euros Sony PCM7040 @ 1.200 Euros Yamaha 03D @ 800 Euros DK AUDIO PT5210, Vari Time Digital Sync Generator @ 2.000 Euros IDX video wireless system SDI, Model: WIVI @ 2.700 Euros AccuScene VF 1280S HD view finder with zebra Black & White, compatible for F23/F35/Genesis/RED @ 9.000 Euros FOUCUS FS-100, fire store HD multiformat DVCPRO HD, 100Go @ 400 Euros Snell & Wilcox IQ MODULAR with IQADBBG and 2x IQAVDA @ 2.000 Euros EVS XT2 6 channels SD, 5x 73GO, audio analo, AES, 2x PSU cool swap, open code, multicam LSM, super motion, FX split screen, network SDTI 1.5, protocol VDCP/DD35/ODETICS/LOUTH, protocol AVSP @ 72.000 Euros Video Brokers [2]www.videobrokers.com Alexandre Villegoureix Tel : +33 (0)6.09.84.13.86 Email : [3]alex@videobrokers.fr [4]If you wish not to receive anyfirther offer from us please follow this link References 1. http://url.videobrokers.com/id.asp?l=51090-4030682-388168-966-0 2. http://url.videobrokers.com/id.asp?l=51090-4030682-388168-966-0 3. mailto:alex@videobrokers.fr 4. http://url.videobrokers.com/id.asp?l=51089-4030682-388168-966-0&id=388168-966-4030682-7705ac45&res=fr From owner-freebsd-arch@FreeBSD.ORG Mon Feb 2 11:06:48 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE23B10656D6 for ; Mon, 2 Feb 2009 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 90ABB8FC21 for ; Mon, 2 Feb 2009 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n12B6mxt094373 for ; Mon, 2 Feb 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n12B6mpt094369 for freebsd-arch@FreeBSD.org; Mon, 2 Feb 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Feb 2009 11:06:48 GMT Message-Id: <200902021106.n12B6mpt094369@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 11:06:49 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Feb 2 22:24:25 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D458106566B for ; Mon, 2 Feb 2009 22:24:25 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 301B78FC2D for ; Mon, 2 Feb 2009 22:24:24 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n12M6TfH077532; Mon, 2 Feb 2009 14:06:29 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n12M6TS2077531; Mon, 2 Feb 2009 14:06:29 -0800 (PST) (envelope-from obrien) Date: Mon, 2 Feb 2009 14:06:29 -0800 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20090202220628.GA76833@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "M. Warner Losh" , arch@FreeBSD.org References: <200901130653.n0D6rrNX092719@svn.freebsd.org> <20090130015518.GA20404@hades.panopticon> <20090130.085130.-4349483.imp@bsdimp.com> <20090130.093052.-2022808221.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090130.093052.-2022808221.imp@bsdimp.com> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 22:24:25 -0000 On Fri, Jan 30, 2009 at 09:30:52AM -0700, M. Warner Losh wrote: > OMG! There's too much make output now, and the recent changes broke > useful make features. All but one were eventually fixed. I just > fixed the -s breakage. I fail to see where 'make -Q -s' is not suitable to achieve the goals you mentioned for 'make -s'. I did make sure you could quiet things. I've tried to measure the "~10% performance improvement" in using 'make -s' that was the technical justification for r187921. I have been unable to achieve ~10%. The summary is: 'make -j16 -Q -s' saves 2.54% over 'make -j16' on local disk. 'make -s' saves 0.96% over 'make' on local disk. results on NFS are insignificant [ delta < 0.5% ]. I ran benchmarks on ref8-amd64 (a machine others have access to and can audit my results). I checked out svn+ssh://svn.freebsd.org/base/head@187920 and built make from that. Using that make I then ran buildworld's. The abbreviated results for local disk are: MAKE=make@r187921 /usr/bin/time -h $MAKE -j16 -Q buildworld >outfile 2>&1 25m38.07s real 1h30m6.59s user 45m37.27s sys 25m15.23s real 1h30m1.67s user 45m28.50s sys 25m22.65s real 1h30m8.85s user 45m32.10s sys (1538.07 + 1515.23 + 1522.65)/3 = 1525.32 sec ave [10% improvement would reduce build by 2m33s] MAKE=make@r187921 /usr/bin/time -h $MAKE -j16 -Q -s buildworld >outfile 2>&1 24m36.12s real 1h27m27.18s user 44m26.88s sys 24m34.77s real 1h27m27.82s user 44m24.56s sys 24m29.01s real 1h27m22.16s user 44m28.23s sys (1476.12 + 1474.77 + 1469.01)/3 = 1473.30 sec ave => 1473.30 / 1525.32 * 100 - 100 = -3.41% change in build time [compared with below] => 1473.30 / 1511.70 * 100 - 100 = -2.54% change in build time MAKE=make@r187921 /usr/bin/time -h $MAKE -j16 buildworld >outfile 2>&1 25m3.95s real 1h27m40.02s user 45m19.12s sys 24m57.35s real 1h27m33.31s user 45m6.81s sys 25m33.81s real 1h27m39.68s user 44m50.02s sys (1503.95 + 1497.35 + 1533.81)/3 = 1511.70 sec ave => 1511.70 / 1525.32 * 100 - 100 = -.89% change in build time MAKE=make@r187921 /usr/bin/time -h $MAKE buildworld >outfile 2>&1 1h48m7.30s real 1h28m22.07s user 22m28.01s sys 1h48m0.94s real 1h28m35.60s user 22m7.59s sys 1h48m4.20s real 1h28m39.28s user 21m58.27s sys (6487.30 + 6480.94 + 6484.20)/3 = 6484.15 sec ave [10% improvement would reduce build by 10m48s] MAKE=make@r187921 /usr/bin/time -h $MAKE -s buildworld >outfile 2>&1 1h47m56.48s real 1h28m35.91s user 22m0.57s sys 1h47m55.65s real 1h28m40.66s user 21m56.70s sys 1h51m5.05s real 1h28m48.22s user 22m21.96s sys (6476.48 + 6475.65 + 6665.05)/3 = 6539.06 sec ave => 6539.06 / 6484.15 * 100 - 100 = .85% change in build time If we toss out the high value and use 6476.48 twice, ave = 6476.20 => 6476.20 / 6539.06 * 100 - 100 = -.96% change in build time The NFS results are: MAKE=make@r187921 /usr/bin/time -h $MAKE -j16 buildworld >outfile 2>&1 35m33.59s real 1h33m20.08s user 52m1.04s sys 31m9.58s real 1h33m43.16s user 52m41.46s sys 31m18.94s real 1h33m40.45s user 52m41.58s sys (2133.59 + 1869.58 + 1878.94)/3 = 1960.70 sec ave MAKE=make@r187921 /usr/bin/time -h $MAKE -j16 -Q -s buildworld >outfile 2>&1 31m42.62s real 1h33m28.64s user 52m4.32s sys 31m14.54s real 1h33m21.25s user 52m8.88s sys 31m17.26s real 1h33m22.48s user 52m10.93s sys (1902.62 + 1874.54 + 1877.26)/3 = 1884.81 sec ave => 1884.81 / 1960.70 * 100 - 100 = -3.87% change in build time To be fair as in the local disk case, redoing the above: (1878.94 + 1869.58 + 1878.94)/3 = 1875.82 sec ave (adjusted) => 1884.81 / 1875.82 * 100 - 100 = .48% change in build time MAKE=make@r187921 /usr/bin/time -h $MAKE buildworld >outfile 2>&1 2h21m30.74s real 1h30m28.41s user 29m8.64s sys 2h21m2.15s real 1h30m25.54s user 29m2.99s sys 2h21m0.24s real 1h30m25.93s user 29m3.85s sys (8490.74 + 8462.15 + 8460.24)/3 = 8471.04 sec ave MAKE=make@r187921 /usr/bin/time -h $MAKE -s buildworld >outfile 2>&1 2h20m48.71s real 1h30m26.02s user 29m7.66s sys 2h21m5.95s real 1h30m21.87s user 29m10.28s sys 2h21m7.70s real 1h30m29.85s user 29m4.29s sys (8448.71 + 8465.95 + 8467.7)/3 = 8460.79 sec ave => 8460.79 /8471.04 * 100 - 100 = -.12% change in build time Thus I think there isn't any real time savings with "-Q -s"/"-s". Granted I was not in full control of the machine to ensure there was no completing usage, but from what I can other users didn't adversely affect my results. Also, three samples is rather small; but I was working from very little data from the "~10% performance improvement". I also "benchmarked" log size to see how much an issue that is: /usr/bin/time -h make@r187921 -j16 buildworld 30692989 , 30076086 , 30039499 (29M) /usr/bin/time -h $MAKE -j16 -Q buildworld 27734095, 27169263, 27169297 (26M) /usr/bin/time -h $MAKE -j16 -s buildworld 1168471 , 1168346 , 1165518 (1.1M) /usr/bin/time -h make@r187921 -j16 -Q -s buildworld 925073 , 925072 , 925103 (903K) /usr/bin/time -h make@r187921 buildworld 27168710 , 27168709 , 27168710 (26M) /usr/bin/time -h make@r187921 -s buildworld 924919 , 924920 , 924919 (903K) I do not consider the 3M of additional output of 'make -j16' vs. 'make -j16 -Q' to be significant with today's disk sizes. -- -- David From owner-freebsd-arch@FreeBSD.ORG Mon Feb 2 22:31:47 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D53781065716 for ; Mon, 2 Feb 2009 22:31:47 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id B47898FC18 for ; Mon, 2 Feb 2009 22:31:47 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n12MVfNj077991; Mon, 2 Feb 2009 14:31:41 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n12MVfEn077990; Mon, 2 Feb 2009 14:31:41 -0800 (PST) (envelope-from obrien) Date: Mon, 2 Feb 2009 14:31:41 -0800 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20090202223141.GB76833@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "M. Warner Losh" , arch@FreeBSD.org References: <200901130653.n0D6rrNX092719@svn.freebsd.org> <20090130015518.GA20404@hades.panopticon> <20090130.085130.-4349483.imp@bsdimp.com> <20090130.093052.-2022808221.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090130.093052.-2022808221.imp@bsdimp.com> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 22:31:48 -0000 On Fri, Jan 30, 2009 at 09:30:52AM -0700, M. Warner Losh wrote: > First, there was absolutely no reason to introduce -Q. -v is > otherwise unused and matches the 'opt-in' debugging that's present in > the rest of make and the build system and other utilities like cp and > mv which will tell you what they are doing only if asked. I disagree. If one aliases "cp='cp -v'" it is easy to disable with issuing "\cp". Make is more complicated and looks at environmental variables to get its options. In those cases it is often useful to have a "disable" option that can used on the command line to override the environment. I could dig up other commands in /usr/src where one command enables something and following option disables it. ('ls -l -C' as one example) > Second, the extra always on debug introduces a performance penalty. I've replied separately on this topic. I was unable to measure any real 'make buildworld' penalty for my change. [that would be 'make -j16 -Q' vs. 'make -j16'] I was also only able to get about 2.5% speedup in a -j16 build after disabling all the output I easily could [make -j16 -Q -s] -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Mon Feb 2 22:42:21 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC2C21065720; Mon, 2 Feb 2009 22:42:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6C8668FC13; Mon, 2 Feb 2009 22:42:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n12MfnSw020319; Mon, 2 Feb 2009 15:41:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 02 Feb 2009 15:42:13 -0700 (MST) Message-Id: <20090202.154213.387237162.imp@bsdimp.com> To: obrien@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090202220628.GA76833@dragon.NUXI.org> References: <20090130.085130.-4349483.imp@bsdimp.com> <20090130.093052.-2022808221.imp@bsdimp.com> <20090202220628.GA76833@dragon.NUXI.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 22:42:22 -0000 In message: <20090202220628.GA76833@dragon.NUXI.org> "David O'Brien" writes: : On Fri, Jan 30, 2009 at 09:30:52AM -0700, M. Warner Losh wrote: : > OMG! There's too much make output now, and the recent changes broke : > useful make features. All but one were eventually fixed. I just : > fixed the -s breakage. : : I fail to see where 'make -Q -s' is not suitable to achieve the goals : you mentioned for 'make -s'. I did make sure you could quiet things. Two points here. (1) Should this be opt-in or opt-out. Is the output really so useful that we can't live without it? I think it should be -v to get the output. This is referred to as 'a -Q world' vs 'a -v world' in other discussions, so I'll use that here. What is the use-case that shows it is a win to be opt-in? What does having it on always buy us that having to repeat a run of a build with special debugging args to debug a problem fail to achieve? (2) Since this output falls outside of posix, one must also interpret the posix standard for what different flags do more loosely. The output is clearly related to the commands run. Is this enough, in a -Q world, to suppress it? That's not an automatic 'no' or 'yes'. In a -v world, it doesn't matter: we don't need to suppress additional output. : I've tried to measure the "~10% performance improvement" in using : 'make -s' that was the technical justification for r187921. I have : been unable to achieve ~10%. The summary is: [[ benchmarks deleted showing about a 2-3% drop in performance for -s ]] I was careful to caveat that with some environments. The one I was in was NFS to a slow server on an otherwise fast machine. I think the output size arguments are weak at best since they don't take into account the semantic value added by the output. Sure, disks can handle it, but does it add value for people or scripts reading the output? However, I think that it is a moot point since (a) I've back out the change and (b) the output is currently wrong. As to (b): Consider the following Makefile: all: one two three four one two three four: @echo ${.TARGET} @echo ${.TARGET} @echo ${.TARGET} @echo ${.TARGET} Right now, we get useless output from these job markers: % make -j 3 all --- one --- --- two --- --- three --- one one one --- one --- one two two two --- two --- two three three three --- three --- three --- four --- four four four four Based on this, I'd suggest we turn them off until we can at least produce good results. I don't know if we want them on by default with good results, but we certainly want them off when they are generating bad results. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Feb 2 23:41:58 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E730D106564A for ; Mon, 2 Feb 2009 23:41:58 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id C7AE48FC16 for ; Mon, 2 Feb 2009 23:41:58 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 7B3D18C065; Mon, 2 Feb 2009 17:24:17 -0600 (CST) Date: Mon, 2 Feb 2009 17:24:17 -0600 To: obrien@freebsd.org, "M. Warner Losh" , arch@FreeBSD.org Message-ID: <20090202232417.GB6767@soaustin.net> References: <200901130653.n0D6rrNX092719@svn.freebsd.org> <20090130015518.GA20404@hades.panopticon> <20090130.085130.-4349483.imp@bsdimp.com> <20090130.093052.-2022808221.imp@bsdimp.com> <20090202223141.GB76833@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090202223141.GB76833@dragon.NUXI.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) Cc: Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 23:41:59 -0000 Why are you being so obstinate about this? Hundreds of thousands of package builds have been done with make(1) before your "fix". Now there are gratuitous differences in the build output. Why? This is an immense POLA violation -- which is something you're very quick to beat other people over the head with. The fact that it was done this way in the historical past is irrelevant. The fact that other OSes may or may not do it this way is irrelevant. The fact that FreeBSD has done it the way that it has for -- what, 10 years -- *is* relevant, and is the *only* thing that is relevant. There are plenty of other _real_ problems in FreeBSD (e.g. ancient PRs assigned to committers that are long-undealt-with). Rather than arguing over a point you've already lost, why not work on those instead? mcl From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 00:23:50 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D08F7106564A for ; Tue, 3 Feb 2009 00:23:50 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id B09D88FC08 for ; Tue, 3 Feb 2009 00:23:50 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n130NiaO014949; Mon, 2 Feb 2009 16:23:44 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n130NiRv014948; Mon, 2 Feb 2009 16:23:44 -0800 (PST) (envelope-from obrien) Date: Mon, 2 Feb 2009 16:23:44 -0800 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20090203002344.GB14870@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "M. Warner Losh" , arch@FreeBSD.org References: <20090130.085130.-4349483.imp@bsdimp.com> <20090130.093052.-2022808221.imp@bsdimp.com> <20090202220628.GA76833@dragon.NUXI.org> <20090202.154213.387237162.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090202.154213.387237162.imp@bsdimp.com> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 00:23:51 -0000 On Mon, Feb 02, 2009 at 03:42:13PM -0700, M. Warner Losh wrote: > Right now, we get useless output from these job markers: > % make -j 3 all .. > --- one --- > --- two --- > --- three --- > one > one > one > --- one --- > one > two > two > two > --- two --- > two > three .. snip.. > Based on this, I'd suggest we turn them off until we can at least > produce good results. I don't know if we want them on by default with > good results, but we certainly want them off when they are generating > bad results. I would have expected a few days to track down the bug. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 00:46:49 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 223E5106566B for ; Tue, 3 Feb 2009 00:46:49 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id DB18A8FC13 for ; Tue, 3 Feb 2009 00:46:48 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n130kgDi015506; Mon, 2 Feb 2009 16:46:42 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n130kgqB015505; Mon, 2 Feb 2009 16:46:42 -0800 (PST) (envelope-from obrien) Date: Mon, 2 Feb 2009 16:46:42 -0800 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20090203004642.GC14870@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "M. Warner Losh" , arch@FreeBSD.org References: <20090130.085130.-4349483.imp@bsdimp.com> <20090130.093052.-2022808221.imp@bsdimp.com> <20090202220628.GA76833@dragon.NUXI.org> <20090202.154213.387237162.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090202.154213.387237162.imp@bsdimp.com> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 00:46:49 -0000 On Mon, Feb 02, 2009 at 03:42:13PM -0700, M. Warner Losh wrote: > Two points here. > (1) Should this be opt-in or opt-out. Is the output really so useful > that we can't live without it? I think it should be -v to get the > output. This is referred to as 'a -Q world' vs 'a -v world' in > other discussions, so I'll use that here. What is the use-case > that shows it is a win to be opt-in? What does having it on > always buy us that having to repeat a run of a build with special > debugging args to debug a problem fail to achieve? It can be hard to get users to repeat something as-is. Enabling the job markers by default gives the information needed to understand issues is present. Much like Robert Watson's desire for textdumps - you want enough information to understand the problem when it occurred. Its hard to get users to go back and get the needed information. Maybe I'm the only one that has found it hard to pin point the reason for a build break with 'make -j'; but I do know over the years we've told folks that report build breaks while using 'make -j' to do the build again with no -j - one reason being its hard to figure out what happened in the build. As if, the way to get support is ``make -j8 buildworld || make buildworld'' > : I've tried to measure the "~10% performance improvement" in using > : 'make -s' that was the technical justification for r187921. I have > : been unable to achieve ~10%. The summary is: > > [[ benchmarks deleted showing about a 2-3% drop in performance for -s ]] > I was careful to caveat that with some environments. The one I was > in was NFS to a slow server on an otherwise fast machine. Actually the commit message said "many environments", but I think we've both added more details and folks can investigate for their own environment. > I think the > output size arguments are weak at best since they don't take into > account the semantic value added by the output. Sure, disks can > handle it, but does it add value for people or scripts reading the > output? However, I think that it is a moot point since (a) I've back > out the change and (b) the output is currently wrong. Once (b) is fixed, I do think it adds value for people and some scripts reading the output. Scripts can unwind the output and present the complete part of the build for a particular target. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 03:27:06 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE1C6106564A; Tue, 3 Feb 2009 03:27:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 614A28FC17; Tue, 3 Feb 2009 03:27:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n133QuXG022835; Mon, 2 Feb 2009 20:26:56 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 02 Feb 2009 20:27:20 -0700 (MST) Message-Id: <20090202.202720.1492586314.imp@bsdimp.com> To: obrien@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090203002344.GB14870@dragon.NUXI.org> References: <20090202220628.GA76833@dragon.NUXI.org> <20090202.154213.387237162.imp@bsdimp.com> <20090203002344.GB14870@dragon.NUXI.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 03:27:07 -0000 In message: <20090203002344.GB14870@dragon.NUXI.org> "David O'Brien" writes: : On Mon, Feb 02, 2009 at 03:42:13PM -0700, M. Warner Losh wrote: : > Right now, we get useless output from these job markers: : > % make -j 3 all : .. : > --- one --- : > --- two --- : > --- three --- : > one : > one : > one : > --- one --- : > one : > two : > two : > two : > --- two --- : > two : > three : .. snip.. : > Based on this, I'd suggest we turn them off until we can at least : > produce good results. I don't know if we want them on by default with : > good results, but we certainly want them off when they are generating : > bad results. : : I would have expected a few days to track down the bug. I don't think so. It is time to put this experiment into the background. The change in defaults is clearly unpopular (14-0 in favor of the patches I posted, not counting your and my votes). Its benefits are unproven at this time. It clearly isn't ready for prime time and needs more testing and careful thought and study. While there may be some minor benefits from this change, if it worked, the overwhelming negative feelings it has generated suggest that the time is not ripe for it socially and that more time is needed to socialize this change within the project before the switch is pulled. If we turn it off now, then that doesn't prevent you from fixing the functionality. It protects the users and developers from faulty data produced by the patches. It also calms down the very inflamed "public opinion" of the developers and users that have cared enough about the patch to send me their votes. I also don't think a couple of days will really matter, but we are wasting way too much time on this issue and it is time to move on and get on with our lives. If you can get it working, and show concrete examples of how it can benefit the project and convince the developers it is a good idea, then we can revisit the issue. Just my two cents, of course. Warner P.S. If you haven't sent me your vote, please do. I'm especially interested to hear from people that like the current patches and would like to see them stay, when fixed. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 04:06:51 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DDD0106564A; Tue, 3 Feb 2009 04:06:51 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id D20498FC1E; Tue, 3 Feb 2009 04:06:50 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id n1346e3G011895; Mon, 2 Feb 2009 23:06:41 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20090202.154213.387237162.imp@bsdimp.com> References: <20090130.085130.-4349483.imp@bsdimp.com> <20090130.093052.-2022808221.imp@bsdimp.com> <20090202220628.GA76833@dragon.NUXI.org> <20090202.154213.387237162.imp@bsdimp.com> Date: Mon, 2 Feb 2009 23:06:40 -0500 To: "M. Warner Losh" , obrien@FreeBSD.org From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 0.10 () [Hold at 20.00] COMBINED_FROM X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 04:06:51 -0000 At 3:42 PM -0700 2/2/09, M. Warner Losh wrote: >[...] However, I think that it is a moot point since > (a) I've backed out the change and > (b) the output is currently wrong. > >As to (b): Consider the following Makefile: > >all: one two three four > >one two three four: > @echo ${.TARGET} > @echo ${.TARGET} > @echo ${.TARGET} > @echo ${.TARGET} > >Right now, we get useless output from these job markers: > >% make -j 3 all >--- one --- >--- two --- >--- three --- >one >one >one >--- one --- >one >two >two >two >--- two --- >two >three >three >three >--- three --- >three >--- four --- >four >four >four >four > >Based on this, I'd suggest we turn them off until we can at least >produce good results. I don't know if we want them on by default >with good results, but we certainly want them off when they are >generating bad results. It looks like the extra output assumes that each target is producing just a single line of output. That's pretty much what I expected would happen, and if so then the extra output doesn't really help all that much when it comes to debugging 'make -j'. I've looked around my various machines, and much to my surprise I think I found some debugging-changes I made to 'make' back in 2003/2004. These changes helped me understand some problems we were having with 'crunchgen' vs 'make -j' at the time. Let me see if I can figure out what the changes are doing, update them to the latest version of 'make', and see if people find those to be interesting. I might not have the time to do that until this weekend, though. (and just to make things more interesting, it seems I've found multiple versions of my changes... Arg.) I do remember the changes needed some more work before they'd be generally-wonderful, which is why I didn't try to commit them at the time. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 07:40:13 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0050E106566B for ; Tue, 3 Feb 2009 07:40:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 957A08FC21 for ; Tue, 3 Feb 2009 07:40:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 170C83F129; Tue, 3 Feb 2009 07:40:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n137eA77009062; Tue, 3 Feb 2009 07:40:10 GMT (envelope-from phk@critter.freebsd.dk) To: obrien@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 02 Feb 2009 14:06:29 PST." <20090202220628.GA76833@dragon.NUXI.org> Date: Tue, 03 Feb 2009 07:40:10 +0000 Message-ID: <9061.1233646810@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 07:40:13 -0000 In message <20090202220628.GA76833@dragon.NUXI.org>, "David O'Brien" writes: David, I am disappointed. You of all people here should know better than making such a mess out of benchmarks. First of all, you don't bother to even calculate a standard deviation even though we have a neat tool that does that in the base system, it's called "ministat", try it. Second you totally bungle your data collection, by not eliminating cache-effects. It should be evident to anybody that when your numbers always follow the pattern "high, low, low", that another run is necessary (you need 3 for stddev) and the first one should be discarded. Poul-Henning >The abbreviated results for local disk are: > >MAKE=make@r187921 /usr/bin/time -h $MAKE -j16 -Q buildworld >outfile 2>&1 > 25m38.07s real 1h30m6.59s user 45m37.27s sys > 25m15.23s real 1h30m1.67s user 45m28.50s sys > 25m22.65s real 1h30m8.85s user 45m32.10s sys > (1538.07 + 1515.23 + 1522.65)/3 = 1525.32 sec ave > [10% improvement would reduce build by 2m33s] Standard deviation: 11.65 seconds >MAKE=make@r187921 /usr/bin/time -h $MAKE -j16 -Q -s buildworld >outfile 2>&1 > 24m36.12s real 1h27m27.18s user 44m26.88s sys > 24m34.77s real 1h27m27.82s user 44m24.56s sys > 24m29.01s real 1h27m22.16s user 44m28.23s sys > (1476.12 + 1474.77 + 1469.01)/3 = 1473.30 sec ave > => 1473.30 / 1525.32 * 100 - 100 = -3.41% change in build time standard deviation: 3.77 second Difference at 95.0% confidence -52.0167 +/- 19.6298 -3.41022% +/- 1.28694% (Student's t, pooled s = 8.6605) > [compared with below] > => 1473.30 / 1511.70 * 100 - 100 = -2.54% change in build time Difference at 95.0% confidence 38.4033 +/- 31.7193 2.60662% +/- 2.15294% (Student's t, pooled s = 13.9942) >MAKE=make@r187921 /usr/bin/time -h $MAKE -j16 buildworld >outfile 2>&1 > 25m3.95s real 1h27m40.02s user 45m19.12s sys > 24m57.35s real 1h27m33.31s user 45m6.81s sys > 25m33.81s real 1h27m39.68s user 44m50.02s sys > (1503.95 + 1497.35 + 1533.81)/3 = 1511.70 sec ave > => 1511.70 / 1525.32 * 100 - 100 = -.89% change in build time standard deviation: 19.42 second >MAKE=make@r187921 /usr/bin/time -h $MAKE buildworld >outfile 2>&1 > 1h48m7.30s real 1h28m22.07s user 22m28.01s sys > 1h48m0.94s real 1h28m35.60s user 22m7.59s sys > 1h48m4.20s real 1h28m39.28s user 21m58.27s sys > (6487.30 + 6480.94 + 6484.20)/3 = 6484.15 sec ave > [10% improvement would reduce build by 10m48s] standard deviation 3.18 seconds >MAKE=make@r187921 /usr/bin/time -h $MAKE -s buildworld >outfile 2>&1 > 1h47m56.48s real 1h28m35.91s user 22m0.57s sys > 1h47m55.65s real 1h28m40.66s user 21m56.70s sys > 1h51m5.05s real 1h28m48.22s user 22m21.96s sys > (6476.48 + 6475.65 + 6665.05)/3 = 6539.06 sec ave N Min Max Median Avg Stddev x 3 6475.65 6665.05 6476.48 6539.06 109.11133 + 3 6480.94 6487.3 6484.2 6484.1467 3.1803354 No difference proven at 95.0% confidence > If we toss out the high value and use 6476.48 twice, ave = 6476.20 > => 6476.20 / 6539.06 * 100 - 100 = -.96% change in build time We don't. Statistics is not a television show. >The NFS results are: > >MAKE=make@r187921 /usr/bin/time -h $MAKE -j16 buildworld >outfile 2>&1 > 35m33.59s real 1h33m20.08s user 52m1.04s sys > 31m9.58s real 1h33m43.16s user 52m41.46s sys > 31m18.94s real 1h33m40.45s user 52m41.58s sys > (2133.59 + 1869.58 + 1878.94)/3 = 1960.70 sec ave standard deviation 149.79 seconds >MAKE=make@r187921 /usr/bin/time -h $MAKE -j16 -Q -s buildworld >outfile 2>&1 > 31m42.62s real 1h33m28.64s user 52m4.32s sys > 31m14.54s real 1h33m21.25s user 52m8.88s sys > 31m17.26s real 1h33m22.48s user 52m10.93s sys > (1902.62 + 1874.54 + 1877.26)/3 = 1884.81 sec ave > => 1884.81 / 1960.70 * 100 - 100 = -3.87% change in build time standard deviation 15.48 seconds N Min Max Median Avg Stddev x 3 1869.58 2133.59 1878.94 1960.7033 149.79737 + 3 1874.54 1902.62 1877.26 1884.8067 15.486631 No difference proven at 95.0% confidence > To be fair as in the local disk case, redoing the above: > (1878.94 + 1869.58 + 1878.94)/3 = 1875.82 sec ave (adjusted) > => 1884.81 / 1875.82 * 100 - 100 = .48% change in build time That has nothing to do with "fair", that is fudging the numbers. What you should have done, was realize that you need to run four tests and throw the first one which primes the cache away. >MAKE=make@r187921 /usr/bin/time -h $MAKE buildworld >outfile 2>&1 > 2h21m30.74s real 1h30m28.41s user 29m8.64s sys > 2h21m2.15s real 1h30m25.54s user 29m2.99s sys > 2h21m0.24s real 1h30m25.93s user 29m3.85s sys > (8490.74 + 8462.15 + 8460.24)/3 = 8471.04 sec ave standard deviation 17.08 seconds >MAKE=make@r187921 /usr/bin/time -h $MAKE -s buildworld >outfile 2>&1 > 2h20m48.71s real 1h30m26.02s user 29m7.66s sys > 2h21m5.95s real 1h30m21.87s user 29m10.28s sys > 2h21m7.70s real 1h30m29.85s user 29m4.29s sys > (8448.71 + 8465.95 + 8467.7)/3 = 8460.79 sec ave standard deviation 10.49 seconds No difference proven at 95.0% confidence -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 14:48:25 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F06106564A; Tue, 3 Feb 2009 14:48:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 36DAE8FC16; Tue, 3 Feb 2009 14:48:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id C2D6346B2A; Tue, 3 Feb 2009 09:48:24 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n13EmIYF050358; Tue, 3 Feb 2009 09:48:18 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 3 Feb 2009 09:48:13 -0500 User-Agent: KMail/1.9.7 References: <200901130653.n0D6rrNX092719@svn.freebsd.org> <20090202223141.GB76833@dragon.NUXI.org> <20090202232417.GB6767@soaustin.net> In-Reply-To: <20090202232417.GB6767@soaustin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902030948.13445.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 03 Feb 2009 09:48:19 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8946/Tue Feb 3 07:32:04 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Mark Linimon , arch@freebsd.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 14:48:25 -0000 On Monday 02 February 2009 6:24:17 pm Mark Linimon wrote: > Why are you being so obstinate about this? > > Hundreds of thousands of package builds have been done with make(1) > before your "fix". Now there are gratuitous differences in the build > output. Why? > > This is an immense POLA violation -- which is something you're very quick > to beat other people over the head with. The fact that it was done this > way in the historical past is irrelevant. The fact that other OSes may > or may not do it this way is irrelevant. The fact that FreeBSD has done > it the way that it has for -- what, 10 years -- *is* relevant, and is > the *only* thing that is relevant. > > There are plenty of other _real_ problems in FreeBSD (e.g. ancient PRs > assigned to committers that are long-undealt-with). Rather than arguing > over a point you've already lost, why not work on those instead? Yes, back it out now. Period. The fact that Warner is doing more work than just backing the whole thing out is very generous and if he wants to do that that is fine, but I would just back this whole mess out. It is nothing short of a POLA disaster for all of our _FreeBSD_ users who have been used to the way make has worked on FreeBSD for the past decade. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 14:48:25 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F06106564A; Tue, 3 Feb 2009 14:48:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 36DAE8FC16; Tue, 3 Feb 2009 14:48:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id C2D6346B2A; Tue, 3 Feb 2009 09:48:24 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n13EmIYF050358; Tue, 3 Feb 2009 09:48:18 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 3 Feb 2009 09:48:13 -0500 User-Agent: KMail/1.9.7 References: <200901130653.n0D6rrNX092719@svn.freebsd.org> <20090202223141.GB76833@dragon.NUXI.org> <20090202232417.GB6767@soaustin.net> In-Reply-To: <20090202232417.GB6767@soaustin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902030948.13445.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 03 Feb 2009 09:48:19 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8946/Tue Feb 3 07:32:04 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Mark Linimon , arch@freebsd.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 14:48:25 -0000 On Monday 02 February 2009 6:24:17 pm Mark Linimon wrote: > Why are you being so obstinate about this? > > Hundreds of thousands of package builds have been done with make(1) > before your "fix". Now there are gratuitous differences in the build > output. Why? > > This is an immense POLA violation -- which is something you're very quick > to beat other people over the head with. The fact that it was done this > way in the historical past is irrelevant. The fact that other OSes may > or may not do it this way is irrelevant. The fact that FreeBSD has done > it the way that it has for -- what, 10 years -- *is* relevant, and is > the *only* thing that is relevant. > > There are plenty of other _real_ problems in FreeBSD (e.g. ancient PRs > assigned to committers that are long-undealt-with). Rather than arguing > over a point you've already lost, why not work on those instead? Yes, back it out now. Period. The fact that Warner is doing more work than just backing the whole thing out is very generous and if he wants to do that that is fine, but I would just back this whole mess out. It is nothing short of a POLA disaster for all of our _FreeBSD_ users who have been used to the way make has worked on FreeBSD for the past decade. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 15:40:22 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1A7F1065697 for ; Tue, 3 Feb 2009 15:40:22 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id C6E648FC20 for ; Tue, 3 Feb 2009 15:40:21 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n13FeEpR035463; Tue, 3 Feb 2009 07:40:14 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n13FeDg1035462; Tue, 3 Feb 2009 07:40:13 -0800 (PST) (envelope-from obrien) Date: Tue, 3 Feb 2009 07:40:13 -0800 From: "David O'Brien" To: Poul-Henning Kamp Message-ID: <20090203154013.GA33520@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Poul-Henning Kamp , "M. Warner Losh" , arch@FreeBSD.org References: <20090202220628.GA76833@dragon.NUXI.org> <9061.1233646810@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9061.1233646810@critter.freebsd.dk> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 15:40:24 -0000 On Tue, Feb 03, 2009 at 07:40:10AM +0000, Poul-Henning Kamp wrote: > In message <20090202220628.GA76833@dragon.NUXI.org>, "David O'Brien" writes: > I am disappointed. > You of all people here should know better than making such a mess > out of benchmarks. Poul-Henning, I fully know these results are not stringent. Warner made a baseless 10% performance claim and used it as the bases for a commit. It took rounds of emails to get any detail from him, none of which were the actual times, standard deviation, etc... The only purpose of my measurements were to see if I could reproduce anything close to the claimed 10%. > Second you totally bungle your data collection, by not eliminating > cache-effects. I would have accepted Warner's 10% if I had gotten that just once, regardless if it was due to cache efforts or not. It would have backed up that, without totally cooking the runs, you could see a 10% time difference. -- David From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 15:54:01 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17AEB10656CE; Tue, 3 Feb 2009 15:54:01 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id DE8778FC21; Tue, 3 Feb 2009 15:53:58 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n13FrsbN035824; Tue, 3 Feb 2009 07:53:54 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n13Frs01035823; Tue, 3 Feb 2009 07:53:54 -0800 (PST) (envelope-from obrien) Date: Tue, 3 Feb 2009 07:53:54 -0800 From: "David O'Brien" To: Garance A Drosehn Message-ID: <20090203155354.GC33520@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Garance A Drosehn , "M. Warner Losh" , arch@FreeBSD.org References: <20090130.085130.-4349483.imp@bsdimp.com> <20090130.093052.-2022808221.imp@bsdimp.com> <20090202220628.GA76833@dragon.NUXI.org> <20090202.154213.387237162.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 15:54:02 -0000 On Mon, Feb 02, 2009 at 11:06:40PM -0500, Garance A Drosehn wrote: > It looks like the extra output assumes that each target is > producing just a single line of output. That's pretty much what > I expected would happen, and if so then the extra output doesn't > really help all that much when it comes to debugging 'make -j'. No, there's a bug in our make. NetBSD's make gives the correct output. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 15:57:53 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B51BB106566B; Tue, 3 Feb 2009 15:57:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5C07A8FC17; Tue, 3 Feb 2009 15:57:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n13Fu5Pj045084; Tue, 3 Feb 2009 08:56:05 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 03 Feb 2009 08:56:31 -0700 (MST) Message-Id: <20090203.085631.-2006820702.imp@bsdimp.com> To: obrien@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090203154013.GA33520@dragon.NUXI.org> References: <20090202220628.GA76833@dragon.NUXI.org> <9061.1233646810@critter.freebsd.dk> <20090203154013.GA33520@dragon.NUXI.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, phk@phk.freebsd.dk Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 15:57:53 -0000 In message: <20090203154013.GA33520@dragon.NUXI.org> "David O'Brien" writes: : Warner made a baseless 10% performance claim and used it as the : bases for a commit. The claim was not baseless. It merely reflects results that were old. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 16:12:44 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3E621065674; Tue, 3 Feb 2009 16:12:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 728A38FC0A; Tue, 3 Feb 2009 16:12:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n13G9XYW045289; Tue, 3 Feb 2009 09:09:33 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 03 Feb 2009 09:09:59 -0700 (MST) Message-Id: <20090203.090959.-1377169487.imp@bsdimp.com> To: obrien@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090203155354.GC33520@dragon.NUXI.org> References: <20090202.154213.387237162.imp@bsdimp.com> <20090203155354.GC33520@dragon.NUXI.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, gad@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 16:12:45 -0000 In message: <20090203155354.GC33520@dragon.NUXI.org> "David O'Brien" writes: : On Mon, Feb 02, 2009 at 11:06:40PM -0500, Garance A Drosehn wrote: : > It looks like the extra output assumes that each target is : > producing just a single line of output. That's pretty much what : > I expected would happen, and if so then the extra output doesn't : > really help all that much when it comes to debugging 'make -j'. : : No, there's a bug in our make. NetBSD's make gives the correct : output. make -s -v gives the correct output, but we don't have the right output w/o -s. That's a big clue there I think... Warner From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 16:23:16 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DFB41065980 for ; Tue, 3 Feb 2009 16:23:16 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5F69A8FC16 for ; Tue, 3 Feb 2009 16:23:16 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n13GN9uU036709; Tue, 3 Feb 2009 08:23:10 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n13GN9Br036708; Tue, 3 Feb 2009 08:23:09 -0800 (PST) (envelope-from obrien) Date: Tue, 3 Feb 2009 08:23:09 -0800 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20090203162309.GD33520@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "M. Warner Losh" , arch@FreeBSD.org References: <20090202220628.GA76833@dragon.NUXI.org> <9061.1233646810@critter.freebsd.dk> <20090203154013.GA33520@dragon.NUXI.org> <20090203.085631.-2006820702.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090203.085631.-2006820702.imp@bsdimp.com> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 16:23:17 -0000 On Tue, Feb 03, 2009 at 08:56:31AM -0700, M. Warner Losh wrote: > In message: <20090203154013.GA33520@dragon.NUXI.org> > "David O'Brien" writes: > : Warner made a baseless 10% performance claim and used it as the > : bases for a commit. > > The claim was not baseless. It merely reflects results that were > old. Where were the runtime numbers? The standard deviation? Ministat output? Details of the machine run on? Information on the storage. You finally mentioned this was on FreeBSD 4.x, 5.2, and 6.0 build machines. A lot has changed since November 2005. And you were timing non-j build's - yet your change was all about parallel builds, it only affected 'make -j'. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 16:30:25 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAD31106567A; Tue, 3 Feb 2009 16:30:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7BFF08FC1A; Tue, 3 Feb 2009 16:30:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n13GS9Xt045574; Tue, 3 Feb 2009 09:28:09 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 03 Feb 2009 09:28:34 -0700 (MST) Message-Id: <20090203.092834.1062687916.imp@bsdimp.com> To: obrien@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090203162309.GD33520@dragon.NUXI.org> References: <20090203154013.GA33520@dragon.NUXI.org> <20090203.085631.-2006820702.imp@bsdimp.com> <20090203162309.GD33520@dragon.NUXI.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 16:30:26 -0000 In message: <20090203162309.GD33520@dragon.NUXI.org> "David O'Brien" writes: : On Tue, Feb 03, 2009 at 08:56:31AM -0700, M. Warner Losh wrote: : > In message: <20090203154013.GA33520@dragon.NUXI.org> : > "David O'Brien" writes: : > : Warner made a baseless 10% performance claim and used it as the : > : bases for a commit. : > : > The claim was not baseless. It merely reflects results that were : > old. : : Where were the runtime numbers? The standard deviation? Ministat : output? Details of the machine run on? Information on the storage. : : You finally mentioned this was on FreeBSD 4.x, 5.2, and 6.0 build : machines. A lot has changed since November 2005. : : And you were timing non-j build's - yet your change was all about : parallel builds, it only affected 'make -j'. I'm done. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 18:24:03 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B884B1065670 for ; Tue, 3 Feb 2009 18:24:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outr.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF7F8FC13 for ; Tue, 3 Feb 2009 18:24:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id D4C9B2342; Tue, 3 Feb 2009 10:24:33 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 204B82D601A; Tue, 3 Feb 2009 10:24:03 -0800 (PST) Message-ID: <49888BC9.4050704@elischer.org> Date: Tue, 03 Feb 2009 10:24:09 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: obrien@freebsd.org, "M. Warner Losh" , arch@FreeBSD.org References: <20090202220628.GA76833@dragon.NUXI.org> <9061.1233646810@critter.freebsd.dk> <20090203154013.GA33520@dragon.NUXI.org> <20090203.085631.-2006820702.imp@bsdimp.com> <20090203162309.GD33520@dragon.NUXI.org> In-Reply-To: <20090203162309.GD33520@dragon.NUXI.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 18:24:04 -0000 David O'Brien wrote:I'm no tgoing to weigh in the technical aspects. but the general rule is you back out when asked and talk later.. can we pleas just do this? From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 18:58:38 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 101EF106566C for ; Tue, 3 Feb 2009 18:58:38 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id E32AB8FC13 for ; Tue, 3 Feb 2009 18:58:37 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n13IwaPS041357; Tue, 3 Feb 2009 10:58:36 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n13Iwa6a041356; Tue, 3 Feb 2009 10:58:36 -0800 (PST) (envelope-from obrien) Date: Tue, 3 Feb 2009 10:58:36 -0800 From: "David O'Brien" To: Julian Elischer Message-ID: <20090203185836.GA41334@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Julian Elischer , arch@FreeBSD.org References: <20090202220628.GA76833@dragon.NUXI.org> <9061.1233646810@critter.freebsd.dk> <20090203154013.GA33520@dragon.NUXI.org> <20090203.085631.-2006820702.imp@bsdimp.com> <20090203162309.GD33520@dragon.NUXI.org> <49888BC9.4050704@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49888BC9.4050704@elischer.org> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 18:58:38 -0000 On Tue, Feb 03, 2009 at 10:24:09AM -0800, Julian Elischer wrote: > David O'Brien wrote:I'm no tgoing to weigh in the technical > aspects. but the general rule is you back out when asked and talk later.. > can we pleas just do this? Hi Julian, I backed out the behavior this morning. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Tue Feb 3 19:35:38 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC336106566B; Tue, 3 Feb 2009 19:35:38 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8BE8FC1A; Tue, 3 Feb 2009 19:35:38 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id n13JZS8W005847; Tue, 3 Feb 2009 14:35:29 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20090203155354.GC33520@dragon.NUXI.org> References: <20090130.085130.-4349483.imp@bsdimp.com> <20090130.093052.-2022808221.imp@bsdimp.com> <20090202220628.GA76833@dragon.NUXI.org> <20090202.154213.387237162.imp@bsdimp.com> <20090203155354.GC33520@dragon.NUXI.org> Date: Tue, 3 Feb 2009 14:35:27 -0500 To: obrien@FreeBSD.org From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 0.10 () [Hold at 20.00] COMBINED_FROM X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 19:35:39 -0000 At 7:53 AM -0800 2/3/09, David O'Brien wrote: >On Mon, Feb 02, 2009, Garance A Drosehn wrote: > > It looks like the extra output assumes that each target is >> producing just a single line of output. That's pretty much what >> I expected would happen, and if so then the extra output doesn't >> really help all that much when it comes to debugging 'make -j'. > >No, there's a bug in our make. NetBSD's make gives the correct >output. Well, I'm thinking about an issue which (I believe) is separate from the bug, but I'll wait until that bug is fixed before I take another look at the update I wrote. Maybe I did more work than I needed to at the time. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 12:18:03 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 034A21065674; Fri, 6 Feb 2009 12:18:03 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DE14C8FC0C; Fri, 6 Feb 2009 12:18:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA11063; Fri, 06 Feb 2009 14:17:53 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <498C2A70.2030909@icyb.net.ua> Date: Fri, 06 Feb 2009 14:17:52 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: "M. Warner Losh" References: <200901260947.32870.jhb@freebsd.org> <20090131093130.GA17896@dragon.NUXI.org> <20090131.212608.-1522433384.imp@bsdimp.com> In-Reply-To: <20090131.212608.-1522433384.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jhb@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 12:18:03 -0000 on 01/02/2009 06:26 M. Warner Losh said the following: ... > hint.sc.0.at="isa" > hint.sc.0.flags="0x100" ... > I'm too chicken to remove the hint.sc.0 hints, but maybe they can go. > I've just tried this (7.1/i386) as those were the last hints, it turned out to be not that scary :) I just didn't get the system console, i.e. there were no kernel messages during boot and no system console at VT0 afterwards. VT0 became and stayed completely blank/black after loader finished its job. But the system successfully went into multi-user mode, getty-s and X started normally. OTOH, with this hint present I see the following in verbose dmesg: ... sc: sc0 already exists; skipping it ... sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) A little bit puzzling. And from the code in sys/isa/syscons_isa.c (scidentify) it seems that sc needs not a hint to get attached. Puzzled again. Let me try again with verbose dmesg that I can check once in multi-user. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 14:57:06 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3055710656C7; Fri, 6 Feb 2009 14:57:06 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id E6B178FC20; Fri, 6 Feb 2009 14:57:05 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 533D473098; Fri, 6 Feb 2009 16:02:52 +0100 (CET) Date: Fri, 6 Feb 2009 16:02:52 +0100 From: Luigi Rizzo To: arch@freebsd.org, Luigi Rizzo , Fabio Checconi , pjd@FreeBSD.org, kmacy@freebsd.org Message-ID: <20090206150252.GB11500@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RFC: upcoming fixes to bioq_disksort() and friends. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 14:57:07 -0000 Hi, [people in Bcc were involved in a previous thread] we recently discovered that bioq_disksort() does not behave as intended, and the consensus on -developers was to revert the behaviour to the one in subr_disklabel.c v.1.1. Given that there are some corner cases that neither the original nor the current code address, we would like to describe how we are going to update the code. Please let us know if you have objections or there is anything unclear. The main methods for manipulating the bioq are bioq_disksort(), which does an ordered insertion, and bioq_first()/bioq_takefirst() which poll or extract the next request from the queue. This was the original API, and the behaviour of the bioq in this case is well specified. However, subr_disk.c also introduced and exported functions to directly manipulate the TAILQ embedded in the bioq. The behaviour of these functions in terms of keeping track of the disk head is not specified, and as a consequence, if you intermix bioq_disksort() and bioq_first()/bioq_takefirst() with the other calls, the ordering of the bioq could be completely disrupted [NOTE 1]. We are going to specify (and implement) the behaviour of the bioq as follows: 1. a bioq defines the current head position, last_offset, as the bio_offset of the first byte after [NOTE 2] the last entry extracted via bioq_takefirst(). 2. bioq_first() returns the next request with bio_offset >= last_offset, leaving the request in the queue; 3. bioq_takefirst() returns the next request with bio_offset >= last_offset, extracting it from the queue and setting last_offset according to #1 4. bioq_disksort() sorts requests using (uoff_t)(bio_offset - last_offset) as the sorting key (the offset space wraps); 5. bioq_insert_tail() appends to the end of the queue and DOES NOT change last_offset; 6. bioq_insert_head() inserts at the head of the queue and sets last_offset = bio_offset [NOTE 3]; 7. in terms of implementation, the field insert_point in struct bioq_head now becomes useless. However we are not going to remove it, so that parts of the kernel that #include bio.h do not need to be rebuilt. The change is only in the behaviour of the functions, and should be considered as a fix rather than a change of features. NOTES: 1. There are only two files that do this, sys/geom/mirror/g_mirror.c and sys/dev/xen/blkfront/blkfront.c. The g_vinum code also has some mix of code but it seems just a result of implementing two different queues with a single bioq, something that should be fixed anyways. 2. Historical behaviour is to just set last_offset = bio_offset. Accounting for the request size makes the code track the head position slightly better (assuming, of course, that we can make assumptions at all on the head position). But this makes a difference only in some corner cases. 3. The update of last_offset guarantees that a bioq_disksort() after a bioq_insert_head() puts the new entry after the one inserted bioq_insert_head(). We can leave last_offset untouched, in which case we lose that guarantee. Given that there is no precedent behaviour to preserve, both approaches are equally good, but we would prefer the one proposed (updating last_offset) as it makes it easier to reason on the behaviour of the queue. cheers luigi and fabio From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 14:59:04 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1377A106566B for ; Fri, 6 Feb 2009 14:59:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D79708FC1C for ; Fri, 6 Feb 2009 14:59:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 8078F46B09; Fri, 6 Feb 2009 09:59:03 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n16EwqV2078031; Fri, 6 Feb 2009 09:58:57 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andriy Gapon Date: Fri, 6 Feb 2009 09:37:55 -0500 User-Agent: KMail/1.9.7 References: <200901260947.32870.jhb@freebsd.org> <20090131.212608.-1522433384.imp@bsdimp.com> <498C2A70.2030909@icyb.net.ua> In-Reply-To: <498C2A70.2030909@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902060937.55724.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 06 Feb 2009 09:58:57 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8961/Fri Feb 6 08:29:06 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 14:59:04 -0000 On Friday 06 February 2009 7:17:52 am Andriy Gapon wrote: > on 01/02/2009 06:26 M. Warner Losh said the following: > ... > > hint.sc.0.at="isa" > > hint.sc.0.flags="0x100" > ... > > I'm too chicken to remove the hint.sc.0 hints, but maybe they can go. > > > > I've just tried this (7.1/i386) as those were the last hints, it turned > out to be not that scary :) I just didn't get the system console, i.e. > there were no kernel messages during boot and no system console at VT0 > afterwards. VT0 became and stayed completely blank/black after loader > finished its job. > But the system successfully went into multi-user mode, getty-s and X > started normally. Yes, it's just the issue of the console that matters. If that could be made to work w/o needing the hint then we could remove it. > OTOH, with this hint present I see the following in verbose dmesg: > ... > sc: sc0 already exists; skipping it This is because it tried to add itself via an identify routine when it already existed. > ... > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) > > A little bit puzzling. > > And from the code in sys/isa/syscons_isa.c (scidentify) it seems that sc > needs not a hint to get attached. Puzzled again. Yes, it only needs the hint for it to be a console device. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 15:22:39 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C668106564A; Fri, 6 Feb 2009 15:22:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DDF108FC1A; Fri, 6 Feb 2009 15:22:37 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA17180; Fri, 06 Feb 2009 17:22:35 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <498C55BB.3030606@icyb.net.ua> Date: Fri, 06 Feb 2009 17:22:35 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: John Baldwin References: <200901260947.32870.jhb@freebsd.org> <20090131.212608.-1522433384.imp@bsdimp.com> <498C2A70.2030909@icyb.net.ua> <200902060937.55724.jhb@freebsd.org> In-Reply-To: <200902060937.55724.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 15:22:40 -0000 on 06/02/2009 16:37 John Baldwin said the following: > > Yes, it only needs the hint for it to be a console device. > I am slightly confused as to how that hint works then, it's not like a standard isa hint it seems. Can it somehow be built-in (into the code)? -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 16:07:07 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 671EA1065673 for ; Fri, 6 Feb 2009 16:07:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 37AD18FC13 for ; Fri, 6 Feb 2009 16:07:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id D706746B37; Fri, 6 Feb 2009 11:07:06 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n16G6s6c078477; Fri, 6 Feb 2009 11:07:00 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andriy Gapon Date: Fri, 6 Feb 2009 11:06:40 -0500 User-Agent: KMail/1.9.7 References: <200901260947.32870.jhb@freebsd.org> <200902060937.55724.jhb@freebsd.org> <498C55BB.3030606@icyb.net.ua> In-Reply-To: <498C55BB.3030606@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902061106.41235.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 06 Feb 2009 11:07:00 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8961/Fri Feb 6 08:29:06 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:07:07 -0000 On Friday 06 February 2009 10:22:35 am Andriy Gapon wrote: > on 06/02/2009 16:37 John Baldwin said the following: > > > > Yes, it only needs the hint for it to be a console device. > > > > I am slightly confused as to how that hint works then, it's not like a > standard isa hint it seems. > Can it somehow be built-in (into the code)? It works "normally" during the new-bus attach, but the low-level console code probably checks for it early on as well. The serial console code works that way. The uart(4) and sio(4) drivers explicitly look for uart/sio hints to find possible console devices. This is separate from when the ISA bus adds uart/sio devices from the hints later on. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 16:27:20 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A574D106564A; Fri, 6 Feb 2009 16:27:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E41148FC12; Fri, 6 Feb 2009 16:27:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n16GOq5C060864; Fri, 6 Feb 2009 09:24:52 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 06 Feb 2009 09:25:23 -0700 (MST) Message-Id: <20090206.092523.2067072549.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200902061106.41235.jhb@freebsd.org> References: <200902060937.55724.jhb@freebsd.org> <498C55BB.3030606@icyb.net.ua> <200902061106.41235.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: avg@icyb.net.ua, freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:27:20 -0000 In message: <200902061106.41235.jhb@freebsd.org> John Baldwin writes: : On Friday 06 February 2009 10:22:35 am Andriy Gapon wrote: : > on 06/02/2009 16:37 John Baldwin said the following: : > > : > > Yes, it only needs the hint for it to be a console device. : > > : > : > I am slightly confused as to how that hint works then, it's not like a : > standard isa hint it seems. : > Can it somehow be built-in (into the code)? : : It works "normally" during the new-bus attach, but the low-level console code : probably checks for it early on as well. The serial console code works that : way. The uart(4) and sio(4) drivers explicitly look for uart/sio hints to : find possible console devices. This is separate from when the ISA bus adds : uart/sio devices from the hints later on. sio could be loaded as a driver, and still be the console driver. But it had to be loaded from /boot/loader. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 16:43:27 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80E361065670 for ; Fri, 6 Feb 2009 16:43:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 509878FC14 for ; Fri, 6 Feb 2009 16:43:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id ECEDA46B09; Fri, 6 Feb 2009 11:43:26 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n16GhLVR078660; Fri, 6 Feb 2009 11:43:21 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Fri, 6 Feb 2009 11:37:41 -0500 User-Agent: KMail/1.9.7 References: <200902060937.55724.jhb@freebsd.org> <200902061106.41235.jhb@freebsd.org> <20090206.092523.2067072549.imp@bsdimp.com> In-Reply-To: <20090206.092523.2067072549.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902061137.42052.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 06 Feb 2009 11:43:21 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8961/Fri Feb 6 08:29:06 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: avg@icyb.net.ua, freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:43:27 -0000 On Friday 06 February 2009 11:25:23 am M. Warner Losh wrote: > In message: <200902061106.41235.jhb@freebsd.org> > John Baldwin writes: > : On Friday 06 February 2009 10:22:35 am Andriy Gapon wrote: > : > on 06/02/2009 16:37 John Baldwin said the following: > : > > > : > > Yes, it only needs the hint for it to be a console device. > : > > > : > > : > I am slightly confused as to how that hint works then, it's not like a > : > standard isa hint it seems. > : > Can it somehow be built-in (into the code)? > : > : It works "normally" during the new-bus attach, but the low-level console code > : probably checks for it early on as well. The serial console code works that > : way. The uart(4) and sio(4) drivers explicitly look for uart/sio hints to > : find possible console devices. This is separate from when the ISA bus adds > : uart/sio devices from the hints later on. > > sio could be loaded as a driver, and still be the console driver. But > it had to be loaded from /boot/loader. Are you sure? The console stuff is initialized (cninit()) well before any SYSINIT's are run. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 16:43:32 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC915106566B for ; Fri, 6 Feb 2009 16:43:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AD6588FC0A for ; Fri, 6 Feb 2009 16:43:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 5AF6846B32; Fri, 6 Feb 2009 11:43:32 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n16GhLVS078660; Fri, 6 Feb 2009 11:43:26 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andriy Gapon Date: Fri, 6 Feb 2009 11:43:09 -0500 User-Agent: KMail/1.9.7 References: <200901260947.32870.jhb@freebsd.org> <200902060937.55724.jhb@freebsd.org> <498C55BB.3030606@icyb.net.ua> In-Reply-To: <498C55BB.3030606@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902061143.10088.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 06 Feb 2009 11:43:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8961/Fri Feb 6 08:29:06 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:43:33 -0000 On Friday 06 February 2009 10:22:35 am Andriy Gapon wrote: > on 06/02/2009 16:37 John Baldwin said the following: > > > > Yes, it only needs the hint for it to be a console device. > > > > I am slightly confused as to how that hint works then, it's not like a > standard isa hint it seems. > Can it somehow be built-in (into the code)? Specifically, look at sc_cnprobe() in sys/dev/syscons/syscons.c. It calls a sc_cons_get_priority() routine that on x86 maps lives in sys/isa/syscons_isa.c. This checks for a syscons hint. Changing it to always assume a unit 0 would probably allow this to work. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 16:48:05 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 405EC106564A; Fri, 6 Feb 2009 16:48:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 31B408FC14; Fri, 6 Feb 2009 16:48:03 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA20067; Fri, 06 Feb 2009 18:48:02 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <498C69C1.70605@icyb.net.ua> Date: Fri, 06 Feb 2009 18:48:01 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: John Baldwin References: <200901260947.32870.jhb@freebsd.org> <200902060937.55724.jhb@freebsd.org> <498C55BB.3030606@icyb.net.ua> <200902061106.41235.jhb@freebsd.org> In-Reply-To: <200902061106.41235.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:48:05 -0000 on 06/02/2009 18:06 John Baldwin said the following: > On Friday 06 February 2009 10:22:35 am Andriy Gapon wrote: >> on 06/02/2009 16:37 John Baldwin said the following: >>> Yes, it only needs the hint for it to be a console device. >>> >> I am slightly confused as to how that hint works then, it's not like a >> standard isa hint it seems. >> Can it somehow be built-in (into the code)? > > It works "normally" during the new-bus attach, but the low-level console code > probably checks for it early on as well. The serial console code works that > way. The uart(4) and sio(4) drivers explicitly look for uart/sio hints to > find possible console devices. This is separate from when the ISA bus adds > uart/sio devices from the hints later on. > John, could it be sc_get_cons_priority function in syscons_isa.c? It seems that it explicitly searches through hints data and makes some important decisions based on it. It seems that without any hints at all it would return CN_DEAD. Maybe that code could be smarter and return something correct without relying that much on hints. It really doesn't seem like the hints should be so critical there (e.g. see ifdef XBOX there). -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 16:48:45 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E525A1065674; Fri, 6 Feb 2009 16:48:45 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D38E48FC17; Fri, 6 Feb 2009 16:48:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA20079; Fri, 06 Feb 2009 18:48:43 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <498C69EA.6030202@icyb.net.ua> Date: Fri, 06 Feb 2009 18:48:42 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: John Baldwin References: <200901260947.32870.jhb@freebsd.org> <200902060937.55724.jhb@freebsd.org> <498C55BB.3030606@icyb.net.ua> <200902061143.10088.jhb@freebsd.org> In-Reply-To: <200902061143.10088.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:48:46 -0000 on 06/02/2009 18:43 John Baldwin said the following: > On Friday 06 February 2009 10:22:35 am Andriy Gapon wrote: >> on 06/02/2009 16:37 John Baldwin said the following: >>> Yes, it only needs the hint for it to be a console device. >>> >> I am slightly confused as to how that hint works then, it's not like a >> standard isa hint it seems. >> Can it somehow be built-in (into the code)? > > Specifically, look at sc_cnprobe() in sys/dev/syscons/syscons.c. It calls a > sc_cons_get_priority() routine that on x86 maps lives in > sys/isa/syscons_isa.c. This checks for a syscons hint. Changing it to > always assume a unit 0 would probably allow this to work. > Mid-air collision detected :-) -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 16:56:03 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 768D5106566C for ; Fri, 6 Feb 2009 16:56:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 46E9A8FC18 for ; Fri, 6 Feb 2009 16:56:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id E282B46B37; Fri, 6 Feb 2009 11:56:02 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n16GttZR078789; Fri, 6 Feb 2009 11:55:55 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 6 Feb 2009 11:55:48 -0500 User-Agent: KMail/1.9.7 References: <200901260947.32870.jhb@freebsd.org> <498C55BB.3030606@icyb.net.ua> <200902061143.10088.jhb@freebsd.org> In-Reply-To: <200902061143.10088.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902061155.48705.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 06 Feb 2009 11:55:55 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8961/Fri Feb 6 08:29:06 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Andriy Gapon Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:56:03 -0000 On Friday 06 February 2009 11:43:09 am John Baldwin wrote: > On Friday 06 February 2009 10:22:35 am Andriy Gapon wrote: > > on 06/02/2009 16:37 John Baldwin said the following: > > > > > > Yes, it only needs the hint for it to be a console device. > > > > > > > I am slightly confused as to how that hint works then, it's not like a > > standard isa hint it seems. > > Can it somehow be built-in (into the code)? > > Specifically, look at sc_cnprobe() in sys/dev/syscons/syscons.c. It calls a > sc_cons_get_priority() routine that on x86 maps lives in > sys/isa/syscons_isa.c. This checks for a syscons hint. Changing it to > always assume a unit 0 would probably allow this to work. Something like this (untested): --- //depot/user/jhb/acpipci/isa/syscons_isa.c +++ /home/jhb/work/p4/acpipci/isa/syscons_isa.c @@ -238,8 +238,10 @@ *flags = f; } } - if (*unit < 0) - return CN_DEAD; + if (*unit < 0) { + *unit = 0; + *flags = 0; + } #if 0 return ((*flags & SC_KERNEL_CONSOLE) ? CN_INTERNAL : CN_NORMAL); #endif -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 17:05:16 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 890761065673; Fri, 6 Feb 2009 17:05:16 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3C38FC0C; Fri, 6 Feb 2009 17:05:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA20472; Fri, 06 Feb 2009 19:05:13 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <498C6DC9.8020700@icyb.net.ua> Date: Fri, 06 Feb 2009 19:05:13 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: John Baldwin References: <200901260947.32870.jhb@freebsd.org> <498C55BB.3030606@icyb.net.ua> <200902061143.10088.jhb@freebsd.org> <200902061155.48705.jhb@freebsd.org> In-Reply-To: <200902061155.48705.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 17:05:17 -0000 on 06/02/2009 18:55 John Baldwin said the following: > On Friday 06 February 2009 11:43:09 am John Baldwin wrote: >> On Friday 06 February 2009 10:22:35 am Andriy Gapon wrote: >>> on 06/02/2009 16:37 John Baldwin said the following: >>>> Yes, it only needs the hint for it to be a console device. >>>> >>> I am slightly confused as to how that hint works then, it's not like a >>> standard isa hint it seems. >>> Can it somehow be built-in (into the code)? >> Specifically, look at sc_cnprobe() in sys/dev/syscons/syscons.c. It calls a >> sc_cons_get_priority() routine that on x86 maps lives in >> sys/isa/syscons_isa.c. This checks for a syscons hint. Changing it to >> always assume a unit 0 would probably allow this to work. > > Something like this (untested): I am not sure, but maybe, just in case, also add sc_get_softc(0,0) != NULL check? I guess device_get_softc returns NULL for non-attached/unknown devices. > --- //depot/user/jhb/acpipci/isa/syscons_isa.c > +++ /home/jhb/work/p4/acpipci/isa/syscons_isa.c > @@ -238,8 +238,10 @@ > *flags = f; > } > } > - if (*unit < 0) > - return CN_DEAD; > + if (*unit < 0) { > + *unit = 0; > + *flags = 0; > + } > #if 0 > return ((*flags & SC_KERNEL_CONSOLE) ? CN_INTERNAL : CN_NORMAL); > #endif > > -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 17:07:18 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A6411065679; Fri, 6 Feb 2009 17:07:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4708FC0A; Fri, 6 Feb 2009 17:07:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n16H54kX061392; Fri, 6 Feb 2009 10:05:04 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 06 Feb 2009 10:05:35 -0700 (MST) Message-Id: <20090206.100535.-221723595.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200902061137.42052.jhb@freebsd.org> References: <200902061106.41235.jhb@freebsd.org> <20090206.092523.2067072549.imp@bsdimp.com> <200902061137.42052.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: avg@icyb.net.ua, freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 17:07:19 -0000 In message: <200902061137.42052.jhb@freebsd.org> John Baldwin writes: : On Friday 06 February 2009 11:25:23 am M. Warner Losh wrote: : > In message: <200902061106.41235.jhb@freebsd.org> : > John Baldwin writes: : > : On Friday 06 February 2009 10:22:35 am Andriy Gapon wrote: : > : > on 06/02/2009 16:37 John Baldwin said the following: : > : > > : > : > > Yes, it only needs the hint for it to be a console device. : > : > > : > : > : > : > I am slightly confused as to how that hint works then, it's not like a : > : > standard isa hint it seems. : > : > Can it somehow be built-in (into the code)? : > : : > : It works "normally" during the new-bus attach, but the low-level console : code : > : probably checks for it early on as well. The serial console code works : that : > : way. The uart(4) and sio(4) drivers explicitly look for uart/sio hints to : > : find possible console devices. This is separate from when the ISA bus : adds : > : uart/sio devices from the hints later on. : > : > sio could be loaded as a driver, and still be the console driver. But : > it had to be loaded from /boot/loader. : : Are you sure? The console stuff is initialized (cninit()) well before any : SYSINIT's are run. I thought so, but maybe I'm just remembering that I could load it for my serial ports. I haven't had a laptop with serial ports on it in a while. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 17:14:45 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE643106566C; Fri, 6 Feb 2009 17:14:45 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B43F78FC1D; Fri, 6 Feb 2009 17:14:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA20659; Fri, 06 Feb 2009 19:14:42 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <498C7002.1090100@icyb.net.ua> Date: Fri, 06 Feb 2009 19:14:42 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: John Baldwin References: <200901260947.32870.jhb@freebsd.org> <498C55BB.3030606@icyb.net.ua> <200902061143.10088.jhb@freebsd.org> <200902061155.48705.jhb@freebsd.org> In-Reply-To: <200902061155.48705.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 17:14:46 -0000 Tangential: maybe AUTODETECT_KBD should be the default? I mean even without hints. I can not see any harm in it. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 17:39:12 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9F191065670; Fri, 6 Feb 2009 17:39:12 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B652B8FC20; Fri, 6 Feb 2009 17:39:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA21183; Fri, 06 Feb 2009 19:39:09 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <498C75BD.5040205@icyb.net.ua> Date: Fri, 06 Feb 2009 19:39:09 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-arch@FreeBSD.org References: <4989EA2A.6050601@icyb.net.ua> In-Reply-To: <4989EA2A.6050601@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: NO_WERROR vs kernel builds X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 17:39:13 -0000 on 04/02/2009 21:19 Andriy Gapon said the following: > It seems that kernel builds ignore NO_WERROR. > Is this on purpose or by accident? > > I think that this happens because of the following lines in > sys/conf/kern.pre.mk: > > .if ${CC} != "icc" > CFLAGS+= -fno-common -finline-limit=${INLINE_LIMIT} > CFLAGS+= --param inline-unit-growth=100 > CFLAGS+= --param large-function-growth=1000 > .if ${MACHINE_ARCH} == "amd64" || ${MACHINE} == "i386" || \ > ${MACHINE_ARCH} == "ia64" || ${MACHINE_ARCH} == "powerpc" || \ > ${MACHINE_ARCH} == "sparc64" > WERROR?= -Werror > .endif > .endif > > I had to specify WERROR= on make's command line to catch a certain kind > of warnings in bulk instead of one by one. This was not obvious. > Can anybody please explain or comment (or rub my nose into it)? -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 18:02:19 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46014106566C for ; Fri, 6 Feb 2009 18:02:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 16ABD8FC1B for ; Fri, 6 Feb 2009 18:02:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id A02AB46B06; Fri, 6 Feb 2009 13:02:18 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n16I2CUY079178; Fri, 6 Feb 2009 13:02:12 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andriy Gapon Date: Fri, 6 Feb 2009 12:54:56 -0500 User-Agent: KMail/1.9.7 References: <200901260947.32870.jhb@freebsd.org> <200902061155.48705.jhb@freebsd.org> <498C6DC9.8020700@icyb.net.ua> In-Reply-To: <498C6DC9.8020700@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902061254.57192.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 06 Feb 2009 13:02:12 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8961/Fri Feb 6 08:29:06 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 18:02:19 -0000 On Friday 06 February 2009 12:05:13 pm Andriy Gapon wrote: > on 06/02/2009 18:55 John Baldwin said the following: > > On Friday 06 February 2009 11:43:09 am John Baldwin wrote: > >> On Friday 06 February 2009 10:22:35 am Andriy Gapon wrote: > >>> on 06/02/2009 16:37 John Baldwin said the following: > >>>> Yes, it only needs the hint for it to be a console device. > >>>> > >>> I am slightly confused as to how that hint works then, it's not like a > >>> standard isa hint it seems. > >>> Can it somehow be built-in (into the code)? > >> Specifically, look at sc_cnprobe() in sys/dev/syscons/syscons.c. It calls a > >> sc_cons_get_priority() routine that on x86 maps lives in > >> sys/isa/syscons_isa.c. This checks for a syscons hint. Changing it to > >> always assume a unit 0 would probably allow this to work. > > > > Something like this (untested): > > I am not sure, but maybe, just in case, also add > sc_get_softc(0,0) != NULL > check? > I guess device_get_softc returns NULL for non-attached/unknown devices. This check happens long before new-bus gets started, so there are no softc's to check. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 18:02:24 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92FFB106566C for ; Fri, 6 Feb 2009 18:02:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6480A8FC1C for ; Fri, 6 Feb 2009 18:02:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 1369346B03; Fri, 6 Feb 2009 13:02:24 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n16I2CUZ079178; Fri, 6 Feb 2009 13:02:18 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andriy Gapon Date: Fri, 6 Feb 2009 12:55:12 -0500 User-Agent: KMail/1.9.7 References: <200901260947.32870.jhb@freebsd.org> <200902061155.48705.jhb@freebsd.org> <498C7002.1090100@icyb.net.ua> In-Reply-To: <498C7002.1090100@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902061255.12880.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 06 Feb 2009 13:02:18 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8961/Fri Feb 6 08:29:06 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Trimming the default /boot/device.hints X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 18:02:24 -0000 On Friday 06 February 2009 12:14:42 pm Andriy Gapon wrote: > > Tangential: maybe AUTODETECT_KBD should be the default? > I mean even without hints. > I can not see any harm in it. Yes, it probably can just be changed so we don't need a hint to set it anymore. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Sat Feb 7 03:12:24 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE67C106566C for ; Sat, 7 Feb 2009 03:12:24 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 658328FC1E for ; Sat, 7 Feb 2009 03:12:24 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LVckx-000173-L9 for freebsd-arch@freebsd.org; Sat, 07 Feb 2009 02:17:19 +0000 Received: from 93-141-48-119.adsl.net.t-com.hr ([93.141.48.119]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Feb 2009 02:17:19 +0000 Received: from ivoras by 93-141-48-119.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Feb 2009 02:17:19 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Sat, 07 Feb 2009 03:16:46 +0100 Lines: 36 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9A2C9143FF082749D11E7EBA" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-141-48-119.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) X-Enigmail-Version: 0.95.7 Sender: news Subject: mount(8) in /stand? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 03:12:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9A2C9143FF082749D11E7EBA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Judging by Google's results I'm only one of many people frustrated by the lack of mount(8) in the "emergency holographic shell". My problem is that I have everything I need to install the system (on a "netbook" laptop - no CD reader) on the USB drive I booted from, but no way to get to the data (the network drivers need to be patched before they can be used so net install is out, sysinstall doesn't recognize the directory structure, has no way of mounting msdosfs, etc.). I see the mount executable is ~~ 17 kB: -r-xr-xr-x 1 root wheel 17232 Dec 29 15:29 /sbin/mount* This is about the third time I needed it in similar circumstances so is probably not unreasonable to request it be crunched in for the future? It's certainly one of the basic emergency utilities. --------------enig9A2C9143FF082749D11E7EBA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmM7xYACgkQldnAQVacBcg+ygCfUTpi/2667wTK1TXrEuyy3mEo 84kAoOBk3E2b7woagvRMeVJtUg6NCzEY =gk+A -----END PGP SIGNATURE----- --------------enig9A2C9143FF082749D11E7EBA-- From owner-freebsd-arch@FreeBSD.ORG Sat Feb 7 05:26:40 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BC30106566B; Sat, 7 Feb 2009 05:26:40 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 936BE8FC18; Sat, 7 Feb 2009 05:26:39 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl91-225.kln.forthnet.gr [77.49.58.225]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id n175A0YZ000322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Feb 2009 07:10:05 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1759xuu029896; Sat, 7 Feb 2009 07:09:59 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1759xKv029884; Sat, 7 Feb 2009 07:09:59 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Ivan Voras References: Date: Sat, 07 Feb 2009 07:09:59 +0200 In-Reply-To: (Ivan Voras's message of "Sat, 07 Feb 2009 03:16:46 +0100") Message-ID: <87y6wivnmg.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n175A0YZ000322 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.869, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.53, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-arch@freebsd.org Subject: Re: mount(8) in /stand? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 05:26:40 -0000 On Sat, 07 Feb 2009 03:16:46 +0100, Ivan Voras wrote: > Judging by Google's results I'm only one of many people frustrated by the > lack of mount(8) in the "emergency holographic shell". My problem is that > I have everything I need to install the system (on a "netbook" laptop - > no CD reader) on the USB drive I booted from, but no way to get to the > data (the network drivers need to be patched before they can be used so > net install is out, sysinstall doesn't recognize the directory structure, > has no way of mounting msdosfs, etc.). I see the mount executable is ~~ > 17 kB: > > -r-xr-xr-x 1 root wheel 17232 Dec 29 15:29 /sbin/mount* > > This is about the third time I needed it in similar circumstances so is > probably not unreasonable to request it be crunched in for the future? > It's certainly one of the basic emergency utilities. You have to account for the size of several mount_xxx executables too. My userland is now installed with DEBUG_FLAGS='-g' so the sizes are not as large as they seem below, but we need at least *some* of these to be in `/stand' before `/stand/mount' is usable e.g. for cd9660 mounts: % keramida@kobe:/sbin$ ls -ld mount* % -r-xr-xr-x 1 root wheel - 47382 Feb 6 23:33 mount % -r-xr-xr-x 1 root wheel - 23848 Feb 6 23:33 mount_cd9660 % -r-xr-xr-x 2 root wheel - 31741 Feb 6 23:33 mount_mfs % -r-xr-xr-x 1 root wheel - 27946 Feb 6 23:33 mount_msdosfs % -r-xr-xr-x 2 root wheel - 60590 Feb 6 23:33 mount_nfs % -r-xr-xr-x 2 root wheel - 60590 Feb 6 23:33 mount_nfs4 % -r-xr-xr-x 1 root wheel - 27835 Feb 6 23:33 mount_ntfs % -r-xr-xr-x 1 root wheel - 19567 Feb 6 23:33 mount_nullfs % -r-xr-xr-x 1 root wheel - 20836 Feb 6 23:33 mount_udf % -r-xr-xr-x 1 root wheel - 21853 Feb 6 23:33 mount_unionfs % keramida@kobe:/sbin$ Then, there's the obstacle of mount_nfs{,4} and all the symbols they will pull into the crunched binary. This may actually increase the disk space requirements of /stand a fair bit. With disks becoming cheaper every day, it may be sensible to include mount_xxx binaries in the default `/stand' for most of the installations, but provide WITHOUT_MOUNT_XXX knobs to allow striping of the parts that risk bloating /stand too much for smaller, embedded installations of BSD. From owner-freebsd-arch@FreeBSD.ORG Sat Feb 7 13:47:30 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2001F106567A for ; Sat, 7 Feb 2009 13:47:30 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-fx0-f14.google.com (mail-fx0-f14.google.com [209.85.220.14]) by mx1.freebsd.org (Postfix) with ESMTP id 7CAEF8FC1B for ; Sat, 7 Feb 2009 13:47:29 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by fxm7 with SMTP id 7so45200fxm.19 for ; Sat, 07 Feb 2009 05:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=bytNI7whMOEb+43mPlFtZ/r00NsLztRE/HftH7tMTsw=; b=E5GuMnRHnj+r7yopngXHwXF+jTvU4/6Wh423fDo/WiMPrDJYrfyEQc28Wd0dFzDs48 VT9lof5BNvc8jATGcdtGXdWQwnTAaHThfYGE857KxXo0sqXx3VZSzo0J17BpY9GIAb0M re3hEpFH3gwlUJqSIaCLIGMcOW18oXjvymogA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UlrBRoHjD4t0104CdzXH0Q455G+9WpREvLPDmIWv6Jy5/Gi3qxXbJ/wnolNBIbw8bp nXLM/E4E7jcyxlPVpwuRJkQz5AYW4IrTcfSDPsjeLUQc0UlBqgtPw+BUVIr77QlAfG2+ Pgg6eSlU1jbObtHPpn57KqOXv314hOLdB3/QY= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.181.206.7 with SMTP id i7mr997116bkq.126.1234013181049; Sat, 07 Feb 2009 05:26:21 -0800 (PST) In-Reply-To: <87y6wivnmg.fsf@kobe.laptop> References: <87y6wivnmg.fsf@kobe.laptop> Date: Sat, 7 Feb 2009 14:26:21 +0100 X-Google-Sender-Auth: af955c5aca0078b6 Message-ID: <9bbcef730902070526q7c35a08dmfe98277d2029da7b@mail.gmail.com> From: Ivan Voras To: Giorgos Keramidas Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: mount(8) in /stand? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 13:47:30 -0000 2009/2/7 Giorgos Keramidas : > On Sat, 07 Feb 2009 03:16:46 +0100, Ivan Voras wrote: >> Judging by Google's results I'm only one of many people frustrated by the >> lack of mount(8) in the "emergency holographic shell". My problem is that >> I have everything I need to install the system (on a "netbook" laptop - >> no CD reader) on the USB drive I booted from, but no way to get to the >> data (the network drivers need to be patched before they can be used so >> net install is out, sysinstall doesn't recognize the directory structure, >> has no way of mounting msdosfs, etc.). I see the mount executable is ~~ >> 17 kB: >> >> -r-xr-xr-x 1 root wheel 17232 Dec 29 15:29 /sbin/mount* >> >> This is about the third time I needed it in similar circumstances so is >> probably not unreasonable to request it be crunched in for the future? >> It's certainly one of the basic emergency utilities. > > You have to account for the size of several mount_xxx executables too. > My userland is now installed with DEBUG_FLAGS='-g' so the sizes are not as > large as they seem below, but we need at least *some* of these to be in > `/stand' before `/stand/mount' is usable e.g. for cd9660 mounts: What is the relationship between mount and mount_xxx? Is it that some file systems cannot be mounted at all if there's no mount_xxx or it's just there to provide advanced or unusual options? Actually what I'm asking is: can "local" file systems that normally have mount_xxx be mounted just with mount, assuming all options default, or they specifically and unconditionally require the special mount_xxx? I think msdosfs, cd9660 and udf are most important here. From owner-freebsd-arch@FreeBSD.ORG Sat Feb 7 15:45:31 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54FFE1065670; Sat, 7 Feb 2009 15:45:31 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 1B49E8FC19; Sat, 7 Feb 2009 15:45:31 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 64C0C73098; Sat, 7 Feb 2009 16:51:19 +0100 (CET) Date: Sat, 7 Feb 2009 16:51:19 +0100 From: Luigi Rizzo To: arch@freebsd.org, Luigi Rizzo , Fabio Checconi , pjd@freebsd.org, kmacy@freebsd.org Message-ID: <20090207155119.GC44298@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: RFC: upcoming fixes to bioq_disksort() and friends. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 15:45:31 -0000 As a followup, below is the core of the new bioq routines, as you can see they are extremely simple. An additional feature that might be useful, and trivial to implement, is let bioq_insert_tail() act as a barrier, so you have the guarantee that all new bioq_disksort() will be inserted after that. The necessart changes are in the #ifdef BARRIER/#endif blocks, and as you can see they are totally straightforward. If there are no objections, i am going to add them as well so the insert_tail() has a well-specified behaviour when intermixed with bioq_disksort() calls. cheers luigi ---- new implementation of bioq routines ------------- static inline uoff_t bioq_bio_key(struct bio_queue_head *head, struct bio *bp) { return ((uoff_t)(bp->bio_offset - head->last_offset)); } void bioq_disksort(struct bio_queue_head *head, struct bio *bp) { struct bio *cur, *prev = NULL; uoff_t key = bioq_bio_key(head, bp); cur = TAILQ_FIRST(&head->queue); #ifdef BARRIER if (head->insert_point) cur = head->insert_point; #endif /* BARRIER */ while (cur != NULL && key >= bioq_bio_key(head, cur)) { prev = cur; cur = TAILQ_NEXT(cur, bio_queue); } if (prev == NULL) TAILQ_INSERT_HEAD(&head->queue, bp, bio_queue); else TAILQ_INSERT_AFTER(&head->queue, prev, bp, bio_queue); } void bioq_remove(struct bio_queue_head *head, struct bio *bp) { if (bp == TAILQ_FIRST(&head->queue)) head->last_offset = bp->bio_offset + bp->bio_length; #ifdef BARRIER if (bp == head->insert_point) head->insert_point = NULL; #endif /* BARRIER */ TAILQ_REMOVE(&head->queue, bp, bio_queue); } struct bio * bioq_first(struct bio_queue_head *head) { return (TAILQ_FIRST(&head->queue)); } struct bio * bioq_takefirst(struct bio_queue_head *head) { struct bio *bp = TAILQ_FIRST(&head->queue); if (bp != NULL) bioq_remove(head, bp); return (bp); } void bioq_insert_head(struct bio_queue_head *head, struct bio *bp) { head->last_offset = bp->bio_offset; TAILQ_INSERT_HEAD(&head->queue, bp, bio_queue); } void bioq_insert_tail(struct bio_queue_head *head, struct bio *bp) { TAILQ_INSERT_TAIL(&head->queue, bp, bio_queue); #ifdef BARRIER head->insert_point = bp; #endif } void bioq_init(struct bio_queue_head *head) { TAILQ_INIT(&head->queue); head->last_offset = 0; head->insert_point = NULL; /* Unused or barrier */ } --------------------------------------------------------------------- From owner-freebsd-arch@FreeBSD.ORG Sat Feb 7 19:10:18 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B3611065670 for ; Sat, 7 Feb 2009 19:10:18 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 2D8FF8FC1A for ; Sat, 7 Feb 2009 19:10:18 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n17JABrG007641; Sat, 7 Feb 2009 14:10:11 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n17JABgb007640; Sat, 7 Feb 2009 14:10:11 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sat, 7 Feb 2009 14:10:11 -0500 From: David Schultz To: Ivan Voras Message-ID: <20090207191011.GA7545@zim.MIT.EDU> Mail-Followup-To: Ivan Voras , Giorgos Keramidas , freebsd-arch@FreeBSD.ORG References: <87y6wivnmg.fsf@kobe.laptop> <9bbcef730902070526q7c35a08dmfe98277d2029da7b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9bbcef730902070526q7c35a08dmfe98277d2029da7b@mail.gmail.com> Cc: Giorgos Keramidas , freebsd-arch@FreeBSD.ORG Subject: Re: mount(8) in /stand? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 19:10:18 -0000 On Sat, Feb 07, 2009, Ivan Voras wrote: > 2009/2/7 Giorgos Keramidas : > > On Sat, 07 Feb 2009 03:16:46 +0100, Ivan Voras wrote: > >> Judging by Google's results I'm only one of many people frustrated by the > >> lack of mount(8) in the "emergency holographic shell". My problem is that > >> I have everything I need to install the system (on a "netbook" laptop - > >> no CD reader) on the USB drive I booted from, but no way to get to the > >> data (the network drivers need to be patched before they can be used so > >> net install is out, sysinstall doesn't recognize the directory structure, > >> has no way of mounting msdosfs, etc.). I see the mount executable is ~~ > >> 17 kB: > >> > >> -r-xr-xr-x 1 root wheel 17232 Dec 29 15:29 /sbin/mount* > >> > >> This is about the third time I needed it in similar circumstances so is > >> probably not unreasonable to request it be crunched in for the future? > >> It's certainly one of the basic emergency utilities. > > > > You have to account for the size of several mount_xxx executables too. > > My userland is now installed with DEBUG_FLAGS='-g' so the sizes are not as > > large as they seem below, but we need at least *some* of these to be in > > `/stand' before `/stand/mount' is usable e.g. for cd9660 mounts: > > What is the relationship between mount and mount_xxx? Is it that some > file systems cannot be mounted at all if there's no mount_xxx or it's > just there to provide advanced or unusual options? Some filesystems have unusual options or require extra magic (e.g., loading kernel modules). These differences should be handled by the filesystem kernel code, but they're presently handled by having N nearly-identical mount_xxx binaries. Craig Rodrigues probably has a better understanding of what's still required to fix this.