From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 24 00:00:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E132DB7B; Sun, 24 Aug 2014 00:00:07 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 006AC3BAF; Sun, 24 Aug 2014 00:00:06 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s7O005uF066838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Aug 2014 17:00:05 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s7O005hc066837; Sat, 23 Aug 2014 17:00:05 -0700 (PDT) (envelope-from jmg) Date: Sat, 23 Aug 2014 17:00:05 -0700 From: John-Mark Gurney To: Stefan Esser Subject: Re: Opinions thought regarding: NEWCONS, rc.conf and rc.d/syscons Message-ID: <20140824000005.GL71691@funkthat.com> Mail-Followup-To: Stefan Esser , "freebsd-hackers@freebsd.org" References: <53F30A81.9090302@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F30A81.9090302@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 23 Aug 2014 17:00:05 -0700 (PDT) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 00:00:08 -0000 Stefan Esser wrote this message on Tue, Aug 19, 2014 at 10:27 +0200: > As you all probably know, 10.1 will ship with both SYSCONS and NEWCONS. > > I'm working keymap files for NEWCONS (translated from those in SYSCONS), > and they'll need to be named differently than before. > > The SYSCONF keymap names in rc.conf will not work for NEWCONS. They > include an encoding scheme in their name, while NEWCONS universally > uses Unicode. > > There are a few points that still need to be considered for 10.1: > > a) Is rc.d/syscons still an appropriate name when using NEWCONS? > (I'd leave it unchanged, but I thought I'd ask ...) Per compatibility, leave it names syscons until the old one is deprecated.. No point is having two copies.... > c) Do we expect to warn the user when he has a SYSCONS keymap name > specified in the rc.conf "keymap" variable, while using NEWCONS? > (This might be a good idea, at least when the default is to use > NEWCONS and the user might not be aware of the change.) Yes, and then if/when syscons is removed, we remove the warning... > d) Do we want to provide the user with an information regarding the > name of the SYSCONS keymap configured, to ease the transition? > (Could be done ...) Yes... > e) Do we want the rc script to translate the SYSCONS keymap name > to its new form? (This might be good for people using foreign > keyboards, if their password uses characters located at other > positions than on the default keymap, that will be used if no > valid "keymap" is specified.) Yes, and make sure to print out a [big] warning to have them update their config... > f) It might be good to introduce "keymap_sc" (and/or "keymap_vt") > as a value used in preference to "keymap" if defined and the > corresponding console driver is detected. (An alternativ to > e) that is easier to implement and still allows to have one > rc.conf file that covers both SYSCONS and NEWCONS.) I would say no, since they are similar compatible... The biggest issue is if someone has a custom keymap... If this is the case, you might want to point them to a guide/your script for converting their custom keymap... Yes, I doubt many people are using a custom keymap, but they are probably out there... btw, thanks for your work on bringing FreeBSD into the 21st century! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 24 11:57:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55814FF3 for ; Sun, 24 Aug 2014 11:57:35 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E393C3545 for ; Sun, 24 Aug 2014 11:57:34 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ho1so1385031wib.16 for ; Sun, 24 Aug 2014 04:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-type:content-disposition:user-agent; bh=7DAcNSmd4Byycelh9qQit5I0/8r+EnCIQyLWn4h1lJc=; b=LEo7P+8nZjQMc9uYx2ZIV6PXKWoL0XfCpBgDlpYe0mEbgAg7v954q2wpk6nLZ7MvP9 axwqBwvv+8n3LIN0slL1Fk5rUL5Og1LL8uJ6sssWBbg7v1hBwfE9/dkA3rEpgBYUvJUV Zx9UqDpCOvfpFq4Ds7Z8+l7e5Zb4x8/K19n3RqA5nF6hSLIKIzosPvNRnkR5XPtMk6QN OyTLPw5fpTLAjiurPRtsRyCbaGbzVIDXEzRp/iAuMgIJevPtGlWSU2Txhp1RKUFfaVV7 OIfEmpF8eWkJYmJFw3jPlUZ+41vt/qT08VE/SUWmnoFUDkZHRmBixcuCQ2cqP766odpD w5cg== X-Received: by 10.194.203.73 with SMTP id ko9mr1505470wjc.101.1408881452659; Sun, 24 Aug 2014 04:57:32 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id g1sm14338807wiy.16.2014.08.24.04.57.31 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 24 Aug 2014 04:57:31 -0700 (PDT) Date: Sun, 24 Aug 2014 13:57:29 +0200 From: Mateusz Guzik To: freebsd-hackers@freebsd.org Subject: atomic_load_acq_int in sequential_heuristic Message-ID: <20140824115729.GC2045@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 11:57:35 -0000 Writer side is: fp->f_seqcount = (arg + bsize - 1) / bsize; do { new = old = fp->f_flag; new |= FRDAHEAD; } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); Reader side is: if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) return (fp->f_seqcount << IO_SEQSHIFT); We can easily get the following despite load_acq: CPU0 CPU1 load_acq fp->f_flag fp->f_seqcount = ... store_rel fp->f_flag read fp->f_seqcount So the barrier does not seem to serve any purpose. Given that this is only a hint and rarely changes it should be fine. So how about the following: diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index f1d19ac..2e056de 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -438,7 +438,7 @@ static int sequential_heuristic(struct uio *uio, struct file *fp) { - if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) + if (fp->f_flag & FRDAHEAD) return (fp->f_seqcount << IO_SEQSHIFT); /* I make no claims about any performance difference in this one. This is only a cleanup. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 24 16:23:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E2B0A97 for ; Sun, 24 Aug 2014 16:23:42 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F11573C20 for ; Sun, 24 Aug 2014 16:23:41 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7OGNV7D045517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Aug 2014 19:23:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7OGNV7D045517 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7OGNVvx045516; Sun, 24 Aug 2014 19:23:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Aug 2014 19:23:31 +0300 From: Konstantin Belousov To: Mateusz Guzik , freebsd-hackers@freebsd.org Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140824162331.GW2737@kib.kiev.ua> References: <20140824115729.GC2045@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3v3azX03nJMP4RYa" Content-Disposition: inline In-Reply-To: <20140824115729.GC2045@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 16:23:42 -0000 --3v3azX03nJMP4RYa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 24, 2014 at 01:57:29PM +0200, Mateusz Guzik wrote: > Writer side is: > fp->f_seqcount =3D (arg + bsize - 1) / bsize; > do { > new =3D old =3D fp->f_flag; > new |=3D FRDAHEAD; > } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); >=20 > Reader side is: > if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) > return (fp->f_seqcount << IO_SEQSHIFT); >=20 > We can easily get the following despite load_acq: > CPU0 CPU1 > load_acq fp->f_flag > fp->f_seqcount =3D ... > store_rel fp->f_flag > read fp->f_seqcount > =09 > So the barrier does not seem to serve any purpose. It does. Consider initial situation, when the flag is not set yet. There, we do not want to allow the reader to interpret automatically calculated f_seqcount as the user-supplied constant. Without barriers, we might read the flag as set, while user-provided value for f_seqcount is still not visible to processor doing read. > Given that this is only a hint and rarely changes it should be fine. >=20 > So how about the following: > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > index f1d19ac..2e056de 100644 > --- a/sys/kern/vfs_vnops.c > +++ b/sys/kern/vfs_vnops.c > @@ -438,7 +438,7 @@ static int > sequential_heuristic(struct uio *uio, struct file *fp) > { > =20 > - if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) > + if (fp->f_flag & FRDAHEAD) > return (fp->f_seqcount << IO_SEQSHIFT); > =20 > /* >=20 > I make no claims about any performance difference in this one. This is > only a cleanup. >=20 > --=20 > Mateusz Guzik > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --3v3azX03nJMP4RYa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT+hGDAAoJEJDCuSvBvK1BdvEP/37QxMM4WZclxuyXGsHNgyjX TIZRJgZYGhUxzXF7BlEGKbSjE9PQo2BQrm9TTGD7JBJw434Ufa2SZ36JwdtY9Z9t YHtRCN8bX68OygrKvJrw6sgZkUKVpWPiUr7dUbru/KXiqAtxnldO42os1fjayxsJ 0eecsikNtkG1weMLU4LeK9l+7k6bzg/caGiYcnzzghja5O9C+Zu7bmB7CfSOlTZQ DMa7LCBqbL6NdGVt27gyELr87McNhNbMsfxlOiTOH4wEgC1s9f5qGMTqnU1pO/sT obdoDlxYJegSXmDvEu/6Yy2SxI+M/HiuDkB81OZUvfeeJSGIH/azjjZUblJFxiG/ N5ZO0fuLABgVbgI/jQ2NWxgvASHDr11wDKbD7WcfWwrPYaS7b9VfMHMmP8UwO8j2 a23XijINjDYUmWuhKjSTTuGO/ap1AO/upEuL+OZp7t4Ym69UA/KrNISnRJQlVuju NkyWRt6Y49gDzIbRFFwgkNVocIu4VKWQua4W1+cdpNigjvqi6a+1r4zvXQwvYZoA n21MHdPUFzxPeYi1vgSV4tJR55GCio707qljucS1M10++uEUbuylOTff6FZ5qTRk EXgkPzz3F/zy/RNrrztYhGvcwODiM0ssHDIMEfQq9VfSwtj4Z9kBXaNb7N/bFQ8+ a/8l9VAqAfcGY0/LR9UJ =dt2I -----END PGP SIGNATURE----- --3v3azX03nJMP4RYa-- From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 24 16:42:46 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32DEEDCD for ; Sun, 24 Aug 2014 16:42:46 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6C5C3DE3 for ; Sun, 24 Aug 2014 16:42:45 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7OGgbAV050150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Aug 2014 19:42:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7OGgbAV050150 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7OGgaaf050149; Sun, 24 Aug 2014 19:42:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Aug 2014 19:42:36 +0300 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140824164236.GX2737@kib.kiev.ua> References: <20140824115729.GC2045@dft-labs.eu> <20140824162331.GW2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oNcod2irK9ys8Qxe" Content-Disposition: inline In-Reply-To: <20140824162331.GW2737@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 16:42:46 -0000 --oNcod2irK9ys8Qxe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 24, 2014 at 07:23:31PM +0300, Konstantin Belousov wrote: > On Sun, Aug 24, 2014 at 01:57:29PM +0200, Mateusz Guzik wrote: > > Writer side is: > > fp->f_seqcount =3D (arg + bsize - 1) / bsize; > > do { > > new =3D old =3D fp->f_flag; > > new |=3D FRDAHEAD; > > } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > >=20 > > Reader side is: > > if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) > > return (fp->f_seqcount << IO_SEQSHIFT); > >=20 > > We can easily get the following despite load_acq: > > CPU0 CPU1 > > load_acq fp->f_flag > > fp->f_seqcount =3D ... > > store_rel fp->f_flag > > read fp->f_seqcount > > =09 > > So the barrier does not seem to serve any purpose. > It does. >=20 > Consider initial situation, when the flag is not set yet. There, we > do not want to allow the reader to interpret automatically calculated > f_seqcount as the user-supplied constant. Without barriers, we might > read the flag as set, while user-provided value for f_seqcount is still > not visible to processor doing read. That said, I think now that there is a real bug. If we did not read the FRDAHEAD in sequential_heuristic(), we may override user-supplied value for f_seqcount. I do not see other solution than start to use locking. --oNcod2irK9ys8Qxe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT+hX8AAoJEJDCuSvBvK1BgmAQAJNQ0m8/urD0kssB0dO81XiS GKYSvzkAX2Ca+kQ6uHZm7JEBsSL8rBgUU/pLa4lUymnQoSjutz54YcuBIvxBnRV2 MZVUy+HqoW4Ze2XP3YQVLAyJjXhH9bVme9dye+btyXOf/qR8WXemGId5vTeZa61T gtAm4jcTPA0tkFFsAUoCBX/+//0ixVZb/YUQGdEPbd1YpModt06Lrgwm9K5mBGNm RZVZ8j0HsjDH6cHxvw4Z1ENwka/1gYA1bIBA1soXUU1RgKZf9kFArds5Y5jo7QTP iDQCquHmPenA1EJ1DUAj6/3EiIErL+Velsyv2xkA00yQgYCUiMk9wOV5lW3c0kCq QKSg2OMnE8SwODDX9QgFNtS2X91Qjj2UayUS4M5Hy1WDHcgzDDhlWipO95bwji9u hl0e2eheENST2DWZ4R6bqE9nmFpcGs8zsG79+2qc5geYpqv5RljgDUp8+STDfhG3 9ddZhv0mnsmRX14gE1AqB9o25XwRQpr4up99S1ilo/3B8Id7TQv0iNvEl3OD7G3U IOB+U0uQ+CxoM70DOGK90fcMzsnflGF0wySUuDEZyaTTqCJL4KnYJYS3ai9plVzM cGtLtdHv08FjsZpA1fy/8p4ePiBui2G3e1mf6s4p98KZSrdJeItop0Dkc4Ykj4X9 jQevNfkEGrydNmFDicfD =7/yO -----END PGP SIGNATURE----- --oNcod2irK9ys8Qxe-- From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 24 22:54:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82283D79; Sun, 24 Aug 2014 22:54:17 +0000 (UTC) Received: from shxd.cx (unknown [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A0413D3C; Sun, 24 Aug 2014 22:54:17 +0000 (UTC) Received: from [64.201.244.132] (port=55382 helo=THEMADHATTER) by shxd.cx with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XLNtz-000AEV-5K; Sat, 23 Aug 2014 19:51:31 -0700 From: To: References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> In-Reply-To: Subject: FW: Lua in the bootloader Date: Sun, 24 Aug 2014 15:53:45 -0700 Message-ID: <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQL5LS+a++1ap+929hQ2F1+mR87LYAKtNDcsAU1XcUwCU0w8F5lbEgLQ Content-Language: en-us Sender: devin@shxd.cx Cc: "'Wojciech A. Koszek'" , dteske@freebsd.org, 'Pedro Giffuni' , 'Pedro Arthur' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 22:54:17 -0000 Hey List, Looks like the Lua Loader GSoC project went well as I'm sure a lot of projects did (including my own student's). I had some time to review the Lua Loader GSoC project results (code-wise) and provide in-depth, detailed feed- back on a hypothetical proposition: keeping Forth but making Lua the default. I'm not against the proposition, quite the contrary. The limitations that I battle in Forth are significant enough that I'd like to see if Lua can break said chains (such as "dictionary full" errors causing BTX halt -- induced simply by adding "too many functions" in Forth). Please read below my comments which the GSoC student (Pedro Arthur ) and mentor (Wojciech A. Koszek ) wanted me to share with the mailing lists (I chose -hackers). -- Cheers, Devin > -----Original Message----- > From: Devin Teske [mailto:devin@shxd.cx] > Sent: Saturday, August 23, 2014 7:40 PM > To: 'Pedro Giffuni' > Cc: 'Julian Elischer'; 'dteske@freebsd.org' > Subject: RE: Lua in the bootloader > > From: Pedro Giffuni [mailto:pfg@freebsd.org] > > Sent: Friday, August 22, 2014 11:01 PM > > To: dteske@freebsd.org > > Cc: Julian Elischer > > Subject: Re: Lua in the bootloader > > > > Il giorno 22/ago/2014, alle ore 22:36, dteske@freebsd.org ha scritto: > >> > >>> -----Original Message----- > >>> From: Pedro Giffuni [mailto:pfg@freebsd.org] > >>> Sent: Friday, August 22, 2014 6:21 PM > >>> To: dteske@freebsd.org > >>> Subject: Lua in the bootloader > >>> > >>> Hi Devin; > >>> > >>> JFYI, It looks like, against my forecast, the Lua project was successful: > >>> > >>> https://wiki.freebsd.org/SummerOfCode2014/LuaLoader > >>> > >>> I haven't looked at the code but it is actually good news as it seems > >>> like we can keep both in the tree :). > >> > >> In related news, I'm making the necessary changes to > >> support ZFS enumeration in the loader. > >> > >> Oh, and btw... the changes I'm making in are in *C* and will effect > >> are going to make it possible to enhance the Forth code to produce > >> a dynamic boot menu where the user can select the ZFS root pool. > >> > >> The reason why I have to modify the C code is because Forth does > >> not support Inter-Process Communication (IPC) components such > >> as pipes. So although the loader environment provides the FICL > >> word "lszfs", that command uses printf directly to print to the > >> screen (to which Forth cannot ``catch'' via pipe from FICL). > > > > Very cool! > > > > I don't know Lua but it does support pipes: > > > > http://www.lua.org/pil/9.2.html > > > > I am starting to wonder if we will end up dumping forth altogether. > > > > Let's not be so hasty. > /me goes and reviews what the Lua GSoC was able to accomplish. > > Hmmm, I'm actually impressed. It got a lot further along than I had > predicted. That being said, I still have to point out several short- > comings that need to be addressed before we switch over to Lua: > > === > > 1. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/drawer.lua > > function drawer.isColorEnabled() simply returns true. > Contrast that with the following: > > http://www.freebsd.org/cgi/man.cgi?query=color.4th > http://svnweb.freebsd.org/base/head/sys/boot/forth/color.4th?view=mark > up > > NB: boot_serial? is defined here... > http://svnweb.freebsd.org/base/head/sys/boot/forth/support.4th?view=m > arkup > > Basically, the drawer.isColorEnabled() function needs to check a > series of environment variables to produce the proper response > (versus the obvious mistake of simply always returnining true). > > Those environment variables are (in no particular order): > $console, $boot_serial, $boot_multicons, $loader_color > > if $console contains "comconsole" (space or comma separated) > then drawer.isColorEnabled() should return False > > if $boot_serial is set to a non-NULL value, then > drawer.isColorEnabled() should return False > > if $boot_multicons is set to a non-NULL value, then > drawer.isColorEnabled() should return False > > if $loader_color is set to "0" or "NO" (case insensitive) then > drawer.isColorEnabled() should return False > > Returning the wrong result in the wrong situation (e.g., always > returning True) can cause unexpected results. > > === > > 2. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/menu.lua > > The menu.run() function always uses ANSI escape sequences. > Contrast with the beastie-start function in the following: > > http://svnweb.freebsd.org/base?view=revision&revision=265028 > > menu.run() needs to check a series of environment variables: > $console, $beastie_disable, $loader_delay > > if $console contains (space or comma separated) "efi" then do > not draw a menu (fall back to autoboot routine). > > if $beastie_disable is set to "YES" (case insensitive), then do not > draw a menu (fall back to autoboot routine). > > === > > 3. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/menu.lua > > NB: Same file as #2. > > menu.options.alias associative array should be merged into > the menu.options plain array. (this will be an utter requirement > if solving the stateful menu system issues below) > > Same thing goes for the boot.options.alias associative array. > > === > > 4. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/menu.lua > > NB: Same file as #2 and #3. > > menu.options associative array defines kernel menu as > "not available" if $kernels is undefined. This is actually > incorrect when compared to what the Forth code does. > > Not only $kernels is probed, but $kernel is also probed. > In fact, the Forth code checks $kernels for $kernel... if > $kernels contains $kernel (space or comma separated) > then you can think of the list presented as $kernels. But > if $kernels does not contain $kernel, then $kernel is > appended to the menu list of kernels. This part is very > important (it means $kernel and $kernels can be given > unique values but both are used to present menu > options). > > === > > 5. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/menu.lua > > NB: Same file as #2, #3, and #4. > > menu.options associative array has static menu items > for the first two items defined: > > 1. Boot Multi user [Enter] > 2. Boot [S]ingle user > > In the Forth code, items #1 and #2 have "toggled values": > > 1. Boot Single user [Enter] > 2. Boot [M]ulti User > > When the environment variable (e.g., from loader.conf(5)) > $boot_single is set to non-NULL, the Forth code reverses > the #1 and #2 menu items, indicating that the default action > as-configured via loader.conf(5) (or manually by dropping > to the loader(8) interactive Forth prompt) using $boot_single. > > Reference: > http://svnweb.freebsd.org/base?view=revision&revision=243660 > > === > > 6. > https://socsvn.freebsd.org/socsvn/soc2014/pedrosouza/lua_loader/head/s > ys/boot/lua/menu.lua > > NB: Same file as #2, #3, #4, and #5. > > menu.options associative does not support setting non-ANSI > colorized versus ANSI colorized captions on menu items. > > Contrast with the following: > http://svnweb.freebsd.org/base/head/sys/boot/forth/menu.rc?view=mark > up > > Use of ANSI caption versus non-ANSI caption should be based > on the return of drawer.isColorEnabled() -- which leads me to > state that perhaps that function (isColorEnabled) is probably > better-off being part of the loader objects (more closely relating > to the Forth code wherein the counter-part is "loader_color?" > function). > > === > > 7. [Extra credit] The Forth code implements an optional delay that > can be introduced just prior to rendering the menu. See below: > http://www.freebsd.org/cgi/man.cgi?query=delay.4th > The Lua code does not implement this feature. > > === > > 8. [Minor Nit] It should be "On"/"off", not "On"/"Off" (as it is > currently in menu.lua). The reason for this is "accessibility" for > disabled persons (generate wider variance between on/off > states for higher visual impact by using case variance as well > as color variance -- for those times color is disabled or you have > a color-blind viewer). > > === > > That's all for now. Please don't take this as a scathing review of > why it's not ready, but rather I'm very happy that we're able to > have this type of discussion (of the minor/major short-comings > versus, say, in-operability). I'm very happy that the GSoC project > was able to make it this far. The door is really truly open in my > mind for Lua possibly replacing Forth. Forth has a lot of limitations > and I gladly welcome Lua if (and only if) we can get it up to snuff. > > If the above issues can be resolved, we have a really good chance > of making Lua the new default. > > >> I don't know if Lua supports IPC or pipes, but if it did then that would > >> mean that it would conceivably already (today) present a menu of > >> ZFS datasets to select as the root device. However, despite whether > >> it has pipes or not, the code that I am changing is in the zfsimpl[e].c > >> code which is the "ZFS Simple Implementation" code of the loader. > >> This is at a layer below both Lua and Forth. The enhancement that > >> I am making starts with teaching the previously mentioned code that > >> currently prints to screen to instead take a by-ref handle argument > >> so that we can make a new function. Said new function would, unlike > >> lszfs, pass a meaningful pointer (instead of NULL) to store the response > >> in memory as an array of strings (char *) that can then be (wait for it)... > >> > >> ...set as a series of environment variables. > >> > >> Forth can surely preen the environment variable namespace and has > >> no problems interacting at that layer (bystepping the problem of not > >> having true IPC in Forth). > >> > >> It is expected that these changes to zfsimpl.c et. al. will benefit Lua > >> because Lua can then preen the environment variable namespace > >> after making a call to a loader-provided function. > >> > >> For example, (pseudo-code; I had doubts you wanted to read Forth): > >> > >> zfs_probe zroot/ROOT > >> for (n = 0; $n < ${zfs_list_max:-0; n++) > >> push(@menu, $zfs_list_item[n]); > >> > >> NB: Yes, I just mixed C, Perl, Shell, and Forth into some weird pseudo- > code > > > > > > Pretty ugly If you ask me .. but I have never wanted to learn Perl ;). > > > > Heh. What's in a language anyhow if it helps people communicate well? > -- > Cheers, > Devin From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 24 23:02:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AB852AE; Sun, 24 Aug 2014 23:02:40 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2001:470:1:2d5:26:3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id E3FAC3E55; Sun, 24 Aug 2014 23:02:39 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id D1D6A34A9E4; Sun, 24 Aug 2014 16:02:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Subject: Re: Lua in the bootloader From: Rui Paulo In-Reply-To: <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> Date: Sun, 24 Aug 2014 16:02:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7EB14166-BD1A-4AA0-A014-5279EE931947@FreeBSD.org> References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> To: dteske@FreeBSD.org X-Mailer: Apple Mail (2.1973.6) Cc: freebsd-hackers@freebsd.org, Pedro Giffuni , "Wojciech A. Koszek" , Pedro Arthur X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 23:02:40 -0000 On Aug 24, 2014, at 15:53, = wrote: >=20 > Hey List, >=20 > Looks like the Lua Loader GSoC project went well as I'm > sure a lot of projects did (including my own student's). >=20 > I had some time to review the Lua Loader GSoC project > results (code-wise) and provide in-depth, detailed feed- > back on a hypothetical proposition: keeping Forth but > making Lua the default. >=20 > I'm not against the proposition, quite the contrary. The > limitations that I battle in Forth are significant enough > that I'd like to see if Lua can break said chains (such as > "dictionary full" errors causing BTX halt -- induced simply > by adding "too many functions" in Forth). >=20 > Please read below my comments which the GSoC > student (Pedro Arthur ) > and mentor (Wojciech A. Koszek ) > wanted me to share with the mailing lists (I chose > -hackers). I have read some of your comments and I don't have much to add. However, being the guy who broke the boot loader (BTX halted, Forth = dictionary full, unable to recover) while trying to do something simple = at work, I cannot say how much I'd love to get rid of forth. Forth is a = language that only a few people care about and that's terrible for an = open source project. It's time we find a good alternative without = disrupting the boot process much.=20 I'd be happy to help reviewing any patch that helps bringing Lua as a = replacement for Forth. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 24 23:43:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7C92BD3; Sun, 24 Aug 2014 23:43:28 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE5493120; Sun, 24 Aug 2014 23:43:27 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 905947EB37; Sun, 24 Aug 2014 16:43:27 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 79735-04; Sun, 24 Aug 2014 16:43:27 -0700 (PDT) Received: from [10.14.123.184] (mobile-166-171-249-079.mycingular.net [166.171.249.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 2A2BD7EB30; Sun, 24 Aug 2014 16:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1408923807; bh=+Hx1PYBcgGY99sq9jV79R1Vgyy4hPUhRiA4DGEJJFYI=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=G5sgu+gUXAsdkTyHYyAObzdso2T3e6i7EqiawIvbbQ/o4GLia495CCLXYuGApNtBX Uju/V3zN/oTGhK3ez6Fy7/bp9bkF/mFRfkcpDofZAmzOcIDf3EOXLmhnOjwn9+9/uf PcE3++h2vy3nKRGYOOiZPXlVPdX+MZSld60YL4zY= References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> In-Reply-To: <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> X-Mailer: iPhone Mail (11D257) From: Jordan Hubbard Subject: Re: Lua in the bootloader Date: Sun, 24 Aug 2014 16:43:24 -0700 To: "" Cc: "" , Pedro Giffuni , "Wojciech A. Koszek" , Pedro Arthur X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 23:43:29 -0000 > limitations that I battle in Forth are significant enough > that I'd like to see if Lua can break said chains (such as > "dictionary full" errors causing BTX halt -- induced simply > by adding "too many functions" in Forth). I'm not one to stand in the way of progress either, but just to make sure we= are not foolishly conflating "language" with "environment" here: You do al= l realize that ficl can have any sized dictionary you want, right? Presumab= ly, it's kept small due to the limitations of the boot loader environment, a= nd Lua is not going to magically transcend those limitations. Writing lots o= f boot code in Lua will require memory, perhaps even MORE memory since, say w= hat you like about Forth, it's hard to get more concise or compact than a Fo= rth dictionary of compiled CFA's. That's why we picked it for the role in t= he first place.=20 So anyway, first try expanding the size of the dictionary. If that can't be d= one, now you know your "ceiling" for Lua. Can you stay below it, not just n= ow but longer term? Those are the questions you need to answer. - Jordan= From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 00:57:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8B82F81 for ; Mon, 25 Aug 2014 00:57:05 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 801873937 for ; Mon, 25 Aug 2014 00:57:05 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x12so12294336wgg.28 for ; Sun, 24 Aug 2014 17:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=iiJtjYh4LzOY5DiI0SEhjWlI+I3aMPKIKwz8oXxBi2s=; b=X+/T8T6ptyb7vRwo2wK4+FYBnIjaVkU754PgBhycGPjC0RhriPbxnuMsIi9hJqA66u Uxtr7FO+L1muTFotQohSA33nITXkO09GeizvJW9VWXkAsIUTLEdYf7QYzdqFM1qssqMs KU8oyEq6+VyFZlBEDvnNwSXX7N57QS8fpyDG8p1Oh4ZNf2mrOpr4IDEXAbU7AyeWJyKI ypajlUwh1FKfY27wU1j/nOdJuGXq7L27MQtxmLF22OXoSOUl+KXnjKErKLBRVx19LkV9 KSWCpqGRVNbsxFY2qvaLflb0KwvPYMwkIRifw05tpEFs24Jn5TR8OOomIvCGsd2rCqXx aaJQ== X-Received: by 10.180.83.8 with SMTP id m8mr11970012wiy.8.1408928223810; Sun, 24 Aug 2014 17:57:03 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id p3sm95693451wjb.21.2014.08.24.17.57.02 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 24 Aug 2014 17:57:02 -0700 (PDT) Date: Mon, 25 Aug 2014 02:57:00 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140825005659.GA14344@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , freebsd-hackers@freebsd.org References: <20140824115729.GC2045@dft-labs.eu> <20140824162331.GW2737@kib.kiev.ua> <20140824164236.GX2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140824164236.GX2737@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 00:57:06 -0000 On Sun, Aug 24, 2014 at 07:42:36PM +0300, Konstantin Belousov wrote: > On Sun, Aug 24, 2014 at 07:23:31PM +0300, Konstantin Belousov wrote: > > On Sun, Aug 24, 2014 at 01:57:29PM +0200, Mateusz Guzik wrote: > > > Writer side is: > > > fp->f_seqcount = (arg + bsize - 1) / bsize; > > > do { > > > new = old = fp->f_flag; > > > new |= FRDAHEAD; > > > } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > > > > > > Reader side is: > > > if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) > > > return (fp->f_seqcount << IO_SEQSHIFT); > > > > > > We can easily get the following despite load_acq: > > > CPU0 CPU1 > > > load_acq fp->f_flag > > > fp->f_seqcount = ... > > > store_rel fp->f_flag > > > read fp->f_seqcount > > > > > > So the barrier does not seem to serve any purpose. > > It does. > > > > Consider initial situation, when the flag is not set yet. There, we > > do not want to allow the reader to interpret automatically calculated > > f_seqcount as the user-supplied constant. Without barriers, we might > > read the flag as set, while user-provided value for f_seqcount is still > > not visible to processor doing read. > That said, I think now that there is a real bug. > > If we did not read the FRDAHEAD in sequential_heuristic(), we may > override user-supplied value for f_seqcount. I do not see other > solution than start to use locking. Right. How about abusing vnode lock for this purpose? All callers of sequential_heuristic have the vnode at least shared locked. FRDAHEAD setting code locks it shared. We can change that to exclusive, which will close the race and should not be problematic given that it is rather rare. diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index 7abdca0..643920b 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -762,18 +762,18 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) } if (arg >= 0) { vp = fp->f_vnode; - error = vn_lock(vp, LK_SHARED); + error = vn_lock(vp, LK_EXCLUSIVE); if (error != 0) { fdrop(fp, td); break; } bsize = fp->f_vnode->v_mount->mnt_stat.f_iosize; - VOP_UNLOCK(vp, 0); fp->f_seqcount = (arg + bsize - 1) / bsize; do { new = old = fp->f_flag; new |= FRDAHEAD; } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); + VOP_UNLOCK(vp, 0); } else { do { new = old = fp->f_flag; diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index f1d19ac..98823f3 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -438,7 +438,8 @@ static int sequential_heuristic(struct uio *uio, struct file *fp) { - if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) + ASSERT_VOP_LOCKED(fp->f_vnode, __func__); + if (fp->f_flag & FRDAHEAD) return (fp->f_seqcount << IO_SEQSHIFT); /* -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 06:27:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B61BC944; Mon, 25 Aug 2014 06:27:32 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81788347D; Mon, 25 Aug 2014 06:27:31 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 3452E7D580; Sun, 24 Aug 2014 23:27:31 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 08535-02; Sun, 24 Aug 2014 23:27:31 -0700 (PDT) Received: from [10.8.0.22] (unknown [10.8.0.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id D45587D578; Sun, 24 Aug 2014 23:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1408948050; bh=HeWO1YsKWPjh9XfNuuhVCuzEHssD2JtXtXSWYX8OVPs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=UDg1BwlKLuzp/LlJPIZbM7L5+eJzpvMUNSI2K0chlqTx/xRyydQYbbzhK/fsF0B8k M+oRt7uq9vBvKOe2xA5roHaOw3004h2avHQFrHNQPU/E07egyL6v41jqB9gzLAJpVI ztMoNTlVY42t5grHu/ER3ihZiSzV2sRHsnMaABiw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Lua in the bootloader From: Jordan Hubbard In-Reply-To: <236878C4-2C3E-4744-A04B-736C91032BFC@felyko.com> Date: Sun, 24 Aug 2014 23:27:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> <236878C4-2C3E-4744-A04B-736C91032BFC@felyko.com> To: Rui Paulo X-Mailer: Apple Mail (2.1878.6) Cc: "Wojciech A. Koszek" , "" , "" , Pedro Giffuni , Pedro Arthur X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 06:27:32 -0000 On Aug 24, 2014, at 9:07 PM, Rui Paulo wrote: > No, it's worse than that. There's not a really limit on the size and = the stack can overflow easily on real hardware while at the same time it = works fine on bhyve at the same time. userboot vs real hardware. I=92m not sure I understand why there would be a difference in behavior = on =93real hardware=94 vs bhyve unless bhyve is initializing ficl = differently and causing it to change its allocation parameters. In some = ways, we lost out for not having gone with =93a real forth=94 = implementation in the most traditional and compact sense. In a = traditional Forth system, the dictionary starts at the bottom of the = available address space and the stack starts at the top - they grow = towards one another, which is how I implemented the PC-532 boot loader = (also in forth, but in assembly language); if you want to keep them out = of their hair, you just put the stack base further away in memory. Ficl is a higher-level C implementation and simply allocates a = fixed-sized chunk of space for the dictionary and for the stack. Our = version of ficl is a bit ancient and I=92m still looking through it to = even see where the dictionary size is chosen. I suspect we simply made = some bogus assumptions early on and never caught them until the FreeBSD = boot environment grew so many logos and menus that it hit the limit. Not that I disagree with any of the other arguments, mind you. I think = a new boot environment language would be fine. I agree that Forth is = largely only attractive to people with grey beard hair (though its value = for torturing Alfred should not be underestimated). I just think that = it=92s also going to be awhile before the new hotness is at full = feature-parity with the current boot loader, and if fixing the amount of = headroom can buy us a little time, why not? We hit the limit with = FreeNAS too (I=92ve seen the same dreaded boot-time crash you did) so = it=92s not just an academic point for me. > The limitation of the dictionary and the size of the stack isn't the = main reason why I would prefer lua over forth. Why do we need to = subject ourselves to a stack based language in 2014? The very limited = number of people hacking on the Forth boot loader on FreeBSD might have = a different opinion, but the language is so arcane that I fail to see = why we shouldn't replace it. Again, no disagreement, though I do wonder how many Lua programmers = FreeBSD has that will be able to hit the ground running as a result of = this evolution. Anyone? Raise your hands! I can=92t raise mine - = I=92ve never used Lua. :) - Jordan= From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 07:34:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21A65B89 for ; Mon, 25 Aug 2014 07:34:11 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B56EA3A0E for ; Mon, 25 Aug 2014 07:34:10 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7P7Y4bm057331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2014 10:34:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7P7Y4bm057331 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7P7Y4Op057330; Mon, 25 Aug 2014 10:34:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Aug 2014 10:34:04 +0300 From: Konstantin Belousov To: Mateusz Guzik , freebsd-hackers@freebsd.org Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140825073404.GZ2737@kib.kiev.ua> References: <20140824115729.GC2045@dft-labs.eu> <20140824162331.GW2737@kib.kiev.ua> <20140824164236.GX2737@kib.kiev.ua> <20140825005659.GA14344@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uepJbk9oh0IF4lih" Content-Disposition: inline In-Reply-To: <20140825005659.GA14344@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:34:11 -0000 --uepJbk9oh0IF4lih Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2014 at 02:57:00AM +0200, Mateusz Guzik wrote: > On Sun, Aug 24, 2014 at 07:42:36PM +0300, Konstantin Belousov wrote: > > On Sun, Aug 24, 2014 at 07:23:31PM +0300, Konstantin Belousov wrote: > > > On Sun, Aug 24, 2014 at 01:57:29PM +0200, Mateusz Guzik wrote: > > > > Writer side is: > > > > fp->f_seqcount =3D (arg + bsize - 1) / bsize; > > > > do { > > > > new =3D old =3D fp->f_flag; > > > > new |=3D FRDAHEAD; > > > > } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > > > >=20 > > > > Reader side is: > > > > if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) > > > > return (fp->f_seqcount << IO_SEQSHIFT); > > > >=20 > > > > We can easily get the following despite load_acq: > > > > CPU0 CPU1 > > > > load_acq fp->f_flag > > > > fp->f_seqcount =3D ... > > > > store_rel fp->f_flag > > > > read fp->f_seqcount > > > > =09 > > > > So the barrier does not seem to serve any purpose. > > > It does. > > >=20 > > > Consider initial situation, when the flag is not set yet. There, we > > > do not want to allow the reader to interpret automatically calculated > > > f_seqcount as the user-supplied constant. Without barriers, we might > > > read the flag as set, while user-provided value for f_seqcount is sti= ll > > > not visible to processor doing read. > > That said, I think now that there is a real bug. > >=20 > > If we did not read the FRDAHEAD in sequential_heuristic(), we may > > override user-supplied value for f_seqcount. I do not see other > > solution than start to use locking. >=20 > Right. >=20 > How about abusing vnode lock for this purpose? All callers of > sequential_heuristic have the vnode at least shared locked. >=20 > FRDAHEAD setting code locks it shared. We can change that to exclusive, > which will close the race and should not be problematic given that it is > rather rare. >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 7abdca0..643920b 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -762,18 +762,18 @@ kern_fcntl(struct thread *td, int fd, int cmd, intp= tr_t arg) > } > if (arg >=3D 0) { > vp =3D fp->f_vnode; > - error =3D vn_lock(vp, LK_SHARED); > + error =3D vn_lock(vp, LK_EXCLUSIVE); > if (error !=3D 0) { > fdrop(fp, td); > break; > } > bsize =3D fp->f_vnode->v_mount->mnt_stat.f_iosize; > - VOP_UNLOCK(vp, 0); > fp->f_seqcount =3D (arg + bsize - 1) / bsize; > do { > new =3D old =3D fp->f_flag; > new |=3D FRDAHEAD; > } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); Do we still need rel there ? > + VOP_UNLOCK(vp, 0); > } else { > do { > new =3D old =3D fp->f_flag; > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > index f1d19ac..98823f3 100644 > --- a/sys/kern/vfs_vnops.c > +++ b/sys/kern/vfs_vnops.c > @@ -438,7 +438,8 @@ static int > sequential_heuristic(struct uio *uio, struct file *fp) > { > =20 > - if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) > + ASSERT_VOP_LOCKED(fp->f_vnode, __func__); > + if (fp->f_flag & FRDAHEAD) > return (fp->f_seqcount << IO_SEQSHIFT); > =20 > /* I believe the patch is correct. Two notes. First, please add a comment explaining which other part of the code is locked against in F_READAHEAD switch case. Second, should the vnode lock cover the FRDAHEAD reset case too, at least for consistency ? --uepJbk9oh0IF4lih Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT+ubsAAoJEJDCuSvBvK1B7XcP/2wadiRcw75ae4/uR6C1RYpn WFAzjNx+KL4fQV5n4aWPaXaqDrIeEfdKYZADj2J6ceVN6sAcWWKWU7Fi3jyUJb8e 1Q5sSgx9TI0Y1ME/nQrs6TVqDMfi1jQZQqkjV6EkZPdXIMG3ZDxt/JlR+ASilxD0 /WBTDoWtBDFEJYAnYeTwzZ4vVDRJ6cWsUoNtTZCl0EgUuAOtIdY1c7xHfRFBp0D8 nypou9Ty0yaO8YkaCRe/6apMmV9++2PPW4TsoN8OlMgOs/etf7l8RrcH5BYq22s1 K2Cz8d54n3fs3zxyPYwfBsnqD6HwEzbwv7B7mF7cHTFwzQiLs1E+rCbVg3hLyWbn XJkU/fiBsz0BbREwaW7yZY9oIOLgsnyZR10Ep9BTk9hy4KOZI74vdI22MSeP/G/u 3ush46DsSGkVWFlH2e3U7stHXN5Dy6pQeOJKzQJ9aZHKi3zm7F0HPL6Jd6BVPE3O nBM1btqxxFkZX7Q48JM35eghD4ouEw01tE0umTnH5d+1lI4Bx6Km1k0VxP0n19YC rVVnT48ypLI+7BkaoiIUV6bfcS6rv1yY08PfRB40ckeyjAilDntjbKpzlayb5BDi mKv04InB+S/1ppZUtiBkP26Qd5QLa2cXz35UJCt9bW/Fwv1SFTI/FjEoUc2UTy3/ O6X8JDdkqSG47kS/EyFR =AARQ -----END PGP SIGNATURE----- --uepJbk9oh0IF4lih-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 08:15:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 014BEAA2 for ; Mon, 25 Aug 2014 08:15:33 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A3183DE7 for ; Mon, 25 Aug 2014 08:15:33 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id f8so3326837wiw.1 for ; Mon, 25 Aug 2014 01:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=0ZkIswYknQxuexOhjIV44iBfgdpdKJshLLWXvWPwA3g=; b=ckHXMQT4Xxzdxicd5JM5p/P2JlwZG1iulPRCvHxb/oXOQ1Ms6uUGWcRdQ6TsIjrAxz y56gt39mDMgUkXYoRMvoW+QeH4VoJ3Wzpt7I2YZhRmwfBdt5kjcBISWdElge0N3y94GG GTa5uqnqcCNgcH+PFDqR1aoL0h+SH2/garwvMnsnqAgXD7ZFBdVZXgSe08VpwGhPJ1Ka lCCiVM7zHJ1+E9+rW2EMEZye4yQ87WKrbI8pT1SWvJWsm5OIlbc11xZO+8muhS0D/f+u 7lypaRbwDR1rkc6cibgZJYi+IYOw1beRpl+25WQh1RoLqnbmdSflBrw0ah0lUe3z/vzQ 7dRg== X-Received: by 10.194.187.4 with SMTP id fo4mr21314192wjc.35.1408954531693; Mon, 25 Aug 2014 01:15:31 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id bk9sm29253416wib.7.2014.08.25.01.15.30 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 25 Aug 2014 01:15:30 -0700 (PDT) Date: Mon, 25 Aug 2014 10:15:26 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140825081526.GB14344@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , freebsd-hackers@freebsd.org References: <20140824115729.GC2045@dft-labs.eu> <20140824162331.GW2737@kib.kiev.ua> <20140824164236.GX2737@kib.kiev.ua> <20140825005659.GA14344@dft-labs.eu> <20140825073404.GZ2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140825073404.GZ2737@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 08:15:34 -0000 On Mon, Aug 25, 2014 at 10:34:04AM +0300, Konstantin Belousov wrote: [..] > Two notes. First, please add a comment explaining which other part > of the code is locked against in F_READAHEAD switch case. Second, > should the vnode lock cover the FRDAHEAD reset case too, at least > for consistency ? I'll start with a side thing: diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index 98823f3..2c3df2b 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -365,7 +365,7 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred *cred, fp->f_ops= &badfileops; return (error); } - fp->f_flag |= FHASLOCK; + atomic_set_int(&fp->f_flag, FHASLOCK); } if (fmode & FWRITE) { VOP_ADD_WRITECOUNT(vp, 1); And now for the patch in question: Yes, _rel is not necessary. In fact, the loop is not necessary either. It would be useful if more than one flag was altered. diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index 7abdca0..433b809 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -476,7 +476,6 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) struct vnode *vp; cap_rights_t rights; int error, flg, tmp; - u_int old, new; uint64_t bsize; off_t foffset; @@ -762,23 +761,21 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) } if (arg >= 0) { vp = fp->f_vnode; - error = vn_lock(vp, LK_SHARED); + /* + * Exclusive lock synchronizes against + * sequential_heuristic(). + */ + error = vn_lock(vp, LK_EXCLUSIVE); if (error != 0) { fdrop(fp, td); break; } bsize = fp->f_vnode->v_mount->mnt_stat.f_iosize; - VOP_UNLOCK(vp, 0); fp->f_seqcount = (arg + bsize - 1) / bsize; - do { - new = old = fp->f_flag; - new |= FRDAHEAD; - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); + atomic_set_int(&fp->f_flag, FHASLOCK); + VOP_UNLOCK(vp, 0); } else { - do { - new = old = fp->f_flag; - new &= ~FRDAHEAD; - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); + atomic_clear_int(&fp->f_flag, FHASLOCK); } fdrop(fp, td); break; diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index f1d19ac..98823f3 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -438,7 +438,8 @@ static int sequential_heuristic(struct uio *uio, struct file *fp) { - if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) + ASSERT_VOP_LOCKED(fp->f_vnode, __func__); + if (fp->f_flag & FRDAHEAD) return (fp->f_seqcount << IO_SEQSHIFT); /* -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 08:35:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6793EB4 for ; Mon, 25 Aug 2014 08:35:45 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CC773FE4 for ; Mon, 25 Aug 2014 08:35:45 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7P8ZdvS091362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2014 11:35:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7P8ZdvS091362 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7P8ZdkH091361; Mon, 25 Aug 2014 11:35:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Aug 2014 11:35:39 +0300 From: Konstantin Belousov To: Mateusz Guzik , freebsd-hackers@freebsd.org Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140825083539.GB2737@kib.kiev.ua> References: <20140824115729.GC2045@dft-labs.eu> <20140824162331.GW2737@kib.kiev.ua> <20140824164236.GX2737@kib.kiev.ua> <20140825005659.GA14344@dft-labs.eu> <20140825073404.GZ2737@kib.kiev.ua> <20140825081526.GB14344@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s24z9xI8tqkHlhZq" Content-Disposition: inline In-Reply-To: <20140825081526.GB14344@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 08:35:45 -0000 --s24z9xI8tqkHlhZq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2014 at 10:15:26AM +0200, Mateusz Guzik wrote: > On Mon, Aug 25, 2014 at 10:34:04AM +0300, Konstantin Belousov wrote: > [..] > > Two notes. First, please add a comment explaining which other part > > of the code is locked against in F_READAHEAD switch case. Second, > > should the vnode lock cover the FRDAHEAD reset case too, at least > > for consistency ? >=20 > I'll start with a side thing: >=20 > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > index 98823f3..2c3df2b 100644 > --- a/sys/kern/vfs_vnops.c > +++ b/sys/kern/vfs_vnops.c > @@ -365,7 +365,7 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucr= ed *cred, > fp->f_ops=3D &badfileops; > return (error); > } > - fp->f_flag |=3D FHASLOCK; > + atomic_set_int(&fp->f_flag, FHASLOCK); > } > if (fmode & FWRITE) { > VOP_ADD_WRITECOUNT(vp, 1); Ok. >=20 > And now for the patch in question: >=20 > Yes, _rel is not necessary. In fact, the loop is not necessary either. It > would be useful if more than one flag was altered. >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 7abdca0..433b809 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -476,7 +476,6 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr= _t arg) > struct vnode *vp; > cap_rights_t rights; > int error, flg, tmp; > - u_int old, new; > uint64_t bsize; > off_t foffset; > =20 > @@ -762,23 +761,21 @@ kern_fcntl(struct thread *td, int fd, int cmd, intp= tr_t arg) > } > if (arg >=3D 0) { > vp =3D fp->f_vnode; > - error =3D vn_lock(vp, LK_SHARED); > + /* > + * Exclusive lock synchronizes against > + * sequential_heuristic(). > + */ > + error =3D vn_lock(vp, LK_EXCLUSIVE); > if (error !=3D 0) { > fdrop(fp, td); > break; > } > bsize =3D fp->f_vnode->v_mount->mnt_stat.f_iosize; > - VOP_UNLOCK(vp, 0); > fp->f_seqcount =3D (arg + bsize - 1) / bsize; > - do { > - new =3D old =3D fp->f_flag; > - new |=3D FRDAHEAD; > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > + atomic_set_int(&fp->f_flag, FHASLOCK); You misspelled FRDAHEAD as FHASLOCK, below as well. Was this tested ? > + VOP_UNLOCK(vp, 0); > } else { > - do { > - new =3D old =3D fp->f_flag; > - new &=3D ~FRDAHEAD; > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > + atomic_clear_int(&fp->f_flag, FHASLOCK); So what about extending the vnode lock to cover the flag reset ? > } > fdrop(fp, td); > break; > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > index f1d19ac..98823f3 100644 > --- a/sys/kern/vfs_vnops.c > +++ b/sys/kern/vfs_vnops.c > @@ -438,7 +438,8 @@ static int > sequential_heuristic(struct uio *uio, struct file *fp) > { > =20 > - if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) > + ASSERT_VOP_LOCKED(fp->f_vnode, __func__); > + if (fp->f_flag & FRDAHEAD) > return (fp->f_seqcount << IO_SEQSHIFT); > =20 > /* >=20 > --=20 > Mateusz Guzik --s24z9xI8tqkHlhZq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT+vVbAAoJEJDCuSvBvK1BjJkP/iSWiYgVq2wE+jFjsacCXfPc E/baLYWpOMNXJ51p8QRAEGgkrlACVZdloIpbdNAvdil7hTCR5D4KpY+Z1o+AzHya FExWKGpJShysRTOIlT0w/k6fH6XtmtkYD4Ai9eQHrlrs0r8wLKxWruTGfhd5HMU7 OZmkz61OGD69dvJg31+ONBKFFku8zqNWR112Bb7b7ql1n3hDSDWFSpMQMVtGTMFM 5roHPPOUG8E5UwhtRSLr0aLaANSVFQoJjep3KE8l+25CF0OtcRy4rcRBIq1ieiff BxhfrgV4fx0OzrTB2Dy9jVyMsBgWRho/IhB/S5Lllf6ioYjTjzMMdL4U1l7WQWRh 2gt1+wT2S+HsWYlClfmInNpCRf1503bV/uIFEw+6vg1frWIKjyiAUZrL//xHllE5 ZqRtAevtsduUqRYly+2Qw70qS/H+oUlXHj5zVmTjRPnIVoNp1/JUBSjDS2nKpfBf /XUhJfk+O2bE6EkcBMdBUPGbu2lyZ/0dZFgQWQrM66tn8e3d89+xvhF5VHmwp45p QAUhF6FocH2YXc0scGHff4XzE5aWWTRiZm/x7cT7mLfMwy8WfKAvJhHOt4RyPlZF WZxK85Js542BeTbG3s8OvlDgbdYrvYAADJ5qZ6zvDRUp2P1du0TJ4dq0oVKZMN0m kRC9NsP+MJfE41Js20HW =bfKF -----END PGP SIGNATURE----- --s24z9xI8tqkHlhZq-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 09:11:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FE88521 for ; Mon, 25 Aug 2014 09:11:02 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C705933B1 for ; Mon, 25 Aug 2014 09:11:01 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id f8so2211247wiw.0 for ; Mon, 25 Aug 2014 02:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=S2t4f8WgfItObdynRzwst8edJm0HbFBEgqkPCm/M+do=; b=TvpGj3SvyeJt3YfqAhpuAkjJVvWFHxBowMc06c77qzpPK+KOEOtkDJ88z27W45NiaA XKqoiIelN7ew2FuIZjTzgrfbOMgUyIEk3gF73sblQq57kf05cjnnj5REbhhNSoGizMPR FAB4faBWhBgd/VuabaP/TSALVm3OoTOQ9r9Ovw3yFO1uWMEosw9CuPE+bi7uhVrgFC4p W7T1ZyBOKwc4jC2fcM7E+yLIdE4S65V+AcgEu8caiCIWJTTRETNwRqLP9RaZKi6g1T7K KulQh2i3mDoK8IkQsgqo5o1f+106n1hNg3ZiVGn/3zKtDSo1Rna2G1ufp/jyAuOz3XRf PY3Q== X-Received: by 10.194.95.234 with SMTP id dn10mr8179532wjb.73.1408957859943; Mon, 25 Aug 2014 02:10:59 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id jx10sm98472688wjc.7.2014.08.25.02.10.58 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 25 Aug 2014 02:10:59 -0700 (PDT) Date: Mon, 25 Aug 2014 11:10:56 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140825091056.GC14344@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , freebsd-hackers@freebsd.org References: <20140824115729.GC2045@dft-labs.eu> <20140824162331.GW2737@kib.kiev.ua> <20140824164236.GX2737@kib.kiev.ua> <20140825005659.GA14344@dft-labs.eu> <20140825073404.GZ2737@kib.kiev.ua> <20140825081526.GB14344@dft-labs.eu> <20140825083539.GB2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140825083539.GB2737@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 09:11:02 -0000 On Mon, Aug 25, 2014 at 11:35:39AM +0300, Konstantin Belousov wrote: > > + atomic_set_int(&fp->f_flag, FHASLOCK); > You misspelled FRDAHEAD as FHASLOCK, below as well. > Was this tested ? > Oops, damn copy-pasto. Sorry. > > + VOP_UNLOCK(vp, 0); > > } else { > > - do { > > - new = old = fp->f_flag; > > - new &= ~FRDAHEAD; > > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > > + atomic_clear_int(&fp->f_flag, FHASLOCK); > So what about extending the vnode lock to cover the flag reset ? > Sure. So this time I tested it properly and found out it is impossible to disable the hint. The test is: -1 is truncated and then read from intptr_t which yields a big positive number instead. Other users in the function use int tmp to work around this issue. diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index 7abdca0..774f647 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -760,7 +760,8 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) error = EBADF; break; } - if (arg >= 0) { + tmp = arg; + if (tmp >= 0) { vp = fp->f_vnode; error = vn_lock(vp, LK_SHARED); if (error != 0) { @@ -769,7 +770,7 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) } bsize = fp->f_vnode->v_mount->mnt_stat.f_iosize; VOP_UNLOCK(vp, 0); - fp->f_seqcount = (arg + bsize - 1) / bsize; + fp->f_seqcount = (tmp + bsize - 1) / bsize; do { new = old = fp->f_flag; new |= FRDAHEAD; Then the patch in question: diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index 774f647..4efadb0 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -476,7 +476,6 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) struct vnode *vp; cap_rights_t rights; int error, flg, tmp; - u_int old, new; uint64_t bsize; off_t foffset; @@ -760,27 +759,25 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) error = EBADF; break; } + vp = fp->f_vnode; + /* + * Exclusive lock synchronizes against + * sequential_heuristic(). + */ + error = vn_lock(vp, LK_EXCLUSIVE); + if (error != 0) { + fdrop(fp, td); + break; + } tmp = arg; if (tmp >= 0) { - vp = fp->f_vnode; - error = vn_lock(vp, LK_SHARED); - if (error != 0) { - fdrop(fp, td); - break; - } bsize = fp->f_vnode->v_mount->mnt_stat.f_iosize; - VOP_UNLOCK(vp, 0); fp->f_seqcount = (tmp + bsize - 1) / bsize; - do { - new = old = fp->f_flag; - new |= FRDAHEAD; - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); + atomic_set_int(&fp->f_flag, FRDAHEAD); } else { - do { - new = old = fp->f_flag; - new &= ~FRDAHEAD; - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); + atomic_clear_int(&fp->f_flag, FRDAHEAD); } + VOP_UNLOCK(vp, 0); fdrop(fp, td); break; diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index f1d19ac..98823f3 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -438,7 +438,8 @@ static int sequential_heuristic(struct uio *uio, struct file *fp) { - if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) + ASSERT_VOP_LOCKED(fp->f_vnode, __func__); + if (fp->f_flag & FRDAHEAD) return (fp->f_seqcount << IO_SEQSHIFT); /* -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 11:10:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 231E48C9 for ; Mon, 25 Aug 2014 11:10:12 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B71653E99 for ; Mon, 25 Aug 2014 11:10:11 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7PBA16S026256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2014 14:10:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7PBA16S026256 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7PBA1aj026255; Mon, 25 Aug 2014 14:10:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Aug 2014 14:10:01 +0300 From: Konstantin Belousov To: Mateusz Guzik , freebsd-hackers@freebsd.org Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140825111000.GC2737@kib.kiev.ua> References: <20140824115729.GC2045@dft-labs.eu> <20140824162331.GW2737@kib.kiev.ua> <20140824164236.GX2737@kib.kiev.ua> <20140825005659.GA14344@dft-labs.eu> <20140825073404.GZ2737@kib.kiev.ua> <20140825081526.GB14344@dft-labs.eu> <20140825083539.GB2737@kib.kiev.ua> <20140825091056.GC14344@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tTm07/aDcFLy+pwu" Content-Disposition: inline In-Reply-To: <20140825091056.GC14344@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 11:10:12 -0000 --tTm07/aDcFLy+pwu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2014 at 11:10:56AM +0200, Mateusz Guzik wrote: > On Mon, Aug 25, 2014 at 11:35:39AM +0300, Konstantin Belousov wrote: > > > + atomic_set_int(&fp->f_flag, FHASLOCK); > > You misspelled FRDAHEAD as FHASLOCK, below as well. > > Was this tested ? > >=20 >=20 > Oops, damn copy-pasto. Sorry. >=20 > > > + VOP_UNLOCK(vp, 0); > > > } else { > > > - do { > > > - new =3D old =3D fp->f_flag; > > > - new &=3D ~FRDAHEAD; > > > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > > > + atomic_clear_int(&fp->f_flag, FHASLOCK); > > So what about extending the vnode lock to cover the flag reset ? > >=20 >=20 > Sure. >=20 > So this time I tested it properly and found out it is impossible to > disable the hint. The test is: >=20 > -1 is truncated and then read from intptr_t which yields a big positive > number instead. Other users in the function use int tmp to work around > this issue. Could you provide me with the test case which demonstrates the problem ? The fcntl(2) prototype in sys/fcntl.h is variadic, so int arg argument is not promoted. On the other hand, syscalls.master declares arg as long. Did you tried to pass -1L as third argument to disable ? >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 7abdca0..774f647 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -760,7 +760,8 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr= _t arg) > error =3D EBADF; > break; > } > - if (arg >=3D 0) { > + tmp =3D arg; > + if (tmp >=3D 0) { > vp =3D fp->f_vnode; > error =3D vn_lock(vp, LK_SHARED); > if (error !=3D 0) { > @@ -769,7 +770,7 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr= _t arg) > } > bsize =3D fp->f_vnode->v_mount->mnt_stat.f_iosize; > VOP_UNLOCK(vp, 0); > - fp->f_seqcount =3D (arg + bsize - 1) / bsize; > + fp->f_seqcount =3D (tmp + bsize - 1) / bsize; > do { > new =3D old =3D fp->f_flag; > new |=3D FRDAHEAD; >=20 > Then the patch in question: >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 774f647..4efadb0 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -476,7 +476,6 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr= _t arg) > struct vnode *vp; > cap_rights_t rights; > int error, flg, tmp; > - u_int old, new; > uint64_t bsize; > off_t foffset; > =20 > @@ -760,27 +759,25 @@ kern_fcntl(struct thread *td, int fd, int cmd, intp= tr_t arg) > error =3D EBADF; > break; > } > + vp =3D fp->f_vnode; > + /* > + * Exclusive lock synchronizes against > + * sequential_heuristic(). I would also add a sentence that we care about f_seqcount update in seq_heur(). Another place to add the locking annotation is the struct file in sys/file.h. Now f_seqcount is 'protected' by the vnode lock. I am not sure how to express the locking model shortly. > + */ > + error =3D vn_lock(vp, LK_EXCLUSIVE); > + if (error !=3D 0) { > + fdrop(fp, td); > + break; > + } > tmp =3D arg; > if (tmp >=3D 0) { > - vp =3D fp->f_vnode; > - error =3D vn_lock(vp, LK_SHARED); > - if (error !=3D 0) { > - fdrop(fp, td); > - break; > - } > bsize =3D fp->f_vnode->v_mount->mnt_stat.f_iosize; > - VOP_UNLOCK(vp, 0); > fp->f_seqcount =3D (tmp + bsize - 1) / bsize; > - do { > - new =3D old =3D fp->f_flag; > - new |=3D FRDAHEAD; > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > + atomic_set_int(&fp->f_flag, FRDAHEAD); > } else { > - do { > - new =3D old =3D fp->f_flag; > - new &=3D ~FRDAHEAD; > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > + atomic_clear_int(&fp->f_flag, FRDAHEAD); > } > + VOP_UNLOCK(vp, 0); > fdrop(fp, td); > break; > =20 > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > index f1d19ac..98823f3 100644 > --- a/sys/kern/vfs_vnops.c > +++ b/sys/kern/vfs_vnops.c > @@ -438,7 +438,8 @@ static int > sequential_heuristic(struct uio *uio, struct file *fp) > { > =20 > - if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) > + ASSERT_VOP_LOCKED(fp->f_vnode, __func__); > + if (fp->f_flag & FRDAHEAD) > return (fp->f_seqcount << IO_SEQSHIFT); > =20 > /* > --=20 > Mateusz Guzik --tTm07/aDcFLy+pwu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT+xmIAAoJEJDCuSvBvK1BmZwP/2LKzDdUErkIZr4iCkFRDLUr xmEngq42kKdrcDPSKjI6j9n7n8k5kSXMl93h2G3t9Q/X526bMmXzaP3gUnLBxJOc ahA2UxBlIT8FC9GxdOFy/m1bBq+i+X1+dnrDtImyYYN2Wh0b6Xw/QvQtiji58Qh1 gGDX/cFENJcXcgEBnZgMNyVeHxjnBfRF1F6cEGVExxLbg0b5M5VmF8oxTQnlxyKe 1GV1PYC2CiFCDkx/lFB85hRjYCTxXyak0sJIH6ySkXTU1vxlcKfWTtWqz6xRG6H8 HHrkLWLID5gdhSK97u7z0IcYSY1ZvSMu3/d7FpeHnS/hgsxg0GtPdkiZhNwTlgoJ fTsiZuvkUBTTKYnhLzGvxkbwaVaOS0zAKsiONynscKXmKIyELRiUSL/mxi83stPw /P7rvGb72rCt5W2ezWh9OjtKvNJVlaHTRh7YWk3213Bgs9VqkSN4dYceHpdkB+XN jOD5T54gB8vLeZYVr4eopju1RLT77O/kKBCLnuuf+hlPv6kt62VZOJrE0P6WOc6m 8jluxqU0//wRx83gADmnHX4P4hix4C20qw23gDSGubCaBy4qzCDiewyyIbyAlM79 QTKIJnh338HNTjQz1mSbpcPEAMof2ZFRjYDTknodj1LyrQp83QQHDKnSLF8EZJUR F3rRTJnkzUJIidBU7MeL =i1pV -----END PGP SIGNATURE----- --tTm07/aDcFLy+pwu-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 04:07:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7164923E; Mon, 25 Aug 2014 04:07:27 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2001:470:1:2d5:26:3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 50FA83970; Mon, 25 Aug 2014 04:07:27 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 0445934A9E5; Sun, 24 Aug 2014 21:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1408939646; bh=xxWP/vvRoGvAH/rfjD1gQyUfF+ISJ/5LUXk326eD7aw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=EWpT8HgF1n40OD03GJevwqecGSRUvdgLQRXdDPB8whKDUJ1dDFE0eVMSnvnZuErcP LEMf1q4xsFK9QUg1QZm7bOTcoOSYaze0/aiDiTeGaBQHTI37RXEEDIq5fgxGskpRRb pBiBnHCnGjK7stwcelrpJgg64hyKo7FeoAg5Esm8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Subject: Re: Lua in the bootloader From: Rui Paulo In-Reply-To: <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> Date: Sun, 24 Aug 2014 21:07:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <236878C4-2C3E-4744-A04B-736C91032BFC@felyko.com> References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> To: Jordan Hubbard X-Mailer: Apple Mail (2.1973.6) X-Mailman-Approved-At: Mon, 25 Aug 2014 11:18:36 +0000 Cc: "Wojciech A. Koszek" , "" , "" , Pedro Giffuni , Pedro Arthur X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 04:07:27 -0000 On Aug 24, 2014, at 16:43, Jordan Hubbard wrote: >=20 >> limitations that I battle in Forth are significant enough >> that I'd like to see if Lua can break said chains (such as >> "dictionary full" errors causing BTX halt -- induced simply >> by adding "too many functions" in Forth). >=20 > I'm not one to stand in the way of progress either, but just to make = sure we are not foolishly conflating "language" with "environment" here: = You do all realize that ficl can have any sized dictionary you want, = right? Presumably, it's kept small due to the limitations of the boot = loader environment, and Lua is not going to magically transcend those = limitations. No, it's worse than that. There's not a really limit on the size and = the stack can overflow easily on real hardware while at the same time it = works fine on bhyve at the same time. userboot vs real hardware. > Writing lots of boot code in Lua will require memory, perhaps even = MORE memory since, say what you like about Forth, it's hard to get more = concise or compact than a Forth dictionary of compiled CFA's. That's = why we picked it for the role in the first place.=20 >=20 > So anyway, first try expanding the size of the dictionary. If that = can't be done, now you know your "ceiling" for Lua. Can you stay below = it, not just now but longer term? Those are the questions you need to = answer. The limitation of the dictionary and the size of the stack isn't the = main reason why I would prefer lua over forth. Why do we need to = subject ourselves to a stack based language in 2014? The very limited = number of people hacking on the Forth boot loader on FreeBSD might have = a different opinion, but the language is so arcane that I fail to see = why we shouldn't replace it. Lua works because it's meant to be a = library language and apparently it's small enough. Given the right = implementation, we might even have a fail-safe boot loader with Lua. No = one tried to fix that in ficl since it came to FreeBSD. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 06:34:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C90CB71; Mon, 25 Aug 2014 06:34:30 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D14C53544; Mon, 25 Aug 2014 06:34:29 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id DD3D21598; Mon, 25 Aug 2014 06:34:28 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s7P6YPPS016674; Mon, 25 Aug 2014 06:34:28 GMT (envelope-from phk@phk.freebsd.dk) To: Jordan Hubbard Subject: Re: Lua in the bootloader In-reply-to: <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> From: "Poul-Henning Kamp" References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> <236878C4-2C3E-4744-A04B-736C91032BFC@felyko.com> <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16672.1408948465.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Aug 2014 06:34:25 +0000 Message-ID: <16673.1408948465@critter.freebsd.dk> X-Mailman-Approved-At: Mon, 25 Aug 2014 11:30:50 +0000 Cc: "" , "Wojciech A. Koszek" , Pedro Arthur , Pedro Giffuni , Rui Paulo , "" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 06:34:30 -0000 -------- In message <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com>, Jordan Hu= bbard writes: > >Again, no disagreement, though I do wonder how many Lua programmers FreeB= SD >has that will be able to hit the ground running as a result of this evolu= tion. >Anyone? Raise your hands! I can't raise mine - I've never used Lua. :) It's easier than FORTH, but not nearly as fun. -- = 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-hackers@FreeBSD.ORG Mon Aug 25 06:51:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15366E93; Mon, 25 Aug 2014 06:51:04 +0000 (UTC) Received: from felyko.com (felyko.com [65.49.80.26]) by mx1.freebsd.org (Postfix) with ESMTP id ED0AC36BD; Mon, 25 Aug 2014 06:51:03 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 4148E34A9E4; Sun, 24 Aug 2014 23:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1408949462; bh=x4dWrxwZT05bh/n4mIQ85gWZh9vG9a4hPFrWfa+/Z+A=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OEckYEl9pARipihtaLYZEUpfeHu2Tww00Y6Lan0uz0Fxl5Ve7lrOgWGHwZHaYLDTz 8YkZSkc78DZaluX329TXFiTvBh1oJy/0NnWjadS5dYTsltZbfyOdb1HsqDGWIAzUMn bT5QFb5ZL1wrxOzDF961AABtU+9v07NaCFLOSWVg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Subject: Re: Lua in the bootloader From: Rui Paulo In-Reply-To: <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> Date: Sun, 24 Aug 2014 23:51:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <11411DFA-5934-49EE-BBB0-AA88E0CA6E20@felyko.com> References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> <236878C4-2C3E-4744-A04B-736C91032BFC@felyko.com> <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> To: Jordan Hubbard X-Mailer: Apple Mail (2.1973.6) X-Mailman-Approved-At: Mon, 25 Aug 2014 11:31:00 +0000 Cc: "Wojciech A. Koszek" , "" , "" , Pedro Giffuni , Pedro Arthur X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 06:51:04 -0000 On Aug 24, 2014, at 23:27, Jordan Hubbard wrote: >=20 > Again, no disagreement, though I do wonder how many Lua programmers = FreeBSD has that will be able to hit the ground running as a result of = this evolution. Anyone? Raise your hands! I can=92t raise mine - = I=92ve never used Lua. :) Clearly it's somewhat popular since this isn't the first GSoC project = with the object of integrating Lua with the boot loader. NetBSD even tried to integrate Lua with kernel scripting, correctly = calling it Lunatik. :-) -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 13:04:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2562579D for ; Mon, 25 Aug 2014 13:04:43 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB60D38ED for ; Mon, 25 Aug 2014 13:04:42 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ho1so2483764wib.16 for ; Mon, 25 Aug 2014 06:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=vTyHXA9oftomgYNjoGVVjIKnhHRoHuQt9EwvjxVpWLM=; b=ot4g+FFWFsjp3fOEPWq5qZCCkupfI6c4LZzrp3/soPCZIXSE9/uQ4rjJE7JeBas4Fu v+PE4IXo1tQq4DHW3jL84aR8czZi2KmZT8+5rMSvJGF2kOUaZsOLzQ+g4qAOQwSF823g 3H2y2EUc/S0i/Cfyz69quSRc1ZV11K88UA5BdNwkctvYMj5o1UTP58/XpsnlAY4XwKn6 WUHI2vDYhVTlBg/70vBpjkVTIxE3ciRoNNCHo8Ni40eg1LKciDhAqXy6rUdM2EJjOuj3 kuybhmCgtLdDdXo7VKTW1sLpPn5Qjt5+Z8RODsSaYZf/c9LS3UFbi2JJ/alqyuYp6wHc cpvw== X-Received: by 10.194.62.19 with SMTP id u19mr2270240wjr.120.1408971880198; Mon, 25 Aug 2014 06:04:40 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id vn10sm99954074wjc.28.2014.08.25.06.04.38 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 25 Aug 2014 06:04:39 -0700 (PDT) Date: Mon, 25 Aug 2014 15:04:33 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140825130433.GD14344@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , freebsd-hackers@freebsd.org References: <20140824115729.GC2045@dft-labs.eu> <20140824162331.GW2737@kib.kiev.ua> <20140824164236.GX2737@kib.kiev.ua> <20140825005659.GA14344@dft-labs.eu> <20140825073404.GZ2737@kib.kiev.ua> <20140825081526.GB14344@dft-labs.eu> <20140825083539.GB2737@kib.kiev.ua> <20140825091056.GC14344@dft-labs.eu> <20140825111000.GC2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140825111000.GC2737@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 13:04:43 -0000 On Mon, Aug 25, 2014 at 02:10:01PM +0300, Konstantin Belousov wrote: > On Mon, Aug 25, 2014 at 11:10:56AM +0200, Mateusz Guzik wrote: > > On Mon, Aug 25, 2014 at 11:35:39AM +0300, Konstantin Belousov wrote: > > > > + atomic_set_int(&fp->f_flag, FHASLOCK); > > > You misspelled FRDAHEAD as FHASLOCK, below as well. > > > Was this tested ? > > > > > > > Oops, damn copy-pasto. Sorry. > > > > > > + VOP_UNLOCK(vp, 0); > > > > } else { > > > > - do { > > > > - new = old = fp->f_flag; > > > > - new &= ~FRDAHEAD; > > > > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > > > > + atomic_clear_int(&fp->f_flag, FHASLOCK); > > > So what about extending the vnode lock to cover the flag reset ? > > > > > > > Sure. > > > > So this time I tested it properly and found out it is impossible to > > disable the hint. The test is: > > > > -1 is truncated and then read from intptr_t which yields a big positive > > number instead. Other users in the function use int tmp to work around > > this issue. > Could you provide me with the test case which demonstrates the problem ? > Nothing special: https://people.freebsd.org/~mjg/patches/F_READAHEAD.c > The fcntl(2) prototype in sys/fcntl.h is variadic, so int arg argument > is not promoted. On the other hand, syscalls.master declares arg as long. > Did you tried to pass -1L as third argument to disable ? > Yes, -1L deals with the problem. I would still argue that using 'tmp' like the rest of the function would not hurt as a cheap solution. > > > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > > index 7abdca0..774f647 100644 > > --- a/sys/kern/kern_descrip.c > > +++ b/sys/kern/kern_descrip.c > > @@ -760,7 +760,8 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) > > error = EBADF; > > break; > > } > > - if (arg >= 0) { > > + tmp = arg; > > + if (tmp >= 0) { > > vp = fp->f_vnode; > > error = vn_lock(vp, LK_SHARED); > > if (error != 0) { > > @@ -769,7 +770,7 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) > > } > > bsize = fp->f_vnode->v_mount->mnt_stat.f_iosize; > > VOP_UNLOCK(vp, 0); > > - fp->f_seqcount = (arg + bsize - 1) / bsize; > > + fp->f_seqcount = (tmp + bsize - 1) / bsize; > > do { > > new = old = fp->f_flag; > > new |= FRDAHEAD; > > > > Then the patch in question: > > > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > > index 774f647..4efadb0 100644 > > --- a/sys/kern/kern_descrip.c > > +++ b/sys/kern/kern_descrip.c > > @@ -476,7 +476,6 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) > > struct vnode *vp; > > cap_rights_t rights; > > int error, flg, tmp; > > - u_int old, new; > > uint64_t bsize; > > off_t foffset; > > > > @@ -760,27 +759,25 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) > > error = EBADF; > > break; > > } > > + vp = fp->f_vnode; > > + /* > > + * Exclusive lock synchronizes against > > + * sequential_heuristic(). > I would also add a sentence that we care about f_seqcount update in > seq_heur(). > /* * Exclusive lock synchronizes against f_seqcount reads and writes in * sequential_heuristic(). */ > Another place to add the locking annotation is the struct file in > sys/file.h. Now f_seqcount is 'protected' by the vnode lock. > I am not sure how to express the locking model shortly. > /* * (a) f_vnode lock required (shared allows both reads and writes) */ -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 16:50:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A6429D9 for ; Mon, 25 Aug 2014 16:50:32 +0000 (UTC) Received: from trypticon.cs.illinois.edu (trypticon.cs.illinois.edu [128.174.237.181]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C6683FF2 for ; Mon, 25 Aug 2014 16:50:31 +0000 (UTC) Received: from trypticon.cs.illinois.edu (localhost [127.0.0.1]) by trypticon.cs.illinois.edu (8.14.4/8.14.4/Debian-2.1ubuntu2) with ESMTP id s7PGg5Gv010459; Mon, 25 Aug 2014 11:42:05 -0500 Received: (from dautenh1@localhost) by trypticon.cs.illinois.edu (8.14.4/8.14.4/Submit) id s7PGg4pw010458; Mon, 25 Aug 2014 11:42:04 -0500 Date: Mon, 25 Aug 2014 11:42:04 -0500 From: Nathan Dautenhahn To: Dieter BSD Subject: Re: stopped processes using cpu? Message-ID: <20140825164204.GB47394@trypticon.cs.illinois.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 16:50:32 -0000 On Wed, Aug 20, 2014 at 01:52:41PM -0700, Dieter BSD wrote: > > whether or not the existing code is good or bad > > It has been awhile since I've looked at the code for firefox, but > that code was OBSCENELY bad. :-( I fixed hundreds and hundreds and > hundreds of bugs (yes, that many!) and it still didn't work (at all). > The firefox idiots didn't believe my bug report. > > Code quality of top/ps/kernel? Look at the code and/or see how many > open PRs there are. > > Firefox runs in a chroot, executables in a read-only partition. > /etc/profile has > ulimit -S -m 400000 > ulimit -S -v 600000 > after an incident where an "idle" firefox grew without bound kicking > everything else out of memory including a small program running at rtprio > logging true real-time data resulting in the loss of data. (the data buffer > was mlocked, but the code wasn't. Silly me thinking that the kernel > wouldn't page out a small loop that is constantly running.) > Firefox is usually stopped when not being actively used. No plugins. > > Other web browsers (smaller, faster, more secure, less buggy, ...) > are used whenever possible. > > Rootkit? Perhaps possible in theory, but very highly unlikely. I concur. I have been doing a lot of rootkit research lately, which bends the mind that direction: if I wanted to hide a process that is doing nefarious things it seems like Firefox, given the evidence you just mentioned, would be ideal. I won't lie though, I am not expertized enough to know how to really bite into this and figure it out. > > CPU% decays as expected when processes are stopped (except for firefox). > Firefox CPU% does not decay as expected, either running or stopped. I tried > running a cpu-bound process in the same chroot as firefox, it decayed as > expected when stopped. > > So firefox seems to be the only thing that this shows up on. And also seems > to be the only thing with THR > 1. So try the -H option: > > PID UID PRI NICE SIZE RES STATE TIME WCPU COMMAND 92986 > 941 54 0 167M 63524K STOP 0:00 5.03% {firefox-bin} 92986 > 941 4 0 167M 63524K STOP 0:25 0.00% {initial thread} 92986 > 941 44 0 167M 63524K STOP 0:01 0.00% {firefox-bin} 92986 > 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986 > 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986 > 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986 > 941 44 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 33796 > 941 44 0 5248K 1200K ttyin 0:00 0.00% bash 92986 941 44 > 0 167M 63524K STOP 0:00 0.00% {firefox-bin} 92986 941 44 0 > 167M 63524K STOP 0:00 0.00% {firefox-bin} 92979 941 48 0 > 6184K 632K STOP 0:00 0.00% sh 92983 941 62 0 6208K 660K > STOP 0:00 0.00% sh 92978 941 44 0 8296K 1372K STOP 0:00 > 0.00% sh > > PID UID PRI NICE SIZE RES STATE TIME WCPU COMMAND 44188 > 937 4 0 303M 187M STOP 104:11 12.65% {initial thread} 44188 > 937 44 0 303M 187M STOP 0:45 0.49% {firefox-bin} 44188 > 937 44 0 303M 187M STOP 8:19 0.29% {firefox-bin} 44188 > 937 44 0 303M 187M STOP 0:02 0.00% {firefox-bin} 44188 > 937 44 0 303M 187M STOP 0:01 0.00% {firefox-bin} 44188 > 937 44 0 303M 187M STOP 0:01 0.00% {firefox-bin} 44188 > 937 44 0 303M 187M STOP 0:00 0.00% {firefox-bin} 44188 > 937 44 0 303M 187M STOP 0:00 0.00% {firefox-bin} 44167 > 937 44 0 5248K 804K ttyin 0:00 0.00% bash 44181 937 76 > 0 6184K 632K STOP 0:00 0.00% sh 44185 937 76 0 6208K > 664K STOP 0:00 0.00% sh 44188 937 60 0 303M 187M STOP > 0:00 0.00% {firefox-bin} > > Any clues there? Not that I can see. From what I know, if you are entertaining the possibility it's a rootkit, the only direction would be to write a different utility that printed out data on the various process lists in the kernel. You could use this to see if any of the state isn't matching. Sorry for not having more detailed ideas/evidence to go upon. Best, ::nathan:: >_______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, > send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 17:22:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B30B3570; Mon, 25 Aug 2014 17:22:59 +0000 (UTC) Received: from shxd.cx (unknown [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 992FF342C; Mon, 25 Aug 2014 17:22:59 +0000 (UTC) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:61725 helo=THEMADHATTER) by shxd.cx with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XLf5t-000J6W-33; Sun, 24 Aug 2014 14:12:57 -0700 From: To: "'Jordan Hubbard'" , References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> In-Reply-To: <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> Subject: RE: Lua in the bootloader Date: Mon, 25 Aug 2014 10:22:13 -0700 Message-ID: <17e701cfc089$1d0e1b30$572a5190$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQL5LS+a++1ap+929hQ2F1+mR87LYAKtNDcsAU1XcUwCGiIQUQGg3s2ImVEFgFA= Content-Language: en-us Sender: devin@shxd.cx Cc: freebsd-hackers@freebsd.org, 'Pedro Giffuni' , "'Wojciech A. Koszek'" , 'Pedro Arthur' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:22:59 -0000 > -----Original Message----- > From: Jordan Hubbard [mailto:jkh@ixsystems.com] > Sent: Sunday, August 24, 2014 4:43 PM > To: > Cc: ; Wojciech A. Koszek; Pedro Giffuni; > Pedro Arthur > Subject: Re: Lua in the bootloader > > > > limitations that I battle in Forth are significant enough > > that I'd like to see if Lua can break said chains (such as > > "dictionary full" errors causing BTX halt -- induced simply > > by adding "too many functions" in Forth). > > I'm not one to stand in the way of progress either, but just to make sure we > are not foolishly conflating "language" with "environment" here: You do all > realize that ficl can have any sized dictionary you want, right? Correct. I've also not yet tried my hand at "dictionary partitioning". You're right that there are things I can do to reduce the dictionary, but I think that where Forth fails us is that Lua already brings a lot of what we need versus in Forth I've had to invent a lot of what I need. For example, simply checking a "string" if it contains another "string" (space or comma-separated) means that I have to create a new function (see below): Plucked from: http://svnweb.freebsd.org/base/head/sys/boot/forth/support.4th?view=markup 205 : contains? ( addr1 len1 addr2 len2 -- 0 | -1 ) 206 2 pick 0= if 2drop 2drop true exit then 207 dup 0= if 2drop 2drop false exit then 208 begin 209 begin 210 swap dup c@ dup 32 = over 9 = or over 10 = or 211 over 13 = or over 44 = or swap drop 212 while 1+ swap 1- repeat 213 swap 2 pick 1- over < 214 while 215 2over 2over drop over compare-insensitive 0= if 216 2 pick over = if 2drop 2drop true exit then 217 2 pick tuck - -rot + swap over c@ dup 32 = 218 over 9 = or over 10 = or over 13 = or over 44 = or 219 swap drop if 2drop 2drop true exit then 220 then begin 221 swap dup c@ dup 32 = over 9 = or over 10 = or 222 over 13 = or over 44 = or swap drop 223 if false else true then 2 pick 0> and 224 while 1+ swap 1- repeat 225 swap 226 repeat 227 2drop 2drop false 228 ; This function takes up space in the dictionary. > Presumably, > it's kept small due to the limitations of the boot loader environment, and Lua > is not going to magically transcend those limitations. To understand why Lua can do better, execute "words" in the Forth loader environment to see the caliber of items taking up space in the dictionary. The idea here is that Lua can provide us with a higher caliber of functionality within the same footprint. > Writing lots of boot > code in Lua will require memory, perhaps even MORE memory since, say > what you like about Forth, it's hard to get more concise or compact than a > Forth dictionary of compiled CFA's. That's why we picked it for the role in the > first place. > Lua can indeed take less memory. Forth has a dynamic dictionary that can be used to hold multiple definitions. The Code Field Address (CFA) does not have to associated with a unique element, and in this implementation you can use the "forget" word in Forth to access old CFA's (using "[']" to get at the eXecution Token, or XT, for the current definition). While Lua allows you to redefine functions [1] the unique identifier maps uniquely to the current definition (old definitions do not pollute the map). [1] http://www.lua.org/pil/6.1.html That is not to say that you cannot have a function in Lua that calls an old copy, but you have to reference the old definition in the redefinition. This is unlike Forth wherein the XT is stored _and_ the dictionary retains CFA mappings. > So anyway, first try expanding the size of the dictionary. If that can't be done, > now you know your "ceiling" for Lua. Can you stay below it, not just now but > longer term? Those are the questions you need to answer. > I know that I can increase the size of the dictionary, and it will work on my machine, but I'm too worried about the machines of yester-year to actually bump the dictionary size. -- Devin From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 17:28:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A13AF9E9 for ; Mon, 25 Aug 2014 17:28:06 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3EE0F349E for ; Mon, 25 Aug 2014 17:28:06 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7PHRtRG012818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2014 20:27:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7PHRtRG012818 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7PHRtAt012817; Mon, 25 Aug 2014 20:27:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Aug 2014 20:27:55 +0300 From: Konstantin Belousov To: Mateusz Guzik , freebsd-hackers@freebsd.org Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140825172755.GD2737@kib.kiev.ua> References: <20140824115729.GC2045@dft-labs.eu> <20140824162331.GW2737@kib.kiev.ua> <20140824164236.GX2737@kib.kiev.ua> <20140825005659.GA14344@dft-labs.eu> <20140825073404.GZ2737@kib.kiev.ua> <20140825081526.GB14344@dft-labs.eu> <20140825083539.GB2737@kib.kiev.ua> <20140825091056.GC14344@dft-labs.eu> <20140825111000.GC2737@kib.kiev.ua> <20140825130433.GD14344@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y3cq2BYpkEb43po+" Content-Disposition: inline In-Reply-To: <20140825130433.GD14344@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:28:06 -0000 --Y3cq2BYpkEb43po+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2014 at 03:04:33PM +0200, Mateusz Guzik wrote: > On Mon, Aug 25, 2014 at 02:10:01PM +0300, Konstantin Belousov wrote: > > On Mon, Aug 25, 2014 at 11:10:56AM +0200, Mateusz Guzik wrote: > > > On Mon, Aug 25, 2014 at 11:35:39AM +0300, Konstantin Belousov wrote: > > > > > + atomic_set_int(&fp->f_flag, FHASLOCK); > > > > You misspelled FRDAHEAD as FHASLOCK, below as well. > > > > Was this tested ? > > > >=20 > > >=20 > > > Oops, damn copy-pasto. Sorry. > > >=20 > > > > > + VOP_UNLOCK(vp, 0); > > > > > } else { > > > > > - do { > > > > > - new =3D old =3D fp->f_flag; > > > > > - new &=3D ~FRDAHEAD; > > > > > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > > > > > + atomic_clear_int(&fp->f_flag, FHASLOCK); > > > > So what about extending the vnode lock to cover the flag reset ? > > > >=20 > > >=20 > > > Sure. > > >=20 > > > So this time I tested it properly and found out it is impossible to > > > disable the hint. The test is: > > >=20 > > > -1 is truncated and then read from intptr_t which yields a big positi= ve > > > number instead. Other users in the function use int tmp to work around > > > this issue. > > Could you provide me with the test case which demonstrates the problem ? > >=20 >=20 > Nothing special: > https://people.freebsd.org/~mjg/patches/F_READAHEAD.c And how did you verified that fcntl(F_READAHEAD, -1) did not worked ? I ended up with adding printf() to kern_fcntl() to see arg value. >=20 > > The fcntl(2) prototype in sys/fcntl.h is variadic, so int arg argument > > is not promoted. On the other hand, syscalls.master declares arg as lo= ng. > > Did you tried to pass -1L as third argument to disable ? > >=20 >=20 > Yes, -1L deals with the problem. I would still argue that using 'tmp' > like the rest of the function would not hurt as a cheap solution. This would deliberately break the current ABI (which takes the argument as long for F_READAHEAD), which is not acceptable. I do think that there is bug in the "-1" stuff, but it is in compat32 shims. The compat/freebsd32/syscalls.master does not provide the compat for fcntl(2), which means that 32bit fcntl(2) does not work when either signed extension is needed (the F_READAHEAD case), or on the big-endian machines. On i386, it did not practically matter before F_READAHEAD, since x86 is little-endian and flags passed as arg did not touch the sign bit. Note that fcntl(2) man page is wrong, it claims that optional argument arg is int. It cannot be true since pointer on LP64 platform cannot fit into int. The SUSv4 is explicit in describing which command takes which type; our man page must be fixed, but this is for later. See the patch at the end of the reply for the fix. It needs sysent regen for actual build. >=20 > > >=20 > > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > > > index 7abdca0..774f647 100644 > > > --- a/sys/kern/kern_descrip.c > > > +++ b/sys/kern/kern_descrip.c > > > @@ -760,7 +760,8 @@ kern_fcntl(struct thread *td, int fd, int cmd, in= tptr_t arg) > > > error =3D EBADF; > > > break; > > > } > > > - if (arg >=3D 0) { > > > + tmp =3D arg; > > > + if (tmp >=3D 0) { > > > vp =3D fp->f_vnode; > > > error =3D vn_lock(vp, LK_SHARED); > > > if (error !=3D 0) { > > > @@ -769,7 +770,7 @@ kern_fcntl(struct thread *td, int fd, int cmd, in= tptr_t arg) > > > } > > > bsize =3D fp->f_vnode->v_mount->mnt_stat.f_iosize; > > > VOP_UNLOCK(vp, 0); > > > - fp->f_seqcount =3D (arg + bsize - 1) / bsize; > > > + fp->f_seqcount =3D (tmp + bsize - 1) / bsize; > > > do { > > > new =3D old =3D fp->f_flag; > > > new |=3D FRDAHEAD; > > >=20 > > > Then the patch in question: > > >=20 > > > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > > > index 774f647..4efadb0 100644 > > > --- a/sys/kern/kern_descrip.c > > > +++ b/sys/kern/kern_descrip.c > > > @@ -476,7 +476,6 @@ kern_fcntl(struct thread *td, int fd, int cmd, in= tptr_t arg) > > > struct vnode *vp; > > > cap_rights_t rights; > > > int error, flg, tmp; > > > - u_int old, new; > > > uint64_t bsize; > > > off_t foffset; > > > =20 > > > @@ -760,27 +759,25 @@ kern_fcntl(struct thread *td, int fd, int cmd, = intptr_t arg) > > > error =3D EBADF; > > > break; > > > } > > > + vp =3D fp->f_vnode; > > > + /* > > > + * Exclusive lock synchronizes against > > > + * sequential_heuristic(). > > I would also add a sentence that we care about f_seqcount update in > > seq_heur(). > >=20 >=20 > /* > * Exclusive lock synchronizes against f_seqcount reads and writes in > * sequential_heuristic(). > */ >=20 > > Another place to add the locking annotation is the struct file in > > sys/file.h. Now f_seqcount is 'protected' by the vnode lock. > > I am not sure how to express the locking model shortly. > >=20 >=20 > /* > * (a) f_vnode lock required (shared allows both reads and writes) > */ Ok. diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index 815a9b7..fb8736c 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -2980,3 +2980,28 @@ freebsd32_procctl(struct thread *td, struct freebsd3= 2_procctl_args *uap) return (kern_procctl(td, uap->idtype, PAIR32TO64(id_t, uap->id), uap->com, data)); } + +int +freebsd32_fcntl(struct thread *td, struct freebsd32_fcntl_args *uap) +{ + intptr_t tmp; + + switch (uap->cmd) { + /* + * Do unsigned conversion for arg when operation + * interprets it as flags or pointer. + */ + case F_SETLK_REMOTE: + case F_SETLKW: + case F_SETLK: + case F_GETLK: + case F_SETFD: + case F_SETFL: + tmp =3D (unsigned int)(uap->arg); + break; + default: + tmp =3D uap->arg; + break; + } + return (kern_fcntl(td, uap->fd, uap->cmd, tmp)); +} diff --git a/sys/compat/freebsd32/syscalls.master b/sys/compat/freebsd32/sy= scalls.master index 3339690..161f69d 100644 --- a/sys/compat/freebsd32/syscalls.master +++ b/sys/compat/freebsd32/syscalls.master @@ -200,7 +200,8 @@ 89 AUE_GETDTABLESIZE NOPROTO { int getdtablesize(void); } 90 AUE_DUP2 NOPROTO { int dup2(u_int from, u_int to); } 91 AUE_NULL UNIMPL getdopt -92 AUE_FCNTL NOPROTO { int fcntl(int fd, int cmd, long arg); } +92 AUE_FCNTL STD { int freebsd32_fcntl(int fd, int cmd, \ + int arg); } 93 AUE_SELECT STD { int freebsd32_select(int nd, fd_set *in, \ fd_set *ou, fd_set *ex, \ struct timeval32 *tv); } --Y3cq2BYpkEb43po+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT+3IbAAoJEJDCuSvBvK1BdzQP/jEbCtmdwVzlWQBLJtWRkAhn C7idTvbhGdRWi1a8G1yEa4fNnxm7z5KGl+WRW+mO7npj8B7w/taX0pCt97J/TCIA 9iJI6qNuzylKXezuiGBrTx78pysmQ/6Y2ozQa3rGwIN4c03802Z+v5bz7uFbKFCP 9THL4Jzi7l8sNicGoG7upd0/gYEOYHg9sNuEgS7204Mn3NzRd5CQqouStm77kAea byx4IWoJrSB66bVSqb8bZcgsUn0xdM0iUcHLQQrF5lEyL6B52K7t+BC5Y5abVA78 XbUjDV1jlzjxxXLidx2ZyABjriK8FGFDBpjXquFjS1YCoz+wxb009pikmRgQP2Wf BBkibiZI/kkSS5rnqKJL2c75CJOOf7ONd/Ye0zvPVPtZbFgF9vmwGrOUwQCKhn+Q OWuQCIvMKDShL9GncrSjHP4cBHzHmxZOozUb8ysO30gWV+4tihPHKakMw9ssKnbv OqAP+qK1oPznhWlIXiciD3oRw/2SpIHErWDJUwXtMhFZvAuWwLZzntUYE5kUjTkD plVRi8gAzAazDVZYDhEa7ycP27P/9PvEzw5URpuxT6ABdzfK9vKpFEFoqiAqcXuE WdBG6cJQTzROrV0cDwfgowmW23FYhdijiHZdv/DccTbKIu5oMrS53bTXZne/ODhC k6nfxbtxS8DHD/KMJcIO =fHHK -----END PGP SIGNATURE----- --Y3cq2BYpkEb43po+-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 17:35:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 186A5E08; Mon, 25 Aug 2014 17:35:20 +0000 (UTC) Received: from shxd.cx (unknown [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0DED35C9; Mon, 25 Aug 2014 17:35:19 +0000 (UTC) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:61853 helo=THEMADHATTER) by shxd.cx with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XLfHx-000JSq-Aj; Sun, 24 Aug 2014 14:25:25 -0700 From: To: "'Jordan Hubbard'" , "'Rui Paulo'" References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> <236878C4-2C3E-4744-A04B-736C91032BFC@felyko.com> <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> In-Reply-To: <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> Subject: RE: Lua in the bootloader Date: Mon, 25 Aug 2014 10:34:42 -0700 Message-ID: <181801cfc08a$db080730$91181590$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQL5LS+a++1ap+929hQ2F1+mR87LYAKtNDcsAU1XcUwCGiIQUQGg3s2IAxzswpoCanVooZkk0JOw Content-Language: en-us Sender: devin@shxd.cx Cc: "'Wojciech A. Koszek'" , freebsd-hackers@freebsd.org, dteske@FreeBSD.org, 'Pedro Giffuni' , 'Pedro Arthur' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:35:20 -0000 > -----Original Message----- > From: Jordan Hubbard [mailto:jkh@ixsystems.com] > Sent: Sunday, August 24, 2014 11:27 PM > To: Rui Paulo > Cc: ; ; Pedro Giffuni; > Wojciech A. Koszek; Pedro Arthur > Subject: Re: Lua in the bootloader > > > On Aug 24, 2014, at 9:07 PM, Rui Paulo wrote: > > > No, it's worse than that. There's not a really limit on the size and the stack > can overflow easily on real hardware while at the same time it works fine on > bhyve at the same time. userboot vs real hardware. > > I'm not sure I understand why there would be a difference in behavior on > "real hardware" vs bhyve unless bhyve is initializing ficl differently and > causing it to change its allocation parameters. Indeed, there are differences in the way FICL is brought up. IIRC, bhyve uses "userboot" which does not provide an exact match to the loader environment (it can't exactly match everything). As an example, I'll draw a parallel with the "testmain" program. Here's an excerpt from sys/boot/ficl/loader.c: #if TESTMAIN /* * The readdirfd() function is specific to the loader environment. * We do the best we can to make freaddir work, but it's not at * all guaranteed. */ In that excerpt, I'm drawing attention to the fact that the "testmain" program which I use to simulate Forth in multi-user environment does not have access to readdirfd(). Outside of the loader environment, ficl itself has to fake a few calls. FYI: readdirfd() is provided by libstand, used by loader. > In some ways, we lost out for > not having gone with "a real forth" implementation in the most traditional > and compact sense. In a traditional Forth system, the dictionary starts at the > bottom of the available address space and the stack starts at the top - they > grow towards one another, which is how I implemented the PC-532 boot > loader (also in forth, but in assembly language); if you want to keep them out > of their hair, you just put the stack base further away in memory. > That seems like a reasonable approach without making me worry about PC's of yester-year. > Ficl is a higher-level C implementation and simply allocates a fixed-sized > chunk of space for the dictionary and for the stack. Our version of ficl is a bit > ancient and I'm still looking through it to even see where the dictionary size is > chosen. I suspect we simply made some bogus assumptions early on and > never caught them until the FreeBSD boot environment grew so many logos > and menus that it hit the limit. > Oh, you jogged my memory that some folks wanted me to update the Ficl implementation in the loader to the latest version. > Not that I disagree with any of the other arguments, mind you. I think a new > boot environment language would be fine. I agree that Forth is largely only > attractive to people with grey beard hair (though its value for torturing Alfred > should not be underestimated). I just think that it's also going to be awhile > before the new hotness is at full feature-parity with the current boot loader, > and if fixing the amount of headroom can buy us a little time, why not? We > hit the limit with FreeNAS too (I've seen the same dreaded boot-time crash > you did) so it's not just an academic point for me. > Ah, then we agree. Lua can spin in a silo while we address Forth issues. 1. Updating FICL to the latest version 2. Adjusting dictionary size (by pushing stack out?) 3. Taking the menus even further (ZFS root selection; i.e., beadm) > > The limitation of the dictionary and the size of the stack isn't the main > reason why I would prefer lua over forth. Why do we need to subject > ourselves to a stack based language in 2014? The very limited number of > people hacking on the Forth boot loader on FreeBSD might have a different > opinion, but the language is so arcane that I fail to see why we shouldn't > replace it. > > Again, no disagreement, though I do wonder how many Lua programmers > FreeBSD has that will be able to hit the ground running as a result of this > evolution. Anyone? Raise your hands! I can't raise mine - I've never used > Lua. :) > Seeing that the GSoC project re-envisioned a lot of my Forth code, I feel that I was able to pickup Lua pretty fast. Not sure how fast others can (that is, without the benefit of seeing in the context of their own code a direct translation). -- Devin From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 17:41:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80DA6480; Mon, 25 Aug 2014 17:41:06 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E42D136AF; Mon, 25 Aug 2014 17:41:05 +0000 (UTC) Received-SPF: pass (freebsd.czest.pl: domain of wkoszek@freebsd.czest.pl designates 212.87.224.105 as permitted sender) receiver=freebsd.czest.pl; client-ip=212.87.224.105; helo=freebsd.czest.pl; envelope-from=wkoszek@freebsd.czest.pl; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf-unknown; Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s7PHYm1J002640; Mon, 25 Aug 2014 17:34:48 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s7PHYmPu002639; Mon, 25 Aug 2014 17:34:48 GMT (envelope-from wkoszek) Date: Mon, 25 Aug 2014 17:34:48 +0000 From: "Wojciech A. Koszek" To: Jordan Hubbard Subject: Re: Lua in the bootloader Message-ID: <20140825173448.GC59838@FreeBSD.org> References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Mon, 25 Aug 2014 17:34:54 +0000 (UTC) Cc: "" , "" , Pedro Giffuni , Pedro Arthur X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:41:06 -0000 On nie, sie 24, 2014 at 04:43:24 -0700, Jordan Hubbard wrote: > > > limitations that I battle in Forth are significant enough > > that I'd like to see if Lua can break said chains (such as > > "dictionary full" errors causing BTX halt -- induced simply > > by adding "too many functions" in Forth). > > I'm not one to stand in the way of progress either, but just to make sure > we are not foolishly conflating "language" with "environment" here: You > do all realize that ficl can have any sized dictionary you want, right? > Presumably, it's kept small due to the limitations of the boot loader > environment, and Lua is not going to magically transcend those > limitations. Writing lots of boot code in Lua will require memory, > perhaps even MORE memory since, say what you like about Forth, it's hard > to get more concise or compact than a Forth dictionary of compiled CFA's. > That's why we picked it for the role in the first place. > > So anyway, first try expanding the size of the dictionary. If that can't > be done, now you know your "ceiling" for Lua. Can you stay below it, not > just now but longer term? Those are the questions you need to answer. It would be good to try to do something more sophisticated in Lua and see what the top memory limit is, before we do any serious moves in the loader land. -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 18:04:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CF332EA for ; Mon, 25 Aug 2014 18:04:23 +0000 (UTC) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 095323948 for ; Mon, 25 Aug 2014 18:04:22 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id k48so13420378wev.26 for ; Mon, 25 Aug 2014 11:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=xjTjM4W470BLHH9lQY9/SYH13A6480NCIfByZdmNGNQ=; b=rBHtTFkfaGVtHcxzXGdyXliMoVWx7LEpyaQ6+4x2JWotAuBeYcKGOWKwYYHiPE1uiW QSmu9+DXeSayjzz8wY1Ne0njb4W2pGhLeLgtqyI4AH88hmmmNBt7G+YkwUQ8qsejiPp7 7mA30n5/fMOnl/JTQwQKROKpPtnY+QpFBfIbuR5sN2Pki5e88xnyazfry0YWZNxzfgoH N2JNBNSiaFcLBn57L8QpJJ2LSVbaYS2DhqylI5t6B/ytIVo7DpZDctGqP4rT22TbP2Rx KAG/rgstC2uL4lI1SaYqcn+w+drdCb/an+LYtmQOe8POMD8Cw0vYQGTzsQB97vxobCAi njBg== X-Received: by 10.180.230.197 with SMTP id ta5mr16741842wic.10.1408989861159; Mon, 25 Aug 2014 11:04:21 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id cy10sm1377502wjb.21.2014.08.25.11.04.19 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 25 Aug 2014 11:04:20 -0700 (PDT) Date: Mon, 25 Aug 2014 20:04:17 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140825180417.GB23088@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , freebsd-hackers@freebsd.org References: <20140824162331.GW2737@kib.kiev.ua> <20140824164236.GX2737@kib.kiev.ua> <20140825005659.GA14344@dft-labs.eu> <20140825073404.GZ2737@kib.kiev.ua> <20140825081526.GB14344@dft-labs.eu> <20140825083539.GB2737@kib.kiev.ua> <20140825091056.GC14344@dft-labs.eu> <20140825111000.GC2737@kib.kiev.ua> <20140825130433.GD14344@dft-labs.eu> <20140825172755.GD2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140825172755.GD2737@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 18:04:23 -0000 On Mon, Aug 25, 2014 at 08:27:55PM +0300, Konstantin Belousov wrote: > On Mon, Aug 25, 2014 at 03:04:33PM +0200, Mateusz Guzik wrote: > > On Mon, Aug 25, 2014 at 02:10:01PM +0300, Konstantin Belousov wrote: > > > On Mon, Aug 25, 2014 at 11:10:56AM +0200, Mateusz Guzik wrote: > > > > On Mon, Aug 25, 2014 at 11:35:39AM +0300, Konstantin Belousov wrote: > > > > > > + atomic_set_int(&fp->f_flag, FHASLOCK); > > > > > You misspelled FRDAHEAD as FHASLOCK, below as well. > > > > > Was this tested ? > > > > > > > > > > > > > Oops, damn copy-pasto. Sorry. > > > > > > > > > > + VOP_UNLOCK(vp, 0); > > > > > > } else { > > > > > > - do { > > > > > > - new = old = fp->f_flag; > > > > > > - new &= ~FRDAHEAD; > > > > > > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > > > > > > + atomic_clear_int(&fp->f_flag, FHASLOCK); > > > > > So what about extending the vnode lock to cover the flag reset ? > > > > > > > > > > > > > Sure. > > > > > > > > So this time I tested it properly and found out it is impossible to > > > > disable the hint. The test is: > > > > > > > > -1 is truncated and then read from intptr_t which yields a big positive > > > > number instead. Other users in the function use int tmp to work around > > > > this issue. > > > Could you provide me with the test case which demonstrates the problem ? > > > > > > > Nothing special: > > https://people.freebsd.org/~mjg/patches/F_READAHEAD.c > And how did you verified that fcntl(F_READAHEAD, -1) did not worked ? > I ended up with adding printf() to kern_fcntl() to see arg value. > 3 uprintfs. one with the value, and then one in each if branch. > > > > > The fcntl(2) prototype in sys/fcntl.h is variadic, so int arg argument > > > is not promoted. On the other hand, syscalls.master declares arg as long. > > > Did you tried to pass -1L as third argument to disable ? > > > > > > > Yes, -1L deals with the problem. I would still argue that using 'tmp' > > like the rest of the function would not hurt as a cheap solution. > This would deliberately break the current ABI (which takes the argument > as long for F_READAHEAD), which is not acceptable. > Ok. > I do think that there is bug in the "-1" stuff, but it is in compat32 > shims. The compat/freebsd32/syscalls.master does not provide the compat > for fcntl(2), which means that 32bit fcntl(2) does not work when either > signed extension is needed (the F_READAHEAD case), or on the big-endian > machines. On i386, it did not practically matter before F_READAHEAD, > since x86 is little-endian and flags passed as arg did not touch the > sign bit. > > Note that fcntl(2) man page is wrong, it claims that optional argument > arg is int. It cannot be true since pointer on LP64 platform cannot > fit into int. The SUSv4 is explicit in describing which command > takes which type; our man page must be fixed, but this is for later. > > See the patch at the end of the reply for the fix. It needs sysent > regen for actual build. > I tested the patch and it fixes the problem. > > /* > > * Exclusive lock synchronizes against f_seqcount reads and writes in > > * sequential_heuristic(). > > */ > > > > > Another place to add the locking annotation is the struct file in > > > sys/file.h. Now f_seqcount is 'protected' by the vnode lock. > > > I am not sure how to express the locking model shortly. > > > > > > > /* > > * (a) f_vnode lock required (shared allows both reads and writes) > > */ > Ok. > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index 7abdca0..52fc01a 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -476,7 +476,6 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) struct vnode *vp; cap_rights_t rights; int error, flg, tmp; - u_int old, new; uint64_t bsize; off_t foffset; @@ -760,26 +759,24 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr_t arg) error = EBADF; break; } + vp = fp->f_vnode; + /* + * Exclusive lock synchronizes against f_seqcount reads and + * writes in sequential_heuristic(). + */ + error = vn_lock(vp, LK_EXCLUSIVE); + if (error != 0) { + fdrop(fp, td); + break; + } if (arg >= 0) { - vp = fp->f_vnode; - error = vn_lock(vp, LK_SHARED); - if (error != 0) { - fdrop(fp, td); - break; - } bsize = fp->f_vnode->v_mount->mnt_stat.f_iosize; - VOP_UNLOCK(vp, 0); fp->f_seqcount = (arg + bsize - 1) / bsize; - do { - new = old = fp->f_flag; - new |= FRDAHEAD; - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); + atomic_set_int(&fp->f_flag, FRDAHEAD); } else { - do { - new = old = fp->f_flag; - new &= ~FRDAHEAD; - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); + atomic_clear_int(&fp->f_flag, FRDAHEAD); } + VOP_UNLOCK(vp, 0); fdrop(fp, td); break; diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index f1d19ac..98823f3 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -438,7 +438,8 @@ static int sequential_heuristic(struct uio *uio, struct file *fp) { - if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) + ASSERT_VOP_LOCKED(fp->f_vnode, __func__); + if (fp->f_flag & FRDAHEAD) return (fp->f_seqcount << IO_SEQSHIFT); /* diff --git a/sys/sys/file.h b/sys/sys/file.h index b7d358b..856f799 100644 --- a/sys/sys/file.h +++ b/sys/sys/file.h @@ -143,6 +143,7 @@ struct fileops { * * Below is the list of locks that protects members in struct file. * + * (a) f_vnode lock required (shared allows both reads and writes) * (f) protected with mtx_lock(mtx_pool_find(fp)) * (d) cdevpriv_mtx * none not locked @@ -168,7 +169,7 @@ struct file { /* * DTYPE_VNODE specific fields. */ - int f_seqcount; /* Count of sequential accesses. */ + int f_seqcount; /* (a) Count of sequential accesses. */ off_t f_nextoff; /* next expected read/write offset. */ union { struct cdev_privdata *fvn_cdevpriv; -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 19:35:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 268DE345 for ; Mon, 25 Aug 2014 19:35:40 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B866E331E for ; Mon, 25 Aug 2014 19:35:39 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7PJZWq2048352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2014 22:35:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7PJZWq2048352 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7PJZVx8048344; Mon, 25 Aug 2014 22:35:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Aug 2014 22:35:31 +0300 From: Konstantin Belousov To: Mateusz Guzik , freebsd-hackers@freebsd.org Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140825193531.GE2737@kib.kiev.ua> References: <20140824164236.GX2737@kib.kiev.ua> <20140825005659.GA14344@dft-labs.eu> <20140825073404.GZ2737@kib.kiev.ua> <20140825081526.GB14344@dft-labs.eu> <20140825083539.GB2737@kib.kiev.ua> <20140825091056.GC14344@dft-labs.eu> <20140825111000.GC2737@kib.kiev.ua> <20140825130433.GD14344@dft-labs.eu> <20140825172755.GD2737@kib.kiev.ua> <20140825180417.GB23088@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="znFrcFTOc9PDN8kJ" Content-Disposition: inline In-Reply-To: <20140825180417.GB23088@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 19:35:40 -0000 --znFrcFTOc9PDN8kJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2014 at 08:04:17PM +0200, Mateusz Guzik wrote: > On Mon, Aug 25, 2014 at 08:27:55PM +0300, Konstantin Belousov wrote: > > On Mon, Aug 25, 2014 at 03:04:33PM +0200, Mateusz Guzik wrote: > > > On Mon, Aug 25, 2014 at 02:10:01PM +0300, Konstantin Belousov wrote: > > > > On Mon, Aug 25, 2014 at 11:10:56AM +0200, Mateusz Guzik wrote: > > > > > On Mon, Aug 25, 2014 at 11:35:39AM +0300, Konstantin Belousov wro= te: > > > > > > > + atomic_set_int(&fp->f_flag, FHASLOCK); > > > > > > You misspelled FRDAHEAD as FHASLOCK, below as well. > > > > > > Was this tested ? > > > > > >=20 > > > > >=20 > > > > > Oops, damn copy-pasto. Sorry. > > > > >=20 > > > > > > > + VOP_UNLOCK(vp, 0); > > > > > > > } else { > > > > > > > - do { > > > > > > > - new =3D old =3D fp->f_flag; > > > > > > > - new &=3D ~FRDAHEAD; > > > > > > > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > > > > > > > + atomic_clear_int(&fp->f_flag, FHASLOCK); > > > > > > So what about extending the vnode lock to cover the flag reset ? > > > > > >=20 > > > > >=20 > > > > > Sure. > > > > >=20 > > > > > So this time I tested it properly and found out it is impossible = to > > > > > disable the hint. The test is: > > > > >=20 > > > > > -1 is truncated and then read from intptr_t which yields a big po= sitive > > > > > number instead. Other users in the function use int tmp to work a= round > > > > > this issue. > > > > Could you provide me with the test case which demonstrates the prob= lem ? > > > >=20 > > >=20 > > > Nothing special: > > > https://people.freebsd.org/~mjg/patches/F_READAHEAD.c > > And how did you verified that fcntl(F_READAHEAD, -1) did not worked ? > > I ended up with adding printf() to kern_fcntl() to see arg value. > >=20 >=20 > 3 uprintfs. one with the value, and then one in each if branch. >=20 > > >=20 > > > > The fcntl(2) prototype in sys/fcntl.h is variadic, so int arg argum= ent > > > > is not promoted. On the other hand, syscalls.master declares arg a= s long. > > > > Did you tried to pass -1L as third argument to disable ? > > > >=20 > > >=20 > > > Yes, -1L deals with the problem. I would still argue that using 'tmp' > > > like the rest of the function would not hurt as a cheap solution. > > This would deliberately break the current ABI (which takes the argument > > as long for F_READAHEAD), which is not acceptable. > >=20 >=20 > Ok. >=20 > > I do think that there is bug in the "-1" stuff, but it is in compat32 > > shims. The compat/freebsd32/syscalls.master does not provide the compat > > for fcntl(2), which means that 32bit fcntl(2) does not work when either > > signed extension is needed (the F_READAHEAD case), or on the big-endian > > machines. On i386, it did not practically matter before F_READAHEAD, > > since x86 is little-endian and flags passed as arg did not touch the > > sign bit. > >=20 > > Note that fcntl(2) man page is wrong, it claims that optional argument > > arg is int. It cannot be true since pointer on LP64 platform cannot > > fit into int. The SUSv4 is explicit in describing which command > > takes which type; our man page must be fixed, but this is for later. > >=20 > > See the patch at the end of the reply for the fix. It needs sysent > > regen for actual build. > >=20 >=20 > I tested the patch and it fixes the problem. Which patch ? Your's or mine ? >=20 > > > /* > > > * Exclusive lock synchronizes against f_seqcount reads and writes in > > > * sequential_heuristic(). > > > */ > > >=20 > > > > Another place to add the locking annotation is the struct file in > > > > sys/file.h. Now f_seqcount is 'protected' by the vnode lock. > > > > I am not sure how to express the locking model shortly. > > > >=20 > > >=20 > > > /* > > > * (a) f_vnode lock required (shared allows both reads and writes) > > > */ > > Ok. > >=20 >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 7abdca0..52fc01a 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -476,7 +476,6 @@ kern_fcntl(struct thread *td, int fd, int cmd, intptr= _t arg) > struct vnode *vp; > cap_rights_t rights; > int error, flg, tmp; > - u_int old, new; > uint64_t bsize; > off_t foffset; > =20 > @@ -760,26 +759,24 @@ kern_fcntl(struct thread *td, int fd, int cmd, intp= tr_t arg) > error =3D EBADF; > break; > } > + vp =3D fp->f_vnode; > + /* > + * Exclusive lock synchronizes against f_seqcount reads and > + * writes in sequential_heuristic(). > + */ > + error =3D vn_lock(vp, LK_EXCLUSIVE); > + if (error !=3D 0) { > + fdrop(fp, td); > + break; > + } > if (arg >=3D 0) { > - vp =3D fp->f_vnode; > - error =3D vn_lock(vp, LK_SHARED); > - if (error !=3D 0) { > - fdrop(fp, td); > - break; > - } > bsize =3D fp->f_vnode->v_mount->mnt_stat.f_iosize; > - VOP_UNLOCK(vp, 0); > fp->f_seqcount =3D (arg + bsize - 1) / bsize; > - do { > - new =3D old =3D fp->f_flag; > - new |=3D FRDAHEAD; > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > + atomic_set_int(&fp->f_flag, FRDAHEAD); > } else { > - do { > - new =3D old =3D fp->f_flag; > - new &=3D ~FRDAHEAD; > - } while (!atomic_cmpset_rel_int(&fp->f_flag, old, new)); > + atomic_clear_int(&fp->f_flag, FRDAHEAD); > } > + VOP_UNLOCK(vp, 0); > fdrop(fp, td); > break; > =20 > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > index f1d19ac..98823f3 100644 > --- a/sys/kern/vfs_vnops.c > +++ b/sys/kern/vfs_vnops.c > @@ -438,7 +438,8 @@ static int > sequential_heuristic(struct uio *uio, struct file *fp) > { > =20 > - if (atomic_load_acq_int(&(fp->f_flag)) & FRDAHEAD) > + ASSERT_VOP_LOCKED(fp->f_vnode, __func__); > + if (fp->f_flag & FRDAHEAD) > return (fp->f_seqcount << IO_SEQSHIFT); > =20 > /* > diff --git a/sys/sys/file.h b/sys/sys/file.h > index b7d358b..856f799 100644 > --- a/sys/sys/file.h > +++ b/sys/sys/file.h > @@ -143,6 +143,7 @@ struct fileops { > * > * Below is the list of locks that protects members in struct file. > * > + * (a) f_vnode lock required (shared allows both reads and writes) > * (f) protected with mtx_lock(mtx_pool_find(fp)) > * (d) cdevpriv_mtx > * none not locked > @@ -168,7 +169,7 @@ struct file { > /* > * DTYPE_VNODE specific fields. > */ > - int f_seqcount; /* Count of sequential accesses. */ > + int f_seqcount; /* (a) Count of sequential accesses. */ > off_t f_nextoff; /* next expected read/write offset. */ > union { > struct cdev_privdata *fvn_cdevpriv; >=20 I think this patch is fine. --znFrcFTOc9PDN8kJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAEBAgAGBQJT+5ACAAoJEJDCuSvBvK1BxfEP+IdeVV1PuLP9N8fnGXAVTnxq h3TsT1CZeQzR0J+DK07FFspWsDzDtPIOletJZa63G7bcV9mMYxfeXdFNaxmjy3sZ 7eD7+VEUfp45HwFSeuQN8I0Nq5qLRv1XvWnU1h9Z9pYqSirXD9N/gMTkb/Mtc3AG XCgu+DmHjoo8mf8p9cB+C1t68I6s8Lc3s6eMI/D9yVv/SFLJj1gVtTO/XMtJfpPV LZbo1bVUzgCIxek5VSfrxAS3tCdplZb2Wjszk+3JLtX+RXr959QZjYvj1jrWU1XK +7KnuiJFc+8WwtGoYKy+PE5H5ioTZippp6weEjsC0W4OpZ0LUuNdAeb0ofzfnpP8 Y0XZl02X2NqsROxW9+kOqmn/ddYA3zBzLNZMF9ouCtxYUMYxQK8ZBDM5FNC+P+Fk u1T8p0kogpTjsVd43XalljNAGChdh4eqHAi64/NGHft0qqcChFSixaao9ZPFeHhK 11rfV8HMMaop0YHLdM+vIz51avC7ejpsX3YC8n7Rfi7ard94sMhWnNkJp+Ub6Y+9 VfglO0PkftkYkVTcnvTrd2eodRiglhFoFRU2GcrPALrAC+8x+O5cDW84mIEKm/ZR Q13KO3OZj/V/NEqB+/0ZQtAOCAHrjyceW21X7cz/LOB6Ns111jx1ozPalvA9aVN7 kpFo3v0WQmOXdV91MDU= =3iw4 -----END PGP SIGNATURE----- --znFrcFTOc9PDN8kJ-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 20:57:40 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4819CF2D; Mon, 25 Aug 2014 20:57:40 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C2BB3B6E; Mon, 25 Aug 2014 20:57:39 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7PKwe1F018958; Mon, 25 Aug 2014 13:58:46 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7PKwZ0V018957; Mon, 25 Aug 2014 13:58:35 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 25 Aug 2014 13:58:35 -0700 (PDT) Message-ID: Date: Mon, 25 Aug 2014 13:58:35 -0700 (PDT) Subject: How to get a mouse in vt(4) -- NEWCONS From: "Chris H" To: "freebsd current" , "freebsd hackers" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 20:57:40 -0000 Greetings, I'm testing 11-CURRENT, and have build/installed a kernel, and world. The KERNCONF includes both sc, and vt. As I understand it. If both are included, I get sc, not vt. But all previous kerns I've built that had sc, provided a mouse upon boot. However, in 11, I don't get one. What must be done? I'd like to try vt(4), and I've read the man page for it, and have added: kern.vty="vt" in /boot/loader.conf having done so, does NOT enable mouse support, and turns OFF cursor="blink" which is defined in rc.conf(5). I also read that hw.vga.textmode is available. However sysctl hw.vga.textmode returns unknown oid. I would choose graphics (0) if it was available. But appears not. Thank you for all your time, and consideration. --Chris From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 22:23:00 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA927785; Mon, 25 Aug 2014 22:23:00 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 98C93343C; Mon, 25 Aug 2014 22:23:00 +0000 (UTC) Received: from u10-2-16-021.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 52889346DE27; Mon, 25 Aug 2014 15:22:54 -0700 (PDT) Message-ID: <53FBB7AB.2080008@freebsd.org> Date: Mon, 25 Aug 2014 15:24:43 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Jordan Hubbard , Rui Paulo Subject: Re: Lua in the bootloader References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> <236878C4-2C3E-4744-A04B-736C91032BFC@felyko.com> <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> In-Reply-To: <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "" , Pedro Giffuni , "" , "Wojciech A. Koszek" , Pedro Arthur X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 22:23:00 -0000 On 8/24/14 11:27 PM, Jordan Hubbard wrote: > On Aug 24, 2014, at 9:07 PM, Rui Paulo wrote: > >> No, it's worse than that. There's not a really limit on the size and the stack can overflow easily on real hardware while at the same time it works fine on bhyve at the same time. userboot vs real hardware. > I’m not sure I understand why there would be a difference in behavior on “real hardware” vs bhyve unless bhyve is initializing ficl differently and causing it to change its allocation parameters. In some ways, we lost out for not having gone with “a real forth” implementation in the most traditional and compact sense. In a traditional Forth system, the dictionary starts at the bottom of the available address space and the stack starts at the top - they grow towards one another, which is how I implemented the PC-532 boot loader (also in forth, but in assembly language); if you want to keep them out of their hair, you just put the stack base further away in memory. > > Ficl is a higher-level C implementation and simply allocates a fixed-sized chunk of space for the dictionary and for the stack. Our version of ficl is a bit ancient and I’m still looking through it to even see where the dictionary size is chosen. I suspect we simply made some bogus assumptions early on and never caught them until the FreeBSD boot environment grew so many logos and menus that it hit the limit. > > Not that I disagree with any of the other arguments, mind you. I think a new boot environment language would be fine. I agree that Forth is largely only attractive to people with grey beard hair (though its value for torturing Alfred should not be underestimated). I just think that it’s also going to be awhile before the new hotness is at full feature-parity with the current boot loader, and if fixing the amount of headroom can buy us a little time, why not? We hit the limit with FreeNAS too (I’ve seen the same dreaded boot-time crash you did) so it’s not just an academic point for me. > >> The limitation of the dictionary and the size of the stack isn't the main reason why I would prefer lua over forth. Why do we need to subject ourselves to a stack based language in 2014? The very limited number of people hacking on the Forth boot loader on FreeBSD might have a different opinion, but the language is so arcane that I fail to see why we shouldn't replace it. > Again, no disagreement, though I do wonder how many Lua programmers FreeBSD has that will be able to hit the ground running as a result of this evolution. Anyone? Raise your hands! I can’t raise mine - I’ve never used Lua. :) Probably about the same amount of Forth coders, if not more. That said the bar to entry with Forth is so much higher (for very little gain) these days that it just makes sense to retire it, or at least offer other options. Seriously, the entire use of Forth in the loader has been done wrong and it is due to Forth being hard to develop in, specifically for C programmers. We do just so many things wrong, and the only thing we're actually doing in forth is emitting ascii code, and now that we have color prompts by default "printenv" is broken. It's just rage inducing and makes FreeBSD (and by extension us (and by that extension me)) look dumb and archaic. Let's get something that's easy to code in and call it a day. I recall taking half a day in order to figure out some magic to help some poor sysadmin pick an include file using a DHCP env var, and *days* working with Devin to just conditionally make a construct to "include file if it exists". Yech! Lua please. -Alfred > > - Jordan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 22:39:42 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9981D9; Mon, 25 Aug 2014 22:39:42 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C733355E; Mon, 25 Aug 2014 22:39:42 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7PMehkB028109; Mon, 25 Aug 2014 15:40:49 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7PMecxV028108; Mon, 25 Aug 2014 15:40:38 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 25 Aug 2014 15:40:38 -0700 (PDT) Message-ID: <0cab774cc83f724aef4cf6ad2ed78090.authenticated@ultimatedns.net> Date: Mon, 25 Aug 2014 15:40:38 -0700 (PDT) Subject: vt(4) -- vidcontrol: setting cursor type: Inappropriate ioctl for device From: "Chris H" To: "freebsd current" , "freebsd hackers" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 22:39:42 -0000 Greetings, On 11-CURRENT, and with vt(4) chosen. I receive the following at boot: vidcontrol: setting cursor type: Inappropriate ioctl for device I _believe_ this is caused by the entry in rc.conf(5) cursor="blink" This entry has always worked fine with sc(4), and as I read it, [should] in vt(4) as well. But the vt(4) man pages seem to be lagging. They discuss oid(s) that don't seem to exist, and I'm unable to determine _what_ I should be doing to get a similar terminal/console as I get w/sc(4). Are there any other docs, or links available to help me with this? Thank you for all your time, and consideration. --Chris P.S. I'm using an Nvidia 8400, w/512Mb ram onboard, as well as the Nvidia blob. If that makes any difference. Thanks again. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 23:15:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9641AD9 for ; Mon, 25 Aug 2014 23:15:42 +0000 (UTC) Received: from nm32-vm0.bullet.mail.bf1.yahoo.com (nm32-vm0.bullet.mail.bf1.yahoo.com [72.30.239.136]) by mx1.freebsd.org (Postfix) with ESMTP id 6782338E3 for ; Mon, 25 Aug 2014 23:15:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1409008411; bh=uecWC9SvgVst9jfWNYY63oZ5Jb9JEsPEJ5+RrE0P7es=; h=Received:Received:Received:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:From:Subject; b=LOgOaYISpm30a1h+tdYbCR5OcnAulNbW2F3/p39qNIQdGF1qe985k+Lo/zoLe7DM1OOrAfjcnfmgEFdeuzf0UILwQZcRkqLXFpgG26lQgOb5HavE6ZtmE1Mq18rv6XoliCPeLMyy4fp5G17hV7bLbeHyS7Wsq4Y2Rvnp2xhgHxD5nvWF/az+S/zZHfW0IIsY8a2RDTSuHK8QoE+QEEB8ft//zPy+E8Gq9XxxhpqhFLTOCTPsnFXIM6ov820ShoTl7oXLd6K0J/8MRw/8TNOuFMhL00olpgdk5V1khittB6AoWK390RFOfxevJbs8R9Xs3XcevlMPp98eYmC6hEhz6Q== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=XmlbrWwyOIRg25XFrT/Yq0/XW3g2Z2KR11xxWxN8cIiMyNHV4ntI6x6ZjMhFYzWKTvvmvvl5Mp5hCgoOD872WRMwwl1oKxnr61S8yptGTDxZdZGTNmp5KkoIU+4pFixbstVQcAKncDP+oDoE4rUY6TgUV5jwuDhIJGfU6eSJI8ZWKXPdNBNOwVOmJzIX+7AftJCrzxALDs1mfY4tyWimFdQA5xOf5keZvpCmbjg+8sNJaB+4XIWNbR3cNPVvDl4WkVa6Ojbe6kZ526cdJ+TDEbvgIbieVO4KYyyDqC/gXmpISfcizNEascpJJ8mWAkWWhcd/ciHxfhIaJCP5TUEdYQ==; Received: from [98.139.212.151] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 25 Aug 2014 23:13:31 -0000 Received: from [98.139.211.161] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 25 Aug 2014 23:13:31 -0000 Received: from [127.0.0.1] by smtp218.mail.bf1.yahoo.com with NNFMP; 25 Aug 2014 23:13:31 -0000 X-Yahoo-Newman-Id: 506985.74396.bm@smtp218.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NLfpazwVM1ltNBSvEl9VDHITN.CdRqKQPQBMYfzI2SEMNeW Qdof2eYCjuJH2okpKXpB79N0ffJAXUaSOXOrU1a3GAgC7182NnJUcRKGgTSD _CxXnYoDSEufsuEi4_qWRzFPS5jOAl6LucWPdsuaITIU9eDQlEFngCcLhmJY FTw7CiXhMH5YJKCiLW5iJZg_lNJ7xPp7TTYK1lwa52lqr_c4R9g6NRmPjY4Y N.vsgbBcUdJrD2uBbo2876crHil1psIOV7iHym.MwDArzN7dra.Cpj.xHALX QMUV_gsNZeG6JcJk5OfoONZrySlSp7FUmKkRzm5sat.xEYwxM.DoLJr_SW8k wu1g2c.t132GbCVnsSP9katwDH4ZyoKast_zLE7Wm.Xms7.vbKnLtIAVYs4B iuw2WgDKD0YDStBKneQ1iciIroMI8lFHB3mkpB_4yLEorGwv.nv0S2l65qEe 1.IDmuG9sK_hFglZxgGq0R8OCXlcN9UuZSniB59zg_ulkkQjWibnjpuaWgWJ mXrTw9Kb1TYY0F9HCevBcVrNL30wNYArkrjPSFVuaQHmB9BNVcumIiUkNzzc lpUZ9n3wOCoZvid.m5QqG8KQQUKTNixIqC620Iet573r5SY4xJBfEbKACneu 7jEZ5EAT7VCPjam5eLbf8.HEYvU3SFC_77Wn__0oqPqaY6V8VWK8xzTLcpi2 r8y3oxT8I X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <53FBC329.6020107@freebsd.org> Date: Mon, 25 Aug 2014 18:13:45 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jordan Hubbard , Rui Paulo Subject: Re: Lua in the bootloader References: <3D62F4F4-ECCF-4622-BB57-D028160F3451@freebsd.org> <157901cfbe83$6cbf18d0$463d4a70$@FreeBSD.org> <16e101cfbfee$42b3b930$c81b2b90$@FreeBSD.org> <5FE57E4E-A627-4ABA-AB73-F0D60A3602D5@ixsystems.com> <236878C4-2C3E-4744-A04B-736C91032BFC@felyko.com> <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> In-Reply-To: <96E32478-5450-4A35-B68A-4791668AA701@ixsystems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "" , "" , "Wojciech A. Koszek" , Pedro Arthur X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 23:15:42 -0000 On 08/25/14 01:27, Jordan Hubbard wrote: > ... >> The limitation of the dictionary and the size of the stack isn't the main reason why I would prefer lua over forth. Why do we need to subject ourselves to a stack based language in 2014? The very limited number of people hacking on the Forth boot loader on FreeBSD might have a different opinion, but the language is so arcane that I fail to see why we shouldn't replace it. > Again, no disagreement, though I do wonder how many Lua programmers FreeBSD has that will be able to hit the ground running as a result of this evolution. Anyone? Raise your hands! I can’t raise mine - I’ve never used Lua. :) > > - Jordan One one hand we have Forth which seems to be under-appreciated. I would think that it is still better than nothing, but then nothing is what other people use and they are not complaining (perhaps because they don't know what they are missing? I don't know). On the other hand there is Lua: If we do a quick look in the net for Lua related code we can find many examples. It seems like there is a new generation of game developers that are very fond of Lua, to the point that it is more popular than Python in gaming. Other than Angry Birds, I am also seeing Lua embedded in Apache httpd, Trafficserver, VLC, there is even a Forth implemented in Lua! To put it someway: Lua absolutely looks better than forth in your resume. FWIW, although somewhat oldish, this looks like an interesting thing to play with http://lua-cui.sourceforge.net/ And there's also this: https://code.google.com/p/llvm-lua/ No equivalents for Forth, AFAICT. This said, while Lua seems to be powerful and exciting, it is not the mighty thing we want everywhere. Apparently Grub2 at some point embedded Lua and later reverted it. NetBSD introduced Lua in their kernel but apparently has found no use for it. DragonFly's installer had an old Lua backend that they removed (they also removed bootforth very early). Options are good, I welcome the Lua option and I will love to see how far it goes but let's not get too excited about the imminent death of Forth just yet. Ultimately, being Devin the driving force behind the bootloader enhancements, I think he is in the best position to choose. Pedro. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 25 23:26:08 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B06D3DBC; Mon, 25 Aug 2014 23:26:08 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E9C439B0; Mon, 25 Aug 2014 23:26:08 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s7PNPr1C084263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Aug 2014 17:25:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s7PNPraA084260; Mon, 25 Aug 2014 17:25:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 25 Aug 2014 17:25:53 -0600 (MDT) From: Warren Block To: Chris H Subject: Re: How to get a mouse in vt(4) -- NEWCONS In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 25 Aug 2014 17:25:53 -0600 (MDT) Cc: freebsd hackers , freebsd current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 23:26:08 -0000 On Mon, 25 Aug 2014, Chris H wrote: > I also read that hw.vga.textmode is available. However sysctl > hw.vga.textmode returns unknown oid. It is a boot-time-only setting for loader.conf. hw.vga.textmode=1 boots in text mode. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 26 00:53:42 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF016ADA; Tue, 26 Aug 2014 00:53:42 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD56C3099; Tue, 26 Aug 2014 00:53:42 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7Q0saIR040032; Mon, 25 Aug 2014 17:54:42 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7Q0sVsL040015; Mon, 25 Aug 2014 17:54:31 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 25 Aug 2014 17:54:31 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Mon, 25 Aug 2014 17:54:31 -0700 (PDT) Subject: Re: How to get a mouse in vt(4) -- NEWCONS From: "Chris H" To: "Warren Block" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd hackers , freebsd current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 00:53:43 -0000 > On Mon, 25 Aug 2014, Chris H wrote: > >> I also read that hw.vga.textmode is available. However sysctl >> hw.vga.textmode returns unknown oid. > > It is a boot-time-only setting for loader.conf. > > hw.vga.textmode=1 > > boots in text mode. Ahh, I see. Thank you very much, Warren, for the reply. :) --Chris > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 26 07:23:23 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5DD261A; Tue, 26 Aug 2014 07:23:23 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81E183291; Tue, 26 Aug 2014 07:23:23 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7Q7OPK6077611; Tue, 26 Aug 2014 00:24:31 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7Q7OJRg077607; Tue, 26 Aug 2014 00:24:19 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 26 Aug 2014 00:24:19 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Tue, 26 Aug 2014 00:24:19 -0700 (PDT) Subject: Re: How to get a mouse in vt(4) -- NEWCONS From: "Chris H" To: "Kevin Oberman" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd hackers , freebsd current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 07:23:23 -0000 > On Mon, Aug 25, 2014 at 5:54 PM, Chris H wrote: > >> > On Mon, 25 Aug 2014, Chris H wrote: >> > >> >> I also read that hw.vga.textmode is available. However sysctl >> >> hw.vga.textmode returns unknown oid. >> > >> > It is a boot-time-only setting for loader.conf. >> > >> > hw.vga.textmode=1 >> > >> > boots in text mode. >> Ahh, I see. Thank you very much, Warren, for the reply. :) >> >> --Chris >> >> > But the mouse should work fine with vt(4). It does for me. You do need to > run moused, though that was the case with cs(4), as well. D'OH! Sorry my bad. I overlooked the entry in loader.conf(5) on my other box. Sorry for the noise. > The lack of > "blink" support was just noted in the last post to this list, so we can > hope to hear a bit about the status of blink soon. That would be good to know. Thank you for taking the time to respond, Kevin. --Chris > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 26 08:20:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 855628E3 for ; Tue, 26 Aug 2014 08:20:33 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B1F337F5 for ; Tue, 26 Aug 2014 08:20:32 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id t60so14330174wes.20 for ; Tue, 26 Aug 2014 01:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=a8WYs7Z328Y35diBXtcvkiLcQAGQPIXyy8puiBOsF2E=; b=JapyFYVMrMqMlDxJbEcaOgj7B29POAa3ZweidoWlompqbPo71sLx13eXehfmnYP7C0 73Om11PPwW51RABPpu7Zw74bS4tFJ3SEhyrX/izILsOKdWB5yCmN91JoCgkCJyy1rwLQ IxgISVHFReqDQBCy1VfL4W4yxzgkAIfpZ7SXs93My6kPyhlqcQwdkneG5mMSt0mUK8wu sdjjwcWVZrGUCbuYwOtveFAtIXuch0484PfMWb21AgCypKuueIi6g6vQA7AXV3CtqhKo lnkb5w4pnQVoxVi1H6kCepR4TFXhN901m8crLjm0ERqJ+Du3d+ka9NvvJh0yBFgLvGsO BFYQ== X-Received: by 10.180.210.231 with SMTP id mx7mr20060311wic.42.1409041231351; Tue, 26 Aug 2014 01:20:31 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id xt6sm6341450wjc.14.2014.08.26.01.20.29 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 26 Aug 2014 01:20:30 -0700 (PDT) Date: Tue, 26 Aug 2014 10:20:27 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: atomic_load_acq_int in sequential_heuristic Message-ID: <20140826082026.GD23088@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , freebsd-hackers@freebsd.org References: <20140825005659.GA14344@dft-labs.eu> <20140825073404.GZ2737@kib.kiev.ua> <20140825081526.GB14344@dft-labs.eu> <20140825083539.GB2737@kib.kiev.ua> <20140825091056.GC14344@dft-labs.eu> <20140825111000.GC2737@kib.kiev.ua> <20140825130433.GD14344@dft-labs.eu> <20140825172755.GD2737@kib.kiev.ua> <20140825180417.GB23088@dft-labs.eu> <20140825193531.GE2737@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140825193531.GE2737@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 08:20:33 -0000 On Mon, Aug 25, 2014 at 10:35:31PM +0300, Konstantin Belousov wrote: > On Mon, Aug 25, 2014 at 08:04:17PM +0200, Mateusz Guzik wrote: > > > I do think that there is bug in the "-1" stuff, but it is in compat32 > > > shims. The compat/freebsd32/syscalls.master does not provide the compat > > > for fcntl(2), which means that 32bit fcntl(2) does not work when either > > > signed extension is needed (the F_READAHEAD case), or on the big-endian > > > machines. On i386, it did not practically matter before F_READAHEAD, > > > since x86 is little-endian and flags passed as arg did not touch the > > > sign bit. > > > > > > Note that fcntl(2) man page is wrong, it claims that optional argument > > > arg is int. It cannot be true since pointer on LP64 platform cannot > > > fit into int. The SUSv4 is explicit in describing which command > > > takes which type; our man page must be fixed, but this is for later. > > > > > > See the patch at the end of the reply for the fix. It needs sysent > > > regen for actual build. > > > > > > > I tested the patch and it fixes the problem. > Which patch ? Your's or mine ? > Yours, apart from mine. I committed my patch as r270648. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 26 08:20:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDDE19BE; Tue, 26 Aug 2014 08:20:49 +0000 (UTC) Received: from mailout08.t-online.de (mailout08.t-online.de [194.25.134.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D2A737FB; Tue, 26 Aug 2014 08:20:49 +0000 (UTC) Received: from fwd41.aul.t-online.de (fwd41.aul.t-online.de [172.20.27.139]) by mailout08.t-online.de (Postfix) with SMTP id 318B21BEE17; Tue, 26 Aug 2014 10:20:46 +0200 (CEST) Received: from [192.168.119.33] (bVdudUZboh93d0hbuP+EAAEclfvXAAhpKxrNgOfnXlgl-qsjXadHi8HQFoRaqXzZyp@[84.154.101.219]) by fwd41.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XMBzh-1eS5lA0; Tue, 26 Aug 2014 10:20:45 +0200 Message-ID: <53FC435C.9000905@freebsd.org> Date: Tue, 26 Aug 2014 10:20:44 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Sergey Kandaurov Subject: Re: [PATCH] Missing references to vt(4) "NEWCONS" in man-pages References: <53F59FE3.7030802@freebsd.org> <20140821085540.GA9402@omg> In-Reply-To: <20140821085540.GA9402@omg> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: bVdudUZboh93d0hbuP+EAAEclfvXAAhpKxrNgOfnXlgl-qsjXadHi8HQFoRaqXzZyp X-TOI-MSGID: 67ae4d33-a563-4571-afcb-c4550bb20d57 Cc: "freebsd-hackers@freebsd.org" , freebsd-doc@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 08:20:49 -0000 Am 21.08.2014 um 10:55 schrieb Sergey Kandaurov: > On Thu, Aug 21, 2014 at 09:29:39AM +0200, Stefan Esser wrote: >> Hi, > > a couple of nits inline Thank you very much for the corrections. I have just committed the updated man-pages as SVN rev. 270647, and I want to MFC them as soon as possible/permitted. Best regards, STefan >> Index: share/man/man4/kbdmux.4 >> =================================================================== >> >> --- share/man/man4/kbdmux.4 (revision 270244) >> +++ share/man/man4/kbdmux.4 (working copy) @@ -35,6 +35,7 @@ .Xr >> atkbd 4 , .Xr syscons 4 , .Xr ukbd 4 +.Xr vt 4 , > > misplaced comma -- comma moved up one line >> .Sh HISTORY The .Nm Index: share/man/man4/splash.4 >> =================================================================== >> >> --- share/man/man4/splash.4 (revision 270244) >> +++ share/man/man4/splash.4 (working copy) @@ -245,6 +245,7 @@ >> .Xr vidcontrol 1 , .Xr syscons 4 , .Xr vga 4 , +.\" .Xr vt 4 , > > why is it commented out? -- I was not sure, whether splash works with vt -- The comments are removed and vt(4) is now referenced in slash(4) [...] >> Index: share/man/man4/vt.4 >> =================================================================== >> >> --- share/man/man4/vt.4 (revision 270244) >> +++ share/man/man4/vt.4 (working copy) @@ -211,7 +211,7 @@ >> Default is 15, all enabled. .El .Sh FILES -.Bl -tag -width >> /usr/share/syscons/keymaps/* -compact +.Bl -tag -width >> /usr/share/vt/keymaps/* -compact .It Pa /dev/console .It Pa >> /dev/consolectl .It Pa /dev/ttyv* > > this section still misses description for paths to fonts and key > maps. The font and keymap paths have been added. Thanks again! From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 26 08:23:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D10B8C1F; Tue, 26 Aug 2014 08:23:32 +0000 (UTC) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9162338BB; Tue, 26 Aug 2014 08:23:32 +0000 (UTC) Received: from fwd40.aul.t-online.de (fwd40.aul.t-online.de [172.20.26.139]) by mailout04.t-online.de (Postfix) with SMTP id 6454C69B17; Tue, 26 Aug 2014 10:23:24 +0200 (CEST) Received: from [192.168.119.33] (E2tRR4Z1ZhHwG8HsZ6pYtFR9zwcbUEFcNbxDyWf+6MIjTYCGiBwhK0edb3uPxPAwwl@[84.154.101.219]) by fwd40.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XMC2D-4Ifrea0; Tue, 26 Aug 2014 10:23:21 +0200 Message-ID: <53FC43F7.3060602@freebsd.org> Date: Tue, 26 Aug 2014 10:23:19 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ed Maste Subject: Re: [PATCH] Missing references to vt(4) "NEWCONS" in man-pages References: <53F59FE3.7030802@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: E2tRR4Z1ZhHwG8HsZ6pYtFR9zwcbUEFcNbxDyWf+6MIjTYCGiBwhK0edb3uPxPAwwl X-TOI-MSGID: ece3407a-cb79-4cc5-a253-de6afcdb7eb0 Cc: "freebsd-hackers@freebsd.org" , freebsd-doc@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 08:23:32 -0000 Am 23.08.2014 um 04:15 schrieb Ed Maste: > Notes on two of the man pages: > > On 21 August 2014 03:29, Stefan Esser wrote: >> share/man/man4/terasic_mtl.4 (does this driver work with vt???) > > Not yet. I have a patch in another tree to add support. Ok, I have left that file untouched and leave it to you to add the references after the functionality is there ... >> share/man/man4/vga.4 > > This one is syscons-specific. We pondered having a vt_vga(4) page, but > the content was so minimal that it's just been put in vt(4) instead. > Specifically, the vga(4) driver is _not_ used by vt(4). Thanks for pointing this out! I have vt_vga configured in my kernel for so long, that I forgot about vga(4) vs. vt_vga(4) ... Best regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 26 10:17:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41C2F121; Tue, 26 Aug 2014 10:17:27 +0000 (UTC) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01F1D3445; Tue, 26 Aug 2014 10:17:26 +0000 (UTC) Received: from fwd12.aul.t-online.de (fwd12.aul.t-online.de [172.20.26.241]) by mailout04.t-online.de (Postfix) with SMTP id 23F4868A30; Tue, 26 Aug 2014 12:17:24 +0200 (CEST) Received: from [192.168.119.33] (EXS5JyZbQhKHAkfmCIscAyOW2SKf2I5jUukoeE9JRr+XAkW5ZDTN3uVrZjg1-QCgso@[84.154.101.219]) by fwd12.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XMDoY-18OWG00; Tue, 26 Aug 2014 12:17:22 +0200 Message-ID: <53FC5EB1.2050606@freebsd.org> Date: Tue, 26 Aug 2014 12:17:21 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: =?windows-1252?Q?V=E1clav_Zeman?= , freebsd-hackers@freebsd.org Subject: Re: Opinions thought regarding: NEWCONS, rc.conf and rc.d/syscons References: <53F30A81.9090302@freebsd.org> <20140821110920.fecb365dda2129e5d21c351b@ddteam.net> <53F659B0.1010602@freebsd.org> <53F8C1EF.8060703@gmail.com> In-Reply-To: <53F8C1EF.8060703@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ID: EXS5JyZbQhKHAkfmCIscAyOW2SKf2I5jUukoeE9JRr+XAkW5ZDTN3uVrZjg1-QCgso X-TOI-MSGID: 737758bb-7526-4d80-9278-3e66102b7084 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:17:27 -0000 Am 23.08.2014 um 18:31 schrieb Václav Zeman: > On 21.8.2014 22:42, Stefan Esser wrote: >> [...] >> s/^eee_nordic\./nordic.asus-eee./ >> s/^spanish\./es./ >> s/^norwegian\./es./ > > This line above looks wrong. Should there something else than "es."? Good catch! Thank you for your review! I'm now using a different approach (sh case, instead of sed), but the error had been moved over and is now fixed ;-) Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 26 10:27:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3F1C541; Tue, 26 Aug 2014 10:27:55 +0000 (UTC) Received: from mailout11.t-online.de (mailout11.t-online.de [194.25.134.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7415F354B; Tue, 26 Aug 2014 10:27:55 +0000 (UTC) Received: from fwd26.aul.t-online.de (fwd26.aul.t-online.de [172.20.26.131]) by mailout11.t-online.de (Postfix) with SMTP id DD3A51130C4; Tue, 26 Aug 2014 12:27:46 +0200 (CEST) Received: from [192.168.119.33] (XpI3pZZbohlkDj+4H43pFCr1XEPZL+aU26g19I6w3nLB1mhJZk9ZrNSjoZJbm5+gRV@[84.154.101.219]) by fwd26.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XMDya-3vQPHU0; Tue, 26 Aug 2014 12:27:44 +0200 Message-ID: <53FC611F.3030407@freebsd.org> Date: Tue, 26 Aug 2014 12:27:43 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: Re: Opinions thought regarding: NEWCONS, rc.conf and rc.d/syscons References: <53F30A81.9090302@freebsd.org> <20140824000005.GL71691@funkthat.com> In-Reply-To: <20140824000005.GL71691@funkthat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: XpI3pZZbohlkDj+4H43pFCr1XEPZL+aU26g19I6w3nLB1mhJZk9ZrNSjoZJbm5+gRV X-TOI-MSGID: 8c698db6-1ca7-4ea3-b2f3-4f127e6faddd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:27:56 -0000 Am 24.08.2014 um 02:00 schrieb John-Mark Gurney: Thank you for the review and the comments. I have prepared a patch for rc.d/syscons, which I'll post for review in a new thread. > Stefan Esser wrote this message on Tue, Aug 19, 2014 at 10:27 +0200: >> As you all probably know, 10.1 will ship with both SYSCONS and NEWCONS. >> >> I'm working keymap files for NEWCONS (translated from those in SYSCONS), >> and they'll need to be named differently than before. >> >> The SYSCONF keymap names in rc.conf will not work for NEWCONS. They >> include an encoding scheme in their name, while NEWCONS universally >> uses Unicode. >> >> There are a few points that still need to be considered for 10.1: >> >> a) Is rc.d/syscons still an appropriate name when using NEWCONS? >> (I'd leave it unchanged, but I thought I'd ask ...) > > Per compatibility, leave it names syscons until the old one is > deprecated.. No point is having two copies.... Agree. >> c) Do we expect to warn the user when he has a SYSCONS keymap name >> specified in the rc.conf "keymap" variable, while using NEWCONS? >> (This might be a good idea, at least when the default is to use >> NEWCONS and the user might not be aware of the change.) > > Yes, and then if/when syscons is removed, we remove the warning... I have that implemented. There is no warning but a message, that the keymap entry in rc.conf should be updated. >> d) Do we want to provide the user with an information regarding the >> name of the SYSCONS keymap configured, to ease the transition? >> (Could be done ...) > > Yes... Is implemented in the patch ... >> e) Do we want the rc script to translate the SYSCONS keymap name >> to its new form? (This might be good for people using foreign >> keyboards, if their password uses characters located at other >> positions than on the default keymap, that will be used if no >> valid "keymap" is specified.) > > Yes, and make sure to print out a [big] warning to have them update > their config... Hmmm, the warning is not really big, right now. This could easily be changed, but I'm afraid that it will still scroll by before the user notices it. >> f) It might be good to introduce "keymap_sc" (and/or "keymap_vt") >> as a value used in preference to "keymap" if defined and the >> corresponding console driver is detected. (An alternativ to >> e) that is easier to implement and still allows to have one >> rc.conf file that covers both SYSCONS and NEWCONS.) > > I would say no, since they are similar compatible... Yes, and with the lookup of the vt/keymaps name that matches a syscons/keymaps file, it is not much use, anyway. > The biggest issue is if someone has a custom keymap... If this > is the case, you might want to point them to a guide/your script > for converting their custom keymap... Yes, I doubt many people are > using a custom keymap, but they are probably out there... Yes, I'll add a message, that the specified keymap could not be loaded. As of now, the lookup of the vt keymap name does not consider the path specified by the user. I did not want to further complicate the code (with checks for an absolute path or whether a keymap really exists in syscons/keymaps before trying to translate the name). Let me know, if you think this should be added ... > btw, thanks for your work on bringing FreeBSD into the 21st century! It was me a pleasure to fill a small gap that had been left ;-) Best regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 26 10:50:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 208E6E0D; Tue, 26 Aug 2014 10:50:21 +0000 (UTC) Received: from mailout11.t-online.de (mailout11.t-online.de [194.25.134.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDC453759; Tue, 26 Aug 2014 10:50:20 +0000 (UTC) Received: from fwd15.aul.t-online.de (fwd15.aul.t-online.de [172.20.27.63]) by mailout11.t-online.de (Postfix) with SMTP id E807F4BF818; Tue, 26 Aug 2014 12:50:18 +0200 (CEST) Received: from [192.168.119.33] (EYMC-QZ6rhL7ALehMN9oHgCBMAlrB1xja5dGabDmua8HM57OiFKXcyRNf8jeS7JwGZ@[84.154.101.219]) by fwd15.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XMEKO-4UkdpQ0; Tue, 26 Aug 2014 12:50:16 +0200 Message-ID: <53FC6667.4090403@freebsd.org> Date: Tue, 26 Aug 2014 12:50:15 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: [PATCH] fixup and warn about syscons keymap file names used with vt Content-Type: multipart/mixed; boundary="------------050704000507080300030303" X-ID: EYMC-QZ6rhL7ALehMN9oHgCBMAlrB1xja5dGabDmua8HM57OiFKXcyRNf8jeS7JwGZ X-TOI-MSGID: c18d5481-3c39-4cbb-af07-f884d0b93211 Cc: John-Mark Gurney , =?UTF-8?B?VsOhY2xhdiBaZW1hbg==?= , Aleksandr Rybalko X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:50:21 -0000 This is a multi-part message in MIME format. --------------050704000507080300030303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The attached patch implements the following new features to aid with the transition from syscons to vt: 1) Determine whether executed under syscons or vt 2) Display the console type used in log messages 3) Warn about keymap files, that cannot be loaded 4) Suggest a compatible keymap file to use under vt, if a syscons keymap is specified in rc.conf 5) Load the suggested keymap file (may be crucial for systems first booted under vt, if the keymap is to different from the default and the name has not been updated in rc.conf before the reboot) With these patches it should be possible to test vt on a system that is configured for syscons. Please test and report any findings. I want to commit this change to head as soon as possible to make sure it will make it into 10.1 ... Regards, STefan --------------050704000507080300030303 Content-Type: text/plain; charset=windows-1252; name="rc.d_syscons-for-vt.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rc.d_syscons-for-vt.diff" SW5kZXg6IHN5c2NvbnMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzY29ucwkoUmV2aXNpb24gMjcw NjQ2KQorKysgc3lzY29ucwkoQXJiZWl0c2tvcGllKQpAQCAtNDUsMTYgKzQ1LDExOCBAQAog a2JkZGV2PS9kZXYvdHR5djAKIHZpZGRldj0vZGV2L3R0eXYwCiAKLV9zY19jb25maWc9InN5 c2NvbnMiCitfc2NfY29uZmlnPQorX3NjX2NvbnNvbGU9CiBfc2NfaW5pdGRvbmU9Citfc2Nf a2V5bWFwX21zZz0KIHNjX2luaXQoKQogewogCWlmIFsgLXogIiR7X3NjX2luaXRkb25lfSIg XTsgdGhlbgorCQlpZiBbIC16ICIke19zY19jb25zb2xlfSIgXTsgdGhlbgorCQkJaWYgWyB4 YHN5c2N0bCAtbiBrZXJuLnZ0eWAgPSB4InZ0IiBdOyB0aGVuCisJCQkJX3NjX2NvbnNvbGU9 InZ0IgorCQkJZWxzZQorCQkJCV9zY19jb25zb2xlPSJzeXNjb25zIgorCQkJZmkKKwkJCV9z Y19jb25maWc9IiR7X3NjX2NvbnNvbGV9IgorCQlmaQogCQllY2hvIC1uICJDb25maWd1cmlu ZyAke19zY19jb25maWd9OiIKIAkJX3NjX2luaXRkb25lPXllcwogCWZpCiB9CiAKKyMgc3lz Y29ucyB0byB2dCBtaWdyYXRpb24gaGVscGVyCitsb29rdXBfa2V5bWFwX2Zvcl92dCgpCit7 CisJa2V5bWFwPWBiYXNlbmFtZSAkMSAua2JkYAorCWNhc2UgJGtleW1hcCBpbgoraHkuYXJt c2NpaS04KQkJCWVjaG8gYW07OworYmUuaXNvLmFjYykJCQllY2hvIGJlLmFjYzs7CitiZS5p c28pCQkJCWVjaG8gYmU7OworYmcuYmRzLmN0cmxjYXBzKQkJZWNobyBiZy5iZHM7OworYmcu cGhvbmV0aWMuY3RybGNhcHMpCQllY2hvIGJnLnBob25ldGljOzsKK2JyMjc1Lmlzby5hY2Mp CQkJZWNobyBicjs7CiticjI3NS4qKQkJCWVjaG8gYnIubm9hY2M7OworYnkuKikJCQkJZWNo byBieTs7Citmcl9DQS5pc28uYWNjKQkJCWVjaG8gY2EtZnI7Oworc3dpc3NnZXJtYW4ubWFj Ym9vay5hY2MpCWVjaG8gY2gubWFjYm9vay5hY2M7Oworc3dpc3NnZXJtYW4uaXNvLmFjYykJ CWVjaG8gY2guYWNjOzsKK3N3aXNzZ2VybWFuLiopCQkJZWNobyBjaDs7Citzd2lzc2ZyZW5j aC5pc28uYWNjKQkJZWNobyBjaC1mci5hY2M7Oworc3dpc3NmcmVuY2guKikJCQllY2hvIGNo LWZyOzsKK2NlLmlzbzIpCQkJZWNobyBjZW50cmFsZXVyb3BlYW4ucXdlcnR5OzsKK2NvbGVt YWsuaXNvMTUuYWNjKQkJZWNobyBjb2xlbWFrLmFjYzs7Citjcy4qfGN6LiopCQkJZWNobyBj ejs7CitnZXJtYW4uaXNvLmFjYykJCQllY2hvIGRlLmFjYzs7CitnZXJtYW4uKikJCQllY2hv IGRlOzsKK2RhbmlzaC5pc28uYWNjKQkJCWVjaG8gZGsuYWNjOzsKK2RhbmlzaC5pc28ubWFj Ym9vaykJCWVjaG8gZGsubWFjYm9vazs7CitkYW5pc2guKikJCQllY2hvIGRrOzsKK2VzdG9u aWFuLiopCQkJZWNobyBlZTs7CitzcGFuaXNoLmR2b3JhaykJCQllY2hvIGVzLmR2b3Jhazs7 CitzcGFuaXNoLmlzbyouYWNjKQkJZWNobyBlcy5hY2M7Oworc3BhbmlzaC5pc28pCQkJZWNo byBlczs7CitmaW5uaXNoLiopCQkJZWNobyBmaTs7Citmci5tYWNib29rLmFjYykJCQllY2hv IGZyLm1hY2Jvb2s7OworZnIuaXNvLmFjYykJCQllY2hvIGZyLmFjYzs7Citmci5pc28pCQkJ CWVjaG8gZnI7OworZWwuaXNvMDcpCQkJZWNobyBncjs7Citnci51czEwMS5hY2MpCQkJZWNo byBnci4xMDEuYWNjOzsKK2hyLmlzbykJCQkJZWNobyBocjs7CitodS5pc28yLjEwMWtleXMp CQllY2hvIGh1LjEwMTs7CitodS5pc28yLjEwMmtleXMpCQllY2hvIGh1LjEwMjs7Citpdy5p c284KQkJCWVjaG8gaWw7OworaWNlbGFuZGljLmlzby5hY2MpCQllY2hvIGlzLmFjYzs7Citp Y2VsYW5kaWMuaXNvKQkJCWVjaG8gaXM7OworaXQuaXNvKQkJCQllY2hvIGl0OzsKK2pwLjEw NngpCQkJZWNobyBqcC5jYXBzY3RybDs7CitqcC4xMDYpCQkJCWVjaG8ganA7OworIz8/IGpw LnBjOTguaXNvKQkJZWNobyBqcC5wYzk4OzsKK2trLnB0MTU0LmlvKQkJCWVjaG8ga3ouaW87 Owora2sucHQxNTQua3N0KQkJCWVjaG8ga3oua3N0OzsKK2xhdGluYW1lcmljYW4uaXNvLmFj YykJCWVjaG8gbGF0aW5hbWVyaWNhbi5hY2M7OworbHQuaXNvNCkJCQllY2hvIGx0OzsKK25v cndlZ2lhbi5pc28pCQkJZWNobyBubzs7Citub3J3ZWdpYW4uZHZvcmFrKQkJZWNobyBuby5k dm9yYWs7OworZHV0Y2guaXNvLmFjYykJCQllY2hvIG5sOzsKK2VlZV9ub3JkaWMpCQkJZWNo byBub3JkaWMuYXN1cy1lZWU7OworcGxfUEwuZHZvcmFrKQkJCWVjaG8gcGwuZHZvcmFrOzsK K3BsX1BMLklTTzg4NTktMikJCWVjaG8gcGw7OworcHQuaXNvLmFjYykJCQllY2hvIHB0LmFj Yzs7CitwdC5pc28pCQkJCWVjaG8gcHQ7OworcnUua29pOC1yLnNoaWZ0KQkJZWNobyBydS5z aGlmdDs7CitydS5rb2k4LXIud2luKQkJCWVjaG8gcnUud2luOzsKK3J1LiopCQkJCWVjaG8g cnU7Oworc3dlZGlzaC4qKQkJCWVjaG8gc2U7Oworc2kuaXNvKQkJCQllY2hvIHNpOzsKK3Nr LmlzbzIpCQkJZWNobyBzazs7Cit0ci5pc285LnEpCQkJZWNobyB0cjs7Cit1YS5rb2k4LXUu c2hpZnQuYWx0KQkJZWNobyB1YS5zaGlmdC5hbHQ7OwordWEuKikJCQkJZWNobyB1YTs7Cit1 ay4qLWN0cmwpCQkJZWNobyB1ay5jYXBzY3RybDs7Cit1ay5kdm9yYWspCQkJZWNobyB1ay5k dm9yYWs7OwordWsuKikJCQkJZWNobyB1azs7Cit1cy5pc28uYWNjKQkJCWVjaG8gdXMuYWNj OzsKK3VzLnBjLWN0cmwpCQkJZWNobyB1cy5jdHJsOzsKK3VzLmlzbykJCQkJZWNobyB1czs7 CisgICAgZXNhYworfQorCitrYmRjb250cm9sX2xvYWRfa2V5bWFwKCkKK3sKKwllcnJtc2c9 YGtiZGNvbnRyb2wgPCAke2tiZGRldn0gLWwgJHtrZXltYXB9IDI+JjFgCisJaWYgWyAtbiAi JHtlcnJtc2d9IiAtYSAiJHtfc2NfY29uc29sZX0iID0gInZ0IiBdOyB0aGVuCisJCV9zY19r ZXltYXBfbXNnPSIke2Vycm1zZ30iCisJCWtleW1hcF92dD1gbG9va3VwX2tleW1hcF9mb3Jf dnQgJHtrZXltYXB9YAorCQlpZiBbIC1uICIke2tleW1hcF92dH0iIF07IHRoZW4KKwkJCWVy cm1zZz1ga2JkY29udHJvbCA8ICR7a2JkZGV2fSAtbCAke2tleW1hcF92dH0gMj4mMWAKKwkJ CWlmIFsgLXogIiR7ZXJybXNnfSIgXTsgdGhlbgorCQkgICAgCQlfc2Nfa2V5bWFwX21zZz0i TmV3IGtleW1hcCBuYW1lOiBJbiAvZXRjL3JjLmNvbmYgcmVwbGFjZSAna2V5bWFwPSR7a2V5 bWFwfScgYnkgJ2tleW1hcD0ke2tleW1hcF92dH0nIgorCQkJZmkKKwkJZmkKKwlmaQorfQor CiAjIGhlbHBlcgogc3lzY29uc19jb25maWd1cmVfa2V5Ym9hcmQoKQogewpAQCAtNjUsNyAr MTY3LDcgQEAKIAkJOzsKIAkqKQogCQlzY19pbml0Ci0JCWVjaG8gLW4gJyBrZXltYXAnOwlr YmRjb250cm9sIDwgJHtrYmRkZXZ9IC1sICR7a2V5bWFwfQorCQllY2hvIC1uICcga2V5bWFw JzsJa2JkY29udHJvbF9sb2FkX2tleW1hcAogCQk7OwogCWVzYWMKIApAQCAtMTM5LDEwICsy NDEsOSBAQAogCSMKIAlpZiBbIC1uICIke19zY19pbml0ZG9uZX0iIF07IHRoZW4KIAkJZWNo byAnLicKLQkJX3NjX2NvbmZpZz0ic3lzY29ucyIKKwkJX3NjX2NvbmZpZz0iJHtfc2NfY29u c29sZX0iCiAJCV9zY19pbml0ZG9uZT0KIAlmaQotCiB9CiAKIHN5c2NvbnNfcHJlY21kKCkK QEAgLTI1Niw2ICszNTcsMTIgQEAKIAlmaQogCiAJWyAtbiAiJHtfc2NfaW5pdGRvbmV9IiBd ICYmIGVjaG8gJy4nCisJaWYgWyAtbiAiJHtfc2Nfa2V5bWFwX21zZ30iIF07IHRoZW4KKwkJ ZWNobworCQllY2hvICJXQVJOSU5HOiIKKwkJZWNobyAiJHtfc2Nfa2V5bWFwX21zZ30uIgor CQllY2hvCisJZmkKIH0KIAogbG9hZF9yY19jb25maWcgJG5hbWUK --------------050704000507080300030303-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 26 03:24:48 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9B9E85D; Tue, 26 Aug 2014 03:24:48 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C31E3E7E; Tue, 26 Aug 2014 03:24:48 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id rl12so10947535iec.38 for ; Mon, 25 Aug 2014 20:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HcWYHBe7l8Th+z2gkMe7ZUMyAMcpfgaEDLFjW8NKC3U=; b=ojRIw8LoMHPp+kKmgPd0fbw7vHAzp9acSbSmBSTbkFVDRBMOwbePikw9aOTOpV/EbI LPfTVLX2pJngA4Knp6ghCI7ubvaRPcUKXtcRff40tpHoVkSvJVvPHuCeTeeeLcPhAg5T nVJ1v6zdiw5bbcnQCXQD9zr6D4WodHHmPoitCmLhITvBOCYAkLaaVagp1Jxcp/u51Vsq bptuW9zqSnQ9+hLIISlSUZyvErJZnPzjHmjJav21eYWScggsaMr9uRcWikXA0qoTr1yL Wb0fGvMWjT1XqDiDDZKXhTarVkaZOf4zG8wRDpjhTAa+GEMqW2Lp5M7A1Vpjt+dApE7u 6/uw== MIME-Version: 1.0 X-Received: by 10.43.149.200 with SMTP id kl8mr9730726icc.52.1409023487580; Mon, 25 Aug 2014 20:24:47 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.163.148 with HTTP; Mon, 25 Aug 2014 20:24:47 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Aug 2014 20:24:47 -0700 X-Google-Sender-Auth: jXoUn-Rtj787sMLPu6cw29ecYFs Message-ID: Subject: Re: How to get a mouse in vt(4) -- NEWCONS From: Kevin Oberman To: Chris H X-Mailman-Approved-At: Tue, 26 Aug 2014 11:20:41 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd hackers , freebsd current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 03:24:49 -0000 On Mon, Aug 25, 2014 at 5:54 PM, Chris H wrote: > > On Mon, 25 Aug 2014, Chris H wrote: > > > >> I also read that hw.vga.textmode is available. However sysctl > >> hw.vga.textmode returns unknown oid. > > > > It is a boot-time-only setting for loader.conf. > > > > hw.vga.textmode=1 > > > > boots in text mode. > Ahh, I see. Thank you very much, Warren, for the reply. :) > > --Chris > > But the mouse should work fine with vt(4). It does for me. You do need to run moused, though that was the case with cs(4), as well. The lack of "blink" support was just noted in the last post to this list, so we can hope to hear a bit about the status of blink soon. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 26 18:04:23 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FEA9C77; Tue, 26 Aug 2014 18:04:23 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7F7534CB; Tue, 26 Aug 2014 18:04:22 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7QI5Q1Y024844; Tue, 26 Aug 2014 11:05:32 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7QI5LcY024843; Tue, 26 Aug 2014 11:05:21 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from unavailable01.ultimatedns.net ([209.180.214.227]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Tue, 26 Aug 2014 11:05:21 -0700 (PDT) Message-ID: Date: Tue, 26 Aug 2014 11:05:21 -0700 (PDT) Subject: did tar(1) loose xz compression support in 11? From: "Chris H" To: "freebsd current" , "freebsd hackers" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 18:04:23 -0000 Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? Thank you for all your time, and consideration. --Chris From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 27 02:10:09 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EACE49CB for ; Wed, 27 Aug 2014 02:10:09 +0000 (UTC) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD3223EF5 for ; Wed, 27 Aug 2014 02:10:09 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id eu11so24541913pac.3 for ; Tue, 26 Aug 2014 19:10:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Miekn/tUYH0H2poIjublzIQoSisZ6XlDR/Mp1T2D/yo=; b=boGejeRJrGHWG+k0LvrjCC0/5kCpXRDZMsQuhhCR4jxwlWDx+47uuqOCtN1UU30xsR AM8lr5X4gw3nYwEHmldXHdUvkna1ZiUanjjtpheRuKFciBFPbWlqXW+RILmv5mADpAZk qeo2mr85QgBEp3BPZ9wouQ6lBQo7zvsPyLEWi/RR8sL8+PEDps+isvqkhwsFULXRUgRD xqZgj15b3tUfdliw4sVpMJyjQW4DjUx72FCcfBS65H38a73gjg2R5Zh07gN4Yf/HiUmb p3gDZqu7ZkivkLfwgAwgMQMpnkfSfp96AVPRjxrjY3HyL6ptajn0cmU1Y+J0OOc2AmDV w6Ug== X-Gm-Message-State: ALoCoQl7PXlQM5vDhGvpwUKoyiJSGuE95hE2AAw5nv1srOaTs3g25+UiNrhR0k3uZ5cSHPdleLWR X-Received: by 10.70.103.42 with SMTP id ft10mr13305856pdb.2.1409105403746; Tue, 26 Aug 2014 19:10:03 -0700 (PDT) Received: from [192.168.1.100] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by mx.google.com with ESMTPSA id ow2sm7199738pdb.27.2014.08.26.19.10.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Aug 2014 19:10:02 -0700 (PDT) Subject: Re: did tar(1) loose xz compression support in 11? Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle X-Priority: 3 (Normal) In-Reply-To: Date: Tue, 26 Aug 2014 19:10:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com> References: To: Chris H X-Mailer: Apple Mail (2.1878.6) Cc: freebsd hackers , freebsd current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 02:10:10 -0000 On Aug 26, 2014, at 11:05 AM, Chris H wrote: > Greetings, > I'm currently testing 11. My build / install is from about 2 days ago. > I generally use xz compression, when creating archives. But when I > attempt the following: >=20 > tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file >=20 > it returns the following: >=20 > tar: Undefined option: `xz:9' >=20 > This has always worked in previous versions. Has the syntax changed, > and the man(1) pages just haven't caught up? I can=92t see any evidence in libarchive=92s source that this ever = worked. However, there was some work done recently to improve error reporting = from the options processor. It=92s quite possible that =97options xz:9 = used to just be ignored and now it=92s reporting an error. Tim From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 27 05:51:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C898ACD for ; Wed, 27 Aug 2014 05:51:51 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1B93601 for ; Wed, 27 Aug 2014 05:51:50 +0000 (UTC) Received: from seabiscuit.panasas.com ([172.17.132.204]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 27 Aug 2014 01:51:49 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Tue, 26 Aug 2014 22:51:48 -0700 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" Subject: OT: testing... Thread-Topic: testing... Thread-Index: AQHPwbr9nZC5RFc0uUK9emdQN7IXKQ== Date: Wed, 27 Aug 2014 05:51:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.17.28.63] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Aug 2014 05:51:49.0400 (UTC) FILETIME=[FE721180:01CFC1BA] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 05:51:51 -0000 Sorry for the spam; I've been having trouble getting through to the list, so I'm trying a test message... -Ravi From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 27 06:35:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04C9F5F2; Wed, 27 Aug 2014 06:35:27 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id A03473977; Wed, 27 Aug 2014 06:35:26 +0000 (UTC) Received: from seabiscuit.panasas.com ([172.17.132.204]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Wed, 27 Aug 2014 02:35:25 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Tue, 26 Aug 2014 23:35:24 -0700 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" , Ryan Stone , Brooks Davis Subject: Re: Common storage of original MAC address Thread-Topic: Common storage of original MAC address Thread-Index: AQHPwcEUUBEgYXTq+ky03AEN5pUz3Q== Date: Wed, 27 Aug 2014 06:35:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.17.28.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <0DE418FD87153B47B67C1DB827ECCCD8@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Aug 2014 06:35:25.0773 (UTC) FILETIME=[15ECE7D0:01CFC1C1] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 06:35:27 -0000 -----Original Message----- From: , Ravi Pokala Date: Monday, August 18, 2014 at 10:19 PM To: Ryan Stone Cc: Brooks Davis , "freebsd-hackers@freebsd.org" Subject: Re: Common storage of original MAC address > -----Original Message----- > From: Ryan Stone > Date: Monday, August 18, 2014 at 11:14 AM > To: Ravi Pokala > Cc: Brooks Davis , "freebsd-hackers@freebsd.org" > > Subject: Re: Common storage of original MAC address >=20 >> On Mon, Aug 18, 2014 at 11:59 AM, Pokala, Ravi >> wrote: >>=20 >>> ... >>=20 >> Personally I think that it would be better to save it in binary format >> and convert it to a string as needed. >=20 > I'm fine with that too; the reason I suggested a string is because that's > what's already getting passed to ether_ifattach(). I suppose it's easy > enough to run the string through ether_aton() to get the binary version. Actually, it turns out ether_aton() is defined in ... but only for userspace. But that's okay - the 'lla' passed to ether_ifattach() isn't a string, it's a byte array; I mis-read it. So, a simple bcopy() DTRT. > But again, not everything is Ethernet, so we might need to have different > binary representations; if we're doing that, we might as well just use > the string version, and let the caller decide how to parse the string. > (I'm specifically thinking about IP-over-Infiniband - while I'm sure IB > cards must have some type of hardware address, it's probably not the same > format as an Ethernet MAC address.) I was right and wrong - the IB hardware address format is different from the Ethernet MAC address format: sys/ofed/drivers/net/mlx4/mlx4_en.h 485 struct mlx4_en_priv { ... 524 u64 mac; But the OFED driver maps the IB hardware address to an Ethernet MAC address: sys/ofed/drivers/net/mlx4/en_netdev.c: mlx4_en_init_netdev() ... 1530 struct mlx4_en_priv *priv; 1531 uint8_t dev_addr[ETHER_ADDR_LEN]; ... 1642 /* Set default MAC */ 1643 for (i =3D 0; i < ETHER_ADDR_LEN; i++) 1644 dev_addr[ETHER_ADDR_LEN - 1 - i] =3D (u8) (priv->mac >> (8 * i)= ); 1645 1646 ether_ifattach(dev, dev_addr); So just using a 'struct ether_addr' seems to be fine. >> It would be useful to have the MAC address saved aside somewhere so that >> a "Restore MAC to HW default" ioctl could be implemented; this would be >> useful in the if_lagg driver to restore the MAC on a port after it has >> been removed from a lagg. Doesn't this restore the original MAC on LAGG teardown? sys/net/if_lagg.c: lagg_port_destroy() 729 /* 730 * Remove multicast addresses and interface flags from this port and 731 * reset the MAC address, skip if the interface is being detached. 732 */ 733 if (!lp->lp_detaching) { 734 lagg_ether_cmdmulti(lp, 0); 735 lagg_setflags(lp, 0); 736 lagg_port_lladdr(lp, lp->lp_lladdr); 737 } If someone can enumerate the places where we want to restore the original LLADDR but currently don't, then I'll add that. > Or how about an ioctl to get the original MAC (rather than a sysctl). > Then the "restore to default" code would be a two-step process - get the > original MAC with the new ioctl (say "SIOCGHWLLADDR" for "Get Hardware > LLADDR"?), and then set the working MAC to that value w/ the existing > ioctl (SIOCSIFLLADDR). >=20 > I actually like this idea more than the sysctl, because it could be done > in one place (probably in net/if.c, next to if_setlladdr() (which is what > implements the guts of SIOCSIFLLADDR)). I've done the easy stuff - added the field to 'struct arpcom', populated it, added the ioctl and a function to implement it, and created a simple test program. See the patch and test code (at end of message); the test output: root@fbsd-X:~ # ifconfig em1 ether em1: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 08:00:27:f0:8f:8a root@fbsd-X:~ # ./ghwlladdr-test em1 em1 current lladdr: 08:00:27:f0:8f:8a em1 hardware lladdr: 08:00:27:f0:8f:8a root@fbsd-X:~ # ifconfig em1 ether 12:34:56:78:9a:bc root@fbsd-X:~ # ifconfig em1 ether em1: flags=3D8802 metric 0 mtu 1500 options=3D9b ether 12:34:56:78:9a:bc root@fbsd-X:~ # ./ghwlladdr-test em1 em1 current lladdr: 12:34:56:78:9a:bc em1 hardware lladdr: 08:00:27:f0:8f:8a > Does that sound like a plan? If what I've done so far looks good, I'll continue to the next steps: changing the places where we want to auto-restore the HW LLADDR (see my question above), and updating `ifconfig' to report and restore the HW LLADDR. Thanks, Ravi --------------------------- ghwlladdr.patch ---------------------------- Index: sys/net/if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if.c (revision 270646) +++ sys/net/if.c (working copy) @@ -2480,6 +2480,10 @@ EVENTHANDLER_INVOKE(iflladdr_event, ifp); break; + case SIOCGHWLLADDR: + error =3D if_gethwlladdr(ifp, ifr); + break; + case SIOCAIFGROUP: { struct ifgroupreq *ifgr =3D (struct ifgroupreq *)ifr; @@ -3353,6 +3357,33 @@ } /* + * Get the link layer address that was read from the hardware at probe. + * + * At this time we only support certain types of interfaces. + */ +int +if_gethwlladdr(struct ifnet *ifp, struct ifreq *ifr) +{ + switch (ifp->if_type) { + case IFT_ETHER: + case IFT_FDDI: + case IFT_XETHER: + case IFT_ISO88025: + case IFT_L2VLAN: + case IFT_BRIDGE: + case IFT_ARCNET: + case IFT_IEEE8023ADLAG: + case IFT_IEEE80211: + bcopy(&IFP2AC(ifp)->hw_lladdr, ifr->ifr_addr.sa_data, ETHER_ADDR_LEN); + ifr->ifr_addr.sa_len =3D ETHER_ADDR_LEN; + break; + default: + return (ENODEV); + } + return (0); +} + +/* * The name argument must be a pointer to storage which will last as * long as the interface does. For physical devices, the result of * device_get_name(dev) is a good choice and for pseudo-devices a Index: sys/net/if_arp.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if_arp.h (revision 270646) +++ sys/net/if_arp.h (working copy) @@ -102,9 +102,11 @@ * Structure shared between the ethernet driver modules and * the address resolution code. */ +#include struct arpcom { struct ifnet *ac_ifp; /* network-visible interface */ void *ac_netgraph; /* ng_ether(4) netgraph node info */ + struct ether_addr hw_lladdr; /* original lladdr from hardware */ }; #define IFP2AC(ifp) ((struct arpcom *)(ifp->if_l2com)) #define AC2IFP(ac) ((ac)->ac_ifp) Index: sys/net/if_ethersubr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if_ethersubr.c (revision 270646) +++ sys/net/if_ethersubr.c (working copy) @@ -841,6 +841,7 @@ sdl->sdl_type =3D IFT_ETHER; sdl->sdl_alen =3D ifp->if_addrlen; bcopy(lla, LLADDR(sdl), ifp->if_addrlen); + bcopy(lla, &IFP2AC(ifp)->hw_lladdr, ifp->if_addrlen); bpfattach(ifp, DLT_EN10MB, ETHER_HDR_LEN); if (ng_ether_attach_p !=3D NULL) Index: sys/net/if_var.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if_var.h (revision 270646) +++ sys/net/if_var.h (working copy) @@ -485,6 +485,7 @@ void if_ref(struct ifnet *); void if_rele(struct ifnet *); int if_setlladdr(struct ifnet *, const u_char *, int); +int if_gethwlladdr(struct ifnet *, struct ifreq *); void if_up(struct ifnet *); int ifioctl(struct socket *, u_long, caddr_t, struct thread *); int ifpromisc(struct ifnet *, int); Index: sys/sys/sockio.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/sys/sockio.h (revision 270646) +++ sys/sys/sockio.h (working copy) @@ -96,6 +96,7 @@ #define SIOCGIFSTATUS _IOWR('i', 59, struct ifstat) /* get IF status */ #define SIOCSIFLLADDR _IOW('i', 60, struct ifreq) /* set linklevel addr */ +#define SIOCGHWLLADDR _IOWR('i', 61, struct ifreq) /* get hw lladdr */ #define SIOCSIFPHYADDR _IOW('i', 70, struct ifaliasreq) /* set gif addres */ #define SIOCGIFPSRCADDR _IOWR('i', 71, struct ifreq) /* get gif psrc addr */ --------------------------- ghwlladdr-test.c --------------------------- #include #include #include #include #include #include #include #include #include #include #include #include int main( int argc, char **argv) { char *ifname =3D NULL; struct ifaddrs *ifap =3D NULL; struct ifaddrs *ifa =3D NULL; struct sockaddr_dl *sdl =3D NULL; struct ifreq ifr; int sock =3D -1; int error =3D 0; if (argc !=3D 2) { printf("usage: %s \n", argv[0]); error =3D 1; goto cleanup; } ifname =3D argv[1]; error =3D getifaddrs(&ifap); if (error !=3D 0) { error =3D errno; printf("getifaddrs(): %d (%s)\n", error, strerror(error)); goto cleanup; } for (ifa =3D ifap; ifa; ifa =3D ifa->ifa_next) { if (strcmp(ifa->ifa_name, ifname) =3D=3D 0) { sdl =3D (struct sockaddr_dl *) ifa->ifa_addr; printf("%s current lladdr: %s\n", ifname, ether_ntoa((struct ether_addr *) LLADDR(sdl))); break; } } strncpy(ifr.ifr_name, ifa->ifa_name, sizeof(ifr.ifr_name)); memcpy(&ifr.ifr_addr, ifa->ifa_addr, sizeof(ifa->ifa_addr->sa_len)); ifr.ifr_addr.sa_family =3D AF_LOCAL; sock =3D socket(ifr.ifr_addr.sa_family, SOCK_DGRAM, 0); if (sock =3D=3D -1) { error =3D errno; printf("socket(): %d (%s)\n", error, strerror(error)); goto cleanup; } error =3D ioctl(sock, SIOCGHWLLADDR, &ifr); if (error =3D=3D -1) { printf("ioctl(): %d (%s)\n", error, strerror(error)); goto cleanup; } printf("%s hardware lladdr: %s\n", ifname, ether_ntoa((const struct ether_addr *) &ifr.ifr_addr.sa_data)); cleanup: if (sock !=3D -1) { close(sock); } return error; } ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 27 14:01:26 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBC9DE80; Wed, 27 Aug 2014 14:01:25 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B54C83568; Wed, 27 Aug 2014 14:01:25 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s7RE2WEm009331; Wed, 27 Aug 2014 07:02:39 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s7RE2Q1r009324; Wed, 27 Aug 2014 07:02:26 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Wed, 27 Aug 2014 07:02:27 -0700 (PDT) Message-ID: In-Reply-To: <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com> References: <134A4303-3421-4A7B-9EB6-74D58B939217@kientzle.com> Date: Wed, 27 Aug 2014 07:02:27 -0700 (PDT) Subject: Re: did tar(1) loose xz compression support in 11? From: "Chris H" To: "Tim Kientzle" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd hackers , freebsd current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 14:01:26 -0000 > > On Aug 26, 2014, at 11:05 AM, Chris H wrote: > >> Greetings, >> I'm currently testing 11. My build / install is from about 2 days ago. >> I generally use xz compression, when creating archives. But when I >> attempt the following: >> >> tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file >> >> it returns the following: >> >> tar: Undefined option: `xz:9' >> >> This has always worked in previous versions. Has the syntax changed, >> and the man(1) pages just haven't caught up? > > I can’t see any evidence in libarchive’s source that this ever worked. > > However, there was some work done recently to improve error reporting from the options > processor. It’s quite possible that —options xz:9 used to just be ignored and now it’s > reporting an error. > > Tim On a hunch. I performed a similar test. I added STAGE to the following port. So I'll test here. # tar -cvJ --options xz:9 -f posadis-xz9.tar.xz ./posadis/ a ./posadis a ./posadis/files a ./posadis/pkg-plist a ./posadis/Makefile a ./posadis/distinfo a ./posadis/pkg-descr a ./posadis/files/patch-Makefile.in a ./posadis/files/patch-configure.in # tar -cvJ --options xz:1 -f posadis-xz1.tar.xz ./posadis/ a ./posadis a ./posadis/files a ./posadis/pkg-plist a ./posadis/Makefile a ./posadis/distinfo a ./posadis/pkg-descr a ./posadis/files/patch-Makefile.in a ./posadis/files/patch-configure.in unlike the previous examples, and arguments. I used the v switch. Presuming that would provide feedback on any anomalous usage. However. The following proves otherwise: # ls -la -rw-r--r-- 1 root wheel 2380 Aug 27 06:47 posadis-xz1.tar.xz -rw-r--r-- 1 root wheel 2380 Aug 27 06:47 posadis-xz9.tar.xz (performed on a RELENG_9 box) As one can see, nothing (compression level(s)) were UNchanged. So the verdict is in; the _recent_ changes provide the needed feedback where anomalous usage is concerned. Short version; tar now works correctly -- it's fixed. :) Humble opinion; the man(1) pages could be somewhat more concise. Humble request; would it be possible to make [bsd]tar(1) honor the short-hand version of options? Thank you, Tim, and everyone else, for all your thoughtful replies. --Chris > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 27 19:07:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B7CD771 for ; Wed, 27 Aug 2014 19:07:44 +0000 (UTC) Received: from mail.choopa.net (mail.choopa.net [216.155.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 416903C7C for ; Wed, 27 Aug 2014 19:07:43 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by mail.choopa.net (iRedMail) with ESMTP id 761674AF416 for ; Wed, 27 Aug 2014 15:02:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.choopa.net Received: from mail.choopa.net ([127.0.0.1]) by localhost (mail.choopa.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08WYFgH5s4uR for ; Wed, 27 Aug 2014 15:02:16 -0400 (EDT) Received: from [10.5.5.117] (office-nat.choopa.net [208.167.225.40]) by mail.choopa.net (iRedMail) with ESMTPSA id 59A6F4AF3E7 for ; Wed, 27 Aug 2014 15:02:16 -0400 (EDT) Message-ID: <53FE2B37.7050309@gameservers.com> Date: Wed, 27 Aug 2014 15:02:15 -0400 From: Brian Rak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Bug in FreeBSD VirtIO network driver (only with pf enabled) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 19:07:44 -0000 I have a FreeBSD 10 x64 guest installed inside a KVM instance on Linux. When pf is active, and the server is sending data it causes the Linux host to report warnings related to GSO. I've talked to some Linux developers, and they believe it to be a bug inside the FreeBSD VirtIO drivers. Based on what I'm seeing, I'm inclined to agree with them. Reproduction is mildly annoying, you need: 1) A KVM guest setup with bridged networking, with FreeBSD running side using the VirtIO network interface. (We tested with CentOS, but the exact distribution should not matter) 2) pf enabled (I'm using a single rule: "scrub in all") 3) Some method of sending a bit of traffic from the guest (I use netcat) So, when I do this: # service pf start # cat /root/test | nc vultr.com 80 The Linux kernel on the host will report: kernel: WARNING: CPU: 7 PID: 7772 at net/core/dev.c:2246 skb_warn_bad_offload+0xc3/0xd0() kernel: igb: caps=(0x0000000640114bb3, 0x0000000000000000) len=1498 data_len=0 gso_size=1380 gso_type=5 ip_summed=0 If I do: # service pf stop # cat /root/test | nc vultr.com 80 No such warning is reported. I can only reproduce this with pf enabled. The contents of the /root/test don't matter, I'm using 4k of data from /dev/urandom. The test file just needs to be bigger then the MTU of the host's network interface. I was able to track this down to the virtio_net_hdr being sent by the FreeBSD guest. With pf enabled, this outbound traffic has the following header: flags = 0 gso_type = VIRTIO_NET_HDR_GSO_TCPV4 hdr_len = 66 gso_size = 1440 csum_start = 0 csum_offset = 0 But, this is not a valid configuration. With VIRTIO_NET_HDR_GSO_TCPV4 enabled, you should also be setting VIRTIO_NET_HDR_F_NEEDS_CSUM and populating the csum_start and csum_offset fields. http://www.spinics.net/lists/netdev/msg293976.html gives more detail on this. I don't fully understand this, so I'd probably mangle the explanation if I tried to give more detail. I can reproduce this at will now, but fixing it is beyond my abilities. Is there a better place to report this? I'm not entirely sure who is responsible for maintaining the virtio driver. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 27 19:29:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2068944C; Wed, 27 Aug 2014 19:29:47 +0000 (UTC) Received: from webmail2.jnielsen.net (webmail2.jnielsen.net [50.114.224.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "webmail2.jnielsen.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F13143F42; Wed, 27 Aug 2014 19:29:46 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by webmail2.jnielsen.net (8.14.9/8.14.9) with ESMTP id s7RJQ6pl080635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Aug 2014 13:26:09 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail2.jnielsen.net: Host office.betterlinux.com [199.58.199.60] claimed to be [10.10.1.198] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Bug in FreeBSD VirtIO network driver (only with pf enabled) From: John Nielsen In-Reply-To: <53FE2B37.7050309@gameservers.com> Date: Wed, 27 Aug 2014 13:26:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <13EFC786-FFFB-479A-A65F-F33B07A78B9F@jnielsen.net> References: <53FE2B37.7050309@gameservers.com> To: Brian Rak , Bryan Venteicher X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.4 at webmail2.jnielsen.net X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 19:29:47 -0000 The virtio maintainer is bryanv (CC'ed). I have KVM+CentOS hosts available at $WORK so let me know if anyone = needs help reproducing this or testing fixes. On Aug 27, 2014, at 1:02 PM, Brian Rak wrote: > I have a FreeBSD 10 x64 guest installed inside a KVM instance on = Linux. When pf is active, and the server is sending data it causes the = Linux host to report warnings related to GSO. >=20 > I've talked to some Linux developers, and they believe it to be a bug = inside the FreeBSD VirtIO drivers. Based on what I'm seeing, I'm = inclined to agree with them. >=20 > Reproduction is mildly annoying, you need: > 1) A KVM guest setup with bridged networking, with FreeBSD running = side using the VirtIO network interface. (We tested with CentOS, but = the exact distribution should not matter) > 2) pf enabled (I'm using a single rule: "scrub in all") > 3) Some method of sending a bit of traffic from the guest (I use = netcat) >=20 > So, when I do this: >=20 > # service pf start > # cat /root/test | nc vultr.com 80 >=20 > The Linux kernel on the host will report: >=20 > kernel: WARNING: CPU: 7 PID: 7772 at net/core/dev.c:2246 = skb_warn_bad_offload+0xc3/0xd0() > kernel: igb: caps=3D(0x0000000640114bb3, 0x0000000000000000) len=3D1498 = data_len=3D0 gso_size=3D1380 gso_type=3D5 ip_summed=3D0 >=20 > If I do: >=20 > # service pf stop > # cat /root/test | nc vultr.com 80 >=20 > No such warning is reported. I can only reproduce this with pf = enabled. The contents of the /root/test don't matter, I'm using 4k of = data from /dev/urandom. The test file just needs to be bigger then the = MTU of the host's network interface. >=20 > I was able to track this down to the virtio_net_hdr being sent by the = FreeBSD guest. With pf enabled, this outbound traffic has the following = header: >=20 > flags =3D 0 > gso_type =3D VIRTIO_NET_HDR_GSO_TCPV4 > hdr_len =3D 66 > gso_size =3D 1440 > csum_start =3D 0 > csum_offset =3D 0 >=20 > But, this is not a valid configuration. With VIRTIO_NET_HDR_GSO_TCPV4 = enabled, you should also be setting VIRTIO_NET_HDR_F_NEEDS_CSUM and = populating the csum_start and csum_offset fields. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 04:43:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECA47949 for ; Thu, 28 Aug 2014 04:43:43 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B65431C24 for ; Thu, 28 Aug 2014 04:43:43 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rl12so320034iec.29 for ; Wed, 27 Aug 2014 21:43:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=M3IaTfEcwc50SyGhE6LYcVZ4d4horODSwO4RSl47DEQ=; b=IV0JZPPqzPNQ6sNMduh5IZ0g964u//COai5aY1nRVfJJgPP03zJhOqVJRwzYdzggPd 1/QBXG49oWAOg8lv8uHXsobFk52iEhitUoQLey44KNM6y6raiT66Y/uxp6OrwNpPywxX iKIKk/GEbFWgbHAwLvJj3sbJdjhHiWFQ7QXfy3m20ZQPat6dav/Yclb4ElGZaB7G+CbH DMSS/TWebFc3bEKemit1cTohl+QhqU/rezTYeatoO7pQOXTQnN3y5EmV4OEfowJwa6aa UamaDkJMxHRlRIJW4m5mVCnhMzqfQcWNFUcre+wSJQRnmZp4U9sZdea9MW0H23mzSAIU X7EA== X-Gm-Message-State: ALoCoQn0mKPHysfmAhaC48GN7tYLIHU2hgV3sTfzrD/iuIfpN5H6d/Qf2mdxXtAaVh/INy4cL19j X-Received: by 10.42.67.133 with SMTP id t5mr2172398ici.62.1409200538167; Wed, 27 Aug 2014 21:35:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.29.20 with HTTP; Wed, 27 Aug 2014 21:35:17 -0700 (PDT) X-Originating-IP: [72.177.8.109] In-Reply-To: <53FE2B37.7050309@gameservers.com> References: <53FE2B37.7050309@gameservers.com> From: Bryan Venteicher Date: Wed, 27 Aug 2014 23:35:17 -0500 Message-ID: Subject: Re: Bug in FreeBSD VirtIO network driver (only with pf enabled) To: Brian Rak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 04:43:44 -0000 On Wed, Aug 27, 2014 at 2:02 PM, Brian Rak wrote: > I have a FreeBSD 10 x64 guest installed inside a KVM instance on Linux. > When pf is active, and the server is sending data it causes the Linux hos= t > to report warnings related to GSO. > > I've talked to some Linux developers, and they believe it to be a bug > inside the FreeBSD VirtIO drivers. Based on what I'm seeing, I'm incline= d > to agree with them. > > Reproduction is mildly annoying, you need: > 1) A KVM guest setup with bridged networking, with FreeBSD running side > using the VirtIO network interface. (We tested with CentOS, but the exac= t > distribution should not matter) > 2) pf enabled (I'm using a single rule: "scrub in all") > 3) Some method of sending a bit of traffic from the guest (I use netcat) > > So, when I do this: > > # service pf start > # cat /root/test | nc vultr.com 80 > > The Linux kernel on the host will report: > > kernel: WARNING: CPU: 7 PID: 7772 at net/core/dev.c:2246 > skb_warn_bad_offload+0xc3/0xd0() > kernel: igb: caps=3D(0x0000000640114bb3, 0x0000000000000000) len=3D1498 > data_len=3D0 gso_size=3D1380 gso_type=3D5 ip_summed=3D0 > > If I do: > > # service pf stop > # cat /root/test | nc vultr.com 80 > > No such warning is reported. I can only reproduce this with pf enabled. > The contents of the /root/test don't matter, I'm using 4k of data from > /dev/urandom. The test file just needs to be bigger then the MTU of the > host's network interface. > > I was able to track this down to the virtio_net_hdr being sent by the > FreeBSD guest. With pf enabled, this outbound traffic has the following > header: > > flags =3D 0 > gso_type =3D VIRTIO_NET_HDR_GSO_TCPV4 > hdr_len =3D 66 > gso_size =3D 1440 > csum_start =3D 0 > csum_offset =3D 0 > > But, this is not a valid configuration. With VIRTIO_NET_HDR_GSO_TCPV4 > enabled, you should also be setting VIRTIO_NET_HDR_F_NEEDS_CSUM and > populating the csum_start and csum_offset fields. > > =E2=80=8BIt would appear that somewhere in pf the CSUM_TCP flag is getting = clear for CSUM_TSO packets. I don't believe the stack otherwise sets CSUM_TSO without CSUM_TCP. Now, it is probably safe to assume CSUM_TCP when CSUM_TSO is set: the mbuf's m_pkthdr.csum_data better be valid in such cases though. > http://www.spinics.net/lists/netdev/msg293976.html gives more detail on > this. I don't fully understand this, so I'd probably mangle the > explanation if I tried to give more detail. I can reproduce this at will > now, but fixing it is beyond my abilities. Is there a better place to > report this? I'm not entirely sure who is responsible for maintaining th= e > virtio driver. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 06:21:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB3A0FE3 for ; Thu, 28 Aug 2014 06:21:32 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B250414F0 for ; Thu, 28 Aug 2014 06:21:32 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id et14so1219389pad.2 for ; Wed, 27 Aug 2014 23:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=KdvTiZT+hEOiKCMvPxxJ3Y4hR1bpPfXWS427p7VKh2s=; b=VAxVxwf8TOpLtMqFCRCTV7MrGAQAuk/U0G5v0jeALjX0cdji0h8zcuaytrZ7bfD9Ek kP0+zyxbozsQlbymfL3Z/3vqKOulfqyEJIQ9ZsEJN8a6vKEq4qkJi/bv+8xiRpfpkTRP wiUwYIznHEdmbSWpw8J3HlWe6D6mr5sF9dvoQ/VD3fzKdDNnmjVJrbTkqeBotPrTkaze PqSM/aN5XfAjYvdSpe6+MV7bqWmulQLaI74+Krhd0X4BMF5btS9hzMYRkJJERA17aHN/ ZM/SJdIGoS3/2iSNFF80gzOtJlyh/G7tH0ZraYb5HjxFXJcNso3wjm16lP7+LWt+BwKA VM8g== X-Received: by 10.70.131.12 with SMTP id oi12mr2634995pdb.116.1409206890651; Wed, 27 Aug 2014 23:21:30 -0700 (PDT) Received: from [10.240.140.110] ([123.58.191.68]) by mx.google.com with ESMTPSA id b4sm3834340pdh.21.2014.08.27.23.21.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Aug 2014 23:21:30 -0700 (PDT) From: Chenguang Li Content-Type: text/plain; charset="utf8"; Content-Transfer-Encoding: 8bit X-Pgp-Agent: GPGMail (null) Subject: On changing rand(3) to random(3) in awk(1) Message-Id: Date: Thu, 28 Aug 2014 14:21:10 +0800 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 06:21:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Below is a summary of my previous posts to freebsd-questions: Since the original rand(3) could not provide a fair, "one-shot" randomness in awk(1), I am writing this to suggest that we change *rand(3) to *random(3), which only requires modifying a few lines of code[1], but will result in better random number generation. BTW, OSX & gawk already have this. Previous discussion can be found here[2]. What do you think? [1] My quick patch: https://gist.github.com/horus/03c3d7c17703536033c1 [2] https://lists.freebsd.org/pipermail/freebsd-questions/2014-August/260534.html Chenguang Li -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT/spWAAoJELG4cS+11lRhDp8QAMY6p/qdZNkhSQw0wlYKRCES KlcD9uGpNKnfN/Y+ihMnMYK/xZg7YO4DbxSSUNEW4z5gcI53W8TxkZJuvO68GCMj oNTxgpEl1OCmYAVNWxklyGvMp5YvEWpUrKkhWSPcB+JKS0s4QQuPGwidXfFEBq2n aS2dIZW5KhSzdx3PZ9qa81fxmB4uDHuw7wVxh4UWrvEbOe9BHQWbIGV9LIn30cLt 3VKmxk+WBdPTCF1Z+Jttrv7snU8oloNbGZXYX7FQBD+MlmPEWFSulSXoav3xT127 +9pKXCy9NpFem7lb+pEYyZ9XwAWp+xicNBNeIk0vG4G1lIllVx10qBDB5Gmqdtq8 OoZBVb4bhDDlWI7VsNzmbXQJOE8d0qpHKAeU7bNzbrbW/E9Zh4KytXho2tgigiMw htY6ljGXee2J4hH8NJ2+WewnTDJM/v1EHz6MWxjpdw25jiGJCuwuVxa03buuOvNa ZPLXpp+9UG48TxIeXbb2pDxGjKD+rIiA9K4bwK2888Of6tyANex9kNdLYnpxRejP VZzP2erTfF6xQY/9W3R2JigzR9ZsTsPJXBcQTf2bBO+9wUENh5ugF/Mna/mwaKf5 c0BmAW7IGqKCbbXY3y8tZvAHu5z2j826WQRvaXr3hjXM1ACRq1PyBR8mMlgM/yG+ /t/et/A01N3FoD4VOUJk =ihl+ -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 09:52:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D6E6287 for ; Thu, 28 Aug 2014 09:52:04 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04CF61B71 for ; Thu, 28 Aug 2014 09:52:03 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id s7so591254lbd.35 for ; Thu, 28 Aug 2014 02:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=IUo6KO4D0nNltf5t+2lFUdHjezC0zljQwVX/e2iDam8=; b=uyjOi1Ib453ZEzZcIROAUyR7ZQPRJb1HgeOnDefaNwwvV48xJ3gKeYy1ESB1uSTprs pHy2vsLXH1UwvDVJnziDIRDGvFTBGV8nhbn0K2Z92itydQvNKim/A3yS+0pB1A72FWIJ UKz3/MqX3UACumaJFAt4Hv8yYk+HZH4BcLIYnzbI89psSSBjntT/vdlne30ThzBcWTBs SGdT4ZeFhAcV/koyQ3L8ByLrx1pb13H+kmPqDuSh1oGTvmD1GdEja9Vth44aYnjr+5ls c8nHNiPOOSylIdxBfo+Ty75K+3uXL68SkmuEzwD0IW5kGhBHf+Z+SL17ioWyaj4fYoAS Pd1g== X-Received: by 10.152.45.101 with SMTP id l5mr3162489lam.20.1409219521995; Thu, 28 Aug 2014 02:52:01 -0700 (PDT) Received: from [172.29.2.131] (altimet-gw.cs2.dp.wnet.ua. [217.20.178.249]) by mx.google.com with ESMTPSA id xc7sm5151680lbb.21.2014.08.28.02.52.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Aug 2014 02:52:01 -0700 (PDT) Message-ID: <53FEFBB8.5040305@gmail.com> Date: Thu, 28 Aug 2014 12:51:52 +0300 From: Vitaly Magerya User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Chenguang Li , freebsd-hackers@freebsd.org Subject: Re: On changing rand(3) to random(3) in awk(1) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 09:52:04 -0000 On 2014-08-28 09:21, Chenguang Li wrote: > Since the original rand(3) could not provide a fair, "one-shot" randomness in awk(1), > I am writing this to suggest that we change *rand(3) to *random(3), which only requires > modifying a few lines of code[1], but will result in better random number generation. > BTW, OSX & gawk already have this. Previous discussion can be found here[2]. > > What do you think? I think this is a useful change; in particular, srandom(3) seems to do a much better job of coping with sequential seeds than srand(3), which solves a big problem with using 'srand' in our awk. > Index: main.c > =================================================================== > --- main.c (revision 270740) > +++ main.c (working copy) > @@ -74,7 +74,7 @@ > signal(SIGFPE, fpecatch); > > srand_seed = 1; > - srand(srand_seed); > + srandom(srand_seed); > > yyin = NULL; > symtab = makesymtab(NSYMTAB/NSYMTAB); > Index: run.c > =================================================================== > --- run.c (revision 270740) > +++ run.c (working copy) > @@ -1522,7 +1522,7 @@ > break; > case FRAND: > /* in principle, rand() returns something in 0..RAND_MAX */ > - u = (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; > + u = (Awkfloat) (random() % RAND_MAX) / RAND_MAX; You should not use RAND_MAX with random(3), since it returns values between 0 and 0x7fffffff (inclusive); RAND_MAX only applies to rand(3). A better patch would be something like this: > - /* in principle, rand() returns something in 0..RAND_MAX */ > - u = (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; > + /* random() returns values in [0, 2147483647] */ > + u = (Awkfloat) random() / 2147483648; Also, awk(1) man page should be updated; it currently says: > rand random number on (0,1) ... while it should say: > rand random number on [0,1) > break; > case FSRAND: > if (isrec(x)) /* no argument provided */ > @@ -1530,7 +1530,7 @@ > else > u = getfval(x); > tmp = u; > - srand((unsigned int) u); > + srandom((unsigned int) u); You should probably use 'unsigned long' here. > u = srand_seed; > srand_seed = tmp; > break; Otherwise, the patch looks fine. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 10:26:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BF1DA63 for ; Thu, 28 Aug 2014 10:26:49 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 029FE1E57 for ; Thu, 28 Aug 2014 10:26:48 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id s7SAQbMY030449 for ; Thu, 28 Aug 2014 12:26:38 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id s7SAQbi5030446 for ; Thu, 28 Aug 2014 12:26:37 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 28 Aug 2014 12:26:37 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: automatically nfs-boot different systems for 32 and 64 bit machine Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 28 Aug 2014 12:26:38 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 10:26:49 -0000 how can i boot different systems automatically depending if 32 or 64 bit machine netboots? ideal would be simple PXE program that would check CPU architecture and then load different files by TFTP. i already took care about the rest. do such a program exist? From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 10:27:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 509A1B50 for ; Thu, 28 Aug 2014 10:27:41 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3D641E65 for ; Thu, 28 Aug 2014 10:27:40 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id s7SARc1C030461 for ; Thu, 28 Aug 2014 12:27:38 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id s7SARast030458 for ; Thu, 28 Aug 2014 12:27:36 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 28 Aug 2014 12:27:36 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: Re: automatically nfs-boot different systems for 32 and 64 bit machine In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 28 Aug 2014 12:27:38 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 10:27:41 -0000 or even simpler - i can modify pxeboot myself, but anyone have a code example running in 32-bit mode that can detect if CPU is x86_64 capable? On Thu, 28 Aug 2014, Wojciech Puchar wrote: > how can i boot different systems automatically depending if 32 or 64 bit > machine netboots? > > ideal would be simple PXE program that would check CPU architecture and then > load different files by TFTP. i already took care about the rest. > > do such a program exist? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 10:36:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0E4AF70 for ; Thu, 28 Aug 2014 10:36:48 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx12.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 985D61F53 for ; Thu, 28 Aug 2014 10:36:48 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,417,1406617200"; d="asc'?scan'208";a="184789959" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 28 Aug 2014 03:36:48 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 28 Aug 2014 03:36:21 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 28 Aug 2014 03:36:20 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::55e3:a7dc:11bd:462%21]) with mapi id 15.00.0913.011; Thu, 28 Aug 2014 03:36:21 -0700 From: "Eggert, Lars" To: Wojciech Puchar Subject: Re: automatically nfs-boot different systems for 32 and 64 bit machine Thread-Topic: automatically nfs-boot different systems for 32 and 64 bit machine Thread-Index: AQHPwqqM3dpxKCvyFUeFBzeMUim/cJvmR/CA Date: Thu, 28 Aug 2014 10:36:20 +0000 Message-ID: <82DBA90E-CB65-4176-9DB5-9BEB70E0E0A6@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_B002809D-409C-4E65-AF60-233F07F29088"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 10:36:48 -0000 --Apple-Mail=_B002809D-409C-4E65-AF60-233F07F29088 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2014-8-28, at 12:26, Wojciech Puchar = wrote: > ideal would be simple PXE program that would check CPU architecture = and then load different files by TFTP. i already took care about the = rest. http://ipxe.org/cmd/cpuid Lars --Apple-Mail=_B002809D-409C-4E65-AF60-233F07F29088 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU/8GPdZcnpRveo1xAQLPQQP/YL7t3WFvwiGbjfAD1DAENCGCjnUWRC5+ k1y49HyNR59zKM0cBgf45hZKRNMNMsLmfNEnRNST/en9DxKfegsvHNJcK7ENphb4 U9aRwr5XTAYCcnbnFW1qHF8kQSywj/TO2KxxkbYjpMtwEre8XQTT7fLqo9GVCj9q VJwLNrmfp58= =5/0M -----END PGP SIGNATURE----- --Apple-Mail=_B002809D-409C-4E65-AF60-233F07F29088-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 13:26:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF50AA5D for ; Thu, 28 Aug 2014 13:26:07 +0000 (UTC) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by mx1.freebsd.org (Postfix) with ESMTP id 871F21481 for ; Thu, 28 Aug 2014 13:26:07 +0000 (UTC) Received: from straylight.m.ringlet.net (unknown [78.90.13.150]) by nimbus.fccf.net (Postfix) with ESMTPSA id C85C8503 for ; Thu, 28 Aug 2014 16:16:28 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 254004e by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Thu, 28 Aug 2014 16:15:27 +0300 Date: Thu, 28 Aug 2014 16:15:27 +0300 From: Peter Pentchev To: Vitaly Magerya Subject: Re: On changing rand(3) to random(3) in awk(1) Message-ID: <20140828131526.GA2385@straylight.m.ringlet.net> Mail-Followup-To: Vitaly Magerya , Chenguang Li , freebsd-hackers@freebsd.org References: <53FEFBB8.5040305@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <53FEFBB8.5040305@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, Chenguang Li X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 13:26:07 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 28, 2014 at 12:51:52PM +0300, Vitaly Magerya wrote: > On 2014-08-28 09:21, Chenguang Li wrote: [snip] > >Index: run.c > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >--- run.c (revision 270740) > >+++ run.c (working copy) > >@@ -1522,7 +1522,7 @@ > > break; > > case FRAND: > > /* in principle, rand() returns something in 0..RAND_MAX= */ > >- u =3D (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; > >+ u =3D (Awkfloat) (random() % RAND_MAX) / RAND_MAX; >=20 > You should not use RAND_MAX with random(3), since it returns values > between 0 and 0x7fffffff (inclusive); RAND_MAX only applies to rand(3). >=20 > A better patch would be something like this: >=20 > >- /* in principle, rand() returns something in 0..RAND_MAX= */ > >- u =3D (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; > >+ /* random() returns values in [0, 2147483647] */ > >+ u =3D (Awkfloat) random() / 2147483648; Hm. Since random() is documented to return "long", wouldn't it be a bit better with #include and LONG_MAX here? G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJT/ytqAAoJEGUe77AlJ98TAB0P/i+SiOsXSe5RYh19zSzVxvUB pXA5fMh2VGU69vT0cuy4aLgWzyyo6vX6fMMbuphYXRRa7RJIyf8XjqYnQPzKphP3 Xj3qs20kcFCPRUXr3LAM8kfOcGjGi++ZIDaEJSYpgqMGsmG7uWJ4cbv0LX6+HfxY 3GJTmBirvVENVwMOA+Rbd6WSH3+42+4eOJhXdtlQWbRB9SzhghIbCME8jMkPbXzS tsXKY3al7x8kYWhV/gQhffPUyFIjRfSe5uU0R9gVsUg5D1k9Z6s2bjX9UJtVAqBE OGYpHaOMffYFymJB8XE5MXHQzDbbOexsiD3v1JRWD7TLD/KaUgSkMiuhMM8I1Ynq Qec8Mnmpu40yI0ytTMuQl/Lbt/Ib/nVau5BBuI0HvdFm+jDXvnPtmo4OT5QDlUVt MOLP+DeN3Q8B9Z2+hV5FOZFPf9/t7w1gLV6c21t8Er9p1lzGP+rakNiT8cZUANVr kuFY/2E0EoYQYNFnOSgSTh9/twUj8Tyh/cOsPSmLUhp8Ol5rf73eNiorilQcbPmE /UU6AVrwhfaOXqjzbqP/JZ2u44sqQ3VNJBUnfSCEiKTu34/BC2Tax4S+/PluCK5n vLH8ICuAs/3MRzeZSZ+/tLCqvEhwstiSzYl4lr2Wvf+000W6uoi8bY6/cno7McBl OtdvZ/rL83V5qjFzGnvp =6Ojf -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 13:29:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6A19B9F for ; Thu, 28 Aug 2014 13:29:09 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99D3414BD for ; Thu, 28 Aug 2014 13:29:09 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id eu11so2560325pac.11 for ; Thu, 28 Aug 2014 06:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=un5gfllXmtWD4NsiAoZnauUNzkV1yVaQqWbiU92ORYM=; b=FEpTe2Htz276RiN6SR7qswahWHd/UN869+tAe2JXps5jq6kBM4PWY9DrnffUYqqqtL msjG/bYyaVl6gX0Q+Z/JTrHTAJkGxk/plQkBeVOnXZlnIENFa9f7UOS5bKRGH9L9m2Tb Qsj4W/dRhUtL7aoN9mJnCFCzwIdD4/WUmuH42g2nOUumFWBob6FCqPzSiT4yIkRmjlYt K8ZaWllI0AXC26Fa+RKYpwiyovr4rrFUpDZNXtKPBKFO9UnJgQA0eqfDo8Juj6FidxKG q1Nnq5a1KNNp3JtkVuiAUnb/SdFhghiocVMV9VEVCyBFYUIwupcmARY0G2gqisWFlEri Npuw== X-Received: by 10.66.121.137 with SMTP id lk9mr6050281pab.86.1409232547098; Thu, 28 Aug 2014 06:29:07 -0700 (PDT) Received: from [127.0.0.1] ([202.55.17.37]) by mx.google.com with ESMTPSA id bq17sm12737255pac.47.2014.08.28.06.29.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 06:29:06 -0700 (PDT) Content-Type: text/plain; charset="utf8"; Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: On changing rand(3) to random(3) in awk(1) X-Pgp-Agent: GPGMail (null) From: Chenguang Li In-Reply-To: <20140828131526.GA2385@straylight.m.ringlet.net> Date: Thu, 28 Aug 2014 21:28:48 +0800 Content-Transfer-Encoding: 8bit Message-Id: <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> To: Peter Pentchev X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org, Vitaly Magerya X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 13:29:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Peter Pentchev wrote: >> On Thu, Aug 28, 2014 at 12:51:52PM +0300, Vitaly Magerya wrote: >>> On 2014-08-28 09:21, Chenguang Li wrote: >>> [snip] >>> Index: run.c >>> =================================================================== >>> --- run.c (revision 270740) >>> +++ run.c (working copy) >>> @@ -1522,7 +1522,7 @@ >>> break; >>> case FRAND: >>> /* in principle, rand() returns something in 0..RAND_MAX */ >>> - u = (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; >>> + u = (Awkfloat) (random() % RAND_MAX) / RAND_MAX; >> >> You should not use RAND_MAX with random(3), since it returns values >> between 0 and 0x7fffffff (inclusive); RAND_MAX only applies to rand(3). >> >> A better patch would be something like this: >> >> - /* in principle, rand() returns something in 0..RAND_MAX */ >> - u = (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; >> + /* random() returns values in [0, 2147483647] */ >> + u = (Awkfloat) random() / 2147483648; > > Hm. Since random() is documented to return "long", wouldn't it be a bit > better with #include and LONG_MAX here? I am using RANDOM_MAX here to maintain the original code structure. I've updated my patch, please check the gist. Thanks! Chenguang Li -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT/y6XAAoJELG4cS+11lRhQwEQALocD2J3I+xbGYqKGkSQ8Irr KnuZ21QJ8H+3eb9KLcJ24Tob/vdVi6eukHIDn1SbmDfdyUfm/ufKBObiQ98Qsyu2 /7PB9BcH3N6f9obkFEJWkBEx5Gc3HOAkFhsJFgRvutGVAi1ISTwmqyEcC+18DgqC NB8j0c5CoFLI03rtJNH+m0Jx5PGPOIHK7t9MrHhKlRmxqbN+pClKDXWLp4/Qfsj9 I6BMLcXcdDMGJ/L81AQUFPbOUXlibjG5m2afV6PSyNwcrPaUT9yyL4lDUunz3IAo ktGs2eDIiGXM36Iqh4jUk9bCXvJfYf1XuHEUCvhnvVHECDJGv6rJlFU3Eq0M5naN ZMVc16zuxWg4J7BLwTqI1ocKD1TigvScnpWWjbfr53WEVRXlBlUHcmwHVyZ2knn5 NAVxF/kp9dB8XqJdIVkoFvge+tO9m+HKEtUxALRwjjql/xX0tNEY/F/lcipv4qUk BKHUPauA5tupolFiI4ucWpOS7XbQBGRQdTEM4CwVrE/wkp6CeTMBagefy0UuGzi1 L/3gq0oMbr9yYjBf8flxO8jz1wbuWIVG00cNUW+ps0ixDsGiD/ea6nfwa8vsx2i3 FnicLPk+ulhlyPqKU70de2Jj7UtJuiVAtQCzEdP3AyJ757V9+y7epMzI7Z5nLHHZ Q1f8DkLLZdyMDlG0siL4 =bY6X -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 13:39:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA59AE3C for ; Thu, 28 Aug 2014 13:39:49 +0000 (UTC) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by mx1.freebsd.org (Postfix) with ESMTP id 5E000172C for ; Thu, 28 Aug 2014 13:39:48 +0000 (UTC) Received: from straylight.m.ringlet.net (unknown [78.90.13.150]) by nimbus.fccf.net (Postfix) with ESMTPSA id E5EB6503 for ; Thu, 28 Aug 2014 16:39:47 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 254004e by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Thu, 28 Aug 2014 16:38:46 +0300 Date: Thu, 28 Aug 2014 16:38:46 +0300 From: Peter Pentchev To: Chenguang Li Subject: Re: On changing rand(3) to random(3) in awk(1) Message-ID: <20140828133846.GB2385@straylight.m.ringlet.net> Mail-Followup-To: Chenguang Li , Vitaly Magerya , freebsd-hackers@freebsd.org References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline In-Reply-To: <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, Vitaly Magerya X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 13:39:50 -0000 --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 28, 2014 at 09:28:48PM +0800, Chenguang Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > > Peter Pentchev wrote: > >> On Thu, Aug 28, 2014 at 12:51:52PM +0300, Vitaly Magerya wrote: > >>> On 2014-08-28 09:21, Chenguang Li wrote: > >>> [snip] > >>> Index: run.c > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> --- run.c (revision 270740) > >>> +++ run.c (working copy) > >>> @@ -1522,7 +1522,7 @@ > >>> break; > >>> case FRAND: > >>> /* in principle, rand() returns something in 0..RAND_MA= X */ > >>> - u =3D (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; > >>> + u =3D (Awkfloat) (random() % RAND_MAX) / RAND_MAX; > >>=20 > >> You should not use RAND_MAX with random(3), since it returns values > >> between 0 and 0x7fffffff (inclusive); RAND_MAX only applies to rand(3). > >>=20 > >> A better patch would be something like this: > >>=20 > >> - /* in principle, rand() returns something in 0..RAND_M= AX */ > >> - u =3D (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; > >> + /* random() returns values in [0, 2147483647] */ > >> + u =3D (Awkfloat) random() / 2147483648; > > > > Hm. Since random() is documented to return "long", wouldn't it be a bit > > better with #include and LONG_MAX here? >=20 > I am using RANDOM_MAX here to maintain the original code structure. > I've updated my patch, please check the gist. Thanks! Right, but you've hard-coded RANDOM_MAX to 2^32-1. I don't think this is correct; I do believe that you should use LONG_MAX for this value. Of course, #define RANDOM_MAX LONG_MAX could be fine for this purpose here, but the point is to use LONG_MAX instead of 2^32-1. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJT/zDeAAoJEGUe77AlJ98TWzUP/ApHYpwoiHG+Blo5AuPItI+U 8/5EBQpjcggTvZxwsmOHZfsWTWN1wNIOpfoaTn8XHGgHUraysXq39EJWJgGfLyf6 oZjRlr7vMXRf/km5A9unMQLLHteHfBqwkBBtqpJfdvkMZmwKV9xXar62SBAZJFCh uykfLy8H3ceqs47DI4AjrsAjmqLXKt8w2kSpWSzLHf1PFPS8Ow8ZhOV+j2jnvNsx P3nAzOkspPiAotEwI8S1ss4K0r6eP9Vw1crftH3stYhBfDiK3VdrE/uhghZrJwxt 1Yjy7ZapKdqin5q5osYBoRyRwNGtoty4gHUCPuFgk8F9+lUPX7CFEAQjEZIeAQoN vg3JuuQlDQXpgOELQrRohxBi/6i5MeaztqkmXczzP/+lHWVYkiEbIrtCainuA1IY I8Lg9DJ8H8CibJlMxy8tIElyqEcfS9w7SDnS3GLzeiz9UuYQDtJqGxLvkzMIS8tA 1UHVoveD5ihL+OQQx2UCYfXGwgnKrhe8UxTAGoczStXDqACps0U4zY9c5bUqk2l5 BexRwEryKwiPOXR4tjb9vCp5sBj1oUIgsXzzcpoX5rWvIjN8QLVLLERLiQT7K9mB GqLUsFw5VGx6FC834ohYy84nMRTlMrVymfJL04bLcI5rr03zCWj4BL9mMFpr1B2V hZzE937WTmhzpe8RUOfC =b6nG -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 13:57:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FAA2408 for ; Thu, 28 Aug 2014 13:57:42 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 619A6192A for ; Thu, 28 Aug 2014 13:57:42 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id et14so2707128pad.2 for ; Thu, 28 Aug 2014 06:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+834Sd35tShCNckwIQPT9ACU/Dl+6MaGMyHumcpp/yc=; b=Z3+vpi2pKbgzy2xRuYlyuOM10IeU/2Fzhvl2m4MLm/0GS8uny6bvrRbA1J+IKUkH4U PM6TMVrH10YBC9vmvnE0hKJVCpkMUx2bD6dxM07YW47nS9jJ+kzUlYSKK2MJsThkQ7x4 QpHoQfpygvbu5C8JbvRK3rnXkrW6TldTkZpeU/z9AV7dTMG81er4sC01tozojc1UPqT5 txKwmtXBf1GiXud5nNnGeqJjeF64c8D7iktZEtFgnyR8CQBoCJId7sbMaJXWu2RRZb/n IQ+Ef3FSzwTAJsJza6EzTaKumHhdv2Ve0FJuI7TTdd5lAgH9KBVcgREvv+Pb+oC4MuYc 0jkA== X-Received: by 10.68.241.138 with SMTP id wi10mr6152991pbc.126.1409234260401; Thu, 28 Aug 2014 06:57:40 -0700 (PDT) Received: from [127.0.0.1] ([202.55.17.37]) by mx.google.com with ESMTPSA id pn1sm3721535pbc.21.2014.08.28.06.57.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 06:57:39 -0700 (PDT) Content-Type: text/plain; charset="utf8"; Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: On changing rand(3) to random(3) in awk(1) X-Pgp-Agent: GPGMail (null) From: Chenguang Li In-Reply-To: <20140828133846.GB2385@straylight.m.ringlet.net> Date: Thu, 28 Aug 2014 21:57:24 +0800 Content-Transfer-Encoding: 8bit Message-Id: References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> <20140828133846.GB2385@straylight.m.ringlet.net> To: Peter Pentchev X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org, Vitaly Magerya X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 13:57:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Peter Pentchev wrote: >> ... ... >> [omitted] > > Right, but you've hard-coded RANDOM_MAX to 2^32-1. I don't think this > is correct; I do believe that you should use LONG_MAX for this value. > Of course, #define RANDOM_MAX LONG_MAX could be fine for this purpose > here, but the point is to use LONG_MAX instead of 2^32-1. I got your point, updated again. :) Chenguang Li -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT/zVKAAoJELG4cS+11lRh7Q4P+wVrPEq6iLXZAgYCUYoaQcik DWLesOxLszjxr1nyx7kHD/vbBE04frhWbJZyBzmkmsLasXPckJxWpejpJGPwUGLX DpCyihobe94SUYwcXbnZ23Yv638dMGWWUptZuWkFe8L7CGUCF1nMwOpCh48U1t9E afDDxDdO8B6FOrAkCuqK5zEmC7yHGqLmG7p054MszG2wlnr8WVXK8xUho2GNccRM ykrpeFBIthzTQrM1UWX9IYmQSDD4nuUYwaL6wR0Jm/p0bhQzeZ01564I2FjkhZzz sKThSsFDjeNS49kQn30FnhbAn7+XfRd0DyWDl/Huaxvw63g4FbhkNUyiECKIiuyk A06Cr6pPeWJxRrsODacXdAhl8LCOQdrXo0XP/HXzT8a3TulCBxE/3v/s8WkJgPTd M8xQ5COtnJOW6GpYnq9cUF2KnelVrwb28N+6ThssRANNepMZ/dGljVoW1u2qBV+H cIn4wZFK++wo3skh4KS66RcfDkP083vsD+5SO742vBaobDxMXuU9jT4xytRW9twv GIl6c86aRhqUaa9FNgE2NGM4hDlyQgTO+I5npAo83JQGq93G5FikjYNA8SweqtrM PwnrIRhiVOMCvLW6Wr0eOUa2/c2WM+Zqb7B3Aoo8H1hAwN6C2SGpLhyY37Vja8Kd nFS/nlVdHpd2LDBV9+vH =gCzN -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 14:18:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F157CB3 for ; Thu, 28 Aug 2014 14:18:08 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 705851BAD for ; Thu, 28 Aug 2014 14:18:08 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id ey11so2738003pad.7 for ; Thu, 28 Aug 2014 07:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=a+upLQxwOK7Vj3d3ouPO/bhBqIg8EA4IQttQdQU/TdQ=; b=mwLfhlv6plx9FYtAs4IQx0KQL0BhaxHK6dlPKQdeQNaUb+jIbi4o3JG8sae9As1Orp ocr9JzkVOiiGN+gqv0Tw2mf90GMnPI6vuQgkrvtGfz6UPXTSM8uz4wq7QDf4ZDXrcOv2 vrd2OKLjXMZAZ7aaxzErFOJbvC/Av0feEoxo+PKHQjr6AL8TbeOGafgFLHDy1dYseMkq LHZIDwb7yaCRg2jJOI2IgpE0OmrmyOVfXs2XwqCJhBd9oafUKjkBBkUcEk+42YslRyxz UxQo8WK+AcqccotJ8llCZTIMJm+nEs6JLSYsYwAxHA5SW1pSJ9GPyrI8m6LcLFcu+O8V dYXw== X-Received: by 10.70.102.5 with SMTP id fk5mr6427820pdb.114.1409235484670; Thu, 28 Aug 2014 07:18:04 -0700 (PDT) Received: from ?IPv6:::1? ([202.55.17.37]) by mx.google.com with ESMTPSA id o2sm5672587pde.30.2014.08.28.07.18.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 07:18:04 -0700 (PDT) Content-Type: text/plain; charset="utf8"; Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: On changing rand(3) to random(3) in awk(1) X-Pgp-Agent: GPGMail (null) From: Chenguang Li In-Reply-To: Date: Thu, 28 Aug 2014 22:17:55 +0800 Content-Transfer-Encoding: 8bit Message-Id: References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> <20140828133846.GB2385@straylight.m.ringlet.net> To: Peter Pentchev X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org, Vitaly Magerya X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 14:18:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Chenguang Li wrote: > Peter Pentchev wrote: > >>> ... ... >>> [omitted] >> >> Right, but you've hard-coded RANDOM_MAX to 2^32-1. I don't think this >> is correct; I do believe that you should use LONG_MAX for this value. >> Of course, #define RANDOM_MAX LONG_MAX could be fine for this purpose >> here, but the point is to use LONG_MAX instead of 2^32-1. > > I got your point, updated again. :) Wait a minute, isn't LONG_MAX architecture-dependent? It's 9223372036854775807 on my 64-bit FreeBSD box. The range of generated random numbers is explicitly documented. So I am afraid I should hard-code 2^32-1 in the file. Chenguang Li -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT/zoTAAoJELG4cS+11lRhycwQALj9YTuHZGW3XVZfq83F+jNu u2mPZP6WarsAwWOUVGKJJEn0+E9TLe72lmIgSVoD+h27Y3lOye3kJ1Hpgx38sXVd Zn554Qi15wbuKDJMUDitJEeBFqlE+9NibVip7UsvzXMAkbGZonJTUAqopz7rXJmY IVZWblq63CUsPa+bz8eQ798jpAB7K+9QAkKaYyllTto0sNBWwCS+ZBO1IV2QzCw6 +BnVlQAioG1Z3cGc4j6lCxED/jGVL0A8dbXa+Eg8x95XfNCJnNDsahwqLBC1P0P7 1pZqJEa4UyLih4QK7msWRqGWXIgnzaytVbLMFEey8pYtc0y3lcHwdvzMgmQ55rvR V9UM68ux2ArcR8OuCKNC/KHPaqzx8RYhmFWj5bwkTylAYrkPbBqb9Ws5L8kBLpLz bn90ofOH+mDzsEyIdoV0C7wFDv0Niu9qubr2qhe2qnSsqQ2lUkIQXIFbSnKfvs1y y3tPB2j1NKVCW6+6S/0oACxOpSAVYuSxzAQqkK/JKvedoJT1/pCmLDTuceAa5Vau E1oCx2pA/8mrB64KNla3dmumSl6cx0bbA0LZb1pByIdlDfqTBaxpKLcBrWchaYnA IN2VVTnJwDv9AXf9BqgwPPRZoTq8JkYwdVT9fS2NniWBnP1l+b/FR5RDBOR6e+MH Ds5aPNGsbbNwGKKSRNWl =m/Rg -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 14:22:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6584C7 for ; Thu, 28 Aug 2014 14:22:51 +0000 (UTC) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by mx1.freebsd.org (Postfix) with ESMTP id 734961C9B for ; Thu, 28 Aug 2014 14:22:50 +0000 (UTC) Received: from straylight.m.ringlet.net (unknown [78.90.13.150]) by nimbus.fccf.net (Postfix) with ESMTPSA id AC9FF4AB for ; Thu, 28 Aug 2014 17:22:49 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 254004f by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Thu, 28 Aug 2014 17:21:47 +0300 Date: Thu, 28 Aug 2014 17:21:47 +0300 From: Peter Pentchev To: Chenguang Li Subject: Re: On changing rand(3) to random(3) in awk(1) Message-ID: <20140828142147.GA2200@straylight.m.ringlet.net> Mail-Followup-To: Chenguang Li , Vitaly Magerya , freebsd-hackers@freebsd.org References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> <20140828133846.GB2385@straylight.m.ringlet.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, Vitaly Magerya X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 14:22:52 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 28, 2014 at 10:17:55PM +0800, Chenguang Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Chenguang Li wrote: >=20 > > Peter Pentchev wrote: > >=20 > >>> ... ... > >>> [omitted] > >> > >> Right, but you've hard-coded RANDOM_MAX to 2^32-1. I don't think this > >> is correct; I do believe that you should use LONG_MAX for this value. > >> Of course, #define RANDOM_MAX LONG_MAX could be fine for this purpose > >> here, but the point is to use LONG_MAX instead of 2^32-1. > >=20 > > I got your point, updated again. :) >=20 > Wait a minute, isn't LONG_MAX architecture-dependent? It's 92233720368547= 75807=20 > on my 64-bit FreeBSD box. The range of generated random numbers is explic= itly=20 > documented. So I am afraid I should hard-code 2^32-1 in the file. Oof. Sorry. My bad. I missed the *second* sentence of the random(3) manual page, didn't I. Specifically looked it over, looked for limits, checked the bottom for various sections that may document constants and stuff... and missed the second sentence. Of course you're right, it's documented as 2^32-1. Though now I wonder whether stdlib.h shouldn't provide some kind of RANDOM_MAX constant for this purpose, instead of programs having to do their own hardcoding. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --azLHFNyN32YCQGCU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJT/zr3AAoJEGUe77AlJ98TROsP/0rM1GD5O7ILMKAWTeBh1vAi j0/L8m+tQHg6XvJ2af08xlTEpkUq21lszOmYw0yLtSOolFajZEaMjSOQfFSQ5MHy oB+dcObVQf1kJ/Elj/HgpOQ1pI1Q4WvVT5jZbKyr6puLeY7EZfcNGJkV9hrtjRA/ gRELgrC0PHhx1gGHFoJHId30ep4mjWxs6puRoB5ESldkHwCaYlfRNdNdw3vf6Jxp B9b7DiaskAQHo//4egy1niP7sXUfPGS8oik3Xw1TP8f90Y7QGdw3BvgZf7Va63XH z7nJMusYHby6E1y0K83o/l9gMybu91HOlTBZ2km/aJgdRuRaj6hsR+h5bcdJiNXV DmWhaqqyL4Ows1OZwEuxUH4CYX1YzlUo2eraPHwyOsJ+WKX1lGkcgfZT6YtEjhPs ycaftfm1lciM4ha1bUOPAelS81bw3iwx3AYDNh1Q86VhQmH8URisGdIXgDpGHZtK XfVyuAOJSBL8zjUPR73T4fT2KGNo2n7oL1xXUF0htuBRG8okOOvYf3F+HEtfU+8I ZJGzxztrtzAl9OFDF755HYnkfLacQsZXPlUAJpG6BMjLtxpndnOIHrBwwQJYGu+8 WMrDjYo4Y3HlHGHJlKtLWndYodV5wlOyPqDGN1ZU1B/XsAZJqsBN7kOIpqVoBcvk AIjfNmsAI814/CpnjFTp =vBxV -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 14:34:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA4B76FA for ; Thu, 28 Aug 2014 14:34:00 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA1F91DC0 for ; Thu, 28 Aug 2014 14:34:00 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id kq14so2804027pab.9 for ; Thu, 28 Aug 2014 07:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wXOCw8VJVETkLHoda64p2H4l+nEd50Azb9eaRqW2Zas=; b=bpw6b3wzJRmfd5I2/5aMg44EF6Gb3IFmCop1HRTtqdzC9Hh39/VWlTJrukaGK9teiN bVBzIzMMGwnCLLDIiXkydfj3QDnHt1p8TmqdIgClDKKH3IOTWGLXN3SwdG2G54Q9pJLN SXU54TjExWwIa1pN82D8mVCdHtt/AzhWGUuDEQFZOPf1n+dllHfDnm+f05IriJ7rS5YJ mzBeT1MdP/xJu7BlNEfPszcStv8vPDWxgLSmbLUGL2NflQoZ8uctgjUnVWgvxV7vvGqB bcbBt8rCe0yb8fDSGF+laYso8y7LAv6o+VXLRI2GfiOkKAy88aYPN6KfyPHdkJIRTq59 iC1Q== X-Received: by 10.69.20.97 with SMTP id hb1mr6565481pbd.150.1409236436570; Thu, 28 Aug 2014 07:33:56 -0700 (PDT) Received: from [127.0.0.1] ([202.55.17.37]) by mx.google.com with ESMTPSA id x7sm5716876pdj.36.2014.08.28.07.33.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 07:33:56 -0700 (PDT) Content-Type: text/plain; charset="utf8"; Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: On changing rand(3) to random(3) in awk(1) X-Pgp-Agent: GPGMail (null) From: Chenguang Li In-Reply-To: <20140828142147.GA2200@straylight.m.ringlet.net> Date: Thu, 28 Aug 2014 22:33:43 +0800 Content-Transfer-Encoding: 8bit Message-Id: <34BC8621-2628-4FD1-9F58-A282B3A96C50@gmail.com> References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> <20140828133846.GB2385@straylight.m.ringlet.net> <20140828142147.GA2200@straylight.m.ringlet.net> To: Peter Pentchev X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org, Vitaly Magerya X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 14:34:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Peter Pentchev wrote: >> On Thu, Aug 28, 2014 at 10:17:55PM +0800, Chenguang Li wrote: >> >> ... ... >> [omitted] >> >> Wait a minute, isn't LONG_MAX architecture-dependent? It's 9223372036854775807 >> on my 64-bit FreeBSD box. The range of generated random numbers is explicitly >> documented. So I am afraid I should hard-code 2^32-1 in the file. > > ... > > I missed the *second* sentence of the random(3) manual page, didn't I. > Specifically looked it over, looked for limits, checked the bottom for > various sections that may document constants and stuff... and missed the > second sentence. That's totally fine. :) > Of course you're right, it's documented as 2^32-1. Though now I wonder > whether stdlib.h shouldn't provide some kind of RANDOM_MAX constant for > this purpose, instead of programs having to do their own hardcoding. It would be nice to have it as a constant, as RAND_MAX for rand(3). Chenguang Li -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT/z3NAAoJELG4cS+11lRhIPoQANoQD6vze5QCK8yN4EWf8B3S 7VzAk6xsY7F2xFjIh/OVGihg7GE83ClwDkEWsbujM8NygqRX3DfMEk4wODWIX3Z/ yjChFFOH+DOHhFXMKFL8p4uEZzUKNZEHRBK0dXlUbCxQsd1YQStnxFGtZhef+90I 9DpQKyKfMzF7eQxHeCMh2s5JNUO8k0jIEPEZWxamjziwIkSPoVqUB50XjtzaIkt6 uU/LuqNukGUbBZSBFbH/2BLRB0Zgv72ncLvBqF8RyIOTL6D80C9ZFw8Snxk198Mj YPmgX+amW1ZydmERzDX3H8jHZ16ejcyufa05rOvlxUF4B8elqeoYamB43dKnmIfp 0JO+96g+1V0pzr1byrMxOlHCTrpObA1sI4egnkccgDr23OuchO/ifWAHsSMk8FUB pE65PxIMNzpdn9coWbfdWAhR2+pw9Pnb4zrzOPF47SkVO8vzyLIPr2ncH492FMh7 shyPOVTTck9Ows3OINomT5EyRH0WKyX8MEVwRZwfF0V8hb9MG3taoqGi9MiQN34g ObrX5E8ciZhEsz0j3UUXgYHFkM+A0+vMMcaqOWXlfAmpMyNa8QOq1WhlvfG9TvS6 KQUfxSWWgpZGNAW4AjNKnoqvM83hZBiCBZA+BypnaEFa2meVRcYDYmBVjB80JoDR vT1m6di0RFT48Zg4Zdlo =AqYi -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 15:05:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8372D97 for ; Thu, 28 Aug 2014 15:05:23 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 9B526125A for ; Thu, 28 Aug 2014 15:05:23 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id 2A01933C1E for ; Thu, 28 Aug 2014 11:05:12 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id CE11839860; Thu, 28 Aug 2014 11:05:10 -0400 (EDT) From: Lowell Gilbert To: freebsd-hackers@freebsd.org Subject: Re: On changing rand(3) to random(3) in awk(1) References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> <20140828133846.GB2385@straylight.m.ringlet.net> <20140828142147.GA2200@straylight.m.ringlet.net> <34BC8621-2628-4FD1-9F58-A282B3A96C50@gmail.com> Date: Thu, 28 Aug 2014 11:05:10 -0400 In-Reply-To: <34BC8621-2628-4FD1-9F58-A282B3A96C50@gmail.com> (Chenguang Li's message of "Thu, 28 Aug 2014 22:33:43 +0800") Message-ID: <44zjeoejtl.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 15:05:23 -0000 Chenguang Li writes: > Peter Pentchev wrote: >> Of course you're right, it's documented as 2^32-1. Though now I wonder >> whether stdlib.h shouldn't provide some kind of RANDOM_MAX constant for >> this purpose, instead of programs having to do their own hardcoding. > > It would be nice to have it as a constant, as RAND_MAX for rand(3). This comes from the POSIX specification, which specifically calls out that value even though it specifies the type as a long int. There's no reason we can't add it to our headers, but it won't be portable. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 16:24:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB362D7C for ; Thu, 28 Aug 2014 16:24:02 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 704DA1D47 for ; Thu, 28 Aug 2014 16:24:02 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id u56so1014791wes.22 for ; Thu, 28 Aug 2014 09:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HD/IuZeIn0m3jOXtFZPwB5T+r51I0nDx19RioiWAe54=; b=HYrcvJV9wCnWoDWiz3EHO2rskPLlPkdObiP4uHhnqvlmYk39oC8xX0uYh8UDXzLXmD mqLRXyieHJlF9NQgdL1oUsbgIbOQVRszG1+7FnLUIs71jknCDobz5UaHGErkbjmIF2pO 2ItE1kAXqz8S8jnf4M+AfC49w12DT166cJlGhh0m4VS1HXJ0P0Qu/aK5HTwIovpNaylD bXt0oIPTgoY/2MYw3x1KWGAxdRyy4GlXY91UWTdHtxaR5f2krUQycrQ1TrCDm6JeUie+ sbTAIMetGzqm0fn+jQQcohUbirccXONC7dQjU2Bw6q4LrDm0nwnGl2NMjAw7OBC8cdEV zHSA== X-Received: by 10.180.189.195 with SMTP id gk3mr23722968wic.82.1409243040629; Thu, 28 Aug 2014 09:24:00 -0700 (PDT) Received: from [172.16.0.2] (tx97.net. [85.198.160.156]) by mx.google.com with ESMTPSA id n5sm11083280wja.38.2014.08.28.09.23.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 09:24:00 -0700 (PDT) Message-ID: <53FF574E.1090108@gmail.com> Date: Thu, 28 Aug 2014 19:22:38 +0300 From: Vitaly Magerya User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Chenguang Li , Peter Pentchev Subject: Re: On changing rand(3) to random(3) in awk(1) References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> In-Reply-To: <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 16:24:02 -0000 On 08/28/14 16:28, Chenguang Li wrote: > I am using RANDOM_MAX here to maintain the original code structure. > I've updated my patch, please check the gist. Thanks! > jmp_buf env; > extern int pairstack[]; > @@ -1522,7 +1522,7 @@ > break; > case FRAND: > /* in principle, rand() returns something in 0..RAND_MAX */ > - u = (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; > + u = (Awkfloat) (random() % RANDOM_MAX) / RANDOM_MAX; > break; > case FSRAND: > if (isrec(x)) /* no argument provided */ OK, so this part is wrong (and it is wrong in the original sources too): this construction generates 0.0 twice as often as it generates other numbers -- both when random() returns 0 and when it returns RANDOM_MAX. The correct construction is this: > case FRAND: > - /* in principle, rand() returns something in 0..RAND_MAX */ > - u = (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; > + /* random() returns values in [0, RANDOM_MAX] */ > + u = (Awkfloat) random() / (RANDOM_MAX + 1ul); > break; Note that the "ul" part in "1ul" is vitally important: otherwise there will be an overflow on systems where long is 32 bit wide. Alternatively "1.0" can be used here instead. (Because this overflow may not be obvious in a casual reading, I'm not a fan of defining RANDOM_MAX separately; I personally would insert the actual number here directly). From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 19:41:56 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC5F4A05 for ; Thu, 28 Aug 2014 19:41:56 +0000 (UTC) Received: from message.langara.bc.ca (message.langara.bc.ca [142.35.159.25]) by mx1.freebsd.org (Postfix) with ESMTP id D22F517CE for ; Thu, 28 Aug 2014 19:41:56 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from langara.bc.ca ([127.0.0.1]) by message.langara.bc.ca (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTP id <0NB100BPE59QC7E0@message.langara.bc.ca> for freebsd-hackers@freebsd.org; Thu, 28 Aug 2014 11:41:50 -0700 (PDT) Received: from [38.108.87.20] by message.langara.bc.ca (mshttpd); Thu, 28 Aug 2014 18:41:50 +0000 (GMT) From: Steven Stewart-Gallus To: freebsd-hackers@freebsd.org Message-id: Date: Thu, 28 Aug 2014 18:41:50 +0000 (GMT) X-Mailer: Sun Java(tm) System Messenger Express 6.3-6.03 (built Mar 14 2008; 32bit) Content-language: en Subject: Can anyone help clarify details about the FreeBSD system call interface? X-Accept-Language: en Priority: normal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 19:41:57 -0000 Hi, I am interested in learning more about how FreeBSD works. I have gathered some information on some of FreeBSD's undocumented system calls and am not sure it is correct. Please correct me if I am wrong about the following system calls. I would be happy to submit some patches to help out with documentation after I get some confirmation and clarification. int sys_yield(void); int sys_sched_yield(void); Not sure how sys_yield differs from sched_yield. sys_yield is defined in sys/kern/kern_synch.c and sys_sched_yield is defined in sys/kern/p1003_1b.c. int sys_sstk(int incr); sys/vm/vm_mmap.c defines this as: /* * MPSAFE */ /* ARGSUSED */ int sys_sstk(td, uap) struct thread *td; struct sstk_args *uap; { /* Not yet implemented */ return (EOPNOTSUPP); } Did sys_sstk use to do something in the past and is now just legacy? int sys_vadvise(int anom); sys/vm/vm_unix.c defines this as: /* * MPSAFE */ /* ARGSUSED */ int sys_ovadvise(td, uap) struct thread *td; struct ovadvise_args *uap; { /* START_GIANT_OPTIONAL */ /* END_GIANT_OPTIONAL */ return (EINVAL); } Did sys_vadvise use to do something in the past and is now just legacy? int sys_mac_syscall(const char * policy, int call, void * arg); Not sure what sys_mac_syscall does. Seems to do a bunch of MAC operations at once. See sys/security/mac for a closer look. int sys___mac_execve(char * fname, char ** argv, char ** envv, struct mac * mac_p); Looks an execve that applys a MAC policy. See sys/security/mac for a closer look. int sys__umtx_lock(struct umtx * umtx); int sys _umtx_unlock(struct umtx * umtx); int sys__umtx_op(void * obj, int op, u_long val, void * uaddr1, void * uaddr2); Seems to implement low level mutexes. See sys/kern/kern_umtx.c for a closer look and lib/libthr/thread/umtx.h for the userspace wrapper. int sys_nlm_syscall(int debug_level, int grace_period, int addr_count, char ** addrs); Multiplexes system calls used to implement the kernel side of the Network Lock Manager protocol. See sys/nlm for a closer look. int sys_nnpfs_syscall(int operation, char * a_pathP, int a_opcode, void * a_paramsP, int a_followSymlinks); Multiplexes system calls used to implement the kernel side of some filesystem thingy. Not sure what it does. I can't find out where this is defined in the source code. int sys_afs3_syscall(long syscall, long parm1, long parm2, long parm3, long parm4, long parm5, long parm6); Multiplexes system calls used to implement the kernel side of the AFS protocol (version 3). I can't find out where this is defined in the source code. Thank you, Steven Stewart-Gallus From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 20:35:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D91FAE8C for ; Thu, 28 Aug 2014 20:35:55 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 624971D57 for ; Thu, 28 Aug 2014 20:35:54 +0000 (UTC) X-AuditID: 1209190f-f79aa6d000005b45-b4-53ff92a3fa71 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id D0.C1.23365.3A29FF35; Thu, 28 Aug 2014 16:35:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s7SKZkQt015760; Thu, 28 Aug 2014 16:35:47 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7SKZiim032329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Aug 2014 16:35:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7SKZiOL020337; Thu, 28 Aug 2014 16:35:44 -0400 (EDT) Date: Thu, 28 Aug 2014 16:35:44 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Steven Stewart-Gallus Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nort40v9gg5+tKhbbN/9jtJj5eR67 A5PHjE/zWTxO/nvLEsAUxWWTkpqTWZZapG+XwJXRcOkVS8EztYpTk/MaGDfIdTFyckgImEgc nnSCHcIWk7hwbz1bFyMXh5DAbCaJZ9+esEA4GxklTn19xgRSJSRwiEnidVc6RKKBUeJCxxcW kASLgLbE/xcfWUFsNgE1icd7m1khxipKbD41iRnEFhGwkfjXNoMNxGYWkJe4sPkQI4gtLBAu sWnnKrA5nAJGEg++nABaxsHBK+Ao0XTPF2KvocT9x1PBykUFdCRW758CVs4rIChxcuYTFoiR WhLLp29jmcAoNAtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxhB 4cspyb+D8dtBpUOMAhyMSjy8MxL+BQuxJpYVV+YeYpTkYFIS5VXv/x8sxJeUn1KZkVicEV9U mpNafIhRgoNZSYS3oAoox5uSWFmVWpQPk5LmYFES531rbRUsJJCeWJKanZpakFoEk5Xh4FCS 4P05AahRsCg1PbUiLTOnBCHNxMEJMpwHaLjZRJDhxQWJucWZ6RD5U4yKUuK8u0GaBUASGaV5 cL2w9PKKURzoFWFeN5B2HmBqgut+BTSYCWjwr46/IINLEhFSUg2MYgyqj+O4M/iCi055LI9S XK10nXXxMqcZkoVHZ1ZtrJv54gR/fMC+bz2O/D/PmXuuLePZUM1vE6ug2qrXcOn9wVj+6eUd zx/u7QwTWlBWEnfg3NnqJfLZbey+j/8saOPavVjzxtPtDaIr2fd7Gv69y6fqH17nf6wuzHqz ivoRMda/11wYpl9VYinOSDTUYi4qTgQAgdaabQoDAAA= Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:35:56 -0000 On Thu, 28 Aug 2014, Steven Stewart-Gallus wrote: > Hi, I am interested in learning more about how FreeBSD works. I have > gathered some information on some of FreeBSD's undocumented system > calls and am not sure it is correct. Please correct me if I am wrong > about the following system calls. I would be happy to submit some > patches to help out with documentation after I get some confirmation > and clarification. > > int sys_yield(void); > int sys_sched_yield(void); > > Not sure how sys_yield differs from sched_yield. sys_yield is defined > in sys/kern/kern_synch.c and sys_sched_yield is defined in > sys/kern/p1003_1b.c. sys_sched_yield just backends to sched_relinquish, which is defined (identically) in kern/sched_{ule,4bsd}.c. They differ in that sys_yield has a check for (PRI_BASE(td->td_pri_class) == PRI_TIMESHARE), and also that sys_sched_yield() always acts on curthread, whereas sys_yield uses the provided thread descriptor. > int sys_sstk(int incr); > > sys/vm/vm_mmap.c defines this as: > > /* > * MPSAFE > */ > /* ARGSUSED */ > int > sys_sstk(td, uap) > struct thread *td; > struct sstk_args *uap; > { > /* Not yet implemented */ > return (EOPNOTSUPP); > } > > Did sys_sstk use to do something in the past and is now just legacy? svn blame says that the whole implementation dates from r1541. Looks like it was never implemented. Some googling indicates that it was a planned routine to set the stack size, which was never implemented, anywhere. > int sys_vadvise(int anom); > > sys/vm/vm_unix.c defines this as: > > /* > * MPSAFE > */ > /* ARGSUSED */ > int > sys_ovadvise(td, uap) > struct thread *td; > struct ovadvise_args *uap; > { > /* START_GIANT_OPTIONAL */ > /* END_GIANT_OPTIONAL */ > return (EINVAL); > } > > Did sys_vadvise use to do something in the past and is now just > legacy? The locking comments were added in r79224, but the implementation is otherwise from r1541, i.e., it was never implemented. > int sys_mac_syscall(const char * policy, int call, void * arg); > > Not sure what sys_mac_syscall does. Seems to do a bunch of MAC > operations at once. See sys/security/mac for a closer look. It applies the indicated MAC policy for the given syscall arguments. I'll defer to someone else on this. > int sys___mac_execve(char * fname, char ** argv, char ** envv, struct > mac * mac_p); > > Looks an execve that applys a MAC policy. See sys/security/mac for a > closer look. Looks like that to me, too. Again, I'll defer. > int sys__umtx_lock(struct umtx * umtx); > int sys _umtx_unlock(struct umtx * umtx); > int sys__umtx_op(void * obj, int op, u_long val, void * uaddr1, void * > uaddr2); > > Seems to implement low level mutexes. See sys/kern/kern_umtx.c for a > closer look and lib/libthr/thread/umtx.h for the userspace wrapper. > > int sys_nlm_syscall(int debug_level, int grace_period, int addr_count, > char ** addrs); > > Multiplexes system calls used to implement the kernel side of the > Network Lock Manager protocol. See sys/nlm for a closer look. I'll defer looking at these. > int sys_nnpfs_syscall(int operation, char * a_pathP, int a_opcode, > void * a_paramsP, int a_followSymlinks); > > Multiplexes system calls used to implement the kernel side of some > filesystem thingy. Not sure what it does. I can't find out where > this is defined in the source code. > > int sys_afs3_syscall(long syscall, long parm1, long parm2, long parm3, > long parm4, long parm5, long parm6); > > Multiplexes system calls used to implement the kernel side of the AFS > protocol (version 3). I can't find out where this is defined in the > source code. Neither of these are implemented in the tree. Both were added for use by different implementations of the AFS protocol; nnpfs for the "Arla" client, and afs3_syscall for the "openafs" client. Unfortunately, OpenAFS actually uses the syscall number from the nnpfs_syscall (IIRC), but with the semantics of afs3_syscall, to avoid breaking existing applications. Arla has not been functional on FreeBSD for several major versions of FreeBSD (probably not since 4.X) and is probably not worth looking at. OpenAFS is available at http://openafs.org or via the net/openafs port; for example, the implementation of afs3_syscall is the tangled mess of preprocessor conditionals starting at https://github.com/openafs/openafs/blob/openafs-stable-1_6_x/src/afs/afs_syscall.c#L468 Conceptually it is actually a multiplexor of multiplexors (ew!), with several operations of type AFSCALL_CALL and many others of type AFSCALL_PIOCTL ("path ioctl"). It's out of scope to describe the behavior of the afs3_syscall in FreeBSD-specific documentation, I think. -Ben From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 21:04:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 616669A5 for ; Thu, 28 Aug 2014 21:04:14 +0000 (UTC) Received: from mail.choopa.net (mail.choopa.net [216.155.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 20BF210A7 for ; Thu, 28 Aug 2014 21:04:13 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by mail.choopa.net (iRedMail) with ESMTP id 4D8064AF45F; Thu, 28 Aug 2014 17:04:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.choopa.net Received: from mail.choopa.net ([127.0.0.1]) by localhost (mail.choopa.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM3Zd1B6ky+Q; Thu, 28 Aug 2014 17:04:01 -0400 (EDT) Received: from [10.5.5.117] (office-nat.choopa.net [208.167.225.40]) by mail.choopa.net (iRedMail) with ESMTPSA id 919184AF422; Thu, 28 Aug 2014 17:04:01 -0400 (EDT) Message-ID: <53FF9941.20807@gameservers.com> Date: Thu, 28 Aug 2014 17:04:01 -0400 From: Brian Rak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: Bug in FreeBSD VirtIO network driver (only with pf enabled) References: <53FE2B37.7050309@gameservers.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 21:04:14 -0000 Should I open a bug about this? On 8/28/2014 12:35 AM, Bryan Venteicher wrote: > > > > On Wed, Aug 27, 2014 at 2:02 PM, Brian Rak > wrote: > > I have a FreeBSD 10 x64 guest installed inside a KVM instance on > Linux. When pf is active, and the server is sending data it > causes the Linux host to report warnings related to GSO. > > I've talked to some Linux developers, and they believe it to be a > bug inside the FreeBSD VirtIO drivers. Based on what I'm seeing, > I'm inclined to agree with them. > > Reproduction is mildly annoying, you need: > 1) A KVM guest setup with bridged networking, with FreeBSD running > side using the VirtIO network interface. (We tested with CentOS, > but the exact distribution should not matter) > 2) pf enabled (I'm using a single rule: "scrub in all") > 3) Some method of sending a bit of traffic from the guest (I use > netcat) > > So, when I do this: > > # service pf start > # cat /root/test | nc vultr.com 80 > > The Linux kernel on the host will report: > > kernel: WARNING: CPU: 7 PID: 7772 at net/core/dev.c:2246 > skb_warn_bad_offload+0xc3/0xd0() > kernel: igb: caps=(0x0000000640114bb3, 0x0000000000000000) > len=1498 data_len=0 gso_size=1380 gso_type=5 ip_summed=0 > > If I do: > > # service pf stop > # cat /root/test | nc vultr.com 80 > > No such warning is reported. I can only reproduce this with pf > enabled. The contents of the /root/test don't matter, I'm using > 4k of data from /dev/urandom. The test file just needs to be > bigger then the MTU of the host's network interface. > > I was able to track this down to the virtio_net_hdr being sent by > the FreeBSD guest. With pf enabled, this outbound traffic has the > following header: > > flags = 0 > gso_type = VIRTIO_NET_HDR_GSO_TCPV4 > hdr_len = 66 > gso_size = 1440 > csum_start = 0 > csum_offset = 0 > > But, this is not a valid configuration. With > VIRTIO_NET_HDR_GSO_TCPV4 enabled, you should also be setting > VIRTIO_NET_HDR_F_NEEDS_CSUM and populating the csum_start and > csum_offset fields. > > > > ​It would appear that somewhere in pf the CSUM_TCP flag is getting > clear for CSUM_TSO packets. I don't believe the stack otherwise sets > CSUM_TSO without CSUM_TCP. Now, it is probably safe to assume CSUM_TCP > when CSUM_TSO is set: the mbuf's m_pkthdr.csum_data better be valid in > such cases though. > > http://www.spinics.net/lists/netdev/msg293976.html gives more > detail on this. I don't fully understand this, so I'd probably > mangle the explanation if I tried to give more detail. I can > reproduce this at will now, but fixing it is beyond my abilities. > Is there a better place to report this? I'm not entirely sure who > is responsible for maintaining the virtio driver. > _______________________________________________ > freebsd-hackers@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org > " > > From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 21:28:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 173AC966 for ; Thu, 28 Aug 2014 21:28:15 +0000 (UTC) Received: from mail.choopa.net (mail.choopa.net [216.155.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id C922E1350 for ; Thu, 28 Aug 2014 21:28:14 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by mail.choopa.net (iRedMail) with ESMTP id 79EA44AF41B; Thu, 28 Aug 2014 17:28:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.choopa.net Received: from mail.choopa.net ([127.0.0.1]) by localhost (mail.choopa.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3izn5OJ8p4gD; Thu, 28 Aug 2014 17:28:07 -0400 (EDT) Received: from [10.5.5.117] (office-nat.choopa.net [208.167.225.40]) by mail.choopa.net (iRedMail) with ESMTPSA id C6CBB4AF3F6; Thu, 28 Aug 2014 17:28:07 -0400 (EDT) Message-ID: <53FF9EE7.8070501@gameservers.com> Date: Thu, 28 Aug 2014 17:28:07 -0400 From: Brian Rak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: Bug in FreeBSD VirtIO network driver (only with pf enabled) References: <53FE2B37.7050309@gameservers.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 21:28:15 -0000 Actually, is this related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192013 ? That looks awfully similar to what I imagine the fix for this issue would look like. On 8/28/2014 12:35 AM, Bryan Venteicher wrote: > > > > On Wed, Aug 27, 2014 at 2:02 PM, Brian Rak > wrote: > > I have a FreeBSD 10 x64 guest installed inside a KVM instance on > Linux. When pf is active, and the server is sending data it > causes the Linux host to report warnings related to GSO. > > I've talked to some Linux developers, and they believe it to be a > bug inside the FreeBSD VirtIO drivers. Based on what I'm seeing, > I'm inclined to agree with them. > > Reproduction is mildly annoying, you need: > 1) A KVM guest setup with bridged networking, with FreeBSD running > side using the VirtIO network interface. (We tested with CentOS, > but the exact distribution should not matter) > 2) pf enabled (I'm using a single rule: "scrub in all") > 3) Some method of sending a bit of traffic from the guest (I use > netcat) > > So, when I do this: > > # service pf start > # cat /root/test | nc vultr.com 80 > > The Linux kernel on the host will report: > > kernel: WARNING: CPU: 7 PID: 7772 at net/core/dev.c:2246 > skb_warn_bad_offload+0xc3/0xd0() > kernel: igb: caps=(0x0000000640114bb3, 0x0000000000000000) > len=1498 data_len=0 gso_size=1380 gso_type=5 ip_summed=0 > > If I do: > > # service pf stop > # cat /root/test | nc vultr.com 80 > > No such warning is reported. I can only reproduce this with pf > enabled. The contents of the /root/test don't matter, I'm using > 4k of data from /dev/urandom. The test file just needs to be > bigger then the MTU of the host's network interface. > > I was able to track this down to the virtio_net_hdr being sent by > the FreeBSD guest. With pf enabled, this outbound traffic has the > following header: > > flags = 0 > gso_type = VIRTIO_NET_HDR_GSO_TCPV4 > hdr_len = 66 > gso_size = 1440 > csum_start = 0 > csum_offset = 0 > > But, this is not a valid configuration. With > VIRTIO_NET_HDR_GSO_TCPV4 enabled, you should also be setting > VIRTIO_NET_HDR_F_NEEDS_CSUM and populating the csum_start and > csum_offset fields. > > > > ​It would appear that somewhere in pf the CSUM_TCP flag is getting > clear for CSUM_TSO packets. I don't believe the stack otherwise sets > CSUM_TSO without CSUM_TCP. Now, it is probably safe to assume CSUM_TCP > when CSUM_TSO is set: the mbuf's m_pkthdr.csum_data better be valid in > such cases though. > > http://www.spinics.net/lists/netdev/msg293976.html gives more > detail on this. I don't fully understand this, so I'd probably > mangle the explanation if I tried to give more detail. I can > reproduce this at will now, but fixing it is beyond my abilities. > Is there a better place to report this? I'm not entirely sure who > is responsible for maintaining the virtio driver. > _______________________________________________ > freebsd-hackers@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org > " > > From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 23:31:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE17ACC1; Thu, 28 Aug 2014 23:31:43 +0000 (UTC) Received: from message.langara.bc.ca (message.langara.bc.ca [142.35.159.25]) by mx1.freebsd.org (Postfix) with ESMTP id A24D01180; Thu, 28 Aug 2014 23:31:43 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from langara.bc.ca ([127.0.0.1]) by message.langara.bc.ca (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTP id <0NB100I7MIOUX1A0@message.langara.bc.ca>; Thu, 28 Aug 2014 16:31:42 -0700 (PDT) Received: from [173.180.212.56] by message.langara.bc.ca (mshttpd); Thu, 28 Aug 2014 23:31:42 +0000 (GMT) From: Steven Stewart-Gallus To: Benjamin Kaduk Message-id: Date: Thu, 28 Aug 2014 23:31:42 +0000 (GMT) X-Mailer: Sun Java(tm) System Messenger Express 6.3-6.03 (built Mar 14 2008; 32bit) Content-language: en Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? X-Accept-Language: en Priority: normal In-reply-to: References: Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 23:31:43 -0000 > sys_sched_yield just backends to sched_relinquish, which is defined > (identically) in kern/sched_{ule,4bsd}.c. They differ in that > sys_yieldhas a check for (PRI_BASE(td->td_pri_class) == > PRI_TIMESHARE), and also > that sys_sched_yield() always acts on curthread, whereas sys_yield > usesthe provided thread descriptor. Okay. > svn blame says that the whole implementation dates from r1541. > Looks like > it was never implemented. Some googling indicates that it was a > plannedroutine to set the stack size, which was never implemented, > anywhere. > The locking comments were added in r79224, but the implementation is > otherwise from r1541, i.e., it was never implemented. Alright, so sys/kern/syscalls.master can be patched somewhat like so and I won't need to document them? -72 AUE_O_VADVISE STD { int ovadvise(int anom); } vadvise \ - ovadvise_args int +72 AUE_NULL OBSOL ovadvise -70 AUE_SSTK STD { int sstk(int incr); } +70 AUE_SSTK OBSOL sstk > It applies the indicated MAC policy for the given syscall arguments. > I'll defer to someone else on this. > Looks like that to me, too. Again, I'll defer. Okay. > I'll defer looking at these. Okay. > Neither of these are implemented in the tree. > Both were added for use by different implementations of the AFS > protocol;nnpfs for the "Arla" client, and afs3_syscall for the > "openafs" client. > Unfortunately, OpenAFS actually uses the syscall number from the > nnpfs_syscall (IIRC), but with the semantics of afs3_syscall, to avoid > breaking existing applications. > > Arla has not been functional on FreeBSD for several major versions of > FreeBSD (probably not since 4.X) and is probably not worth looking at. > OpenAFS is available at http://openafs.org or via the net/openafs > port;for example, the implementation of afs3_syscall is the tangled > mess of > preprocessor conditionals starting at > https://github.com/openafs/openafs/blob/openafs-stable- > 1_6_x/src/afs/afs_syscall.c#L468Conceptually it is actually a > multiplexor of multiplexors (ew!), with > several operations of type AFSCALL_CALL and many others of type > AFSCALL_PIOCTL ("path ioctl"). It's out of scope to describe the > behaviorof the afs3_syscall in FreeBSD-specific documentation, I > think. > -Ben Okay, Linux has similar reserved system calls such as tuxcall. Linux deals with these by having an unimplemented.2 manpage which lists obsolete or reserved system calls. So we can just add to the manpage stuff like: afs3_syscall is a system call reserved for the use of the OpenAFS people. Thank you, Steven Stewart-Gallus From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 29 02:06:38 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7832880E for ; Fri, 29 Aug 2014 02:06:38 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6651075 for ; Fri, 29 Aug 2014 02:06:37 +0000 (UTC) Received: from zenyatta.panasas.com ([172.17.28.63]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Thu, 28 Aug 2014 15:30:41 -0400 Received: from ZENYATTA.int.panasas.com ([fe80::44ca:f0e1:b97e:bf79]) by zenyatta.int.panasas.com ([fe80::44ca:f0e1:b97e:bf79%15]) with mapi id 14.03.0181.006; Thu, 28 Aug 2014 15:30:40 -0400 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" Subject: Re: automatically nfs-boot different systems for 32 and 64 bit machine Thread-Topic: automatically nfs-boot different systems for 32 and 64 bit machine Thread-Index: AQHPwvaM81/ZwU2QsEenpDwo2BP7tw== Date: Thu, 28 Aug 2014 19:30:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.17.133.77] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Aug 2014 19:30:41.0127 (UTC) FILETIME=[8DA66770:01CFC2F6] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 02:06:38 -0000 > how can i boot different systems automatically depending if 32 or 64 bit >machine netboots? >=20 > ideal would be simple PXE program that would check CPU architecture and >then load different files by TFTP. i already took care about the rest. We had a similar problem several years ago. Because the number of 32-bit models was relatively small, we implemented a lookup table based on the SMBIOS product names: sys/boot/forth/loader.4th: \ checks if string specified by c-addr2 u2 is contained \ in the string specified by c-addr1 u1. : substring ( c-addr1 u1 c-addr2 u2 -- c-addr1 u1 flag ) 2 pick 1 pick - dup 0 < if drop drop drop false exit else 1 + 0 do 2over drop I + 1 pick 2over compare 0=3D if drop drop unloop true exit then loop drop drop false then ; \ tests if any of the known 32-bit SMBIOS substrings are present \ return true flag if yes : test32bit ( -- flag ) s" smbios.planar.product" getenv dup -1 =3D if s" BIOS version not present" type cr drop true exit else s" BIOS version: " type 2dup type cr \ Run "kenv smbios.planar.product" on the 32-bit machines, and \ add their strings to this list c" 32-bit plat1" count substring if 2drop true exit then c" plat2-32" count substring if 2drop true exit then then \ we'll call it 64-bit 2drop false ; sys/boot/i386/loader/loader.rc test32bit [if] \ Path to 32-bit kernel load /kernel boot [else] \ Path to 64-bit kernel load /boot/kernel/kernel boot [then] NB: I modified this a bit to remove some proprietary details; what's listed above might not actually work, but it should be relatively close, and should point you in the right direction. -Ravi From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 29 06:44:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D791D59 for ; Fri, 29 Aug 2014 06:44:53 +0000 (UTC) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 211371CA9 for ; Fri, 29 Aug 2014 06:44:53 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id x19so2278701ier.21 for ; Thu, 28 Aug 2014 23:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gEj04jKGaAhBOyMatTSl88lZ2UMJ4OJfi+Pb4Ui2xwU=; b=sRRhi3/+PWowOlfmMAOAK8uNslBl9pGhRWuImybHhoN+tw/wH5/AsR9TZn1QkIt2wI D4bqXZg/4F2Yt74VXVvUleXXfF/0KJxHUzBLZ0qE0FDMkIGj7nx74A6b4Vq67WUz4sch TfwG3FnrUjTJTPDRiNBJ+7REpvEDoqReEOeZWHWpAwQR+0IojECod5SsKQaM8g3J2bnR 8UzZR5cemqpCljlnNTSehZKcWeKdCGba+Tgn/iar6GtiVEoh9ia2Q7BBkJXID7iv0T15 Jqe4oBMJ9Y05JQxaGlrXkGQi9mV6XBHSo82zSFiQhv3F/lRmu8GYpDHnS36KAFYQaBa7 UQVg== MIME-Version: 1.0 X-Received: by 10.50.67.51 with SMTP id k19mr1792920igt.39.1409294692527; Thu, 28 Aug 2014 23:44:52 -0700 (PDT) Received: by 10.107.15.1 with HTTP; Thu, 28 Aug 2014 23:44:52 -0700 (PDT) Date: Fri, 29 Aug 2014 08:44:52 +0200 Message-ID: Subject: Sudden and strange problem From: Oriental Sensation To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 06:44:53 -0000 Hi guys, No idea if this is related to FreeBSD but hopefully someone could help me. Couple of days ago I upgraded to 10.1-PRERELEASE and something happened. My configuration is a host with 2 jails -- the host runs unbound and the two jails use it to resolve. There's one local zone entitled "local" and few hosts to identify the jails: dbs.local, smtp.local, www.local, etc. One jail runs dovecot+postfix and the other runs a web server. There's a really strange thing going on because occasionally trying to telnet from the web server to the other jail (port 25 or 143) takes few seconds, but most of the time it takes a millisecond. I did a 'truss' and 'drill' and I am attaching 2 links to the logs: http://pastebin.com/rUrq10vd (look at line 276, I surrounded it with empty lines because that's where the delay happens -- this time for 2 seconds) http://pastebin.com/Q3W3dhLM (again, I inserted spaces around line #151 where 5 seconds in delay -- twice). By the way, running the same commands few times after, no delay is apparent. Anyone got an idea what on earth is causing this? Thanks in advance for any help. /OriS From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 29 06:51:29 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04477E81 for ; Fri, 29 Aug 2014 06:51:29 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A65131D5E for ; Fri, 29 Aug 2014 06:51:28 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1XNFpB-000G7k-KO; Fri, 29 Aug 2014 09:38:17 +0300 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Mellanox 10gb driver? From: Daniel Braniss In-Reply-To: <8FD6967F-E130-4FBC-B93B-D5D508279E11@cs.huji.ac.il> Date: Fri, 29 Aug 2014 09:37:12 +0300 Message-Id: <76068BC4-886A-46F9-A535-EB2109FE1ECF@cs.huji.ac.il> References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> <53EF0260.9030806@selasky.org> <7D49FD54-AA37-4F04-952E-5A07754762E5@cs.huji.ac.il> <53EF09DC.60601@selasky.org> <8FD6967F-E130-4FBC-B93B-D5D508279E11@cs.huji.ac.il> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 06:51:29 -0000 hi all, I managed to have the card recognised, now working is a different story = :-) It sort of works, the console is full of: <6>mlx4_en: mlxen0: Link Up <6>mlx4_en: mlxen0: Link Up <6>mlx4_en: mlxen0: Link Up ... killing dhclient got rid of that. maybe the fact that my card is an =91engineering sample=92 have any = thing to do? without dhclient, and not diskless it seems to be doing ok. also, I can=92t get it working with a 15m Twinax cheers, danny On Aug 16, 2014, at 11:36 AM, Daniel Braniss = wrote: snipped ... >=20 > I solved the puzzle! > added > options OFED > device mlxen > device mlx4ib > device mthca > to my kernel config and that did it - not sure the last 2 are needed. > now to connect and check, but that will have to wait till tomorrow. >=20 > thanks, > danny >=20 >> --HPS >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 29 07:13:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A0523EC for ; Fri, 29 Aug 2014 07:13:04 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D54B1F35 for ; Fri, 29 Aug 2014 07:13:04 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id bj1so5833060pad.32 for ; Fri, 29 Aug 2014 00:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UFSrSZaFl+LNoM+gycuXrrjYeyJvQytDHdEJBQF1z4Y=; b=LziAczXhxjxpQ/NHMWs9FYssYof9GCyS/Sr1ou/Z/xHlAWmulmX3VcNFmlhFr7O3HX son810rXdPVTlkMGOkjE5PKQkBJ/djDIFXIUMBSSF3Mo9cE7zGCkG940N4IsXt/LQ7jU xbsSfWsUMALKX3fmid+iCPl9WkRsRt2qm3mo0YLNnHyzjk/ZF/mKaH5IJqm8LqrLEDpO zT4UpHwFT3nFWJBTZeO5Sn4XangTqzfuaQwlFmUZvaffGXKNPfKgVV1ijbtRJd6J8Oho /pRqJrispjQqVIN5TNYv2iNv1iUfN7aDyaCpB6ZTD4GvF78luOnbrOSYxqnhXghsTKGz 3kaQ== X-Received: by 10.68.65.36 with SMTP id u4mr12801869pbs.127.1409296383558; Fri, 29 Aug 2014 00:13:03 -0700 (PDT) Received: from [10.240.140.110] ([123.58.191.67]) by mx.google.com with ESMTPSA id xr10sm20763923pab.35.2014.08.29.00.13.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Aug 2014 00:13:03 -0700 (PDT) Content-Type: text/plain; charset="utf8"; Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: On changing rand(3) to random(3) in awk(1) X-Pgp-Agent: GPGMail (null) From: Chenguang Li In-Reply-To: <53FF574E.1090108@gmail.com> Date: Fri, 29 Aug 2014 15:12:44 +0800 Content-Transfer-Encoding: 8bit Message-Id: <78248D53-D8B6-4135-B900-74E0047F92F1@gmail.com> References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> <53FF574E.1090108@gmail.com> To: Vitaly Magerya X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 07:13:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Vitaly Magerya wrote: > On 08/28/14 16:28, Chenguang Li wrote: >> I am using RANDOM_MAX here to maintain the original code structure. >> I've updated my patch, please check the gist. Thanks! >> >> jmp_buf env; >> extern int pairstack[]; >> @@ -1522,7 +1522,7 @@ >> break; >> case FRAND: >> /* in principle, rand() returns something in 0..RAND_MAX */ >> - u = (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; >> + u = (Awkfloat) (random() % RANDOM_MAX) / RANDOM_MAX; >> break; >> case FSRAND: >> if (isrec(x)) /* no argument provided */ > > OK, so this part is wrong (and it is wrong in the original sources > too): this construction generates 0.0 twice as often as it generates > other numbers -- both when random() returns 0 and when it returns > RANDOM_MAX. The correct construction is this: Yes, I've noticed there's a fairness problem, 0 comes out more often. Since the original code is buggy too, do we need to be compatible with it? >> case FRAND: >> - /* in principle, rand() returns something in 0..RAND_MAX */ >> - u = (Awkfloat) (rand() % RAND_MAX) / RAND_MAX; >> + /* random() returns values in [0, RANDOM_MAX] */ >> + u = (Awkfloat) random() / (RANDOM_MAX + 1ul); >> break; > > Note that the "ul" part in "1ul" is vitally important: otherwise there > will be an overflow on systems where long is 32 bit wide. Alternatively > "1.0" can be used here instead. > > (Because this overflow may not be obvious in a casual reading, I'm not > a fan of defining RANDOM_MAX separately; I personally would insert the > actual number here directly). Thanks for pointing that out, I've modified the gist as your suggestion. Chenguang Li -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUACfzAAoJELG4cS+11lRhIFgQAII3b12r1JO+KPbnXfEdrsoA SFaRiG/Z6a8gQBpqTdUA4te9wT+FxQO081bipUv2po7Ys4MZOPkSJ8jh0jiZ02NX Vw95A+8TfUS5CWq78eqiSgP/x9UxomJ20qM5eUlhslRUX/8Lr4tpVQ3gGuCK0i5n bq3TgbJiNKaHPwSniVCDv2saS3lUGZp1QWxMK4ecwrmXoMlkNRpBygb2zRep2Q9p L9ccIQXmDZnZV5A/udIieGbvz5Gfk1utbOTwii41d+1j+zeWtkBlaMFDoWtNhqwp 31EIVQonSPTqStDAOptsixfI5O7G0mfa3nk1eDj+dUABg6qQbPtjWlG9uZL3JjZb A1ESdzlUSyxoOR2zoEkCgadAkMrbaqA2ziZvPB0o/ClwI99j3htUY+a9NJJmk43y qDQ0rBaQhj5TajUxsRir46sV70hpITBQP6EB4E18zWpT+GtgUkbPpW3CeKNcCuDk omTL6XZoS2jXyd62m9woDN3txddvU3XBJxiSL0Mo0hpUnwgg6GCtceAVkQvX6mck bCBZDPYzsIPMY30esJcL+NkLViwbVufthP/E8pWRU4Jn1a4bCrEA+WBkfTRhI53K Ph9zMVmZyD/SBwzbgi5eHYdAjTLjOAWyYQpPJ4vRQOe4iX9WNOPF36DjbnAUMLl/ f5sCba2r0hxdjksFQsDF =FBZK -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 29 08:39:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E091FFC for ; Fri, 29 Aug 2014 08:39:40 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D779B1964 for ; Fri, 29 Aug 2014 08:39:39 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id p9so2224708lbv.19 for ; Fri, 29 Aug 2014 01:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qD1volQVAHPW1QoUdoSmD3K+bRpXXs+XEqAvUZRVDTQ=; b=jG5YeB0aRY4RjhXw+E6qqwqE5k55DH/Lw4luf2KGww2aJx+IxuT76myQ7XvY1aFug1 4EVwYk3pNGQf3/Bd8zsXS3qVKIrF2yu0+XsUGpN4uMAYARyItP8TLHGvGZQVYI0HraIS l52LJqVVqkvRZp1WExVIZ9NBG96Sva4Ug9BF581VPCwrtBRWfqhON4SmINwLaWadmS6F CDXxZj69WZbmt1j17uLaO0d9LzXxmsZ+NWSvzeeDFxopstR4/QyjqvqkxKdODD+nZEHk ZXuet1PbNa1nmqXLA93A0Ch6HaKQsh4KKi/iGELAcgqNUN4U1z4hoJf5dCnHGxvkwgc9 7aFg== X-Received: by 10.152.4.9 with SMTP id g9mr10070847lag.14.1409301577768; Fri, 29 Aug 2014 01:39:37 -0700 (PDT) Received: from [172.29.2.131] (altimet-gw.cs2.dp.wnet.ua. [217.20.178.249]) by mx.google.com with ESMTPSA id f6sm4091770lae.7.2014.08.29.01.39.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Aug 2014 01:39:37 -0700 (PDT) Message-ID: <54003C42.1070309@gmail.com> Date: Fri, 29 Aug 2014 11:39:30 +0300 From: Vitaly Magerya User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Chenguang Li Subject: Re: On changing rand(3) to random(3) in awk(1) References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> <53FF574E.1090108@gmail.com> <78248D53-D8B6-4135-B900-74E0047F92F1@gmail.com> In-Reply-To: <78248D53-D8B6-4135-B900-74E0047F92F1@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 08:39:40 -0000 On 2014-08-29 10:12, Chenguang Li wrote: >> OK, so this part is wrong (and it is wrong in the original sources >> too): this construction generates 0.0 twice as often as it generates >> other numbers -- both when random() returns 0 and when it returns >> RANDOM_MAX. The correct construction is this: > > Yes, I've noticed there's a fairness problem, 0 comes out more often. Since > the original code is buggy too, do we need to be compatible with it? I see no reason why we would. Interestingly enough, GNU awk has this bug as well (and I am entirely too lazy to report it). > Thanks for pointing that out, I've modified the gist as your suggestion. Looks good to me. You might want to open a bug report with that patch, as it's not clear if any committer is reading this thread. From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 29 08:56:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 680929D5 for ; Fri, 29 Aug 2014 08:56:13 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A3B71B39 for ; Fri, 29 Aug 2014 08:56:13 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id lj1so6089861pab.28 for ; Fri, 29 Aug 2014 01:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9589ska9TSPiUdbjAklb26/Frooidq2oorRsE59Sd00=; b=flwCXdS+Y3lRudqFqqD5q2nUdYyk5KIIFIK1XwCSLxi9wTxLoGS6LiT7eU4r1dmoTY djrkDb4FCZhGeNfAEnahZZN3fM149/l2fhflYaW9OF02FpQ6fb5cMgIVWJajLCmmePC/ q2iZbCUAlcDKONu4xBqUG+8w49kYAzV7TJdaXy4IYGO59UEOgQOZM3tY9gN+uj/QDAfA AxzloiiJauaL5/g3AXtaYTi6QqR3/6UR1pjpWSNr4YS6nFBGHJ4z4ZGR3guVjMq5TVmc FoKTXBmO9ds/j+WPcxhoQnRrEybiRIUjC0DueF1hIQtLNJl7+3KtYyFI+RcJ8iKm21yy bh+A== X-Received: by 10.70.34.235 with SMTP id c11mr13760819pdj.76.1409302572579; Fri, 29 Aug 2014 01:56:12 -0700 (PDT) Received: from [10.240.140.110] ([123.58.191.67]) by mx.google.com with ESMTPSA id bx6sm21559530pab.48.2014.08.29.01.56.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Aug 2014 01:56:12 -0700 (PDT) Content-Type: text/plain; charset="utf8"; Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: On changing rand(3) to random(3) in awk(1) X-Pgp-Agent: GPGMail (null) From: Chenguang Li In-Reply-To: <54003C42.1070309@gmail.com> Date: Fri, 29 Aug 2014 16:55:57 +0800 Content-Transfer-Encoding: 8bit Message-Id: <97E2800A-1AC1-4595-872B-E4576D4B5FFB@gmail.com> References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> <53FF574E.1090108@gmail.com> <78248D53-D8B6-4135-B900-74E0047F92F1@gmail.com> <54003C42.1070309@gmail.com> To: Vitaly Magerya X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 08:56:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Vitaly Magerya wrote: > On 2014-08-29 10:12, Chenguang Li wrote: >> ... ... >> >> Yes, I've noticed there's a fairness problem, 0 comes out more often. Since >> the original code is buggy too, do we need to be compatible with it? >> > I see no reason why we would. > > Interestingly enough, GNU awk has this bug as well (and I am entirely > too lazy to report it). Yes, I came across that line a few days ago. OSX's awk also has this bug, judging from their code[1]: u = (Awkfloat) (random() % RAND_MAX) / RAND_MAX; >> Thanks for pointing that out, I've modified the gist as your suggestion. > > Looks good to me. You might want to open a bug report with that patch, > as it's not clear if any committer is reading this thread. I guess Peter (roam@) is one of the committers? [1] http://www.opensource.apple.com/source/awk/awk-18/src/run.c Chenguang Li -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUAEAjAAoJELG4cS+11lRhJWcP/jo5UwRDrOrqJhatH8iZC4P0 XqaOZh35tAgNdzWKS9GtTirUVWcCNcIqN6VfqYLjTFBnXa1bKk2KntwzW2oCd86J Cl/JaMMaiIqoMGhG1D4i2rue73cl+XWhX8EiRN3BhcLLWkVdYGDzwKkTFzE4t35Y FxCfNhIr/05Ek6rsAsGiEgGIuOpztUL7QpYTrhaP/SmBD8ffdL56MdgxCryR9Z5c 321Rt14CAhlzYAlwjNL0KLetQDIufuCrUmlnsip0PeYXzzx0F/L4Uox9eBj0vPTW bg6IYTOKpYhtj2vgKqkK8iWMxOSpCqBIMd2WgfofVxKgWBRMb3FY1yHzrpiu4cb4 osAEfCLp9NCMArFQZB563yuM2PhhSSGw561JJhUNNtKv7kCMYeXFOdEGesggcOhK 8XS1qQHzymAzNlysNoBDD56KhNgMwLxLSxPZEWCqF/rLUwumQC+g5/OO/DXsD2pa 1ZnwEMIz1f6uLqdpTpB3plRfmKlikFrDc9F/yCZbOSXBO/w8iZeQucEjoe57HaXE jAbkCJfAoJtA8E+YwgZhaWJOwDOI2IUMrILfyE6T5VqHeTDeu/U+449ykiv+cU/4 uNJFc0sqI/+Ww/ZVjkruOiH056+IUM4jmaAMxQZ3XMG5pEQccLe/rqCyLcvzYTr3 9c7HvK6f0iUsgKCHcwgn =Pxqp -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 29 09:13:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D6164AC for ; Fri, 29 Aug 2014 09:13:17 +0000 (UTC) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by mx1.freebsd.org (Postfix) with ESMTP id 04FE91D63 for ; Fri, 29 Aug 2014 09:13:16 +0000 (UTC) Received: from straylight.m.ringlet.net (unknown [78.90.13.150]) by nimbus.fccf.net (Postfix) with ESMTPSA id 4E9D12E7 for ; Fri, 29 Aug 2014 12:13:13 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 2540047 by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Fri, 29 Aug 2014 12:12:10 +0300 Date: Fri, 29 Aug 2014 12:12:10 +0300 From: Peter Pentchev To: Chenguang Li Subject: Re: On changing rand(3) to random(3) in awk(1) Message-ID: <20140829091210.GB2200@straylight.m.ringlet.net> Mail-Followup-To: Chenguang Li , Vitaly Magerya , freebsd-hackers@freebsd.org References: <53FEFBB8.5040305@gmail.com> <20140828131526.GA2385@straylight.m.ringlet.net> <5C40F611-22EB-49E4-8925-37922E771C0F@gmail.com> <53FF574E.1090108@gmail.com> <78248D53-D8B6-4135-B900-74E0047F92F1@gmail.com> <54003C42.1070309@gmail.com> <97E2800A-1AC1-4595-872B-E4576D4B5FFB@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QTprm0S8XgL7H0Dt" Content-Disposition: inline In-Reply-To: <97E2800A-1AC1-4595-872B-E4576D4B5FFB@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, Vitaly Magerya X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 09:13:17 -0000 --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 29, 2014 at 04:55:57PM +0800, Chenguang Li wrote: > Vitaly Magerya wrote: > > On 2014-08-29 10:12, Chenguang Li wrote: > >> Thanks for pointing that out, I've modified the gist as your suggestio= n. > >=20 > > Looks good to me. You might want to open a bug report with that patch, > > as it's not clear if any committer is reading this thread. >=20 > I guess Peter (roam@) is one of the committers? Er... not really, sorry :) A couple of years ago I gave my commit bit in for safekeeping since other things ate up all my FreeBSD time, and ever since then I've thought about returning, but not yet. I can't really commit your changes, sorry. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --QTprm0S8XgL7H0Dt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUAEPlAAoJEGUe77AlJ98TMeIP/AuXsdoelV+dOgWyIkioghpU Clb5s4qimw/eTGPWNRH2WD7Fib8gDdulMhmb3X7fga4vV6WNSijUPkKA3iU8QXyr pj8IEEQwN/fEEtM1qX3Hj0rO4aWYd800EAWTSLQ3ukKUMOE63O8Vu4Td4IGg0LyZ 7rGwcd3nDUn/S29BG1LcKZ6UxuIbWERGBuTF6cKqkDik+BFO1fPwJ+KUdyCDmCBJ mJj4N9dLQOwIwJE6L97BCYmj5OST3XwEP9sPIn9LbgmMSq3Q3FDIkIR4wfeWQwSe +HhWTIm1MiawffuWbiKx3IY/PEPU7eeObPCeqKkffY+XzRYz6XZAJ9jL2HI4p2/q U/2RUPeohszI9r4tOGFdDmA0tpP0E6XcLRrYSczzG5UtJYTOb7HJCgrAZKPakgun JqWaSBUp7VNNv6U6ma1+CYbh78MLLVyAwn3FFf3hpU4i3HAtFOSMVlSftZixmKKB xU4h0weKOXEHheAhizxjiRwYibPPH8x+mlh/R9vSLtSPxkK2g96mNOYI/n8tETBr ZCY1wO/CVBp3dBYX93yoVxBlGVYqk43DV5yjkPWIRubDiedzn1T8MFM90cVDSzQl L+dILDbEmsnN/rHDB31+aSoR4sExtDbPAUzi3wbNNDIAjYLp5A109OR6yDvk+DOG xX8Q3US0y+668S1hzsX7 =+VHZ -----END PGP SIGNATURE----- --QTprm0S8XgL7H0Dt-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 29 13:29:12 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 857A790E for ; Fri, 29 Aug 2014 13:29:12 +0000 (UTC) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B0331CED for ; Fri, 29 Aug 2014 13:29:11 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id ij19so2417123vcb.40 for ; Fri, 29 Aug 2014 06:29:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=dDX5XWNeY4w4/48VH/RML8kV/coTWus84/DAkTJi4Sk=; b=FHMgM3+HJhGopTzao/YDeMD+t7mY+t0HvjjXY1rj+TcYWrdM6DakXJO0DvWhP7MfDL Y+u7S2flceLSZp55NGkTjzupOtZ1YLciGee9vodF41hyxqdEPLZYECmJtDjwYa/7egyP vToK21+9FjKV3qhbw+TlWAPqqWSCGVj/rqRPupdVojd1yHE9/8+oV1DXTlGvXISzdJeT /eA5gBv/+K6m3xXHigViDzFRHqqwfd9Mt0QCoLA4GPjrGPOR7/pYbrS1/RbM5rbLLv41 tPLOgi5pIVAvB15q/4eQQIWxLVmkdeEbz/wxw1mJ4aCQySsw/Tgg34e8ENqdhEwhYcez zixA== X-Gm-Message-State: ALoCoQmo/3hvZQ4q//mkuIvi6wjEcWQ+oSxfJcRLaff7HNV0P4oPotKsGQgif/5EhjUghRiQ6fa1 X-Received: by 10.220.122.194 with SMTP id m2mr8603411vcr.17.1409318945019; Fri, 29 Aug 2014 06:29:05 -0700 (PDT) Received: from [97.32.34.146] (146.sub-97-32-34.myvzw.com. [97.32.34.146]) by mx.google.com with ESMTPSA id t7sm21174273vdg.26.2014.08.29.06.29.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Aug 2014 06:29:03 -0700 (PDT) References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> <53EF0260.9030806@selasky.org> <7D49FD54-AA37-4F04-952E-5A07754762E5@cs.huji.ac.il> <53EF09DC.60601@selasky.org> <8FD6967F-E130-4FBC-B93B-D5D508279E11@cs.huji.ac.il> <76068BC4-886A-46F9-A535-EB2109FE1ECF@cs.huji.ac.il> Mime-Version: 1.0 (1.0) In-Reply-To: <76068BC4-886A-46F9-A535-EB2109FE1ECF@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Mark Saad Subject: Re: Mellanox 10gb driver? Date: Fri, 29 Aug 2014 09:23:13 -0400 To: Daniel Braniss Cc: Hans Petter Selasky , "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 13:29:12 -0000 > On Aug 29, 2014, at 2:37 AM, Daniel Braniss wrote: >=20 > hi all, > I managed to have the card recognised, now working is a different story :-= ) > It sort of works, the console is full of: >=20 > <6>mlx4_en: mlxen0: Link Up > <6>mlx4_en: mlxen0: Link Up > <6>mlx4_en: mlxen0: Link Up > ... >=20 > killing dhclient got rid of that. >=20 > maybe the fact that my card is an =E2=80=98engineering sample=E2=80=99 ha= ve any thing to do? > without dhclient, and not diskless it seems to be doing ok. > also, I can=E2=80=99t get it working with a 15m Twinax >=20 I ran into an issue with intel 10gb cards where the twinax cables from Cisco= would not work with the intel nics . You issue could be related , double c= heck the twinax cables are supported . Truth be told it's the integrated sfp= + that is the issue . -- Mark saad | mark.saad@longcount.org =20 > cheers, > danny >=20 >> On Aug 16, 2014, at 11:36 AM, Daniel Braniss wrote:= >> snipped ... >>=20 >> I solved the puzzle! >> added >> options OFED >> device mlxen >> device mlx4ib >> device mthca >> to my kernel config and that did it - not sure the last 2 are needed. >> now to connect and check, but that will have to wait till tomorrow. >>=20 >> thanks, >> danny >>=20 >>> --HPS >>=20 >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 29 23:59:40 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BE6111F; Fri, 29 Aug 2014 23:59:40 +0000 (UTC) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E8951C55; Fri, 29 Aug 2014 23:59:39 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id s7TNWtTr046045; Fri, 29 Aug 2014 17:32:55 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201408292332.s7TNWtTr046045@elf.torek.net> From: Chris Torek To: Benjamin Kaduk Subject: Re: Can anyone help clarify details about the FreeBSD system call interface? In-reply-to: Your message of "Thu, 28 Aug 2014 16:35:44 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46043.1409355175.1@elf.torek.net> Date: Fri, 29 Aug 2014 17:32:55 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Fri, 29 Aug 2014 17:32:55 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, Steven Stewart-Gallus X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 23:59:40 -0000 >> int sys_sstk(int incr); [...] >> Did sys_sstk use to do something in the past and is now just legacy? >svn blame says that the whole implementation dates from r1541. Looks like >it was never implemented. Some googling indicates that it was a planned >routine to set the stack size, which was never implemented, anywhere. It was the stack equivalent of sbrk(). Stacks always grew automatically but could not be shrunk. Before mmap/munmap, this was supposed to let you pre-allocate the stack if you wanted, or shrink it. >> int sys_vadvise(int anom); [...] >> Did sys_vadvise use to do something in the past and is now just >> legacy? >The locking comments were added in r79224, but the implementation is >otherwise from r1541, i.e., it was never implemented. Again this is from the pre-mmap() days. It actually did do something once (in 4.1BSD), but when mmap() went in it was replaced with madvise(), which is finer grained (per page rather than entire process) and has more options. (Franz Lisp used vadvise() when doing mark-and-sweep GC, if anyone here remembers Franz Lisp from UCB. :-) Notifying the pager of sequential behavior, where LRU is worst and you want MRU paging, was helpful back when a VAX with 8 MB of RAM had a lot of memory.) Chris