From owner-freebsd-hackers@freebsd.org Sun Jan 22 00:08:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0554ECB016C; Sun, 22 Jan 2017 00:08:13 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C825C6A; Sun, 22 Jan 2017 00:08:12 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id v0LNpVDb043310 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Jan 2017 15:51:31 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id v0LNpVBV043309; Sat, 21 Jan 2017 15:51:31 -0800 (PST) (envelope-from jmg) Date: Sat, 21 Jan 2017 15:51:31 -0800 From: John-Mark Gurney To: Aijaz Baig Cc: "Greg 'groggy' Lehey" , FreeBSD Hackers , freebsd-scsi@freebsd.org Subject: Re: Understanding the rationale behind dropping of "block devices" Message-ID: <20170121235131.GF1768@funkthat.com> Mail-Followup-To: Aijaz Baig , Greg 'groggy' Lehey , FreeBSD Hackers , freebsd-scsi@freebsd.org References: <20170116071105.GB4560@eureka.lemis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-ALPHA2 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 21 Jan 2017 15:51:31 -0800 (PST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 00:08:13 -0000 Aijaz Baig wrote this message on Mon, Jan 16, 2017 at 14:19 +0530: > Nevertheless my question still holds. What does 'removing support for block > device' mean in this context? Was what I mentioned earlier with regards to > my understanding correct? Viz. all disk devices now have a character (or > raw) interface and are no longer served via the "page cache" but rather the > "buffer cache". Does that mean all disk accesses are now direct by passing > the file system?? One of the other reasons block devices were removed was that if there was a write error on the underlying device, there was no way for the writer to know that the write failed. This could/would lead to corrupted data which is bad. -- 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 Jan 22 05:57:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A206CBCAD7 for ; Sun, 22 Jan 2017 05:57:24 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id CB9BE6F for ; Sun, 22 Jan 2017 05:57:22 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 39582695; Sun, 22 Jan 2017 11:52:52 +0600 Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.transneft.ru (8.14.9/8.14.9) with ESMTP id v0M5vJwb000405; Sun, 22 Jan 2017 12:57:19 +0700 (KRAT) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: (from sudakov@localhost) by admin.sibptus.transneft.ru (8.14.9/8.14.9/Submit) id v0M5vGbo000404; Sun, 22 Jan 2017 12:57:16 +0700 (KRAT) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to sudakov+freebsd@sibptus.tomsk.ru using -f Date: Sun, 22 Jan 2017 12:57:16 +0700 From: Victor Sudakov To: Joe Nosay Cc: Victor Sudakov , FreeBSD Hackers Subject: Re: make.conf options and poudriere Message-ID: <20170122055716.GA307@admin.sibptus.transneft.ru> References: <20170120091718.GA73239@admin.sibptus.transneft.ru> <20170120163158.GA78266@admin.sibptus.transneft.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 05:57:24 -0000 Joe Nosay wrote: > > > > Are you suggesting some alternative to poudriere? Of course I can > > create a dedicated ports tree in poudriere, edit the Makefile manually > > and never update that special tree. But isn't it something of an overkill > > if I just want to protect my precious changes from being overwritten > > by the next ports tree update? > Keep the untouched file within the standard /usr/ports directory and build > the edited file in the jail. Whatever differences there are, you will be > able to share with the mailing list. Which means the edited package will not make it into one of the repositories I publish via poudriere for my hosts? This would be an inconvenience. I think I'd better go with the ".if ${.CURDIR.....}" clause in make.conf. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 From owner-freebsd-hackers@freebsd.org Sun Jan 22 08:02:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 473B3CBCC14; Sun, 22 Jan 2017 08:02:44 +0000 (UTC) (envelope-from phk@freebsd.org) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0D233A7D; Sun, 22 Jan 2017 08:02:43 +0000 (UTC) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id ADC22273DA; Sun, 22 Jan 2017 08:02:35 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v0M82Ynx074697; Sun, 22 Jan 2017 08:02:35 GMT (envelope-from phk@freebsd.org) To: John-Mark Gurney cc: Aijaz Baig , "Greg 'groggy' Lehey" , FreeBSD Hackers , freebsd-scsi@freebsd.org Subject: Re: Understanding the rationale behind dropping of "block devices" In-reply-to: <20170121235131.GF1768@funkthat.com> From: "Poul-Henning Kamp" References: <20170116071105.GB4560@eureka.lemis.com> <20170121235131.GF1768@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74695.1485072153.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Jan 2017 08:02:34 +0000 Message-ID: <74696.1485072154@critter.freebsd.dk> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 08:02:44 -0000 -------- In message <20170121235131.GF1768@funkthat.com>, John-Mark Gurney writes: >Aijaz Baig wrote this message on Mon, Jan 16, 2017 at 14:19 +0530: >> Nevertheless my question still holds. What does 'removing support for b= lock >> device' mean in this context? Was what I mentioned earlier with regards= to >> my understanding correct? Viz. all disk devices now have a character (o= r >> raw) interface and are no longer served via the "page cache" but rather= the >> "buffer cache". Does that mean all disk accesses are now direct by pass= ing >> the file system?? > >One of the other reasons block devices were removed was that if there >was a write error on the underlying device, there was no way for the >writer to know that the write failed. This could/would lead to corrupted >data which is bad. This paper hopefully answers a lot of the questions: https://www.usenix.org/conference/bsdcon02/rethinking-dev-and-devices-= unix-kernel -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Sun Jan 22 13:37:57 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41102CBCB41 for ; Sun, 22 Jan 2017 13:37:57 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF6EE857 for ; Sun, 22 Jan 2017 13:37:56 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id k86so80946363lfi.0 for ; Sun, 22 Jan 2017 05:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IREjVZ9sj+SqVYT8/F/ZGg+aawx+uNtGzmj6VZMEPgw=; b=VROSS2Ei26IvHui5b97/idWJU7lvo7IUgPtnBMgJfq7BKPLygXMJD+TIe8yUYODdHt seX+DelStedsmgX7AJlrvmc2pMCWgseNv6U3JtS+J9JMjlwLgIyE3Qr1WskPXkLDfkCr y1CtEb4z9WqTIGZZr8gLGTZ/ZUmTUKSjgBb/VwBKmJuPngx6gCpPDo6k/LFfuJdTwAmO 2cVC0cjSiOOj9Jj7SnrYA0ATwmj4fnpK1SC0A/480Dwtv6I4arA/tmADwi+KFEz8lKEO 1meFy39CaG0c2ItO/3j3IaYIeY9TREeW1J3vOxFT/dk3EmltrDO85Avii/DY70l2DOBC 1+CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IREjVZ9sj+SqVYT8/F/ZGg+aawx+uNtGzmj6VZMEPgw=; b=TOabnjX/DHaz/l+kSfv+xg659M8NHU4F1mF/E03hREb9VqhceOO6wdg9mz0Yv3VAcc /1C/KQBcHEBt6deL2UA/uirRvWyCpa9w8O2QdEZXHnK5r4097Fg46b+HRHE4uQopH8+C AaVJu7KkImvtTYX/xu3PozfwBarwHduJ/elUd2c23MpD/8s+fxLyUsoGnJP/+LBczsAc wC543EH2A+aINxAWttu6A8Mbtc2EQYQu3qXbEe53AzClptROZtvgnSgYe7ycsyyg89ns tp76mLawa/pIPY3+UeZzbLg8h64w9nQTwc2VAjivCtzFFzu3pfP5M/z7RDbMS5Wfpsar XsEg== X-Gm-Message-State: AIkVDXLwJiQhVEilBDKkJl1AU86dPKNYuT1tBqnaGG/CGsKsNn4Mj/1GGftQlmjSr2txo2CBy8VmLIvHZ2AsUA== X-Received: by 10.46.69.215 with SMTP id s206mr10557917lja.26.1485092274758; Sun, 22 Jan 2017 05:37:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.79.15 with HTTP; Sun, 22 Jan 2017 05:37:54 -0800 (PST) From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Sun, 22 Jan 2017 14:37:54 +0100 Message-ID: Subject: CURRENT panics on boot in VirtualBox To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 13:37:57 -0000 Hi, I get not reply in @questions so sending it here again. I can't get FreeBSD 12 r311461 to boot in VirtualBox. I'm using this image: http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/12.0-CURRENT/i386/20170105/FreeBSD-12.0-CURRENT-i386-20170105-r311461.vmdk.xz. VirtualBox version is 5.1.14 (pkg installed). FreeBSD panics during boot with the following message: panic: atpic_assign_cpu: bad cookie I tried disabling ACPI to no luck. I can boot FreeBSD 11 STABLE with the latest snapshot without problems though. I would need this to test one of my ports that breaks due to a change in zlib in -CURRENT. Any ideas? Thanks in advance. From owner-freebsd-hackers@freebsd.org Tue Jan 24 01:21:07 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 562A9CBD2B0 for ; Tue, 24 Jan 2017 01:21:07 +0000 (UTC) (envelope-from derrick.mckee@gmail.com) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11850A34 for ; Tue, 24 Jan 2017 01:21:07 +0000 (UTC) (envelope-from derrick.mckee@gmail.com) Received: by mail-vk0-x22d.google.com with SMTP id t8so102798677vke.3 for ; Mon, 23 Jan 2017 17:21:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=tEHG1rb3f8tMPQq7kR58L7PXngCQjaXQevG2WWVYMVQ=; b=RmcRZnXW0m2rfxPGgEIdvo7Xpqs3qHB8VtNuU1nsDjAypJD1SrTPos3fOzS/1Ztzte 81q8ZoyKJB5GS+iH1rRlgmXzzKGwmv+7R2v+qBn6JN/tA0xgXQBRTf0pwpr1DnW+vCsO 7CpcCc2iy4i7uM7zIqPWtH8pwztXzkxMKy8+Trzt592OYMNCJxWzEaFN0+D+ia1QDW5x diFsY1tHOyE/NHFDNl1QDMfcEv6AZztt1Mgfi2I1wmMXR0g8baZJcCpTXfe6AmcR1Tnc HevMbv/7+2LdKJqPsgkiNcX/Rh9n1WcF+qq7iM/nZUpXh0bazpoMx/hXQ+zjxU8/DO8G layw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tEHG1rb3f8tMPQq7kR58L7PXngCQjaXQevG2WWVYMVQ=; b=VyIJO9pLeooXFINWPy4F5hwOaj8rIB5FhA/qzQ+TSqdrc80Ryz3ROkTGDWDCFfET+h rDRYojh9JkAr6CQTPwvTiHOrz/2OuQhMRtLImZJQSDhO48X7uSYekSUWo3hnDFKVUjqk A4vRClhGFpnL4mTIFgbMRNG9VvhuzQgjpM2lH7++x1nWYSo6eqotxjNMYPBE671OCSa+ F2hVzj3kaK5MS/cjEQ4KwUiB7dkQh9mVBRkVU5KeMY3Zy6dCJT6dDIepWySe/hC+S79S 9+aysbuERuwL1hOdZsYuXP3nKGR/x6VVXkudKPV8Keb2LSfgsQ7XLNPdbN91T6CGZJzN sgXw== X-Gm-Message-State: AIkVDXI5qZq1r5z8QEIYlOECdtK0mlJBfi7aPEaitgVIaqUZGz9GKOyEs9bNJGKHo8UYUyf217V6z0ylboqVwQ== X-Received: by 10.31.68.130 with SMTP id r124mr14488551vka.98.1485220865810; Mon, 23 Jan 2017 17:21:05 -0800 (PST) MIME-Version: 1.0 From: Derrick McKee Date: Tue, 24 Jan 2017 01:20:54 +0000 Message-ID: Subject: Missing pthread support for custom libc To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 01:21:07 -0000 Hi, I've compiled libc using a custom version of clang, and it seems to be missing pthread support. When I try to compile Firefox and use my version of libc, I get the following error: checking for pthread_create in -lpthreads... no checking for pthread_create in -lpthread... no checking for pthread_create in -lc_r... no checking for pthread_create in -lc... no configure: error: --with-pthreads specified for a system without pthread support DEBUG: DEBUG: int main() { DEBUG: pthread_create() DEBUG: ; return 0; } DEBUG: configure:10603: checking for pthread_create in -lc DEBUG: configure:10622: /home/dmc/install/bin/clang -std=gnu99 -o conftest -O2 -pipe -pthread -static -g -mllvm -hexsafe-analysis -Wno-expansion-to-defined -nostdlib -I/usr/src/include -D__GNUC_VA_LIST -D_VA_LIST_DECLARED /usr/src/lib/csu/amd64/crt*.o -O3 -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -Qunused-arguments -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_C99_MATH_TR1 -D_DECLARE_C99_LDBL_MATH -isystem/usr/local/include -DLIBICONV_PLUG -pthread -L/usr/src/lib/libc++ -L/usr/src/lib/libc -L/usr/lib -lc++ -lc -L/usr/local/lib -Wl,-rpath,/usr/local/lib/firefox -Wl,--as-needed -fstack-protector -Wl,-z,noexecstack -Wl,-z,text conftest.c -lc 1>&5 DEBUG: /tmp/conftest-e31ca2.o: In function `main': DEBUG: /usr/ports/www/firefox/work/firefox-50.1.0/obj-x86_64-unknown-freebsd11.0/configure:10618: undefined reference to `pthread_create' DEBUG: clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation) DEBUG: configure: failed program was: DEBUG: #line 10611 "configure" DEBUG: #include "confdefs.h" DEBUG: /* Override any gcc2 internal prototype to avoid an error. */ DEBUG: /* We use char because int might match the return type of a gcc2 DEBUG: builtin and then its argument prototype would still apply. */ DEBUG: char pthread_create(); DEBUG: DEBUG: int main() { DEBUG: pthread_create() DEBUG: ; return 0; } DEBUG: configure: error: --with-pthreads specified for a system without pthread support I've added -pthread to both CFLAGS and LDFLAGS when I compile libc, and you can see that it is included when I attempt to compile Firefox. Any ideas on what I am missing? Thanks. - Derrick McKee -- Derrick McKee Ph.D. Student at Purdue University From owner-freebsd-hackers@freebsd.org Tue Jan 24 02:54:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35FF3CBE33B for ; Tue, 24 Jan 2017 02:54:12 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 212C08D5 for ; Tue, 24 Jan 2017 02:54:11 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from imac.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 4FE885649D; Mon, 23 Jan 2017 20:54:10 -0600 (CST) Subject: Re: Missing pthread support for custom libc To: Derrick McKee , "freebsd-hackers@freebsd.org" References: From: Eric van Gyzen Message-ID: <6105991c-64a2-758b-049b-d3409b612501@vangyzen.net> Date: Mon, 23 Jan 2017 20:54:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 02:54:12 -0000 On 1/23/17 7:20 PM, Derrick McKee wrote: > I've compiled libc using a custom version of clang, and it seems to be > missing pthread support. When I try to compile Firefox and use my version > of libc, I get the following error: > > checking for pthread_create in -lpthreads... no > checking for pthread_create in -lpthread... no > checking for pthread_create in -lc_r... no > checking for pthread_create in -lc... no > configure: error: --with-pthreads specified for a system without pthread > support FreeBSD's pthread support is provided by libpthread, a.k.a. libthr, the source for which is in base/lib/libthr. Cheers, Eric From owner-freebsd-hackers@freebsd.org Tue Jan 24 03:18:11 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08860CBF02D for ; Tue, 24 Jan 2017 03:18:11 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C40361AD1 for ; Tue, 24 Jan 2017 03:18:10 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id v0O3I2eC032238; Mon, 23 Jan 2017 22:18:02 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Mon, 23 Jan 2017 22:18:03 -0500 (EST) Date: Mon, 23 Jan 2017 22:18:02 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Derrick McKee cc: "freebsd-hackers@freebsd.org" Subject: Re: Missing pthread support for custom libc In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 03:18:11 -0000 On Tue, 24 Jan 2017, Derrick McKee wrote: > Hi, > > I've compiled libc using a custom version of clang, and it seems to be > missing pthread support. When I try to compile Firefox and use my version > of libc, I get the following error: > > checking for pthread_create in -lpthreads... no > checking for pthread_create in -lpthread... no > checking for pthread_create in -lc_r... no > checking for pthread_create in -lc... no > configure: error: --with-pthreads specified for a system without pthread > support [ ... ] > I've added -pthread to both CFLAGS and LDFLAGS when I compile libc, and you > can see that it is included when I attempt to compile Firefox. Any ideas > on what I am missing? Thanks. > Is this a custom libc _and_ a custom clang? As for clang, you'll need to make sure your version of it supports the -pthread option. Check the source code for FreeBSD's native version to see how that is brought in. It doesn't look like your version of clang properly supports it. If you are building apps (firefox) from ports and using your custom clang, can also try forcing the threads library by setting PTHREAD_LIBS=-lpthread in /etc/make.conf. This should override the default -pthread option. If you are also using a custom libc, then you may run into other problems as there are some internal libc<->libpthread interfaces. -- DE From owner-freebsd-hackers@freebsd.org Tue Jan 24 04:40:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DCDACBF0A3; Tue, 24 Jan 2017 04:40:17 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 154AA3EC; Tue, 24 Jan 2017 04:40:17 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id r126so163416730wmr.0; Mon, 23 Jan 2017 20:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6TVJwf6yjP1d56UpF8cXGajYWsnDZcxv0oePv8iA1Oc=; b=Yy9EgPKSO0EVxcKnrN/1odQq0EgPlTDJHP7tvLXyL6p9azpJyM7ZrK3NIY7mue3+B4 5GCfPB8DDCgFkzDbMZLV3wIEsuK4HiEiOwHatti0ic9U5yNCPS88cLU6zRfT3po9gszW BqH7n3UjKlwQSGDHgb9bxmnBNbDRky8WmoIylG97hCEzXXd0MUbGa5noudbSUzaVs71x EY49i8Ap9FWwuBX6WMua4D324bnvdee+/3TCkIWgwtM5hR8oGwfpnyrXpqvubvxO6GBJ MAt8zVCmYVYuoF+hfhSdueZhWX6XaRLo4wSQpe1JsjkVstyltumj6oIvnkz+Ua7ctkKW qaOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6TVJwf6yjP1d56UpF8cXGajYWsnDZcxv0oePv8iA1Oc=; b=r4xsFhSivGLEHylJ2g1xe+bSeZtNpp8Kht5H93mz5wlGJj1yJ6y0xVMzdQLPkVTrIG +Toom0fDKbAkXSbwGRLu0s4BOkKCq+LGUPGFqrR/8wRjn9v/A1qHsuFLkFY+7ZNjgITf RdJtGPxK6db+tE0b2YO9Uv/9ILbTC0XVBI4i8vDMJwkY7S0ymPGP5rbjtPjyPFBubzaw hXSB8XptFwh0EIXs8RdAwbhwaFbv/6LFp9AhKxIG1tbZeiSssJSONavjpykGl/LEoesa jrbBqlelwgqF+4bbYehluFfThDFYTrhpGYS8VesO+AnHeNF6PA4kTDjDudxSIIYtgCAq +Qgg== X-Gm-Message-State: AIkVDXKqcAv6/Ns4U32KVv6qTMbK6xjeEbpyuIt/uVnhMu/Yfrh8KmEqjgUlJMUy8fN33y61TCLZgIe3JHqBPA== X-Received: by 10.223.165.87 with SMTP id j23mr32293490wrb.79.1485232815040; Mon, 23 Jan 2017 20:40:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.189.103 with HTTP; Mon, 23 Jan 2017 20:40:14 -0800 (PST) In-Reply-To: <74696.1485072154@critter.freebsd.dk> References: <20170116071105.GB4560@eureka.lemis.com> <20170121235131.GF1768@funkthat.com> <74696.1485072154@critter.freebsd.dk> From: Aijaz Baig Date: Tue, 24 Jan 2017 10:10:14 +0530 Message-ID: Subject: Re: Understanding the rationale behind dropping of "block devices" To: Poul-Henning Kamp Cc: John-Mark Gurney , "Greg 'groggy' Lehey" , FreeBSD Hackers , freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 04:40:17 -0000 Oh thank you Poul. This would hopefully cover almost everything I need to know! On Sun, Jan 22, 2017 at 1:32 PM, Poul-Henning Kamp wrote: > -------- > In message <20170121235131.GF1768@funkthat.com>, John-Mark Gurney writes: > >Aijaz Baig wrote this message on Mon, Jan 16, 2017 at 14:19 +0530: > >> Nevertheless my question still holds. What does 'removing support for > block > >> device' mean in this context? Was what I mentioned earlier with regards > to > >> my understanding correct? Viz. all disk devices now have a character (or > >> raw) interface and are no longer served via the "page cache" but rather > the > >> "buffer cache". Does that mean all disk accesses are now direct by > passing > >> the file system?? > > > >One of the other reasons block devices were removed was that if there > >was a write error on the underlying device, there was no way for the > >writer to know that the write failed. This could/would lead to corrupted > >data which is bad. > > This paper hopefully answers a lot of the questions: > > https://www.usenix.org/conference/bsdcon02/rethinking-dev-and-devices- > unix-kernel > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -- Best Regards, Aijaz Baig From owner-freebsd-hackers@freebsd.org Tue Jan 24 08:29:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1D98CBE00F for ; Tue, 24 Jan 2017 08:29:00 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 81110F9A for ; Tue, 24 Jan 2017 08:29:00 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 9B4E25A9F12; Tue, 24 Jan 2017 08:20:20 +0000 (UTC) Date: Tue, 24 Jan 2017 08:20:20 +0000 From: Brooks Davis To: Derrick McKee Cc: "freebsd-hackers@freebsd.org" Subject: Re: Missing pthread support for custom libc Message-ID: <20170124082020.GA7873@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 08:29:00 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2017 at 01:20:54AM +0000, Derrick McKee wrote: > Hi, >=20 > I've compiled libc using a custom version of clang, and it seems to be > missing pthread support. When I try to compile Firefox and use my version > of libc, I get the following error: >=20 > checking for pthread_create in -lpthreads... no > checking for pthread_create in -lpthread... no [...] > I've added -pthread to both CFLAGS and LDFLAGS when I compile libc, and y= ou > can see that it is included when I attempt to compile Firefox. Any ideas > on what I am missing? Thanks. Your clang's library search path clearly doesn't include a libpthread. Adding -pthread to CFLAGS and LDFLAGS is unlikely to be to solution since it just adds -lpthread to the link command which the generated Makefile will do if it's found during configure. Also, if you're using -nostdlib to link your custom libc, it looks like -pthread simply does nothing at all. If you can find the clang command used to run the checks above in your configure log, you may find the result of adding -### to the command informative. -- Brooks --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYhw5EAAoJEKzQXbSebgfAwbYH/RBLUKPpbxczB6pSQetzxFY0 AHN/RqzqzOVLZ94oisO101oIKzUcjtyOGUZlrm5HwZCqQvD0+yhoduMG6t8rccYV RRR0JcfRhjxLYmZlgTCaDjiM1PTTKWhDeiLfHbLNY2Id1c/fTb2n5i2hgySvRtDt eamSXHDRynuUUiDzWkGA952COJsMwbi/oLQVqDg1sgktVAGUdZBPasJav50qyr9A 8icYmdUD68+29dYmgfYsv4Ojarrut+PP6j7RA17XfdoMIz60fMBPudu4P1Jy1oC9 cmL2/41JIAXMz1pjKqI1GLJ3X7dogR2fhmh+fG7h+EaBD6K8g/6NQETR7+ug7IY= =RN53 -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-hackers@freebsd.org Fri Jan 27 02:25:43 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D60E2CC30A4; Fri, 27 Jan 2017 02:25:43 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BA4D9DC4; Fri, 27 Jan 2017 02:25:43 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-228-247.lns20.per1.internode.on.net [121.45.228.247]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v0R2Pb45085620 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 26 Jan 2017 18:25:41 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Understanding the rationale behind dropping of "block devices" To: Konstantin Belousov References: <20170116071105.GB4560@eureka.lemis.com> <20170116110009.GN2349@kib.kiev.ua> Cc: Aijaz Baig , "Greg 'groggy' Lehey" , FreeBSD Hackers , freebsd-scsi@freebsd.org From: Julian Elischer Message-ID: <7cf12959-5c1e-2be8-5974-69a96f2cd9d7@freebsd.org> Date: Fri, 27 Jan 2017 10:25:32 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170116110009.GN2349@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 02:25:43 -0000 On 16/1/17 7:00 pm, Konstantin Belousov wrote: > On Mon, Jan 16, 2017 at 05:20:25PM +0800, Julian Elischer wrote: >> On 16/01/2017 4:49 PM, Aijaz Baig wrote: >>> Oh yes I was actually running an old release inside a VM and yes I had >>> changed the device names myself while jotting down notes (to give it a more >>> descriptive name like what the OSX does). So now I've checked it on a >>> recent release and yes there is indeed no block device. >>> >>> root@bsd-client:/dev # gpart show >>> => 34 83886013 da0 GPT (40G) >>> 34 1024 1 freebsd-boot (512K) >>> 1058 58719232 2 freebsd-ufs (28G) >>> 58720290 3145728 3 freebsd-swap (1.5G) >>> 61866018 22020029 - free - (10G) >>> >>> root@bsd-client:/dev # ls -lrt da* >>> crw-r----- 1 root operator 0x4d Dec 19 17:49 da0p1 >>> crw-r----- 1 root operator 0x4b Dec 19 17:49 da0 >>> crw-r----- 1 root operator 0x4f Dec 19 23:19 da0p3 >>> crw-r----- 1 root operator 0x4e Dec 19 23:19 da0p2 >>> >>> So this shows that I have a single SATA or SAS drive and there are >>> apparently 3 partitions ( or is it four?? Why does it show unused space >>> when I had used the entire disk?) >>> >>> Nevertheless my question still holds. What does 'removing support for block >>> device' mean in this context? Was what I mentioned earlier with regards to >>> my understanding correct? Viz. all disk devices now have a character (or >>> raw) interface and are no longer served via the "page cache" but rather the >>> "buffer cache". Does that mean all disk accesses are now direct by passing >>> the file system?? >> Basically, FreeBSD never really buffered/cached by device. >> >> Buffering and caching is done by vnode in the filesystem. >> We have no device-based block cache. If you want file X at offset Y, >> then we can satisfy that from cache. >> VM objects map closely to vnode objects so the VM system IS the file >> system buffer cache. > This is not true. > > We do have buffer cache of the blocks read through the device (special) > vnode. This is how, typically, the metadata for filesystems which are > clients of the buffer cache, is handled, i.e. UFS msdosfs cd9600 etc. > It is up to the filesystem to not create aliased cached copies of the > blocks both in the device vnode buffer list and in the filesystem vnode. > > In fact, sometimes filesystems, e.g. UFS, consciously break this rule > and read blocks of the user vnode through the disk cache. For instance, > this happens for the SU truncation of the indirect blocks. yes this caches blocks as an offset into a device, but it is still really a part of the system which provides caching services to vnodes. (at least that is how it was last time I looked) > >> If you want device M, at offset N we will fetch it for you from the >> device, DMA'd directly into your address space, >> but there is no cached copy. >> Having said that, it would be trivial to add a 'caching' geom layer to >> the system but that has never been needed. > The useful interpretation of the claim that FreeBSD does not cache > disk blocks is that the cache is not accessible over the user-initiated > i/o (read(2) and write(2)) through the opened devfs nodes. If a program > issues such request, it indeed goes directly to/from disk driver, which > is supplied a kernel buffer formed by remapped user pages. Note that > if this device was or is mounted and filesystem kept some metadata in > the buffer cache, then the devfs i/o would make the cache inconsistent. > >> The added complexity of carrying around two alternate interfaces to >> the same devices was judged by those who did the work to be not worth >> the small gain available to the very few people who used raw devices. >> Interestingly, since that time ZFS has implemented a block-layer cache >> for itself which is of course not integrated with the non-existing >> block level cache in the system :-). > We do carry two interfaces in the cdev drivers, which are lumped into > one. In particular, it is not easy to implement mapping of the block > devices exactly because the interfaces are mixed. If cdev disk device is > mapped, VM would try to use cdevsw d_mmap or later mapping interfaces to > handle user page faults, which is incorrect for the purpose of the disk > block mapping. >