From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 24 01:28:41 2013 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 6E34FAC2; Sun, 24 Nov 2013 01:28:41 +0000 (UTC) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AEDA225E4; Sun, 24 Nov 2013 01:28:40 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id b10so1441404eae.33 for ; Sat, 23 Nov 2013 17:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N9hTop8FsCeWsdRmjiJNqD+wOODAobEtdc7S0r7QfJ4=; b=ekkNgOiBRwZGlkHYx0BhFq0amRg/OJJgoDVz26GX03vM/ru36q2J77kwS09TWjecIQ J7OtEEgoBVKprJJzkf3skFbeSlHac4WBw7dCqrIe4uzc2K6bMyxoExuyBh2hZO9Cda0W 8GmLSX11FdeZPLWTqa7AQDySib0fAOrWL+hH/cJHANjLBCUJVv3DcMmIdPjHohAArYQ2 gLc+JrSW+fbpCvv/dryRXvtTxmYWj68lLMcyrR8l//1qov9A7atgKgJ7Wzz/AQ+nKDm8 tjmOgpsuVAyiDTGCyoSkPQPsdyVtoVrwpNvB2CpO8ptsbJuGPvzo+uEMJVf4cB952+If v2MQ== X-Received: by 10.14.199.197 with SMTP id x45mr26581941een.8.1385256519028; Sat, 23 Nov 2013 17:28:39 -0800 (PST) Received: from mini.home (abwu147.neoplus.adsl.tpnet.pl. [83.8.244.147]) by mx.google.com with ESMTPSA id g8sm88818527eep.20.2013.11.23.17.28.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 17:28:38 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: O_XATTR support in FreeBSD? From: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= In-Reply-To: <820263347.19772534.1385247218007.JavaMail.root@uoguelph.ca> Date: Sun, 24 Nov 2013 02:28:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <987A1DDC-0C8F-4EEF-9504-D28CA7027F56@FreeBSD.org> References: <820263347.19772534.1385247218007.JavaMail.root@uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1822) Cc: Freebsd hackers list , Richard Yao , Pedro Giffuni , Robert Watson , Cedric Blancher X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 01:28:41 -0000 Wiadomo=C5=9B=C4=87 napisana przez Rick Macklem w = dniu 23 lis 2013, o godz. 23:53: > Pedro Giffuni wrote: >> On 23.11.2013 02:13, Cedric Blancher wrote: >>> On 22 November 2013 20:55, Pedro Giffuni wrote: >>>> Well ... >>>>=20 >>>> According to: >>>>=20 >>>> https://wiki.freebsd.org/ZFS >>>>=20 >>>> We do support Extended Attributes on ZFS but they differ from the >>>> ones in >>>> Solaris (and Linux). >>> Well, we need the one specified in the NFSv4 standard. The Linux >>> extended attributes are pretty much useless because they are size >>> restricted (typical attribute size here is in the GB range, and for >>> example NIH and CERN have even much bigger sizes), can't be >>> accessed >>> like normal files and are incompatible to Window's Alternate >>> Streams. >>>=20 >>> Ced >>=20 >> I was unaware of a standard for EA beyond the old posix draft. >> The reason for Extended Attributes is supporting ACL and we support >> both >> the draft posix and the NFS/win style ACLs. >>=20 > Interestingly, FreeBSD has a VOP_OPENEXTATTR() but no syscall > that uses it nor support for it in ZFS. (I'm just guessing it > was intended for an openat(2) syscall at some time?) Hm, interesting. It looks kind of unused (MAC uses it to implement mac_vnode_create_extattr() and mac_vnode_setlabel_extattr()). Robert = (Cc-ed), perhaps you know what=E2=80=99s the story here? % grep -R openextattr * =20 fs/unionfs/union.h:#define UNIONFS_OPENEXTL 0x01 /* openextattr = (lower) */ fs/unionfs/union.h:#define UNIONFS_OPENEXTU 0x02 /* openextattr = (upper) */ fs/unionfs/union_vnops.c:unionfs_openextattr(struct vop_openextattr_args = *ap) fs/unionfs/union_vnops.c: .vop_openextattr =3D = unionfs_openextattr, kern/vnode_if.src:%% openextattr vp L L L kern/vnode_if.src:vop_openextattr { ufs/ffs/ffs_vnops.c:static vop_openextattr_t ffs_openextattr; ufs/ffs/ffs_vnops.c: .vop_openextattr =3D ffs_openextattr, ufs/ffs/ffs_vnops.c: .vop_openextattr =3D ffs_openextattr, ufs/ffs/ffs_vnops.c:ffs_openextattr(struct vop_openextattr_args *ap) ufs/ffs/ffs_vnops.c:struct vop_openextattr_args { % grep -R VOP_OPENEXTATTR * fs/unionfs/union_vnops.c: error =3D VOP_OPENEXTATTR(tvp, = ap->a_cred, ap->a_td); fs/unionfs/union_vnops.c: VOP_OPENEXTATTR(lvp, = cred, td)) { fs/unionfs/union_vnops.c: panic("unionfs: = VOP_OPENEXTATTR failed"); fs/unionfs/union_vnops.c: if ((error =3D = VOP_OPENEXTATTR(uvp, cred, td)) !=3D 0) fs/unionfs/union_vnops.c: VOP_OPENEXTATTR(lvp, = cred, td)) { fs/unionfs/union_vnops.c: panic("unionfs: = VOP_OPENEXTATTR failed"); fs/unionfs/union_vnops.c: if ((error =3D = VOP_OPENEXTATTR(uvp, cred, td)) !=3D 0) security/mac/mac_vfs.c: error =3D VOP_OPENEXTATTR(vp, cred, curthread); security/mac/mac_vfs.c: error =3D VOP_OPENEXTATTR(vp, cred, curthread); Anyway - extended attributes _are_ supported on ZFS; see extattr(2) for = API. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 23 22:28:40 2013 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 C361BF5D; Sat, 23 Nov 2013 22:28:40 +0000 (UTC) Received: from nuanti.com (nuanti.com [207.192.69.172]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7FA542EB3; Sat, 23 Nov 2013 22:28:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nuanti.com (Postfix) with ESMTP id A336C29880; Sat, 23 Nov 2013 22:20:18 +0000 (GMT) Received: from nuanti.com ([127.0.0.1]) by localhost (nuanti.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uDYN0zB9D2N; Sat, 23 Nov 2013 22:20:17 +0000 (GMT) Message-ID: <52912A1E.5090105@nuanti.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuanti.com; s=default; t=1385245217; bh=Bj/kSrEsnCPSpDMW7B1FNRmTLpu00zJzR1IfEFnD0yU=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=iH2ouH8xibkvLMPaqvQ41c9LV3KM9D4pc2OG4ggaWOGLNIs5+hNzwAR3JlSEHtKxq DkGb4R3IRfGzVYsewwc5WERcq5rHKG007PZu7LT4QknUSJ9xF1qmaNoOa2yxLrCtO2 KzTHOL381cV7QSxxcRz3UDL6mU0xY2IsoaWgpvw0= Date: Sat, 23 Nov 2013 22:20:14 +0000 From: Alp Toker User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Dimitry Andric , =?ISO-8859-1?Q?=22C=2E_Bergstr=F6?= =?ISO-8859-1?Q?m=22?= Subject: Re: SSE2 intrinsics: gcc46 vs. clang contradiction References: <20131101124645.GA73456@regency.nsu.ru> <20131101154320.GA11359@regency.nsu.ru> <52742115.9010404@pathscale.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 24 Nov 2013 03:36:27 +0000 Cc: Alexey Dokuchaev , hackers@FreeBSD.org, cfe-commits@cs.uiuc.edu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 22:28:40 -0000 Thanks Dimitry, I've confirmed your fix is correct. Landed in r195558. Alp. On 02/11/2013 00:07, Dimitry Andric wrote: > On 01 Nov 2013, at 22:45, C. Bergström wrote: >> On 11/ 1/13 10:43 PM, Alexey Dokuchaev wrote: >>> On Fri, Nov 01, 2013 at 07:46:45PM +0700, Alexey Dokuchaev wrote: >>>> What adds to confusion, in their manual [1] Intel spells them differently >>>> themselves: first, in the table, it says: >>>> >>>> _mm_movpi64_epi64 Move MOVDQ2Q >>>> ^^^^^ >>>> >>>> Then later, when they describe what it does, it says: >>>> >>>> __m128i _mm_movpi64_pi64(__m64 a) >>>> ^^^^ >>>> Moves the 64 bits of a to the lower 64 bits of the result, zeroing the >>>> upper bits. >>> Microsoft (http://msdn.microsoft.com/en-us/library/has3d153(v=vs.90).aspx) >>> defines these two: >>> >>> _mm_movepi64_pi64 MOVDQ2Q Move >>> _mm_movpi64_epi64 MOVQ2DQ Move >>> >>> That is: >>> >>> __m64 _mm_movepi64_pi64 (__m128i a); >>> MOVDQ2Q >>> r0 := a0 ; >>> >>> __m128i _mm_movpi64_epi64 (__m64 a); >>> MOVDQ2Q >>> r0 := a0 ; r1 := 0X0 ; >>> >>> Cf. Intel's: >>> >>> _mm_movepi64_pi64 Move MOVDQ2Q >>> _mm_movpi64_epi64 Move MOVDQ2Q >>> >>> __m64 _mm_movepi64_pi64(__m128i a) >>> Returns the lower 64 bits of a as an __m64 type: R0 := a0 >>> >>> __m128i _mm_movpi64_pi64(__m64 a) >>> Moves the 64 bits of a to the lower 64 bits >>> of the result, zeroing the upper bits: R0 := a0, R1 = 0X0 >>> >>> Assuming that both documents correctly assign instructions to function >>> names (bonus clue: it also makes them symmetrical), then _mm_movpi64_pi64 >>> is indeed a typo and Clang's header is wrong, while GCC's is correct: it >>> should read _mm_movpi64_epi64(), not _mm_movpi64_pi64(). >> Why isn't this being asked on the clang or llvm mailing list? Wouldn't this impact upstream as well? > Indeed, so redirecting to the cfe-commits list. It looks like this incorrect function name has been in emmintrin.h since clang r61443 (by andersca). Basically, we need the typo fixed as follows: > > Index: tools/clang/lib/Headers/emmintrin.h > =================================================================== > --- tools/clang/lib/Headers/emmintrin.h (revision 193039) > +++ tools/clang/lib/Headers/emmintrin.h (working copy) > @@ -1366,7 +1366,7 @@ _mm_movepi64_pi64(__m128i __a) > } > > static __inline__ __m128i __attribute__((__always_inline__, __nodebug__)) > -_mm_movpi64_pi64(__m64 __a) > +_mm_movpi64_epi64(__m64 __a) > { > return (__m128i){ (long long)__a, 0 }; > } > > Is this OK? > > -Dimitry > > > > _______________________________________________ > cfe-commits mailing list > cfe-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits -- http://www.nuanti.com the browser experts From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 24 09:23:39 2013 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 1A5209F3; Sun, 24 Nov 2013 09:23:39 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id CACA0282C; Sun, 24 Nov 2013 09:23:38 +0000 (UTC) Received: from [10.0.1.16] (host86-132-106-161.range86-132.btcentralplus.com [86.132.106.161]) by cyrus.watson.org (Postfix) with ESMTPSA id 830EB46B2A; Sun, 24 Nov 2013 04:23:35 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: O_XATTR support in FreeBSD? From: "Robert N. M. Watson" In-Reply-To: <987A1DDC-0C8F-4EEF-9504-D28CA7027F56@FreeBSD.org> Date: Sun, 24 Nov 2013 09:23:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <820263347.19772534.1385247218007.JavaMail.root@uoguelph.ca> <987A1DDC-0C8F-4EEF-9504-D28CA7027F56@FreeBSD.org> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.1822) Cc: Freebsd hackers list , Richard Yao , Rick Macklem , Pedro Giffuni , Cedric Blancher X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 09:23:39 -0000 On 24 Nov 2013, at 01:28, Edward Tomasz Napiera=C5=82a = wrote: >>> I was unaware of a standard for EA beyond the old posix draft. >>> The reason for Extended Attributes is supporting ACL and we support >>> both >>> the draft posix and the NFS/win style ACLs. >>>=20 >> Interestingly, FreeBSD has a VOP_OPENEXTATTR() but no syscall >> that uses it nor support for it in ZFS. (I'm just guessing it >> was intended for an openat(2) syscall at some time?) >=20 > Hm, interesting. It looks kind of unused (MAC uses it to implement > mac_vnode_create_extattr() and mac_vnode_setlabel_extattr()). Robert = (Cc-ed), > perhaps you know what=E2=80=99s the story here? >=20 > % grep -R openextattr * =20 > fs/unionfs/union.h:#define UNIONFS_OPENEXTL 0x01 /* openextattr = (lower) */ > fs/unionfs/union.h:#define UNIONFS_OPENEXTU 0x02 /* openextattr = (upper) */ > fs/unionfs/union_vnops.c:unionfs_openextattr(struct = vop_openextattr_args *ap) > fs/unionfs/union_vnops.c: .vop_openextattr =3D = unionfs_openextattr, > kern/vnode_if.src:%% openextattr vp L L L > kern/vnode_if.src:vop_openextattr { > ufs/ffs/ffs_vnops.c:static vop_openextattr_t ffs_openextattr; > ufs/ffs/ffs_vnops.c: .vop_openextattr =3D ffs_openextattr, > ufs/ffs/ffs_vnops.c: .vop_openextattr =3D ffs_openextattr, > ufs/ffs/ffs_vnops.c:ffs_openextattr(struct vop_openextattr_args *ap) > ufs/ffs/ffs_vnops.c:struct vop_openextattr_args { >=20 > % grep -R VOP_OPENEXTATTR * > fs/unionfs/union_vnops.c: error =3D VOP_OPENEXTATTR(tvp, = ap->a_cred, ap->a_td); > fs/unionfs/union_vnops.c: = VOP_OPENEXTATTR(lvp, cred, td)) { > fs/unionfs/union_vnops.c: = panic("unionfs: VOP_OPENEXTATTR failed"); > fs/unionfs/union_vnops.c: if ((error =3D = VOP_OPENEXTATTR(uvp, cred, td)) !=3D 0) > fs/unionfs/union_vnops.c: = VOP_OPENEXTATTR(lvp, cred, td)) { > fs/unionfs/union_vnops.c: = panic("unionfs: VOP_OPENEXTATTR failed"); > fs/unionfs/union_vnops.c: if ((error =3D = VOP_OPENEXTATTR(uvp, cred, td)) !=3D 0) > security/mac/mac_vfs.c: error =3D VOP_OPENEXTATTR(vp, cred, = curthread); > security/mac/mac_vfs.c: error =3D VOP_OPENEXTATTR(vp, cred, = curthread); >=20 > Anyway - extended attributes _are_ supported on ZFS; see extattr(2) = for API. This VOP doesn't do what you think it does. Within our VFS we support = "transactions" in order to allow multiple EA writes to be atomic. This = is used when setting labels associated with multiple policies in a = single call to mac_set_file(), mac_set_fd(), and mac_set_link(). This = provides atomicity against (a) simultaneous access to the same file as = security attributes are changing, and (b) in the event of a crash during = attribute update. The transaction model depends on the vnode lock being = held exclusively over the call to VOP_OPENEXTATTR(), a series of = VOP_SETEXTATTR() calls, and VOP_CLOSEEXTATTR(). The feature was added in = UFS2 (it's not present in the UFS1 EA implementation), and it looks like = extattr(9) didn't get updated. Robert From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 24 14:18:19 2013 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 50824A85; Sun, 24 Nov 2013 14:18:19 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D453622BF; Sun, 24 Nov 2013 14:18:18 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAN4JklKDaFve/2dsb2JhbABZgz9Tgnm4Vk6BMnSCJQEBAQMBAQEBICsgCxsOCgICDRkCKQEJJgYIBwQBHASHWgYNrHOQOReBKY0GBwEBGwEzB4JrgUgDiUKMA4N/iRuHR4NGHjF7CRci X-IronPort-AV: E=Sophos;i="4.93,762,1378872000"; d="scan'208";a="71809142" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 24 Nov 2013 09:18:16 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EDB90B408B; Sun, 24 Nov 2013 09:18:16 -0500 (EST) Date: Sun, 24 Nov 2013 09:18:16 -0500 (EST) From: Rick Macklem To: Jordan Hubbard Message-ID: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: O_XATTR support in FreeBSD? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Freebsd hackers list , Richard Yao , Pedro Giffuni , Cedric Blancher X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 14:18:19 -0000 Jordan Hubbard wrote: >=20 > On Nov 23, 2013, at 2:53 PM, Rick Macklem > wrote: >=20 > > Interestingly, FreeBSD has a VOP_OPENEXTATTR() but no syscall > > that uses it nor support for it in ZFS. (I'm just guessing it > > was intended for an openat(2) syscall at some time?) Oops, my mistake. Robert has clarified what the VOP_OPENEXTATTR() is used for. Therefore, there doesn't appear to be any support for subfiles/fork files in the VFS (VOP_xxx()) or syscalls. > > Btw Cedric, if you had mentioned "subfiles" or "fork files" in your > > subject line, you might have gotten a better answer. I, for one, > > didn't know what O_XATTR is. I also always get confused w.r.t. what > > to call these beasts. (NFSv4 calls the named attributes.) > >=20 > > Btw, apps can use extended attributes (the limited sized > > atomically stored/read kind). They aren't just for > > storing ACLs. >=20 > Sigh. Extended Attributes. :-/ >=20 > I guess I=E2=80=99ll raise my head in this discussion. They=E2=80=99ve c= ertainly > been the bane of my existence for long enough! >=20 > First, supporting EAs properly really involves multiple levels of the > Unix command and library stack. >=20 > The filesystem can support them natively, sure, but that=E2=80=99s actual= ly > somewhat optional since you can always (cough cough) stick them in a > side-store if the rest of the stack cooperates. That=E2=80=99s where the > awesome AppleDouble files came from (=E2=80=9C._weirdfile" corresponding = to > =E2=80=9Cweirdfile") which remain useful even after filesystems like > HFS/ZFS/UFS became EA-aware natively because there=E2=80=99s always those > foreign data stores to talk to (some early AFP/CIFS/NFS mount, for > example) and the fact that you still need to *serialize* the dang > things into tar / cpio / zip / ??? files as well as across network > replication with tools like rsync. What good is an EA, much less an > ACL that=E2=80=99s been stored in an EA, if it gets stripped off the firs= t > time you tar up a directory and extract it somewhere else? >=20 > So I wouldn=E2=80=99t start with NFSv4 or ZFS if I was asking the questio= n. > I would start with libc and ask if it had anything similar to > copyfile(3) so that the tools above it could start actually > supporting those attributes on a *practical* basis! :) >=20 Righto, w.r.t. the client side. For the NFSv4 server side, it would be what the VFS and file systems support. Just to clarify, I wasn't interested in doing this. It was Cedric who asked about them. My impression is that with the Linux "marketshare", apps will tend to use the atomic limited size ones already supported by FreeBSD. (NFSv4.0 and 4.1 don't support these, but there is discussion w.r.t. adding support for them in a future minor revision of the protocol, possibly 4.2. The named attributes in NFSv4 expect the subfile/forkfile model and do not support atomic writing of an entire extended attribute.) rick > - Jordan >=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 From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 24 22:35:04 2013 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 1AD8A49B; Sun, 24 Nov 2013 22:35:04 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D10802999; Sun, 24 Nov 2013 22:35:03 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id l6so3515214oag.7 for ; Sun, 24 Nov 2013 14:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=2Ikz/FYtx15epFzDOiFYsn/Zd6ea5/XmhMz1vaS7AsE=; b=e9LdP0uGmBuEJ/lOkQPow+1gC9r2d9zk3tX31bpUsJB/YbOsAq05slIDENhSNe83hm b8hMOc2e8MmmPnhUkHeySnLxTCbJmP4u6c2fYMo34QlyzQ3AN6yHpF1UHBS6sdWaHKjs QDBaaOVpzeEkrOdyp1PsPFicZmdw9ppiwskmZq/0GBPOtIkqJI3//PSpSDuI8OBcTGls E7FJnkZNRYuCn0lv5hnJse+JppZiHRDaK0q4VWrkzHGLfvlzj1RuyiShliSUxTsBzpiv E2BbwnKGQ8lSYAeVej0xcQTTZUC9XDXjRuFZHX0SOv5L6+XAYpNm3B3K0AwdfFeiQyQS Jckg== MIME-Version: 1.0 X-Received: by 10.60.68.135 with SMTP id w7mr22483845oet.9.1385332503163; Sun, 24 Nov 2013 14:35:03 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.182.110.195 with HTTP; Sun, 24 Nov 2013 14:35:03 -0800 (PST) Date: Sun, 24 Nov 2013 14:35:03 -0800 X-Google-Sender-Auth: BPli1DLR37vq2xCJ3ueGxR9wONA Message-ID: Subject: Are computers always this hard? From: Matthew Fleming To: freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: bdrewery@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 22:35:04 -0000 I'm just trying to get FreeBSD in a VM running again on my Mac. I had had VMware installed, but it stopped working when I updated my OS and I didn't want to re-pay, so I got VirtualBox today. I've got an installed 10-beta3, but I can't get source code on it. I tried to use folder sharing, since I have FreeBSD sources on my mac; that got me an error about the VirtualBox Guest additions not being installed. I tried to use NFS mounting but I got too annoyed trying to get my Mac set up as an NFS server. I tried to use svnlite to fetch from svn+ssh://mdf@, but it doesn't like my pass phrase for my ssh key. I can ssh from the new FreeBSD install to freefall, so this seems to be an svnlite issue. I tried to use pkg to install subversion. This gives me errors: ... Conflict found on path /usr/local/share/subversion/server-side/test_svn_server_log_parse.py between subversion-1.8.4(devel/subversion) and subversion-1.6.23_2(devel/subversion16) Conflict found on path /usr/local/share/subversion/xslt/svnindex.css between subversion-1.8.4(devel/subversion) and subversion-1.6.23_2(devel/subversion16) Conflict found on path /usr/local/share/subversion/xslt/svnindex.xsl between subversion-1.8.4(devel/subversion) and subversion-1.6.23_2(devel/subversion16) Conflict found on path /usr/local/etc/rc.d/svnserve between subversion-1.8.4(devel/subversion) and subversion-1.6.23_2(devel/subversion16) root@mdf-bsd:~ # pkg info pkg-1.1.4_10 New generation package manager So what's conflicting? To summarize: 1) can't (easily) share using VirtualBox 2) NFS didn't work in the first 2 minutes of effort 3) svnlite doesn't do svn+ssh 4) pkg can't install subversion I'm going to poke at NFS for a bit, but at some point I'd really just rather play a video game than hit my head against the wall. Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 24 22:53:04 2013 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 B004394A; Sun, 24 Nov 2013 22:53:04 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2747B2A80; Sun, 24 Nov 2013 22:53:04 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.7/8.14.7) with ESMTP id rAOMquNm043563 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 24 Nov 2013 22:52:56 GMT (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk rAOMquNm043563 Authentication-Results: smtp.infracaninophile.co.uk/rAOMquNm043563; dkim=none reason="no signature"; dkim-adsp=none Message-ID: <52928336.1070704@FreeBSD.org> Date: Sun, 24 Nov 2013 22:52:38 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Matthew Fleming , freebsd-hackers Subject: Re: Are computers always this hard? References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AEu78XkdMH2EFG8Iao1qxP1lI2LerMuOr" X-Virus-Scanned: clamav-milter 0.98 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: bdrewery@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 22:53:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AEu78XkdMH2EFG8Iao1qxP1lI2LerMuOr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 24/11/2013 22:35, Matthew Fleming wrote: > I tried to use pkg to install subversion. This gives me errors: Until the maintainers of the subversion ports fix the package name collision, the magic incantation is: pkg install devel/subversion Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --AEu78XkdMH2EFG8Iao1qxP1lI2LerMuOr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJSkoNHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkAT5akP/iTfEhkSC6r7secSA0cjBToG 6amARE54eFzt4svshmAoprCo3nCxc8vjZbRe/buHRzj7tAw7JwZhKAqjWdEZ8hhI DNnCCLe/y6Kxq0VcwllGZMBhPLdLciWWnWrIMwEAoPtcR2l+fKdP7oiK7bkgR3gr Tf6j0Uog31ng6JILjHYk+kzRYa1vIyJ6hlTpeL0zh3qSCJ1EIkAsdPmagp1HnVB3 qdQjjXugHe8HEKH7HtFrN4q63sTrG7xl+JfTTfN6kKzsGxoPDTDt28naYpcnlF95 Mq4EnKurTSAZ60w+yGu+S5D1LHgPDVJ9webj0ZkSn1nF3yAq9WqP2uyuzccLG7T9 lInOU89x+5TcyQspN0o2CDJq7QZFlnGZkjNPU/B2E/4OGttugEY2EvNeAVYnXY25 VMq29BuibX7fZTYKQtS4smMdK+UTZZ5XoRZ+i9+QyvgO3Be0MXpJV6+ia4C5fkI1 J5diAKCP53IEG8z1//S7sIAkJBRaz9xeyyT3zrLFEHTcBodzBP1Ryia8zX1ngHKS p8B+aGLgINn+JelVzjNwhyWQAV7y/BeViFfRIHa7F/tQBVFLGIiVMnaKa0OlH2Nn lEoSn5CEzRA9Hfs04seU9JLkqnTIjf58a3dJjaOCK+WAhzCZZTcw2mq9t+jC4/4P nCdYRRgB2g0iOmHvBEe7 =4p/P -----END PGP SIGNATURE----- --AEu78XkdMH2EFG8Iao1qxP1lI2LerMuOr-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 01:28:06 2013 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 17990E25 for ; Mon, 25 Nov 2013 01:28:06 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DA8FB2149 for ; Mon, 25 Nov 2013 01:28:05 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id i7so3676002oag.16 for ; Sun, 24 Nov 2013 17:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=zoFzjFZu0d1KHRLxFkXrbovqPE4PC974Gn8RtlMkIkc=; b=QLcD5NrqVO0qShR3VlDJuDoyxp0AlbA2NP4KfWWfgzD90uLPgyrJrYrA3/xtqFp8c9 JTUK1wvs9+mjhvOAuP3medZi/P9N2gJj3XBy7q9yO/SKF61whCRwcLAO5Msc9ZzKrfJE 7Gx2cDHVrRXW5E/LbKGyBwB1Lu8/0xmo6TaHVMGYvJj++TJP88y0a0B1UjHCHAMaLDkS 0UGZOQAw+iErRbq2bpUEVVjqvinlDXS7RCj+dbNs+vZf5Dhnzh8Ddy7Z/ROx8BtLwFeE YuOPbYYo4jdBVfEPSkXPbgS6t6WeGwEd1DV1PjJh/xIJopdVxmuzQyekDGhLgS8MFDHL RqKA== MIME-Version: 1.0 X-Received: by 10.60.59.5 with SMTP id v5mr22582655oeq.30.1385342885138; Sun, 24 Nov 2013 17:28:05 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.182.110.195 with HTTP; Sun, 24 Nov 2013 17:28:05 -0800 (PST) Date: Sun, 24 Nov 2013 17:28:05 -0800 X-Google-Sender-Auth: -Kj8-C1YX0J3pkxhwew6nfhagKs Message-ID: Subject: Building with gcc? From: Matthew Fleming To: freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 01:28:06 -0000 I'm trying to test a change to gcc, and I'd like to do a full buildworld/buildkernel using the gcc compiler. So I added this to my /etc/src.conf (and make.conf, since I can't remember under which scenarios they're different): WITHOUT_CLANG=YES WITH_GCC=YES WITH_GNUCXX=YES and I started a buildworld. It's currently building clang. Why is it building clang? Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 01:31:25 2013 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 EBCE2161; Mon, 25 Nov 2013 01:31:25 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C31DA21A5; Mon, 25 Nov 2013 01:31:25 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 250CF13DDB; Mon, 25 Nov 2013 01:31:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 250CF13DDB Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 24 Nov 2013 20:31:22 -0500 From: Glen Barber To: Matthew Fleming Subject: Re: Building with gcc? Message-ID: <20131125013122.GE1627@glenbarber.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ns7jmDPpOpCD+GE/" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 01:31:26 -0000 --Ns7jmDPpOpCD+GE/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 24, 2013 at 05:28:05PM -0800, Matthew Fleming wrote: > I'm trying to test a change to gcc, and I'd like to do a full > buildworld/buildkernel using the gcc compiler. So I added this to my > /etc/src.conf (and make.conf, since I can't remember under which scenarios > they're different): >=20 > WITHOUT_CLANG=3DYES > WITH_GCC=3DYES > WITH_GNUCXX=3DYES >=20 > and I started a buildworld. It's currently building clang. >=20 > Why is it building clang? >=20 You also want WITHOUT_CLANG_IS_CC=3DYES. I have no reasonable explanation for why it is different. You'll also need: W_ERROR=3D NO_WERROR=3DYES Glen --Ns7jmDPpOpCD+GE/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSkqhpAAoJELls3eqvi17QoCIP/3gcdyqxwJxA+ZCTxmaEVNuP gw4Ixhtr+ntgUO/hsb5Q4MgJ6UywixJgPyKBV3K3XhgUjbSeTqsGgwSexEFDnvJn qi04he9xkxRNEH3oJ32MGeFjPuUdhRGWz4KDPoJiIM/uALHtY38j55Vj3l6gCpRu I04JEMEhFNJw2cepz6LwVncV45hSIcHwR3zmCquFDvBm7JGpQGzdjuGTztIrLJCY sMWeth7S30w6Sndd3jYvvkQg7SOVVyjjrd3H0lz+i01bmtDooeTy/De/pdpADBgN cqo1fG7BBMG/mfPlXBGNldnwr3Zlvil0t9GtoiWwUJoJMIcvISerLDBDstEko6xD yhBaCuP45YhGtydOXceN+FItVut5XkIMcuO0i1xpeGpgLS8yJRTnE4rfC4p0UVgY gnqbJN5oW7F6CulVfGsJnBI2S4jQ0CL6bNXVEwXSMfmddNE6FaKyYpTnZLfZJUyL nnWrnGnihR6K2dUcdMfQWoFGZQma1GPA6BZkit6j4nJK7MF5TddPDk1uGLnic8uR hCiX7JzopUg9W1FsCwxGAl/gZpV1n/dSo6zP6Zuqk1eQg/x2k5osDxaspsan2FgZ tZPnFRTH7zrxcHw6CmUJyqLN+g4Mx2cm0vdayjiW8hqXwcHOgR0Dg0rQ0k7MExY5 2D+8s7i8Zt8Nw5/Pjwqa =ZaLK -----END PGP SIGNATURE----- --Ns7jmDPpOpCD+GE/-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 01:37:32 2013 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 C0A63295 for ; Mon, 25 Nov 2013 01:37:32 +0000 (UTC) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 840EC21E0 for ; Mon, 25 Nov 2013 01:37:32 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id 1so1176926qec.9 for ; Sun, 24 Nov 2013 17:37:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=qlVtJolOG1Y3g8XZi2J6MVAbH/rEK5WW79L/8tEyhKg=; b=bq35CsNhgtTiPpx4kJOkHvL3z9dTbcwNkBs5iC31mmZhFk3JdL+fLJZBI42jS0znQ0 CByH+zRuo+jOSvyeAzDOrhk9tg3qSEUwKe2Xmgk2IsxBPLuJwHX9vZqFnaGm71Zchbyy Z/zvFvplIYiymE3bkQMUn87kbzj4m9Q7sPS54= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=qlVtJolOG1Y3g8XZi2J6MVAbH/rEK5WW79L/8tEyhKg=; b=SQEK/NrEDJict22PXM1A8cB23GF2XSUwIpIlaY7aDV0p0tYFpT0oiqs3R4C0RY/YXE EmbLtebqV6mDa1x+aTEPFN8Si9yrYAOQKoOdcc3AloWdgM2J1ApyqaMNJDRwUmPXIowM Ro4wb08G9A7jqL7sPlbwbDiJdeB7LtTCl490fHlU8yHzpHkoENDfrPqFxZlX6Qh4NbeU LY1xCe2rRRm/dEO3C+39JY6TOoP+z1BGWh6pUxFbw8HU2xIODbFFxWHCDpQDQCqyPKVE Ky9WLlS3bVkJkKY09nOBLcf4G03xZMod8gM30jk3hEuq9Vnw/9Z0/RfbO/yEdRbjAIH5 Z/Fw== X-Gm-Message-State: ALoCoQlnuGLt9Dj/EoqLJnRR0+jyIyThEDMst2YOKdxquy6o6YiRSmpzyNULU70oZrnigLmgWkKf X-Received: by 10.224.34.71 with SMTP id k7mr41368868qad.15.1385343451754; Sun, 24 Nov 2013 17:37:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Sun, 24 Nov 2013 17:37:01 -0800 (PST) From: Eitan Adler Date: Sun, 24 Nov 2013 20:37:01 -0500 Message-ID: Subject: hw.pci.do_power_nodriver=3 To: "hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 01:37:32 -0000 Is there any reason we can not set hw.pci.do_power_nodriver=3 by default? My understanding is that there were problems with hardware being powered off and not being powered back on when drivers were loaded. Is this still a concern? If yes, can we flip the switch in HEAD and fix the drivers? -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 02:00:38 2013 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 BBD3C518; Mon, 25 Nov 2013 02:00:38 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7BCE022F7; Mon, 25 Nov 2013 02:00:38 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id i7so3711887oag.30 for ; Sun, 24 Nov 2013 18:00:37 -0800 (PST) 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=8mTgvQs9ewYpIMyz+a+AaJlwaCZPUIWM1lbgAMdtfbo=; b=ewmuEA+oRGHfw866BCGhBpKbOaI8ZLP4CU6XcY3TZPsrQHZEqqPkB7ix0i3Jh8ZLL3 bAUkCQA8KukWE04xn3BmbzMWBD2Oic68l/QW/ImUM4CuEmgX3vIMruEcauqiSHLDZ6qA P6JbtrOB56e933PoRRax3g9uMIqaA+S2feOxOMVKB4AQJzap4mmBt/vM18TCFai7OQmf IE4WYzlDZ1BQYbllbuxt8K10DSEEv26nJGpm9+Qg/F18r0JysPpD2xueDQTc1amV05Nj AorZJeMk2ngIBw0pehXLATn6Znm6YzQx5w/51SE4s4ZMRtx0gmNcoBs7zWFIRk1nTR97 wzqA== MIME-Version: 1.0 X-Received: by 10.60.45.102 with SMTP id l6mr4195018oem.36.1385344837767; Sun, 24 Nov 2013 18:00:37 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.182.110.195 with HTTP; Sun, 24 Nov 2013 18:00:37 -0800 (PST) In-Reply-To: <20131125013122.GE1627@glenbarber.us> References: <20131125013122.GE1627@glenbarber.us> Date: Sun, 24 Nov 2013 18:00:37 -0800 X-Google-Sender-Auth: op2NdD6whL1IxR15ix3CM9RufDY Message-ID: Subject: Re: Building with gcc? From: Matthew Fleming To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 02:00:38 -0000 On Sun, Nov 24, 2013 at 5:31 PM, Glen Barber wrote: > On Sun, Nov 24, 2013 at 05:28:05PM -0800, Matthew Fleming wrote: > > I'm trying to test a change to gcc, and I'd like to do a full > > buildworld/buildkernel using the gcc compiler. So I added this to my > > /etc/src.conf (and make.conf, since I can't remember under which > scenarios > > they're different): > > > > WITHOUT_CLANG=YES > > WITH_GCC=YES > > WITH_GNUCXX=YES > > > > and I started a buildworld. It's currently building clang. > > > > Why is it building clang? > > > > You also want WITHOUT_CLANG_IS_CC=YES. I have no reasonable explanation > for why it is different. > > You'll also need: > W_ERROR= > NO_WERROR=YES Whoops. I had known about WITH_CLANG_IS_CC back when it wasn't yet the default. Somehow I didn't make the connection to having to reverse it now. Seems to be working as I expect now. Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 03:50:00 2013 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 C6A153D7 for ; Mon, 25 Nov 2013 03:50:00 +0000 (UTC) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D38C2799 for ; Mon, 25 Nov 2013 03:50:00 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id wm4so3654558obc.10 for ; Sun, 24 Nov 2013 19:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tPXD3vsPg6oybPYUjGefukGgYODUqgY+yQDVpBFKqi4=; b=cyUFInI52t+4Jp3T7FUa06wAqb0v4DofmL+Ss2uG+2MTw+QipyBJ1+NV4B5y5IwU7b Hx93OXoaFq6dJJkoT5UPIHAjvdwaFqbbs0I2KWRUInGzo1Q0iM/8rTTUlOpctRvtVOlm CguMkJfyPne/IjK0KCT50DvNOqfWPWp5KdwrU= 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:date :message-id:subject:from:to:cc:content-type; bh=tPXD3vsPg6oybPYUjGefukGgYODUqgY+yQDVpBFKqi4=; b=FL+FiEFOX4hN0TWL6iPNvJnpu6Kyn+Bc5HclWiFw65ZCLcpFa52eIEnLSzDm7rKBWY yT08iPKGKIuNl8T/VV7+XggvzICRLa7K8flAWZ2BOFUWdR7wwCfAcpYNnBcMP2fIyURi ROkRhhz9cE9ds7/XE8mHPiNT7KkI5lIM7/X78QM80Z6EtCeNnMYamd/JSpzFNQC3dwhn PjpKQfFUr16WWbTTxNEgUrEwSey7XYpeA9lfjwz+Vp134QmuzUEYrtF6EWH0jp49ZOSk EwIHlS331MfUUX6DCXMTDmcrz1QMqKVAmQplhwGJ4JZEJUoUhc3NUb6ABxIzi2rmrY2M t8aQ== X-Gm-Message-State: ALoCoQnu5oSXLQLB8ib9087Z9GV38BiZlx+pi8iO8tXi221xaXgGW2ZqX498V/DVQ/11UKkI8yog MIME-Version: 1.0 X-Received: by 10.182.129.42 with SMTP id nt10mr22751728obb.19.1385351399609; Sun, 24 Nov 2013 19:49:59 -0800 (PST) Received: by 10.76.154.2 with HTTP; Sun, 24 Nov 2013 19:49:59 -0800 (PST) X-Originating-IP: [176.66.111.246] Received: by 10.76.154.2 with HTTP; Sun, 24 Nov 2013 19:49:59 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Nov 2013 04:49:59 +0100 Message-ID: Subject: Re: Are computers always this hard? From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= To: Matthew Fleming X-Mailman-Approved-At: Mon, 25 Nov 2013 04:07:01 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-hackers , Bryan Drewery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 03:50:00 -0000 Am 24.11.2013 23:35 schrieb "Matthew Fleming" : > > I'm just trying to get FreeBSD in a VM running again on my Mac. I had had > VMware installed, but it stopped working when I updated my OS and I didn't > want to re-pay, so I got VirtualBox today. I've got an installed 10-beta3, > but I can't get source code on it. > > I tried to use folder sharing, since I have FreeBSD sources on my mac; that > got me an error about the VirtualBox Guest additions not being installed. Shared folders support for vbox was a GSoC project this year but it is not production ready yet. There is a halfway finished kernel module that needs to get his vfs stuff fixed. I would use scp 10.0.0.2 to copy the portstree from host to guest. If you use nat networking 10.0.0.2 is always the host. > I tried to use NFS mounting but I got too annoyed trying to get my Mac set > up as an NFS server. > > I tried to use svnlite to fetch from svn+ssh://mdf@, but it doesn't like my > pass phrase for my ssh key. I can ssh from the new FreeBSD install to > freefall, so this seems to be an svnlite issue. > > I tried to use pkg to install subversion. This gives me errors: As someone mentioned pkg install devel/subversion is what you look for. > ... > Conflict found on path > /usr/local/share/subversion/server-side/test_svn_server_log_parse.py > between subversion-1.8.4(devel/subversion) and > subversion-1.6.23_2(devel/subversion16) > > Conflict found on path /usr/local/share/subversion/xslt/svnindex.css > between subversion-1.8.4(devel/subversion) and > subversion-1.6.23_2(devel/subversion16) > > Conflict found on path /usr/local/share/subversion/xslt/svnindex.xsl > between subversion-1.8.4(devel/subversion) and > subversion-1.6.23_2(devel/subversion16) > > Conflict found on path /usr/local/etc/rc.d/svnserve between > subversion-1.8.4(devel/subversion) and > subversion-1.6.23_2(devel/subversion16) > > root@mdf-bsd:~ # pkg info > pkg-1.1.4_10 New generation package manager > > So what's conflicting? > > To summarize: > > 1) can't (easily) share using VirtualBox > 2) NFS didn't work in the first 2 minutes of effort > 3) svnlite doesn't do svn+ssh > 4) pkg can't install subversion > > I'm going to poke at NFS for a bit, but at some point I'd really just > rather play a video game than hit my head against the wall. > > Thanks, > matthew > _______________________________________________ > 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 Nov 25 04:21:14 2013 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 70CC2756 for ; Mon, 25 Nov 2013 04:21:14 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.103]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7D628D8 for ; Mon, 25 Nov 2013 04:21:14 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type; b=vctXyKy85gk7AeEUFwNftlSVebPae/+BIunoRVKGMj6i1UvT1B0lwbRfgtaCU9SARw1ZLJabluIk iAV/kGK1lvuZXGuqsLE+H5QcDnZ0dokNFjXsmUOlDZwJpwEOEQyK Received: from [192.168.2.5] (224-8-237-24.gci.net [24.237.8.224]) by mx.zohomail.com with SMTPS id 1385350141362643.8981711911233; Sun, 24 Nov 2013 19:29:01 -0800 (PST) Message-ID: <5292C3F9.5060908@zoho.com> Date: Sun, 24 Nov 2013 18:28:57 -0900 From: zbr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: hiren panchasara , "freebsd-hackers@freebsd.org" Subject: Re: ULE thread scheduling in -head References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 04:21:14 -0000 On 11/14/2013 23:30, hiren panchasara wrote: > I want to understand how thread affinity works and for that I need to > understand how scheduling works. I am reading things and trying to map > them to the code in FreeBSD-head (in and around sys/kern/sched_ule.c) > > In terms of scheduler queues, I found 2 different things: > 1) > "ULE: A Modern Scheduler For FreeBSD" paper from jeffr mentions > following in 3.1 Queue Mechanisms: > Fairness is implemented by keeping two queues; current and next. Each > thread that is granted a > slice is assigned to either the current queue or the next queue. > > 2) > I found another interesting struct in there: struct tdq - per > processor runqs and statistics which has 3 queues: realtime, timeshare > and idle. > > I could not find 1) in source code. > > Can someone throw some light on how a thread gets scheduled? Do 1) and > 2) both exist and work together currently in -head FreeBSD? > > Trying to follow the code, sched_setup() calls sched_setup_smp() where > for each cpu we call tdq_setup() where we initialize 3 queues > mentioned in 2) -- But it seems this is all one time setup on boot. > What happens when a new thread is spawned? > > Any good pointer/reference for further reading would be great. > > cheers, > Hiren > _______________________________________________ > 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" > Hi Hiren, As far as I know two different schedulers exist in BSD (you can use either one): 1) ULE scheduler (sys/kern/sched_ule.c) -- That's the one described in the paper mentioned by you, 2) Old 4BSD scheduler (sys/kern/kern_4bsd.c) Thanks, -LW From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 08:29:35 2013 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 6C476696; Mon, 25 Nov 2013 08:29:35 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF6EB2476; Mon, 25 Nov 2013 08:29:34 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rAP8TKJc017969; Mon, 25 Nov 2013 10:29:20 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rAP8TKJc017969 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rAP8TJoq017968; Mon, 25 Nov 2013 10:29:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 25 Nov 2013 10:29:19 +0200 From: Konstantin Belousov To: Doug Ambrisko Subject: Re: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20131125082919.GO59496@kib.kiev.ua> References: <52854161.6080104@FreeBSD.org> <20131115010854.GA76106@ambrisko.com> <20131116183129.GD59496@kib.kiev.ua> <20131118190142.GA28210@ambrisko.com> <20131119074922.GY59496@kib.kiev.ua> <20131119174216.GA80753@ambrisko.com> <20131120075531.GE59496@kib.kiev.ua> <20131121174028.GA80520@ambrisko.com> <20131122074228.GT59496@kib.kiev.ua> <20131122170419.GA60910@ambrisko.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HjlUprwJuNajQ6MQ" Content-Disposition: inline In-Reply-To: <20131122170419.GA60910@ambrisko.com> User-Agent: Mutt/1.5.22 (2013-10-16) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, Dirk Engling , Jase Thew , mdf@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 08:29:35 -0000 --HjlUprwJuNajQ6MQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 22, 2013 at 09:04:19AM -0800, Doug Ambrisko wrote: > On Fri, Nov 22, 2013 at 09:42:28AM +0200, Konstantin Belousov wrote: > | On Thu, Nov 21, 2013 at 09:40:28AM -0800, Doug Ambrisko wrote: > | > On Wed, Nov 20, 2013 at 09:55:31AM +0200, Konstantin Belousov wrote: > | > | On Tue, Nov 19, 2013 at 09:42:16AM -0800, Doug Ambrisko wrote: > | > | > I was talking about the more general case since the system tries = to keep > | > | > the path in the stat structure. My prior approach which had more= issues > | > | > was to modify the stat structure of which I was pointed to NetBSD= and their > | > | > change to statvfs which doesn't really solve the problem. They d= on't > | > | > have the check to see if the mount is longer then VFS_MNAMELEN (i= n their case) > | > | > and just truncate things. > | > | >=20 > | > | > If we are just talking about adding it to the mount structure that > | > | > would be okay since it isn't exposed to user land. I can add tha= t. > | > | > | > | Yes, this is exactly what I mean. Add a struct mount field, and use > | > | it for kernel only. In fact, it only matters for sys_unmount() and > | > | kern_jail.c, other locations in kernel use the path for warnings, a= nd > | > | this could be postponed if you prefer to minimize the patch. > | >=20 > | > Okay, I went through all of the occurances and compile tested (except > | > for #DEBUG). I united a few things but should do more once I get > | > consensus on the approach. I found a few spots that should be update= d as > | > well and made the length check more consistant. Some were doing >=3D= and others > | > >. So this should be better, however, a lot larger. On the plus side > | > when we figure out how to return the longer path length to user land > | > that can be more flexible since the kernel is tracking the longer len= gth. > | > Probably things to note are changes in: > | > ZFS to mount snapshot > | > cd9660 for symlinks > | > fuse to return full path > | > jail to check statfs and mount > | > mount/umount to save and check full path > | > mountroot to save new field for full path > | > =09 > | > Just in case it doesn't make it in email the full patch is at: > | > http://people.freebsd.org/~ambrisko/mount_bigger.patch > | >=20 > | Yes, this is closer to the patch I can agree with :). > |=20 > | Two notes, one was already made, about off by one. >=20 > The off by one, I want to revisit so that it is consistant. We have > places in which there was checks > if (strlen(fstype) >=3D MFSNAMELEN || strlen(fspath) >=3D MNAMELEN) > and > if (strlen(fstype) >=3D MFSNAMELEN - 1 || strlen(fspath) >=3D MNAMELEN -= 1) > both with the same comment of "Be ultra-paranoid". Unless something is > special they should have been the same and whatever is right should be > carried forward. If there is a special case then it should be clearly > commented. Since this check has moved into other code we need to get > it hashed out once and for all IMHO. I mainly did this current change > to make sure attention is drawn to this for now until it is resolved. > =20 > | Second is, I suggest to make the mnt_path member a char *. Usually, the > | mount point path length is quite short, so 1024 bytes for the buffer is > | excessive. You can allocate exact needed buffer, which would save in > | around 10KB of kernel memory even for relatively modest amount of 10 > | mounts. >=20 > Okay, I thought you wanted it a const char to potential guard against > some mis use of the field in that this should be a read only value. const char * is fine, but is usually quite hard to use. Kernel is hostile to constness, since lot of older functions, while accessing the arguments read-only, were written before const was invented. > I had actually planned to do the malloc since I was concerned about > if this structure got allocated on the stack then it could explode > the kernel's stack. It seems most of the consumers access the mount > structure as a pointer so then I wasn't as concerned. Are there any instance in the kernel where the structure is not allocated through vfs_mount_alloc() ? I am not aware of such case. > =20 > | For additional cleverness, mnt_path could point to f_mntonname when > | the length is less than MNAMELEN. Since mp deallocation is centralized, > | code for the trick should be not too hard. >=20 > I'll look to see if I can change the other places that update mnt_path > to use the vfs_mount_alloc type function. Since then we could get more > sophisticated about the mnt_path allocater/reference as you mention. > In nfs_mounroot.c it probably doesn't matter much since it should be a > short path but it could be more of an issue with zfs snapshots. >=20 > It looks like we are converging. I'll make some more changes to make > sure we are getting on a good path port another patch. Once that looks > okay in concept then I'll start looking into testing the various file > systems since unfortuanately it touches a lot of code even though it is > mostly mechanical. I don't have a lot of time to work on this so I > want to optimize various things as once. If someone can help unit test > corner cases that would be great with the various file systems. Atleast > I have VirtualBox netbooting so I can test things quicker. However, > that required some debugging and changes to pxeboot to send the Client ID > so isc-dhcpd didn't get upset with it. I need to check that doesn't > break the non-ipxe boot stuff that doesn't require the Client ID field to > be set. I've only run into this issue with ipxe in VirtualBox and qemu. > I also have some pxe boot robustness and caching fixes that I should > get in as well. Well, the changes to most filesystems are trivial, so I would not gate the patch with testing of rarely-used and mostly rotten filesystems. --HjlUprwJuNajQ6MQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSkwpeAAoJEJDCuSvBvK1BtqkP/i+p6tKqhFng9uoOct1BvMM+ 5uobMKFKRb/0r52+J1SkjnQd62+Ck54jIiDRxTmtsymeiztwm01qvgrDjKr4Fe1K hXeBuc0OOqJyQ7Upr4XDkWN0RCtwuCz1Y/06n28x822uFmU6GKSlM6y+Gy/xQ0bN wJk8Zj9fDXGHlBmQKE+zCUOAAd6JUiiNhve90ooUHGAR108z4m5+57WpLCiH4Vvx FQgA+oJlRLwpMLGPHSKFMYX2dwXZzlxgoToetx8iCnPQrazd3Z42/gDfwZM7ndRj 06f9Y1DLx698ciNSxptQOlpbcggoracHNoi6gDjp9ix03OtheDTgIMZNU+NnRn02 6wihf2+sDPZ4NGenMKlG3OAd0Vmrptc/prKN4fy1sC5fiyxgZr1zjQK09ul6SVOC p1so6SBtIkCb5BUqv5vWfl7COpXrwNHjQgKcqMJBhZECheH5u/NhYTl2Rv1HlNqJ /OhOBbKxggf72pBIt9KXg0uYWqhfKs5/MpySOg659cAaplFijSurGyrQm8Tu5PYZ 7oHYePb2XzE5ESq66MgEYVBw3pJPUIUV0OqkCHxeuSIMQD0vPDHsdvxgTGm/bThc EyRY1MLXEGeWKyP+7cn7vvrubZa21v3mRLRC90wHt8bzl+p2AygOJ5Fm9qpj2YND 7CzHWz1U4JuiHF8+oUDd =NVf9 -----END PGP SIGNATURE----- --HjlUprwJuNajQ6MQ-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 12:59:08 2013 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 7F641854; Mon, 25 Nov 2013 12:59:08 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 420FB277E; Mon, 25 Nov 2013 12:59:08 +0000 (UTC) Received: from [192.168.2.2] (unknown [77.243.161.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 224075C43; Mon, 25 Nov 2013 13:59:03 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_97856E56-D5E1-4275-A25C-4BC90D51E1EA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Building with gcc? From: Dimitry Andric In-Reply-To: <20131125013122.GE1627@glenbarber.us> Date: Mon, 25 Nov 2013 13:59:03 +0100 Message-Id: <65EE6ADD-78CB-4990-ABED-CCFCC4446C34@FreeBSD.org> References: <20131125013122.GE1627@glenbarber.us> To: Glen Barber X-Mailer: Apple Mail (2.1822) Cc: Matthew Fleming , Brooks Davis , freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 12:59:08 -0000 --Apple-Mail=_97856E56-D5E1-4275-A25C-4BC90D51E1EA Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 25 Nov 2013, at 02:31, Glen Barber wrote: > On Sun, Nov 24, 2013 at 05:28:05PM -0800, Matthew Fleming wrote: >> I'm trying to test a change to gcc, and I'd like to do a full >> buildworld/buildkernel using the gcc compiler. So I added this to my >> /etc/src.conf (and make.conf, since I can't remember under which scenarios >> they're different): >> >> WITHOUT_CLANG=YES >> WITH_GCC=YES >> WITH_GNUCXX=YES >> >> and I started a buildworld. It's currently building clang. >> >> Why is it building clang? >> > > You also want WITHOUT_CLANG_IS_CC=YES. I have no reasonable explanation > for why it is different. WITHOUT_CLANG and WITHOUT_CLANG_IS_CC were decoupled in r256915 by brooks: "Stop conflating WITHOUT_CLANG with WITHOUT_CLANG_IS_CC. This allows bootstrapping a copy of clang without building clang for the base system which is useful for nanobsd and similar setups. It's still probably wrong to conflate what is installed as /usr/bin/cc with the selection of a bootstrap compiler under WITH*_CLANG_IS_CC, but that's for another day." I would still say that WITHOUT_CLANG implies that you cannot have clang as cc, so maybe it would be better to error out in this case? -Dimitry --Apple-Mail=_97856E56-D5E1-4275-A25C-4BC90D51E1EA 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----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlKTSZcACgkQsF6jCi4glqNi3ACffg6SxeSeB2VRb19U3xRNYY6g l3kAoM2hyRg2I8WKpmdxzudYiHkIIU1e =1QIn -----END PGP SIGNATURE----- --Apple-Mail=_97856E56-D5E1-4275-A25C-4BC90D51E1EA-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 13:36:58 2013 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 2ACD95C4; Mon, 25 Nov 2013 13:36:58 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0165D29F3; Mon, 25 Nov 2013 13:36:58 +0000 (UTC) Received: from glenbarber.us (70.15.88.86.res-cmts.sewb.ptd.net [70.15.88.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 1680015372; Mon, 25 Nov 2013 13:36:56 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 1680015372 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 25 Nov 2013 08:36:54 -0500 From: Glen Barber To: Dimitry Andric Subject: Re: Building with gcc? Message-ID: <20131125133654.GE2310@glenbarber.us> References: <20131125013122.GE1627@glenbarber.us> <65EE6ADD-78CB-4990-ABED-CCFCC4446C34@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RpqchZ26BWispMcB" Content-Disposition: inline In-Reply-To: <65EE6ADD-78CB-4990-ABED-CCFCC4446C34@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Matthew Fleming , Brooks Davis , freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 13:36:58 -0000 --RpqchZ26BWispMcB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2013 at 01:59:03PM +0100, Dimitry Andric wrote: > On 25 Nov 2013, at 02:31, Glen Barber wrote: > > On Sun, Nov 24, 2013 at 05:28:05PM -0800, Matthew Fleming wrote: > >> I'm trying to test a change to gcc, and I'd like to do a full > >> buildworld/buildkernel using the gcc compiler. So I added this to my > >> /etc/src.conf (and make.conf, since I can't remember under which scena= rios > >> they're different): > >>=20 > >> WITHOUT_CLANG=3DYES > >> WITH_GCC=3DYES > >> WITH_GNUCXX=3DYES > >>=20 > >> and I started a buildworld. It's currently building clang. > >>=20 > >> Why is it building clang? > >>=20 > >=20 > > You also want WITHOUT_CLANG_IS_CC=3DYES. I have no reasonable explanat= ion > > for why it is different. >=20 > WITHOUT_CLANG and WITHOUT_CLANG_IS_CC were decoupled in r256915 by brooks: >=20 > "Stop conflating WITHOUT_CLANG with WITHOUT_CLANG_IS_CC. This allows > bootstrapping a copy of clang without building clang for the base system > which is useful for nanobsd and similar setups. It's still probably > wrong to conflate what is installed as /usr/bin/cc with the selection > of a bootstrap compiler under WITH*_CLANG_IS_CC, but that's for another > day." >=20 > I would still say that WITHOUT_CLANG implies that you cannot have clang > as cc, so maybe it would be better to error out in this case? >=20 Yes, that is what I meant by not having a reasonable explanation why. If WITHOUT_CLANG is set, WITHOUT_CLANG_IS_CC should (as it was before) be implied. Glen --RpqchZ26BWispMcB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSk1J2AAoJELls3eqvi17Qi2UP/36esaOAq1yflWTcR6vndMCk nJkJBZMFuw6kPEfYVJ919JfBhy3jWa2LhNlck46sjsa1CZzGMiSENvs2F3nj2Qyq XtAOPS/HLhwJV6YjtaZ0J8jLR2X1QP73Q9ddN5UqBu+UB6oHy5RBWB0fYs/j1RRq GLn/c+u5MlCmhjPGaOaub6UuQ8bV1p3xBECOkPPO+ydbJ6aK9O04V7dhkaH7NvRN eulVacT4N8jj8H9G8Fx1jz4WG5tZ4fFvFZET+/HfPRo/D4I0FCMABaaTbliMuIQ1 LK2+hD2nMBNtQPQKWbl4YWs88hQst+ry+M/WyHHqZHwk8/mXJUcIRKlG4/ahLeiD PVXsIBRUIWl0NNVBnw4yRgw20mHX60xnZVIvIdG+9xKQ6XE7svqvTEe+pfbtvWft ET3ZAfntCosFrXTJvzngyh5qToT3zosXlh7aCvxv1Zl4ChDT3SCngmYjOEapmyBX 7RpftYbOzyXDJPXFgbSxCjQaOB7BOXTYHx4ng2qBLtcXEaAkaN6P7WhKLt5EKhjm nZcSBFd3/5zMrEcTgV98ORkMAH9WQUKwTxx1ZIjofktNgqOXtL6XeHn5vrKaOyTY YuLkb3BMT3grt46qvrlLVv0sctCDHOFvzgIDHk2eYgEsA1W4BG3J3+XPI/dmTjU8 Sa95OhHEiIKmDfd95vbq =weGh -----END PGP SIGNATURE----- --RpqchZ26BWispMcB-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 14:57:56 2013 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 8EDBFF65; Mon, 25 Nov 2013 14:57:56 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 634632F6F; Mon, 25 Nov 2013 14:57:56 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vkxbn-000Iru-CB; Mon, 25 Nov 2013 14:57:55 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rAPEvqbs004641; Mon, 25 Nov 2013 07:57:52 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18oasKQpz2hFWQEv4hWKXzF Subject: Re: Building with gcc? From: Ian Lepore To: Glen Barber In-Reply-To: <20131125133654.GE2310@glenbarber.us> References: <20131125013122.GE1627@glenbarber.us> <65EE6ADD-78CB-4990-ABED-CCFCC4446C34@FreeBSD.org> <20131125133654.GE2310@glenbarber.us> Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Nov 2013 07:57:52 -0700 Message-ID: <1385391472.1220.1.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Matthew Fleming , Brooks Davis , Dimitry Andric , freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 14:57:56 -0000 On Mon, 2013-11-25 at 08:36 -0500, Glen Barber wrote: > On Mon, Nov 25, 2013 at 01:59:03PM +0100, Dimitry Andric wrote: > > On 25 Nov 2013, at 02:31, Glen Barber wrote: > > > On Sun, Nov 24, 2013 at 05:28:05PM -0800, Matthew Fleming wrote: > > >> I'm trying to test a change to gcc, and I'd like to do a full > > >> buildworld/buildkernel using the gcc compiler. So I added this to my > > >> /etc/src.conf (and make.conf, since I can't remember under which scenarios > > >> they're different): > > >> > > >> WITHOUT_CLANG=YES > > >> WITH_GCC=YES > > >> WITH_GNUCXX=YES > > >> > > >> and I started a buildworld. It's currently building clang. > > >> > > >> Why is it building clang? > > >> > > > > > > You also want WITHOUT_CLANG_IS_CC=YES. I have no reasonable explanation > > > for why it is different. > > > > WITHOUT_CLANG and WITHOUT_CLANG_IS_CC were decoupled in r256915 by brooks: > > > > "Stop conflating WITHOUT_CLANG with WITHOUT_CLANG_IS_CC. This allows > > bootstrapping a copy of clang without building clang for the base system > > which is useful for nanobsd and similar setups. It's still probably > > wrong to conflate what is installed as /usr/bin/cc with the selection > > of a bootstrap compiler under WITH*_CLANG_IS_CC, but that's for another > > day." > > > > I would still say that WITHOUT_CLANG implies that you cannot have clang > > as cc, so maybe it would be better to error out in this case? > > > > Yes, that is what I meant by not having a reasonable explanation why. > If WITHOUT_CLANG is set, WITHOUT_CLANG_IS_CC should (as it was before) > be implied. > > Glen > In a cross-build situation, you should be able to specify WITH_CLANG_IS_CC and WITHOUT_CLANG and you get a system that is cross-compiled for the target by clang, but clang itself is not cross-compiled and installed onto the target. (I'm not sure that actually works yet, but I think that's the intention.) The names involved are confusing, but the concept makes sense. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 17:19:54 2013 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 C928B3C8 for ; Mon, 25 Nov 2013 17:19:54 +0000 (UTC) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by mx1.freebsd.org (Postfix) with ESMTP id 67F75298A for ; Mon, 25 Nov 2013 17:19:53 +0000 (UTC) Received: from nskntcmgw05p ([61.9.169.165]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20131125171952.YZTN1968.nskntmtas02p.mx.bigpond.com@nskntcmgw05p> for ; Mon, 25 Nov 2013 17:19:52 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.113.247]) by nskntcmgw05p with BigPond Outbound id ttKs1m00C5LKYmq01tKsb7; Mon, 25 Nov 2013 17:19:52 +0000 X-Authority-Analysis: v=2.0 cv=GIWK45xK c=1 sm=1 a=YibVxx38Z+cwdCKSMcELyg==:17 a=1YbsQLIiAAQA:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=g2jgOUAJe-4A:10 a=6I5d2MoRAAAA:8 a=6o5Nn00VdWYb3woe-z0A:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=YibVxx38Z+cwdCKSMcELyg==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id rAPHJi4B058559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 26 Nov 2013 04:19:45 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <52938611.3010407@heuristicsystems.com.au> Date: Tue, 26 Nov 2013 04:17:05 +1100 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Building with gcc? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 17:19:54 -0000 On 25/11/2013 12:28 PM, Matthew Fleming wrote: > I'm trying to test a change to gcc, and I'd like to do a full > buildworld/buildkernel using the gcc compiler. So I added this to my > /etc/src.conf (and make.conf, since I can't remember under which scenarios > they're different): > > WITHOUT_CLANG=YES > WITH_GCC=YES > WITH_GNUCXX=YES > > and I started a buildworld. It's currently building clang. > > Why is it building clang? > > Thanks, > matthew > _______________________________________________ > 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" > > You need, in /etc/make.conf CC=gcc Regards, Dewayne. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 18:19:38 2013 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 415B141F for ; Mon, 25 Nov 2013 18:19:38 +0000 (UTC) Received: from sanddollar.geekisp.com (sanddollar.geekisp.com [216.168.135.167]) by mx1.freebsd.org (Postfix) with SMTP id CEF852DA1 for ; Mon, 25 Nov 2013 18:19:37 +0000 (UTC) Received: (qmail 10789 invoked by uid 1003); 25 Nov 2013 18:12:56 -0000 Received: from unknown (HELO kiwi.coupleofllamas.com) (tyler@monkeypox.org@64.125.69.200) by mail.geekisp.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Nov 2013 18:12:56 -0000 Date: Mon, 25 Nov 2013 10:12:32 -0800 From: "R. Tyler Croy" To: freebsd-hackers Subject: Do pfil(9) hooks receive TCP retransmissions? Message-ID: <20131125181232.GB6275@kiwi.coupleofllamas.com> Mail-Followup-To: freebsd-hackers MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 18:19:38 -0000 --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm looking at the pfil(9) interface to accomplish some packet inspection tasks, but the man page leaves some ambiguity in this case. If the hooks are not invoked multiple times for retransmissions then I can imagine it being relatively "simple" to implement a basic firewall with these hooks without implementing loads of state tracking for packets. I would appreciate any guidance the list can offer on using pfil(9) :) Cheers - R. Tyler Croy -------------------------------------- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero rtyler@jabber.org --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlKTkxAACgkQFCbH3D9R4W+LbgCfTcxl8JkYuKIeXAK6sLVi18w1 9DUAn11/pCTXf6ezCwbQ1ggTwqTfNxWK =c9Rg -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 18:45:12 2013 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 492F3325 for ; Mon, 25 Nov 2013 18:45:12 +0000 (UTC) Received: from mailb.knobbe.us (mailb.knobbe.us [66.179.102.190]) by mx1.freebsd.org (Postfix) with SMTP id 0624E2F9B for ; Mon, 25 Nov 2013 18:45:11 +0000 (UTC) Received: from localhost (HELO mail.knobbe.us) by localhost with SMTP; 25 Nov 2013 12:38:30 -0600 Date: Mon, 25 Nov 2013 12:38:29 -0600 From: Frank Knobbe To: freebsd-hackers Subject: Re: Do pfil(9) hooks receive TCP retransmissions? Message-ID: <20131125183829.GA75749@knobbe.us> References: <20131125181232.GB6275@kiwi.coupleofllamas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131125181232.GB6275@kiwi.coupleofllamas.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 18:45:12 -0000 On Mon, Nov 25, 2013 at 10:12:32AM -0800, R. Tyler Croy wrote: > I'm looking at the pfil(9) interface to accomplish some packet inspection > tasks, but the man page leaves some ambiguity in this case. > > If the hooks are not invoked multiple times for retransmissions then I can > imagine it being relatively "simple" to implement a basic firewall with these > hooks without implementing loads of state tracking for packets. I'm not sure if I follow. Typically you only have one function that gets "hooked" into the pfil chain. That function will receive ALL packets leaving or entering the system. It's up to your code to check for the interface, apply state tracking, or whatever other checks need to be performed. For a very basic firewall (just dropping traffic from/to a certain IP address or a certain port or protocol) you probably don't need to track state. If the packet passes your filter criteria and is to be passed on (down the chain of other firewalls), your function is to return 0. If you need to filter the packet, your function needs to a) m_freem the mbuf, and b) return -1. That'll drop the packet and it won't be passed on to other firewalls in the chain or the system. Hope that helps. Cheers, Frank From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 18:52:52 2013 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 BFB9299D for ; Mon, 25 Nov 2013 18:52:52 +0000 (UTC) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 974202046 for ; Mon, 25 Nov 2013 18:52:52 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id g10so6099072pdj.15 for ; Mon, 25 Nov 2013 10:52:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=JoCSINDFgtZ4gnRDiNrCajsFJ4fM279ik12SDIOq6DM=; b=bEPl3g9Ljvgv0TPk4WEpG+EudDgXW8emuwYq/ytgUwubi1YCSuPGxDZNPN0Tf9uUXu bTAuUTVzalVXO5BX5xqjrQ46DHjokVh5btdVHNsTyejStoi0eBjd6F3QBnnBor1FIuns Ag7kypDYJmE67cvjWBe0hZ7XiULZ/blnxkGkDTdgawT+k3R9X1S6TzSkWDSEzUgoMD/U rA//Qg6gvq97EBuUKf6pVlzU5O2eFSEYeRhs/8cHMjhRQYXg8yMBaipuC+iA8K+cHlN3 F1o8FoPkrcK82NQYgUt8yFCk5N/yVq1PWoPcOAUMoZdceRQVrk+SAW6s8+0qdL4iHf1Q ss1w== X-Gm-Message-State: ALoCoQlxYDlG10Re7bS+McGhVCVS3FDOjsDDSh2fevRjwvsbbXBe/+aH0cnmOu7+HJAn6k2x1AAJ X-Received: by 10.66.122.40 with SMTP id lp8mr28606588pab.82.1385405566015; Mon, 25 Nov 2013 10:52:46 -0800 (PST) Received: from [192.168.2.123] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPSA id ja5sm74438760pbc.14.2013.11.25.10.52.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 10:52:44 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: O_XATTR support in FreeBSD? From: Tim Kientzle In-Reply-To: Date: Mon, 25 Nov 2013 10:52:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <820263347.19772534.1385247218007.JavaMail.root@uoguelph.ca> To: Jordan Hubbard X-Mailer: Apple Mail (2.1822) Cc: Freebsd hackers list , Richard Yao , Rick Macklem , Pedro Giffuni , Cedric Blancher X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 18:52:52 -0000 On Nov 23, 2013, at 3:41 PM, Jordan Hubbard = wrote: > I would start with libc and ask if it had anything similar to = copyfile(3) =85 But less broken, please. Libarchive uses copyfile() to fetch/restore extended attribute bundles on Mac OS, but it=92s a pretty ugly API. In particular, there=92s no = way to fetch/restore an EA bundle directly to/from memory; you must go through an intermediate file on disk, which is slow and race-prone. Tim From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 19:05:36 2013 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 9FC81559 for ; Mon, 25 Nov 2013 19:05:36 +0000 (UTC) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7947A2149 for ; Mon, 25 Nov 2013 19:05:36 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id p10so6093344pdj.18 for ; Mon, 25 Nov 2013 11:05:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=gB8VNwwuF8kuBt1h2RLeijr95lhXfZgb4MYo38v29TU=; b=YZtnYoULxw6mCerX2az6mVNb8DE1y5T+sWQ2JWQq1tgvTslp4yWy47YXTe1ucA5jL4 /+O9S1YAtUvF90GH7lNkeg48CCJBu3ltLjBu+d9lCacL2cUAKk2na3T+ogzPtTI+JDA/ zcpsypCpkxWFAL8pF7vIcYd8NQmjTZ6WhAmilkL4sddkqi0c8obrYJes4TSlZAlQchM3 7z6R+dS7XQNA1G3Nn6kWYf6XL9iQXEI1417X/dsuWqNKrIK1tyufczM0tDgamSnggIAU rzIYgTDN27Lcov1JrL9V+vQh+ub7Uptl3rMdaM7aTwI8kMUDPL+5raP8PBGjxIm0SDb7 /RRQ== X-Gm-Message-State: ALoCoQngYy7+roiEwfZ0vxa7KMXijZs+EuvfgQMcZ73xgwFECUKvcRUsOMe0R/W0VfPYh8smAsgW X-Received: by 10.69.31.1 with SMTP id ki1mr9392874pbd.124.1385406330042; Mon, 25 Nov 2013 11:05:30 -0800 (PST) Received: from [192.168.2.123] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPSA id g6sm76657423pat.2.2013.11.25.11.05.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 11:05:29 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Are computers always this hard? From: Tim Kientzle In-Reply-To: Date: Mon, 25 Nov 2013 11:05:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <10864114-B5DD-4AF4-A842-AF1251D5EB4C@kientzle.com> References: To: Matthew Fleming X-Mailer: Apple Mail (2.1822) Cc: freebsd-hackers , bdrewery@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 19:05:36 -0000 On Nov 24, 2013, at 2:35 PM, Matthew Fleming wrote: > I'm just trying to get FreeBSD in a VM running again on my Mac. I had = had > VMware installed, but it stopped working when I updated my OS and I = didn't > want to re-pay, so I got VirtualBox today. I=92ve had decent luck with both Parallels and VMWare Fusion on Mac. > I tried to use NFS mounting but I got too annoyed trying to get my Mac = set > up as an NFS server. It is mildly annoying, especially the part where the NFS lock server on Mac OS keeps stopping. So every time I use svn (or git, for that matter), I have to wait 10 seconds or so for the lock server to come back. (It always does; it=92s just an annoying delay.) In any case, I wrote up how I got this working; you might find some useful hints in here: = https://github.com/kientzle/crochet-freebsd/wiki/Tracking-FreeBSD-CURRENT-= with-VMWare-Fusion-and-Crochet Tim From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 19:14:49 2013 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 3E9C2E0F for ; Mon, 25 Nov 2013 19:14:49 +0000 (UTC) Received: from starfish.geekisp.com (starfish.geekisp.com [216.168.135.166]) by mx1.freebsd.org (Postfix) with SMTP id D2E1021F0 for ; Mon, 25 Nov 2013 19:14:48 +0000 (UTC) Received: (qmail 12954 invoked by uid 1003); 25 Nov 2013 19:08:07 -0000 Received: from unknown (HELO kiwi.coupleofllamas.com) (tyler@monkeypox.org@64.125.69.200) by mail.geekisp.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Nov 2013 19:08:06 -0000 Date: Mon, 25 Nov 2013 11:08:03 -0800 From: "R. Tyler Croy" To: Frank Knobbe Subject: Re: Do pfil(9) hooks receive TCP retransmissions? Message-ID: <20131125190803.GC6275@kiwi.coupleofllamas.com> Mail-Followup-To: Frank Knobbe , freebsd-hackers References: <20131125181232.GB6275@kiwi.coupleofllamas.com> <20131125183829.GA75749@knobbe.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vOmOzSkFvhd7u8Ms" Content-Disposition: inline In-Reply-To: <20131125183829.GA75749@knobbe.us> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 19:14:49 -0000 --vOmOzSkFvhd7u8Ms Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 25 Nov 2013, Frank Knobbe wrote: > On Mon, Nov 25, 2013 at 10:12:32AM -0800, R. Tyler Croy wrote: > > I'm looking at the pfil(9) interface to accomplish some packet inspecti= on > > tasks, but the man page leaves some ambiguity in this case. > >=20 > > If the hooks are not invoked multiple times for retransmissions then I = can > > imagine it being relatively "simple" to implement a basic firewall with= these > > hooks without implementing loads of state tracking for packets. >=20 > I'm not sure if I follow. Typically you only have one function that gets > "hooked" into the pfil chain. That function will receive ALL packets leav= ing > or entering the system. It's up to your code to check for the interface, > apply state tracking, or whatever other checks need to be performed. For a > very basic firewall (just dropping traffic from/to a certain IP address or > a certain port or protocol) you probably don't need to track state. >=20 > If the packet passes your filter criteria and is to be passed on (down the > chain of other firewalls), your function is to return 0. If you need to > filter the packet, your function needs to a) m_freem the mbuf, and=20 > b) return -1. That'll drop the packet and it won't be passed on to other > firewalls in the chain or the system. Let's say for example I wanted to filter out a specific HTTP response, just= as a more complex kind of traffic on top of the TCP stream. Would my hook be invoked for packets 1-100 of the HTTP response 100 times, or could it be invoked any number of times depending on whether there are retransmissions = of various packets? My goal is not necessarily to write a simple firewall at an IP level, but prototype a slightly more complex firewall filtering of application layer traffic. I'm not 100% certain pfil(9) is the right way to do this, but it's= the first useful API I've stumbled across. > Hope that helps. Most certainly :) - R. Tyler Croy -------------------------------------- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero rtyler@jabber.org --vOmOzSkFvhd7u8Ms Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlKToBMACgkQFCbH3D9R4W9PfgCfZxHgCBqcyO1reH/a4UQSWM4Q a1wAoIvt9CY0cQ3ytydbxd64JuBxCVVA =11XG -----END PGP SIGNATURE----- --vOmOzSkFvhd7u8Ms-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 19:26:36 2013 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 5DFEB5BD for ; Mon, 25 Nov 2013 19:26:36 +0000 (UTC) Received: from mailb.knobbe.us (mailb.knobbe.us [66.179.102.190]) by mx1.freebsd.org (Postfix) with SMTP id 1948C22CE for ; Mon, 25 Nov 2013 19:26:35 +0000 (UTC) Received: from localhost (HELO mail.knobbe.us) by localhost with SMTP; 25 Nov 2013 13:26:33 -0600 Date: Mon, 25 Nov 2013 13:26:33 -0600 From: Frank Knobbe To: freebsd-hackers Subject: Re: Do pfil(9) hooks receive TCP retransmissions? Message-ID: <20131125192633.GB75749@knobbe.us> References: <20131125181232.GB6275@kiwi.coupleofllamas.com> <20131125183829.GA75749@knobbe.us> <20131125190803.GC6275@kiwi.coupleofllamas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131125190803.GC6275@kiwi.coupleofllamas.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 19:26:36 -0000 On Mon, Nov 25, 2013 at 11:08:03AM -0800, R. Tyler Croy wrote: > Let's say for example I wanted to filter out a specific HTTP response, just as > a more complex kind of traffic on top of the TCP stream. Would my hook be > invoked for packets 1-100 of the HTTP response 100 times, or could it be > invoked any number of times depending on whether there are retransmissions of > various packets? Ah, gotcha. The answer is Yes. :) pfil works at the packet level. You will receive ALL packets going through the system. That means your function has to look for HTTP traffic (and ignore/pass the rest). You will also have to keep track of the session state. In essence, you get all packets involved in the TCP 3-way handshake. You probably want to track that and mark a session as established. Then on established sessions, you probably want to keep track of HTTP content and "HTTP level session state", for example limiting your actions on responses to GET requests (or POSTs or whatever you need), and not the request itself. Then finally evaluate the packet (well, stream) content for the response. Since the pfil hooks work on each packet, you will also have to reassemble the TCP/HTTP stream properly so that your checks can not be bypassed by fragmentation attacks. Say your tracking the packets, tracking 3-way, building an established TCP session table, tracking the in- or outbound request, and then wait for a response, an "attacker" could feed the response with, say, 2 byte packets, so your function will have to catch all these, in the proper order, and reassemble a complete response before you can perform any sort of content matching. This will be quite an effort. It might be easier to see if there are HTTP proxies (for example, Apache) where you could hook into in order to avoid having to do all the grunt work from the packet level up. The pfil interface is for a very low level of network traffic, and it sounds like you're wanting to build something for a much higher level in the OSI stack. Can it be done with pfil? Sure, but I wonder if the effort required would make pfil a good choice. Cheers, Frank From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 19:42:50 2013 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 17420AE3 for ; Mon, 25 Nov 2013 19:42:50 +0000 (UTC) Received: from sanddollar.geekisp.com (sanddollar.geekisp.com [216.168.135.167]) by mx1.freebsd.org (Postfix) with SMTP id ADA3D2413 for ; Mon, 25 Nov 2013 19:42:49 +0000 (UTC) Received: (qmail 13399 invoked by uid 1003); 25 Nov 2013 19:42:47 -0000 Received: from unknown (HELO kiwi.coupleofllamas.com) (tyler@monkeypox.org@64.125.69.200) by mail.geekisp.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Nov 2013 19:42:47 -0000 Date: Mon, 25 Nov 2013 11:42:43 -0800 From: "R. Tyler Croy" To: Frank Knobbe Subject: Re: Do pfil(9) hooks receive TCP retransmissions? Message-ID: <20131125194243.GD6275@kiwi.coupleofllamas.com> Mail-Followup-To: Frank Knobbe , freebsd-hackers References: <20131125181232.GB6275@kiwi.coupleofllamas.com> <20131125183829.GA75749@knobbe.us> <20131125190803.GC6275@kiwi.coupleofllamas.com> <20131125192633.GB75749@knobbe.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uxuisgdDHaNETlh8" Content-Disposition: inline In-Reply-To: <20131125192633.GB75749@knobbe.us> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 19:42:50 -0000 --uxuisgdDHaNETlh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 25 Nov 2013, Frank Knobbe wrote: > On Mon, Nov 25, 2013 at 11:08:03AM -0800, R. Tyler Croy wrote: > > Let's say for example I wanted to filter out a specific HTTP response, = just as > > a more complex kind of traffic on top of the TCP stream. Would my hook = be > > invoked for packets 1-100 of the HTTP response 100 times, or could it be > > invoked any number of times depending on whether there are retransmissi= ons of > > various packets? >=20 > Ah, gotcha. The answer is Yes. :) pfil works at the packet level. You wi= ll > receive ALL packets going through the system. That means your function has > to look for HTTP traffic (and ignore/pass the rest). You will also=20 > have to keep track of the session state. In essence, you get all packets > involved in the TCP 3-way handshake. You probably want to track that and > mark a session as established. Then on established sessions, you probably > want to keep track of HTTP content and "HTTP level session state", for > example limiting your actions on responses to GET requests (or POSTs or > whatever you need), and not the request itself. Then finally evaluate the= =20 > packet (well, stream) content for the response. >=20 > Since the pfil hooks work on each packet, you will also have to reassemble > the TCP/HTTP stream properly so that your checks can not be bypassed by > fragmentation attacks. Say your tracking the packets, tracking 3-way,=20 > building an established TCP session table, tracking the in- or outbound > request, and then wait for a response, an "attacker" could feed the respo= nse > with, say, 2 byte packets, so your function will have to catch all these, > in the proper order, and reassemble a complete response before you can > perform any sort of content matching.=20 >=20 > This will be quite an effort. It might be easier to see if there are HTTP > proxies (for example, Apache) where you could hook into in order to avoid > having to do all the grunt work from the packet level up.=20 I don't disagree with you that this might be a large amount of effort. Unfortunately I've not found any existing tools that give me the ability to create application layer filtering, while still acting as a full transparent TCP proxy. Performing such filtering in an HTTP proxy is fine, but I'm more interested (academically) in filtering traffic transparently across more than just HTT= P. > The pfil interface is for a very low level of network traffic, and it sou= nds > like you're wanting to build something for a much higher level in the OSI > stack. Can it be done with pfil? Sure, but I wonder if the effort required > would make pfil a good choice. Agreed, pfil(9) is a very big and basic hammer. - R. Tyler Croy -------------------------------------- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero rtyler@jabber.org --uxuisgdDHaNETlh8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlKTqDMACgkQFCbH3D9R4W9JrgCgoiMU5lqWuZMJy/bx8QWfXXlb /jAAn2j6UHzwOv5HHXCO4GGCFA7LeyJ0 =4jeB -----END PGP SIGNATURE----- --uxuisgdDHaNETlh8-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 19:48:39 2013 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 63C46D50 for ; Mon, 25 Nov 2013 19:48:39 +0000 (UTC) Received: from mailb.knobbe.us (mailb.knobbe.us [66.179.102.190]) by mx1.freebsd.org (Postfix) with SMTP id 30F06247F for ; Mon, 25 Nov 2013 19:48:38 +0000 (UTC) Received: from localhost (HELO mail.knobbe.us) by localhost with SMTP; 25 Nov 2013 13:48:38 -0600 Date: Mon, 25 Nov 2013 13:48:37 -0600 From: Frank Knobbe To: freebsd-hackers Subject: Re: Do pfil(9) hooks receive TCP retransmissions? Message-ID: <20131125194837.GC75749@knobbe.us> References: <20131125181232.GB6275@kiwi.coupleofllamas.com> <20131125183829.GA75749@knobbe.us> <20131125190803.GC6275@kiwi.coupleofllamas.com> <20131125192633.GB75749@knobbe.us> <20131125194243.GD6275@kiwi.coupleofllamas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131125194243.GD6275@kiwi.coupleofllamas.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 19:48:39 -0000 On Mon, Nov 25, 2013 at 11:42:43AM -0800, R. Tyler Croy wrote: > I don't disagree with you that this might be a large amount of effort. > Unfortunately I've not found any existing tools that give me the ability to > create application layer filtering, while still acting as a full transparent > TCP proxy. > > Performing such filtering in an HTTP proxy is fine, but I'm more interested > (academically) in filtering traffic transparently across more than just HTTP. "filtering traffic transparently" sounds like an IPS to me. Have you looked at Snort or Suricata (both free IPS software) to perform the filtering you desire? Perhaps you could build something on top of these? Cheers, Frank From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 21:29:27 2013 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 9262EA6E for ; Mon, 25 Nov 2013 21:29:27 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A2302ACA for ; Mon, 25 Nov 2013 21:29:27 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id j5so7218274qaq.19 for ; Mon, 25 Nov 2013 13:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=EIRD2OH7dFAlU8zCLv9mcEqR8+vtRQ/CB5ii/YtZAWw=; b=F/9/ddB0zTtLaGAaCFvY8zFSME9h6YOeQbxrLi6XCKeJ6xCeH7HHvu2AzYjWY9rtXz u1P5iGzPBMUUSZPsT4l9tCKsewqzei7BluswEU5/YdnVo5SsjB8zpyBSba53jE8la7uG 5LV8lY2lgwFx+qeCv7FIkkBzlxYod8AG9AYr/fHVWxwv95tOKgOHF7dKW/htKIcqNKEO 9eELq86vuOWL8lzro/Xotb1vwlDgpS0RiHZcettiUP6RHhAnItOmbPxQEMIczGthhQkW o/iqJkAtCnwclZxpDGQgBkFEj+piGyDXbgV5hUDuVGimP47g4K+fTC51m71yHrTUQU2V R2Ig== MIME-Version: 1.0 X-Received: by 10.224.10.197 with SMTP id q5mr28662865qaq.76.1385414966493; Mon, 25 Nov 2013 13:29:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 25 Nov 2013 13:29:26 -0800 (PST) Date: Mon, 25 Nov 2013 13:29:26 -0800 X-Google-Sender-Auth: X9nT56SaAVmOpP9rLXpw6hqYm-4 Message-ID: Subject: [review request] make sendfile usable from inside the kernel itself From: Adrian Chadd To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 21:29:27 -0000 Hi, http://people.freebsd.org/~adrian/netflix/20131125-sendfile-shuffle-1.diff This moves the copyout to the 'sbytes' field occur _outside_ of vn_sendfile() so vn_sendfile() itself can be called from kernel code. There's likely some more shuffling I have to do with sendfile but this seems like a good, simple starting point. I've done some light testing with some local code to no ill effect. Thanks! -adrian From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 22:26:00 2013 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 EA75329A; Mon, 25 Nov 2013 22:26:00 +0000 (UTC) Received: from frv154.fwdcdn.com (frv154.fwdcdn.com [212.42.77.154]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8C8B2E5C; Mon, 25 Nov 2013 22:26:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Message-ID:Subject:To:From:Date; bh=GEIDBN7xelYZGSv05Y02qrIR3g0Psmr+v85sc8IBuBk=; b=bPBQgNAWFbYVIHTOH5TzdNJuXVxEUKI0xx77fXHuFWAi+IwLIgEe4UVqp5UBRSpEsFbGgi+YgAKcsfDtezbTubdpIsxqR1GEP4MjQ7gFgpqp7swiEe+0I64Jk18oB+HHXfBMWAKLT2U5cK/TXP+RH0yNW+cKaTPC5qYTo2Qi0ZU=; Received: from [37.115.116.138] (helo=nonamehost.local) by frv154.fwdcdn.com with esmtpsa ID 1Vl4bN-0005Hv-Mj ; Tue, 26 Nov 2013 00:25:57 +0200 Date: Tue, 26 Nov 2013 00:25:57 +0200 From: Ivan Klymenko To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: SCHED_ULE and function sched_shouldpreempt Message-ID: <20131126002557.6820c60e@nonamehost.local> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Result: IP=37.115.116.138; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 22:26:01 -0000 Hello all. sched_shouldpreempt function can return only 2 values: 0 or 1 there is a set of specific conditions under which the function returns 1 if the remaining conditions - it will return 0. why use a kung fu which is currently in use? not be simpler to use that variant?: --- sched_ule.c.orig 2013-11-18 17:41:52.000000000 +0200 +++ sched_ule.c 2013-11-18 17:48:21.000000000 +0200 @@ -419,32 +419,7 @@ static inline int sched_shouldpreempt(int pri, int cpri, int remote) { - /* - * If the new priority is not better than the current priority there is - * nothing to do. - */ - if (pri >= cpri) - return (0); - /* - * Always preempt idle. - */ - if (cpri >= PRI_MIN_IDLE) - return (1); - /* - * If preemption is disabled don't preempt others. - */ - if (preempt_thresh == 0) - return (0); - /* - * Preempt if we exceed the threshold. - */ - if (pri <= preempt_thresh) - return (1); - /* - * If we're interactive or better and there is non-interactive - * or worse running preempt only remote processors. - */ - if (remote && pri <= PRI_MAX_INTERACT && cpri > PRI_MAX_INTERACT) + if ((remote && pri <= PRI_MAX_INTERACT && cpri > PRI_MAX_INTERACT)||(pri <= preempt_thresh)||(cpri >= PRI_MIN_IDLE)) return (1); return (0); } or indeed there is some uneven distribution fulfillment of certain conditions under which the execution time of that function will be much more? or to use the original variant there is any other reasons? Thanks. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 23:05:42 2013 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 6C49623E; Mon, 25 Nov 2013 23:05:42 +0000 (UTC) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D2D820B0; Mon, 25 Nov 2013 23:05:42 +0000 (UTC) Received: by mail-ve0-f182.google.com with SMTP id jy13so3360399veb.41 for ; Mon, 25 Nov 2013 15:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KoZ4BvqbCGwBU6iBqgnJfnx7g7AnbJuE6vfmrBIEBzY=; b=D8eXzeYO6ns4qb9JVjzJPCdYTCGuudUFx65HEcQYwf5sq5EvwD9P8iKFKjEt6hlVWO DSsvhQi1RqiXROF1+XQDvCP7sMQ0tHcUGqMKEoOfHmPXcVeNAzUIYsYEKVM6IshWY5iu N6bCilL9bmV4/ShjxkZAMKpKdSqgwwpggR5IgaZByqj3IYtlrWL5EKXM/mlAGJcGyZTI wnzaN6kofpWhMc3mMeTB67R86ZAIc6JzuUl4coM/qlf5wgRUw4ywV63UbcDuVx9Nmrja EihIf2jjaVUJop1QPA1L+eCfbKFcvb7QOJyY1rIwYHFeG5FZSK7DFkWAx+yGTw/9zDVB EEpA== MIME-Version: 1.0 X-Received: by 10.58.210.66 with SMTP id ms2mr28816214vec.10.1385420741237; Mon, 25 Nov 2013 15:05:41 -0800 (PST) Received: by 10.220.145.143 with HTTP; Mon, 25 Nov 2013 15:05:41 -0800 (PST) In-Reply-To: <20131126002557.6820c60e@nonamehost.local> References: <20131126002557.6820c60e@nonamehost.local> Date: Tue, 26 Nov 2013 00:05:41 +0100 Message-ID: Subject: Re: SCHED_ULE and function sched_shouldpreempt From: Daniel Janzon To: Ivan Klymenko Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 23:05:42 -0000 On Mon, Nov 25, 2013 at 11:25 PM, Ivan Klymenko wrote: > Hello all. > > sched_shouldpreempt function can return only 2 values: 0 or 1 > > there is a set of specific conditions under which the function returns > 1 if the remaining conditions - it will return 0. > why use a kung fu which is currently in use? > not be simpler to use that variant?: > > --- sched_ule.c.orig 2013-11-18 17:41:52.000000000 +0200 > +++ sched_ule.c 2013-11-18 17:48:21.000000000 +0200 > @@ -419,32 +419,7 @@ > static inline int > sched_shouldpreempt(int pri, int cpri, int remote) > { > - /* > - * If the new priority is not better than the current priority > there is > - * nothing to do. > - */ > - if (pri >= cpri) > - return (0); > - /* > - * Always preempt idle. > - */ > - if (cpri >= PRI_MIN_IDLE) > - return (1); > - /* > - * If preemption is disabled don't preempt others. > - */ > - if (preempt_thresh == 0) > - return (0); > - /* > - * Preempt if we exceed the threshold. > - */ > - if (pri <= preempt_thresh) > - return (1); > - /* > - * If we're interactive or better and there is non-interactive > - * or worse running preempt only remote processors. > - */ > - if (remote && pri <= PRI_MAX_INTERACT && cpri > PRI_MAX_INTERACT) > + if ((remote && pri <= PRI_MAX_INTERACT && cpri > > PRI_MAX_INTERACT)||(pri <= preempt_thresh)||(cpri >= PRI_MIN_IDLE)) > return (1); > return (0); > } > > or indeed there is some uneven distribution fulfillment of certain > conditions under which the execution time of that function will be much > more? > > or to use the original variant there is any other reasons? > The compiler can generate efficient code in both cases. So the code should be quick to understand, not quick to type. Also notice that all the comments are deleted in your patch. Suppose you enter the function with pri=3, cpri=2 and remote = 0. What is returned? In the deleted portion of the patch, you have the answer loud and clear in the first if case. Cheers, Daniel From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 25 22:58:16 2013 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 C2051FE9; Mon, 25 Nov 2013 22:58:16 +0000 (UTC) Received: from mail.crittercasa.com (mail.turbofuzz.com [208.87.221.144]) by mx1.freebsd.org (Postfix) with ESMTP id 9F6D52058; Mon, 25 Nov 2013 22:58:15 +0000 (UTC) Received: from kruse-49.3.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.crittercasa.com (Postfix) with ESMTPS id CD6AC164882; Mon, 25 Nov 2013 14:57:34 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: O_XATTR support in FreeBSD? From: Jordan Hubbard In-Reply-To: Date: Mon, 25 Nov 2013 14:58:07 -0800 Message-Id: References: <820263347.19772534.1385247218007.JavaMail.root@uoguelph.ca> To: Tim Kientzle X-Mailer: Apple Mail (2.1822) X-Mailman-Approved-At: Mon, 25 Nov 2013 23:11:58 +0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: Rick Macklem , Cedric Blancher , Freebsd hackers list , Richard Yao , Pedro Giffuni , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 22:58:16 -0000 On Nov 25, 2013, at 10:52 AM, Tim Kientzle wrote: > But less broken, please. >=20 > Libarchive uses copyfile() to fetch/restore extended attribute bundles > on Mac OS, but it=92s a pretty ugly API. In particular, there=92s no = way > to fetch/restore an EA bundle directly to/from memory; you must go > through an intermediate file on disk, which is slow and race-prone. If FreeBSD would be willing to take on copyfile(3) as an API, I think it = could be arranged that any flaws or concerns with it were addressed as a = prerequisite to adoption! - Jordan From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 00:31:45 2013 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 C4F7A838 for ; Tue, 26 Nov 2013 00:31:45 +0000 (UTC) Received: from mail.rlwinm.de (mail.rlwinm.de [46.4.89.243]) by mx1.freebsd.org (Postfix) with ESMTP id 8929B2522 for ; Tue, 26 Nov 2013 00:31:45 +0000 (UTC) Received: from hexe.rlwinm.de (p57A7C0C7.dip0.t-ipconnect.de [87.167.192.199]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 10CB95AE7 for ; Tue, 26 Nov 2013 00:31:44 +0000 (UTC) Message-ID: <5293EBEF.5040605@rlwinm.de> Date: Tue, 26 Nov 2013 01:31:43 +0100 From: Jan Bramkamp User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Do pfil(9) hooks receive TCP retransmissions? References: <20131125181232.GB6275@kiwi.coupleofllamas.com> In-Reply-To: <20131125181232.GB6275@kiwi.coupleofllamas.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 00:31:45 -0000 On 25.11.2013 19:12, R. Tyler Croy wrote: > > I'm looking at the pfil(9) interface to accomplish some packet inspection > tasks, but the man page leaves some ambiguity in this case. > > If the hooks are not invoked multiple times for retransmissions then I can > imagine it being relatively "simple" to implement a basic firewall with these > hooks without implementing loads of state tracking for packets. > > > I would appreciate any guidance the list can offer on using pfil(9) :) > Why do you want to reinvent the wheel? What requires you to start from scratch with pfil(9)? From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 09:51:56 2013 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 F1ACB9D4; Tue, 26 Nov 2013 09:51:56 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A43762FE6; Tue, 26 Nov 2013 09:51:56 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id to1so8913161ieb.32 for ; Tue, 26 Nov 2013 01:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8uRPI+4/4ofFhlwRw8vVeAQ5R38mEnZjo8v6xQ8RQV4=; b=zw6Y3++4/dp5ogcm7lIbbfBx3yHq6mlR8EIjOcINfo9zU0mbArkn7Th1bmiQkjaeKW bDao2SXKAMZ5dGytDrzUM13cV5pOelM1rUeZEHjgf8RWrqSrY6IpLAbYsddmNxfTymFM IBtpHet31bnQFJcAWNhPJwhg9ZLh5zYL2S5IsRePR7s0qG4iKch5ToAw1MuJJyU+msP5 uivIKa++x2DYkq45oYEuTE+bShoYHbRbiNsOb1hYGULdyJyQlNniC7UCEtIGZxtI5vMp EuQdcLJBP7QFaPCdDZsRA6gdNdMHWeQm9kuaZmm/NX4KrQ+XqwIkUSDe8ufjrtxPIkFo f5HA== MIME-Version: 1.0 X-Received: by 10.42.40.83 with SMTP id k19mr18837986ice.3.1385459515757; Tue, 26 Nov 2013 01:51:55 -0800 (PST) Received: by 10.50.225.70 with HTTP; Tue, 26 Nov 2013 01:51:55 -0800 (PST) In-Reply-To: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> References: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> Date: Tue, 26 Nov 2013 10:51:55 +0100 Message-ID: Subject: Re: O_XATTR support in FreeBSD? From: Cedric Blancher To: Freebsd hackers list Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Rick Macklem , Richard Yao , Pedro Giffuni , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 09:51:57 -0000 On 24 November 2013 15:18, Rick Macklem wrote: > Jordan Hubbard wrote: >> >> On Nov 23, 2013, at 2:53 PM, Rick Macklem >> wrote: >> >> > Interestingly, FreeBSD has a VOP_OPENEXTATTR() but no syscall >> > that uses it nor support for it in ZFS. (I'm just guessing it >> > was intended for an openat(2) syscall at some time?) > Oops, my mistake. Robert has clarified what the VOP_OPENEXTATTR() > is used for. > > Therefore, there doesn't appear to be any support for subfiles/fork files > in the VFS (VOP_xxx()) or syscalls. > >> > Btw Cedric, if you had mentioned "subfiles" or "fork files" in your >> > subject line, you might have gotten a better answer. I, for one, >> > didn't know what O_XATTR is. I also always get confused w.r.t. what >> > to call these beasts. (NFSv4 calls the named attributes.) >> > >> > Btw, apps can use extended attributes (the limited sized >> > atomically stored/read kind). They aren't just for >> > storing ACLs. >> >> Sigh. Extended Attributes. :-/ >> >> I guess I=92ll raise my head in this discussion. They=92ve certainly >> been the bane of my existence for long enough! >> >> First, supporting EAs properly really involves multiple levels of the >> Unix command and library stack. >> >> The filesystem can support them natively, sure, but that=92s actually >> somewhat optional since you can always (cough cough) stick them in a >> side-store if the rest of the stack cooperates. That=92s where the >> awesome AppleDouble files came from (=93._weirdfile" corresponding to >> =93weirdfile") which remain useful even after filesystems like >> HFS/ZFS/UFS became EA-aware natively because there=92s always those >> foreign data stores to talk to (some early AFP/CIFS/NFS mount, for >> example) and the fact that you still need to *serialize* the dang >> things into tar / cpio / zip / ??? files as well as across network >> replication with tools like rsync. What good is an EA, much less an >> ACL that=92s been stored in an EA, if it gets stripped off the first >> time you tar up a directory and extract it somewhere else? >> >> So I wouldn=92t start with NFSv4 or ZFS if I was asking the question. >> I would start with libc and ask if it had anything similar to >> copyfile(3) so that the tools above it could start actually >> supporting those attributes on a *practical* basis! :) >> > Righto, w.r.t. the client side. For the NFSv4 server side, it > would be what the VFS and file systems support. > > Just to clarify, I wasn't interested in doing this. It was Cedric > who asked about them. My impression is that with the Linux "marketshare", > apps will tend to use the atomic limited size ones already supported > by FreeBSD. (NFSv4.0 and 4.1 don't support these, but there is discussion > w.r.t. adding support for them in a future minor revision of the > protocol, possibly 4.2. The named attributes in NFSv4 expect the > subfile/forkfile model and do not support atomic writing of an > entire extended attribute.) Some clarifications: 1. You do not need more syscalls. Solaris uses the plain openat() syscall for this, with the O_XATTR flag passed to the normal open()/openat() flags to open a named attribute. Likewise read(), write(), mmap() etc work, too. 2. The filesystem implementation should be quite easy too. For example Solaris UFS seems to use the special *file* name '/@/' (or part of a file name, I don't know) to describe that this is a named attribute 3. We use NFSv4 attributes (as opened with O_XATTR, accessed with openat(), read(), write() like normal files, and most importantly with unlimited size) quite expensively, and if you look around you see that institutions like CERN, software like SAMBA or SAP+OracleDB or much code from NIH uses this stuff. 4. Usage seems even to be common enough that the latest ksh version (ksh93v-) includes special support for O_XATTR attributes (like cd -@ filename or a builtin virtual filesystem (like ksh's /dev/tcp/host/portnumber) so that you can use cat Institute Pasteur From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 10:19:13 2013 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 611642E6; Tue, 26 Nov 2013 10:19:13 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 316312191; Tue, 26 Nov 2013 10:19:13 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id g10so7463327pdj.1 for ; Tue, 26 Nov 2013 02:19:12 -0800 (PST) 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 :message-id:references:to; bh=DxxCbJCrCF+0GrIm+Tw3u0g+vHCje3kiK/lXHrI5tbQ=; b=VS/ZS9p+8k2sGHI7T+GQ7HR+bM1PMAsiGm+8jK5lmRd3DItZqSbOSjsLzrl6wrCHPL 6Lq4hrn5Yovp1I8bmPmCOqj53LPiOwy9Jt6d6q5tEscB2wijtyM9KIGsFW9fC+bjBfr6 +/g2sRNSH4bwlLf8Zdmxyay7Lhm5UE0CZaty7PEaPzUSXYk8K4sEVg7yO2E18TSQAfJV 3S22xdnRxir9mZyF2Gxz7rzYOu28JONLt08ei4GfrLljr3KITfhQ7Y/Hp64z0Tg73gRT C9VDn+yaB6aLXJffUzILlBjl3xWJuaE3xIHu8HcFJ8d3+bEKpkZtrQQiVMnzm4KyC8R8 gHkg== X-Received: by 10.66.2.66 with SMTP id 2mr33871828pas.72.1385461152670; Tue, 26 Nov 2013 02:19:12 -0800 (PST) Received: from [10.20.30.117] (16.sub-70-197-7.myvzw.com. [70.197.7.16]) by mx.google.com with ESMTPSA id jn12sm38146827pbd.37.2013.11.26.02.19.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 02:19:11 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) Subject: Re: O_XATTR support in FreeBSD? From: Jordan Hubbard In-Reply-To: Date: Tue, 26 Nov 2013 02:19:08 -0800 Message-Id: References: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> To: Cedric Blancher X-Mailer: Apple Mail (2.1812) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: Freebsd hackers list , Richard Yao , Pedro Giffuni , Rick Macklem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 10:19:13 -0000 On Nov 26, 2013, at 1:51 AM, Cedric Blancher = wrote: > 1. You do not need more syscalls. Solaris uses the plain openat() > syscall for this, with the O_XATTR flag passed to the normal > open()/openat() flags to open a named attribute. Likewise read(), > write(), mmap() etc work, too. I don=92t know if I=92d go so far as to say =93you do not need more = syscalls=94; there are additional functions for manipulating EAs that go well beyond the Solaris extensions to the directory and file I/O functions. = Assuming you want to be able to get/set as well as enumerate or remove EAs, then you might just as well add getxattr(2), listxattr(2), removexattr(2), = setxattr(2) too and follow the herd (Linux and OS X, so far). We=92re also glossing over ACLs and where they get to live. I don=92t = know if Robert and friends have stuck them in a separate namespace on FreeBSD or if = they=92re in system-protected EAs, as they are in OS X, but ACL preservation = across serialization / deserialization is just as important as it is for EAs. > 5. Support for tar and pax is already there. Its described in > Solaris's fsattr man page, they use a extended header with filename > /dev/null (to prevent older tar versions from tripping over the new > headers) and then have a named attribute header which describes the > attributes names and flags. This approach gets uglier when you try to apply to tools like rsync or = scp - now we=92re going to version their protocols? I think this was the = wrong approach, basically. Now there are multiple semi-compatible versions of tar and pax on Solaris, and they didn=92t do anything for zip/bzip/gzip = (what happens when you bzip2 a file with EAs and then unbzip it again? What if that file is on a remote NFSv3 share?). Again, the =93sidecar=94 files may strike all concerned as grotty hacks, = and they sort of ARE, but they=92re also the only fully functional, = work-in-pretty-much-all=20 situations solution for these scenarios. If the underlying filesystem = supports EAs, you just copy it from old to new or you stick it in the sidecar = file. If you=92re serializing a file across *any* streaming serialization protocol, you = sidecar it and if the other side doesn=92t support EAs, fine, the sidecar file = remains there intact and no data-loss has occurred. If it does, it simply combines = the file and sidecar files together and they disappear again. - Jordan From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 12:27:46 2013 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 953E0515; Tue, 26 Nov 2013 12:27:46 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E19129C3; Tue, 26 Nov 2013 12:27:46 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id y13so7564574pdi.19 for ; Tue, 26 Nov 2013 04:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3xaogLIP2VAB2Y7pOH8Of4XAAkTFXeBAIiiigmeMWrI=; b=eW41jgQyWq4PacGTRW1aGDaJJHHfPLQFkSr1zl8KBSAcjS3yucw0sh10xHTZQBN4tH RHoajFvpTfDJW2lSnzQLSZrw5toml6HiltDtQ1m5ahnJak6KIRROutv8laM1tl22vShZ H40eHBQzR4B5pVWB2722HEmJ9MtICIj+L6ingWAJq5j77vShNahqJqCXLyFlWIDmZTr+ 0OGagIbZdofQg198R11ABZVNqIaj5QoXTMvtvTF3dyDUNFcYFnk4+ywH6UMLBcv6AqDR e2GJZeydm/38ys7odnQ8NlA0FyhuUxDVAUYzN38WJTTHvNaVdvZV6JvBfdRjqP3bjs3a Kt1A== MIME-Version: 1.0 X-Received: by 10.66.147.9 with SMTP id tg9mr34597881pab.5.1385468865905; Tue, 26 Nov 2013 04:27:45 -0800 (PST) Received: by 10.70.64.132 with HTTP; Tue, 26 Nov 2013 04:27:45 -0800 (PST) Date: Tue, 26 Nov 2013 13:27:45 +0100 Message-ID: Subject: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) From: Lionel Cons To: Freebsd hackers list Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Richard Yao , Jordan Hubbard , Pedro Giffuni , Cedric Blancher , Rick Macklem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 12:27:46 -0000 On 26 November 2013 11:19, Jordan Hubbard wrote: > > On Nov 26, 2013, at 1:51 AM, Cedric Blancher = wrote: > >> 1. You do not need more syscalls. Solaris uses the plain openat() >> syscall for this, with the O_XATTR flag passed to the normal >> open()/openat() flags to open a named attribute. Likewise read(), >> write(), mmap() etc work, too. > > I don=92t know if I=92d go so far as to say =93you do not need more sysca= lls=94; > there are additional functions for manipulating EAs that go well beyond > the Solaris extensions to the directory and file I/O functions. Assuming= you > want to be able to get/set as well as enumerate or remove EAs, then > you might just as well add getxattr(2), listxattr(2), removexattr(2), set= xattr(2) > too and follow the herd (Linux and OS X, so far). You mean 'follow the lemmings down into the abyss'? :) > We=92re also glossing over ACLs and where they get to live. I don=92t kn= ow if Robert > and friends have stuck them in a separate namespace on FreeBSD or if they= =92re > in system-protected EAs, as they are in OS X, but ACL preservation across > serialization / deserialization is just as important as it is for EAs. Could we first agree what we are talking about, please? I'm a bit new to this thread, but AFAIK we are talking about the Windows Alternate Data Streams as they appear in networked filesystem like NFSv4 and CIFS and physical filesystems like NTFS, ZFS and Solaris UFS, right? ACLs have no direct relation to those streams. The attributes support from Linux has been proven (at least from CERNs viewpoint) as pretty useless because of their size constrains and crappy API (i.e. no mmap(), no sparse support, no normal tools can access them, ...) so IMHO the herd to follow is the herd which implements at least the following requirements: 1) A proper implementation, which includes access using the normal system utilities (in Solaris there is the runat(1) utility to access the hidden directory containing the attribute files, and bash4.3 and ksh have cd -@ to cwd into the hidden directories containing the attribute files. From that point on (inside the hidden directory) ls(1) and even chown(1) and chmod(1) work as usual. You can even stick ZFS and NFSv4 ACLs on the files in the hidden directory containing the attribute files) 2) read(), write() and mmap() access, i.e. the normal POSIX API (of course with the minor extension to flag an access to an alternate data stream or the directory containing the alternate data streams) 2) Support in networked filesystems (i.e. NFSv4, CIFS) 3) No size restrictions (just to explain, at CERN the alternate data streams are often precompiled caches or index files of the main file's contents, and can easily in the TB range) 4) Support for sparse data (i.e. SEEK_HOLE and SEEK_DATA) 5) More than one implementation available AFAIK Solaris, Nexenta, Illumos (NFSv4, ZFS, UFS) and Windows Alternate Data Streams (CIFS, NTFS) fit these requirements. Lionel From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 15:28:12 2013 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 7253FF15; Tue, 26 Nov 2013 15:28:12 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 41F97261E; Tue, 26 Nov 2013 15:28:09 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA15275; Tue, 26 Nov 2013 17:28:08 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VlKYZ-0001Fc-Ou; Tue, 26 Nov 2013 17:28:07 +0200 Message-ID: <5294BDCF.1050702@FreeBSD.org> Date: Tue, 26 Nov 2013 17:27:11 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: John Baldwin , freebsd-hackers@FreeBSD.org Subject: Re: taskqueue_block References: <5287BDB9.10201@FreeBSD.org> <528B7681.6090806@FreeBSD.org> <201311211414.06849.jhb@freebsd.org> In-Reply-To: <201311211414.06849.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Bernhard Schmidt , Luigi Rizzo , ray@FreeBSD.org, Andrew Thompson , Pyun YongHyeon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 15:28:12 -0000 on 21/11/2013 21:14 John Baldwin said the following: > On Tuesday, November 19, 2013 10:29:18 pm Adrian Chadd wrote: >> Yes, and lets fix this. :) > > Hmm, is taskqueue_block() always used in context where waiting is safe? I reviewed usage of taskqueue_block() and it appears that in all cases except for if_ath (which I'd like to discuss separately) the function is a part of the anti-pattern taskqueue_block + taskqueue_drain. That, according to my understanding, means that a) taskqueue_block() would be safe to use if it were blocking and b) in many cases it should not be necessary at all. Here are some annotated patches: ================================================ --- a/sys/dev/jme/if_jme.c +++ b/sys/dev/jme/if_jme.c @@ -2259,6 +2259,9 @@ jme_link_task(void *arg, int pending) jme_stop_rx(sc); jme_stop_tx(sc); + /* Unblock execution of task. */ + taskqueue_unblock(sc->jme_tq); + /* XXX Drain all queued tasks. */ JME_UNLOCK(sc); taskqueue_drain(sc->jme_tq, &sc->jme_int_task); @@ -2332,8 +2335,6 @@ jme_link_task(void *arg, int pending) ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; callout_reset(&sc->jme_tick_ch, hz, jme_tick, sc); - /* Unblock execution of task. */ - taskqueue_unblock(sc->jme_tq); /* Reenable interrupts. */ CSR_WRITE_4(sc, JME_INTR_MASK_SET, JME_INTRS); ================================================ I am not sure if taskqueue_block is really needed in this driver. I took a safer assumption and decided that it could be needed while jme_stop_rx, etc are being called. But the taskqueue should not be block over a call to taskqueue_drain. This patch could easily be wrong and some further reshuffling of the code could be needed, but the patch shows the direction. Particularly, I am concerned about possible interaction between JME_LOCK/JME_UNLOCK and taskqueue_block. ================================================ --- a/sys/dev/netmap/if_em_netmap.h +++ b/sys/dev/netmap/if_em_netmap.h @@ -53,13 +53,10 @@ em_netmap_block_tasks(struct adapter *adapter) struct rx_ring *rxr = adapter->rx_rings; for (i = 0; i < adapter->num_queues; i++, txr++, rxr++) { - taskqueue_block(txr->tq); taskqueue_drain(txr->tq, &txr->tx_task); - taskqueue_block(rxr->tq); taskqueue_drain(rxr->tq, &rxr->rx_task); } } else { /* legacy */ - taskqueue_block(adapter->tq); taskqueue_drain(adapter->tq, &adapter->link_task); taskqueue_drain(adapter->tq, &adapter->que_task); } @@ -69,18 +66,6 @@ em_netmap_block_tasks(struct adapter *adapter) static void em_netmap_unblock_tasks(struct adapter *adapter) { - if (adapter->msix > 1) { - struct tx_ring *txr = adapter->tx_rings; - struct rx_ring *rxr = adapter->rx_rings; - int i; - - for (i = 0; i < adapter->num_queues; i++) { - taskqueue_unblock(txr->tq); - taskqueue_unblock(rxr->tq); - } - } else { /* legacy */ - taskqueue_unblock(adapter->tq); - } } diff --git a/sys/dev/netmap/if_lem_netmap.h b/sys/dev/netmap/if_lem_netmap.h index 25e5c7c..76c8246 100644 --- a/sys/dev/netmap/if_lem_netmap.h +++ b/sys/dev/netmap/if_lem_netmap.h @@ -60,7 +60,6 @@ lem_netmap_reg(struct ifnet *ifp, int onoff) ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); #ifndef EM_LEGACY_IRQ // XXX do we need this ? - taskqueue_block(adapter->tq); taskqueue_drain(adapter->tq, &adapter->rxtx_task); taskqueue_drain(adapter->tq, &adapter->link_task); #endif /* !EM_LEGCY_IRQ */ @@ -83,10 +82,6 @@ fail: lem_init_locked(adapter); /* also enable intr */ } -#ifndef EM_LEGACY_IRQ - taskqueue_unblock(adapter->tq); // XXX do we need this ? -#endif /* !EM_LEGCY_IRQ */ - EM_CORE_UNLOCK(adapter); return (error); ================================================ taskqueue_block that is immediately followed by taskqueue_drain is completely redundant (in addition to being deadlock prone). So this is an easy case. ================================================ --- a/sys/dev/rt/if_rt.c +++ b/sys/dev/rt/if_rt.c @@ -810,22 +810,17 @@ rt_stop_locked(void *priv) ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); callout_stop(&sc->periodic_ch); callout_stop(&sc->tx_watchdog_ch); + + /* disable interrupts */ + RT_WRITE(sc, GE_PORT_BASE + FE_INT_ENABLE, 0); + RT_SOFTC_UNLOCK(sc); - taskqueue_block(sc->taskqueue); - /* - * Sometime rt_stop_locked called from isr and we get panic - * When found, I fix it - */ -#ifdef notyet taskqueue_drain(sc->taskqueue, &sc->rx_done_task); taskqueue_drain(sc->taskqueue, &sc->tx_done_task); taskqueue_drain(sc->taskqueue, &sc->periodic_task); -#endif - RT_SOFTC_LOCK(sc); - /* disable interrupts */ - RT_WRITE(sc, GE_PORT_BASE + FE_INT_ENABLE, 0); + RT_SOFTC_LOCK(sc); /* reset adapter */ RT_WRITE(sc, GE_PORT_BASE + FE_RST_GLO, PSE_RESET); ================================================ I am not sure why the calls to taskqueue_drain were commented out. In my opinion they are correct. I was not able to find any possible way for rt_stop_locked to be called from an ISR as the comment alleged. I suspect that the problem was actually caused by the taskqueue_block + taskqueue_drain deadlock. Also, I think that disabling interrupts before calling taskqueue_drain should ensure that no new tasks will be enqueued, but I could be wrong about this. ================================================ --- a/sys/net80211/ieee80211_proto.c +++ b/sys/net80211/ieee80211_proto.c @@ -1207,14 +1207,12 @@ update_chw(void *arg, int npending) void ieee80211_waitfor_parent(struct ieee80211com *ic) { - taskqueue_block(ic->ic_tq); ieee80211_draintask(ic, &ic->ic_parent_task); ieee80211_draintask(ic, &ic->ic_mcast_task); ieee80211_draintask(ic, &ic->ic_promisc_task); ieee80211_draintask(ic, &ic->ic_chan_task); ieee80211_draintask(ic, &ic->ic_bmiss_task); ieee80211_draintask(ic, &ic->ic_chw_task); - taskqueue_unblock(ic->ic_tq); } /* ================================================ Again, this is an obvious case of the wrong taskqueue_block usage. I've CC-ed the developers who seem to have worked recently on the affected code. I would like to ask you to review and/or test the changes. My understanding of the code is based on a quick glance, so I could be very wrong. In that case, I would like to discuss how the code actually works and what it expects to achieve by using taskqueue_block. Please see the quoted below text for my thoughts on why using taskqueue_block + taskqueue_drain is a problem. Thank you! >> On 19 November 2013 06:32, Andriy Gapon wrote: >>> >>> Forwarding this to the larger audience for a discussion. >>> >>> -------- Original Message -------- >>> Message-ID: <5287BDB9.10201@FreeBSD.org> >>> Date: Sat, 16 Nov 2013 20:47:21 +0200 >>> From: Andriy Gapon >>> Subject: taskqueue_block >>> >>> >>> >>> It seems that either I do not understand something about taskqueue_block code or >>> it is a quite dangerous and abused API. The fact that it is not properly >>> documented does not help either. >>> >>> The commit message said: >>>> Implement taskqueue_block() and taskqueue_unblock(). These functions allow the >>>> owner of a queue to block and unblock execution of the tasks in the queue while >>>> allowing tasks to continue to be added queue. Combining this with >>>> taskqueue_drain() allows a queue to be safely disabled. The unblock function may >>> [...] >>> >>> I indeed see this (anti?) pattern being used in the code. >>> But what about the following case. One thread calls taskqueue_block() and sets >>> TQ_FLAGS_BLOCKED. Another thread calls taskqueue_enqueue, this adds a task to >>> the queue and sets ta_pending of the task to 1. tq_enqueue is not called, so an >>> actual queue runner is not called or waken up. Then the first thread calls >>> taskqueue_drain() on the task. As far as I can see, the thread would then just >>> wait forever because the task is pending and is not going to be executed. >>> >>> Additionally, it is impossible to reason about the taskqueue's state after >>> taskqueue_block call, because the call just sets the flag and does not do any >>> synchronization. And as described above, it is not safe to call APIs that could >>> allow the taskqueue or the task state to become known. >>> >>> I think that taskqueue_block() should wait on the currently active tasks to >>> complete. I don't think that this behavior could be optional. I do see any >>> reasonable and safe use for "non-blocking" taskqueue_block(). >>> taskqueue_drain() calls after taskqueue_block() must be removed. The code >>> should either use taskqueue_drain() or "blocking" taskqueue_block() depending on >>> concrete circumstances. >>> >>> What do you think? >>> Thank you. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 17:08:34 2013 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 7024C53D; Tue, 26 Nov 2013 17:08:34 +0000 (UTC) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 41C712DEA; Tue, 26 Nov 2013 17:08:34 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id rp16so8415921pbb.18 for ; Tue, 26 Nov 2013 09:08:33 -0800 (PST) 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=zcuDVBL9+HVR+z2AVOM08PtBBo7uwAPFg+8gdOLugu8=; b=MNIfHjdyeiRunG67qBN8k4vewGBVDeJHCSe4cwhUNoCvdIR5OcIitEy986cc5ZGT+Y jLx5eJ3TvYIVK0wtH6q0vsgY7qzrNbhDzIstf6uenIbonyu9+zcx1q+8MJltkTFTpiXY GNg6x8I8v0iUy/nG+z4p7NYcFCsCIJTTeSkMwxOGkVM/03dx8LR5ummXFG7LlLcDxdAq zZTsaf1dU49VJZ6MieWxi33YiA3lRKrrvUh5WjzIwfBILowI0WftSK1jydD6kbwvRiDL FMb0n6r2hFbQd0BpLtGw+1wk/miQHmOg796ILThNt64VaFpAAviRklb6a5jAOaKQHNQx QwdA== X-Received: by 10.68.232.37 with SMTP id tl5mr402218pbc.86.1385485713262; Tue, 26 Nov 2013 09:08:33 -0800 (PST) Received: from [10.20.30.117] (45.sub-70-197-14.myvzw.com. [70.197.14.45]) by mx.google.com with ESMTPSA id sg1sm81909879pbb.16.2013.11.26.09.08.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 09:08:32 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) Subject: Re: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) From: Jordan Hubbard In-Reply-To: Date: Tue, 26 Nov 2013 09:08:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1934C2F2-C380-4689-A811-61BB0009BA6B@gmail.com> References: To: Lionel Cons X-Mailer: Apple Mail (2.1812) Cc: Freebsd hackers list , Richard Yao , Pedro Giffuni , Cedric Blancher , Rick Macklem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 17:08:34 -0000 On Nov 26, 2013, at 4:27 AM, Lionel Cons = wrote: >> I don=92t know if I=92d go so far as to say =93you do not need more = syscalls=94; >> there are additional functions for manipulating EAs that go well = beyond >> the Solaris extensions to the directory and file I/O functions. = Assuming you >> want to be able to get/set as well as enumerate or remove EAs, then >> you might just as well add getxattr(2), listxattr(2), removexattr(2), = setxattr(2) >> too and follow the herd (Linux and OS X, so far). >=20 > You mean 'follow the lemmings down into the abyss'? :) Well, I don=92t know that it=92s an =93abyss=94 - EAs may or may not be = useful, depending on how you employ them! In the first version of OS X to support them, in fact, I believe they = were limited in size to 4883 bytes (don=92t ask me why that number) and = they were still used to apply various =93tags=94 to files (Finder = metadata, some index values into the search database, etc). General = pressure to use them for more things eventually got this size bumped up = to 128K, and now it=92s actually 2GB(!) = (http://support.apple.com/kb/HT5983) so I think it=92s fair to say that = EAs in OS X are now essentially equivalent to forked files, more or = less. > Could we first agree what we are talking about, please? I'm a bit new > to this thread, but AFAIK we are talking about the Windows Alternate > Data Streams as they appear in networked filesystem like NFSv4 and > CIFS and physical filesystems like NTFS, ZFS and Solaris UFS, right? > ACLs have no direct relation to those streams. Actually, I didn=92t think we were talking about alternate data streams = myself. Conceptually they=92re equivalent, I guess, but I=92ve always = through they were somewhat overkill and I=92ve yet to encounter an = application that seriously uses them. I=92m sure they=92re out there = somewhere, but even back in the days when EAs were limited to just over = 4K, we found them very useful for what was essentially their original = purpose - an extension to the file attribute data that Unix already = proves. The only reason that ACLs crept into the discussion is because = of where they=92re stored. I don=92t know about Linux, but Apple has = chosen to store ACLs in EAs, which is pretty useful because this gives = you an easy way of serializing the ACLs too - you just serialize them = from a suitably privileged process. The main point I was trying to make is that if you=92re going to have = EAs at all, you need to commit fully. The various Unix tools need to = support them (we=92ve already talked about the archivers and = compressors) and tools like ls(1) need to be able to show them on files. = You need a way of dealing with them on foreign filesystems that don=92t = support EAs. Most folks just cram EAs into the filesystem, add a few = decorations to existing system calls and then shout =93done!=94 and do a = victory dance. Then when nobody actually uses EAs, they go =93See? I = always told you EAs were crap! Terrible idea! Never should have added = them!=94 This is tantamount to building a car with an engine but no wheels, = dashboard or steering wheel and then declaring that the world just isn=92t= ready for cars since they=92re not buying yours. I know you cite Solaris=92 integration as an example of such a =93full = solution, and maybe the =93~@=93 syntax was awesome in practice, I = dunno, all I can say is that the only namespace trick we needed to pull = at Apple were the AppleDouble (._) sidecar files. There was an earlier = filename/..rfork/ syntax for addressing resource forks, which predated = EAs in OS X, and some folks used it quite a bit, but it was eventually = deprecated in favor of the single sidecar file. I never found a need to = =93cd=94 into the namespace of a file=92s EAs when I had the xattr(1) = command so handy for deleting / changing them, and ls=92s -@ argument = would also display them for me. I suppose it is all a matter of taste. = If someone wanted to do the namespace thing in FreeBSD, I wouldn=92t = argue against it. I also wouldn=92t argue against fully parallel =93forks=94 being a = superset of EAs, since I guess at CERN where folks are routinely looking = at Petabytes of data from a detector like ATLAS or CMS, anything that = puts size constraints on their data is just the devil, but again, that = wasn=92t actually the point I was trying to make. I was simply trying = to say that NFSv4 or ZFS =93native EA support=94 is the easy part. The = harder part is in making sure that the EAs don=92t get stripped out in = transit or during routine file manipulations, and this requires that = everything from cp(1) to rsync(8) becomes EA-aware. Most of the = implementations I=92ve seen don=92t bother to do that last mile of = integration, and as a result EAs are just basically untrustworthy beasts = that users shy away from. - Jordan From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 17:17:44 2013 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 34A539B7; Tue, 26 Nov 2013 17:17:44 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E60162E6B; Tue, 26 Nov 2013 17:17:43 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id uy5so6140556obc.12 for ; Tue, 26 Nov 2013 09:17:43 -0800 (PST) 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=jsYFPGh3LRq/4k4EJOn9FBacVSAoSyChDpZoIuv6TH0=; b=FkZLGspTv6lmzQN+S4IsnNrWFtciTTt65lM8rB5P/REmSC56JkSY8NK3osMmJWQeg2 Vszq+1PUTlh5JJLqty/mb7Hjpi9E+Q9AQqxkd2T0F776YTDxnq5/bDArmblLusMDOnt6 bamNODnCINZDqyJX/NQc83kW+ctKNB96JFu6nMQSqNBI14v7uRz/2SSOq2JU7lNGQ2Si ty1GoL2PnC4PhJDuES1F5Bwhlg/aYXXdvjnIDwDusoe57K0tH2p7yFl/VpYdlZl0CltT nfP3K85RY/kX5QrooifvqawqnprsctXKU51jydiFZt7kuq93/0kv1DqSmAPEzwZLc9yt JkkQ== MIME-Version: 1.0 X-Received: by 10.182.213.166 with SMTP id nt6mr6456302obc.53.1385486263195; Tue, 26 Nov 2013 09:17:43 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.182.110.195 with HTTP; Tue, 26 Nov 2013 09:17:43 -0800 (PST) In-Reply-To: <1934C2F2-C380-4689-A811-61BB0009BA6B@gmail.com> References: <1934C2F2-C380-4689-A811-61BB0009BA6B@gmail.com> Date: Tue, 26 Nov 2013 09:17:43 -0800 X-Google-Sender-Auth: rCsx-LjIUJhjO7gtzxK7iDYF6Vs Message-ID: Subject: Re: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) From: Matthew Fleming To: Jordan Hubbard Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: Rick Macklem , Cedric Blancher , Freebsd hackers list , Richard Yao , Pedro Giffuni , Lionel Cons X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 17:17:44 -0000 On Tue, Nov 26, 2013 at 9:08 AM, Jordan Hubbard w= rote: > > On Nov 26, 2013, at 4:27 AM, Lionel Cons wrote= : > > Could we first agree what we are talking about, please? I'm a bit new > > to this thread, but AFAIK we are talking about the Windows Alternate > > Data Streams as they appear in networked filesystem like NFSv4 and > > CIFS and physical filesystems like NTFS, ZFS and Solaris UFS, right? > > ACLs have no direct relation to those streams. > > Actually, I didn=92t think we were talking about alternate data streams > myself. Conceptually they=92re equivalent, I guess, but I=92ve always th= rough > they were somewhat overkill and I=92ve yet to encounter an application th= at > seriously uses them. Anyone implementing a SMB/CIFS filesystem on top of FreeBSD (e.g. a vendor) will need to come up with support for ADS. Whether or not any "FreeBSD" application has use for them is maybe beside the point -- vendors have a use for support. Though probably every vendor who wants them has already coded their own variant. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 17:34:24 2013 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 7823DFF3; Tue, 26 Nov 2013 17:34:24 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 368912F67; Tue, 26 Nov 2013 17:34:24 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id at1so9423256iec.7 for ; Tue, 26 Nov 2013 09:34:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0SMUPu5jk+v4jPc4Pqpia0UGnWU2P/MVqePqkY0A9JE=; b=hQXKSnNbbZ/bmm9XiLvX4JJKmYk0AIHIq49mmqLCetHQMt+CS6WoiJJFqo7e533YuS 2JARu/V8hyhACO7ytcbQbovLRR3s5zaZPC7U+JtHnUURHH/FM7z/FfDKmjnHsBQipCzL Qs56yXBE55Hkw12ubG2PpxuxLfNar4NvpTPNejOs8EG4JnXXBO2uEsoKAcgZ+vYSmBln PPu4zoL9wYpuz6A758JTKEMhaBnvZ6rzlVsItdL6Q52tZ3bAfehVgGRfBthU+62BR0oA qGBYCZ8yivPjiNUFSqpybXX/KoROA2lg74LsUHn3XUudowQHp33gU1v422gywabCJI4y rUKg== MIME-Version: 1.0 X-Received: by 10.50.50.169 with SMTP id d9mr18194574igo.28.1385487263670; Tue, 26 Nov 2013 09:34:23 -0800 (PST) Received: by 10.50.225.70 with HTTP; Tue, 26 Nov 2013 09:34:23 -0800 (PST) In-Reply-To: References: <1934C2F2-C380-4689-A811-61BB0009BA6B@gmail.com> Date: Tue, 26 Nov 2013 18:34:23 +0100 Message-ID: Subject: Re: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) From: Cedric Blancher To: Matthew Fleming Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Rick Macklem , Freebsd hackers list , Richard Yao , Pedro Giffuni , Jordan Hubbard , Lionel Cons X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 17:34:24 -0000 On 26 November 2013 18:17, Matthew Fleming wrote: > On Tue, Nov 26, 2013 at 9:08 AM, Jordan Hubbard > wrote: >> >> >> On Nov 26, 2013, at 4:27 AM, Lionel Cons wrot= e: >> > Could we first agree what we are talking about, please? I'm a bit new >> > to this thread, but AFAIK we are talking about the Windows Alternate >> > Data Streams as they appear in networked filesystem like NFSv4 and >> > CIFS and physical filesystems like NTFS, ZFS and Solaris UFS, right? >> > ACLs have no direct relation to those streams. >> >> Actually, I didn=92t think we were talking about alternate data streams >> myself. Conceptually they=92re equivalent, I guess, but I=92ve always t= hrough >> they were somewhat overkill and I=92ve yet to encounter an application t= hat >> seriously uses them. > > > Anyone implementing a SMB/CIFS filesystem on top of FreeBSD (e.g. a vendo= r) > will need to come up with support for ADS. Whether or not any "FreeBSD" > application has use for them is maybe beside the point -- vendors have a = use > for support. Though probably every vendor who wants them has already cod= ed > their own variant. +1 BTW: FreeBSD uses ZFS as main file system, and ZFS has native O_XATTR support (aka Alternate Data Streams). How hard is it to add O_XATTR, VFS_XATTR and FXATTR in the FreeBSD vfs layer? Ced --=20 Cedric Blancher Institute Pasteur From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 17:48:35 2013 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 D12B48EC; Tue, 26 Nov 2013 17:48:35 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 98F0F2070; Tue, 26 Nov 2013 17:48:35 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id lx4so9785633iec.37 for ; Tue, 26 Nov 2013 09:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0bTbCpF8CajlSaVamxi+I+cGZ2ZnQtG2Koku1Az4KUw=; b=SAKZfs/EWfi0BX6B1lSNrqmZFhJbWbvo4iUdas6+NhnEsQ1hSYEkIiy6AainfDkYTU /xh4ir//z0ZZRJAZAHbx30OdF5Vfy0ilbKpItfuOMBhTIO8Q7CQpNgVaw5TvK5zVx2hc 8tntrPTYU9hTdXncGNQkaQeSCtIKVAzeUGypDaCoQH96xuM3UHYS2F0hPXczNu8oQqya cdeBlmVJhg24fNOmiEWAxdC2seRruHqEqce0kxoix0Dp5bgWrBntfsngMDV/qkvRI464 wC8Nc9eJeNypnwAmHAiUj4DxngzCfqG+3kina0xc+BZDaHHF/ZYRrpRAM6NVqkZt5A4E xIKg== MIME-Version: 1.0 X-Received: by 10.50.238.196 with SMTP id vm4mr17944968igc.43.1385488106991; Tue, 26 Nov 2013 09:48:26 -0800 (PST) Received: by 10.50.225.70 with HTTP; Tue, 26 Nov 2013 09:48:26 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Nov 2013 18:48:26 +0100 Message-ID: Subject: Re: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) From: Cedric Blancher To: Lionel Cons Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Freebsd hackers list , Richard Yao , Jordan Hubbard , Pedro Giffuni , Rick Macklem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 17:48:35 -0000 On 26 November 2013 13:27, Lionel Cons wrote: > On 26 November 2013 11:19, Jordan Hubbard wrot= e: >> >> On Nov 26, 2013, at 1:51 AM, Cedric Blancher = wrote: >> >>> 1. You do not need more syscalls. Solaris uses the plain openat() >>> syscall for this, with the O_XATTR flag passed to the normal >>> open()/openat() flags to open a named attribute. Likewise read(), >>> write(), mmap() etc work, too. >> >> I don=92t know if I=92d go so far as to say =93you do not need more sysc= alls=94; >> there are additional functions for manipulating EAs that go well beyond >> the Solaris extensions to the directory and file I/O functions. Assumin= g you >> want to be able to get/set as well as enumerate or remove EAs, then >> you might just as well add getxattr(2), listxattr(2), removexattr(2), se= txattr(2) >> too and follow the herd (Linux and OS X, so far). > > You mean 'follow the lemmings down into the abyss'? :) > >> We=92re also glossing over ACLs and where they get to live. I don=92t k= now if Robert >> and friends have stuck them in a separate namespace on FreeBSD or if the= y=92re >> in system-protected EAs, as they are in OS X, but ACL preservation acros= s >> serialization / deserialization is just as important as it is for EAs. > > Could we first agree what we are talking about, please? I'm a bit new > to this thread, but AFAIK we are talking about the Windows Alternate > Data Streams as they appear in networked filesystem like NFSv4 and > CIFS and physical filesystems like NTFS, ZFS and Solaris UFS, right? > ACLs have no direct relation to those streams. > > The attributes support from Linux has been proven (at least from CERNs > viewpoint) as pretty useless because of their size constrains and > crappy API (i.e. no mmap(), no sparse support, no normal tools can > access them, ...) so IMHO the herd to follow is the herd which > implements at least the following requirements: > 1) A proper implementation, which includes access using the normal > system utilities (in Solaris there is the runat(1) utility to access > the hidden directory containing the attribute files, and bash4.3 and > ksh have cd -@ to cwd into the hidden directories containing the > attribute files. From that point on (inside the hidden directory) > ls(1) and even chown(1) and chmod(1) work as usual. You can even stick > ZFS and NFSv4 ACLs on the files in the hidden directory containing the > attribute files) > 2) read(), write() and mmap() access, i.e. the normal POSIX API (of > course with the minor extension to flag an access to an alternate data > stream or the directory containing the alternate data streams) > 2) Support in networked filesystems (i.e. NFSv4, CIFS) > 3) No size restrictions (just to explain, at CERN the alternate data > streams are often precompiled caches or index files of the main file's > contents, and can easily in the TB range) > 4) Support for sparse data (i.e. SEEK_HOLE and SEEK_DATA) > 5) More than one implementation available > > AFAIK Solaris, Nexenta, Illumos (NFSv4, ZFS, UFS) and Windows > Alternate Data Streams (CIFS, NTFS) fit these requirements. +1 Other argument pro-Alternate Data Streams: Alternate Data Streams are a superset of the Linux extended attributes (and can thus be used to emulate them in libc), have all their strengths but none of their weaknesses (like the hideously duplicated vfs apis and the lack of support in POSIX utilities). IMHO the Solaris/Illumos/Nexenta solution of O_XATTR provides a better integration into the Unix filesystem philosophy (everything is a file) and already reached such a common market penetration that common of the shelf shells like bash and ksh integrated support for them. Ced --=20 Cedric Blancher Institute Pasteur From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 19:00:36 2013 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 BCED8D6D; Tue, 26 Nov 2013 19:00:36 +0000 (UTC) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2299D24C8; Tue, 26 Nov 2013 19:00:35 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.7/8.14.7) with ESMTP id rAQJ0YdF077241; Tue, 26 Nov 2013 13:00:34 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id rAQJ0YW0077240; Tue, 26 Nov 2013 13:00:34 -0600 (CST) (envelope-from brooks) Date: Tue, 26 Nov 2013 13:00:34 -0600 From: Brooks Davis To: Ian Lepore Subject: Re: Building with gcc? Message-ID: <20131126190034.GD29388@lor.one-eyed-alien.net> References: <20131125013122.GE1627@glenbarber.us> <65EE6ADD-78CB-4990-ABED-CCFCC4446C34@FreeBSD.org> <20131125133654.GE2310@glenbarber.us> <1385391472.1220.1.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qz2CZ664xQdCRdPu" Content-Disposition: inline In-Reply-To: <1385391472.1220.1.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Glen Barber , Dimitry Andric , freebsd-hackers , Matthew Fleming X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 19:00:36 -0000 --Qz2CZ664xQdCRdPu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2013 at 07:57:52AM -0700, Ian Lepore wrote: > On Mon, 2013-11-25 at 08:36 -0500, Glen Barber wrote: > > On Mon, Nov 25, 2013 at 01:59:03PM +0100, Dimitry Andric wrote: > > > On 25 Nov 2013, at 02:31, Glen Barber wrote: > > > > On Sun, Nov 24, 2013 at 05:28:05PM -0800, Matthew Fleming wrote: > > > >> I'm trying to test a change to gcc, and I'd like to do a full > > > >> buildworld/buildkernel using the gcc compiler. So I added this to= my > > > >> /etc/src.conf (and make.conf, since I can't remember under which s= cenarios > > > >> they're different): > > > >>=20 > > > >> WITHOUT_CLANG=3DYES > > > >> WITH_GCC=3DYES > > > >> WITH_GNUCXX=3DYES > > > >>=20 > > > >> and I started a buildworld. It's currently building clang. > > > >>=20 > > > >> Why is it building clang? > > > >>=20 > > > >=20 > > > > You also want WITHOUT_CLANG_IS_CC=3DYES. I have no reasonable expl= anation > > > > for why it is different. > > >=20 > > > WITHOUT_CLANG and WITHOUT_CLANG_IS_CC were decoupled in r256915 by br= ooks: > > >=20 > > > "Stop conflating WITHOUT_CLANG with WITHOUT_CLANG_IS_CC. This allows > > > bootstrapping a copy of clang without building clang for the base sys= tem > > > which is useful for nanobsd and similar setups. It's still probably > > > wrong to conflate what is installed as /usr/bin/cc with the selection > > > of a bootstrap compiler under WITH*_CLANG_IS_CC, but that's for anoth= er > > > day." > > >=20 > > > I would still say that WITHOUT_CLANG implies that you cannot have cla= ng > > > as cc, so maybe it would be better to error out in this case? > > >=20 > >=20 > > Yes, that is what I meant by not having a reasonable explanation why. > > If WITHOUT_CLANG is set, WITHOUT_CLANG_IS_CC should (as it was before) > > be implied. > >=20 > > Glen > >=20 >=20 > In a cross-build situation, you should be able to specify > WITH_CLANG_IS_CC and WITHOUT_CLANG and you get a system that is > cross-compiled for the target by clang, but clang itself is not > cross-compiled and installed onto the target. (I'm not sure that > actually works yet, but I think that's the intention.) That is the intention as expressed in the commit log. Users of systems like nanobsd or consumers like NetFlix want to build with the standard compiler which currently that means bootstrapping clang, but they have no interest in installing it on the host platform as it's a waste of space and build time. > The names involved are confusing, but the concept makes sense. As the commit log says, it would make sense to break WITH*_CLANG_IS_CC into WITH*_CLANG_IS_CC and something like WITH*_CROSS_COMPILER_IS_CLANG, that name also sucks so it wasn't the issue I was trying to address at the time. Yes, the names suck, but I didn't invent them. There should probably be some hierarchy in the names so things that effect _what_ is built (most of the options) are clearly differentiated from things that effect _how_ things are built. -- Brooks --Qz2CZ664xQdCRdPu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFSlO/RXY6L6fI4GtQRAifjAJsFyD+Rw06WC9BI/vBZEFjVSW3qXACeP3Bb Z9kvBJhP7njugnz/VJC96IU= =RGao -----END PGP SIGNATURE----- --Qz2CZ664xQdCRdPu-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 20:24:06 2013 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 12A758FA; Tue, 26 Nov 2013 20:24:06 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 387252A9A; Tue, 26 Nov 2013 20:24:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA18959; Tue, 26 Nov 2013 22:24:03 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VlPAx-0001Xc-5O; Tue, 26 Nov 2013 22:24:03 +0200 Message-ID: <5295032B.4010200@FreeBSD.org> Date: Tue, 26 Nov 2013 22:23:07 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: Re: taskqueue_drain_all References: <525519F1.3050703@FreeBSD.org> In-Reply-To: <525519F1.3050703@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 20:24:06 -0000 on 09/10/2013 11:55 Andriy Gapon said the following: > > I would like to propose to extend taskqueue API with taskqueue_drain_all. > A potential use case: I have a private taskqueue, several kinds of tasks get > executed via it and then I want to make sure that all of them are completed. > Obviously, I have a way to ensure that no new ones get enqueued. Provided I do not get any no-s or why-s I am going to commit the following slightly different version soon: http://people.freebsd.org/~avg/taskqueue_drain_all.diff P.S. taskqueue_drain_running introduced in the above patch could also be used to add wait semantics to taskqueue_block. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 20:25:10 2013 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 497FD9F6 for ; Tue, 26 Nov 2013 20:25:10 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0CEE62AAC for ; Tue, 26 Nov 2013 20:25:09 +0000 (UTC) Received: from [89.204.154.254] (helo=tiny-r255948) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VlPBt-0005Zh-QL for freebsd-hackers@freebsd.org; Tue, 26 Nov 2013 21:25:02 +0100 Received: from tiny-r255948 (localhost [127.0.0.1]) by tiny-r255948 (8.14.7/8.14.3) with ESMTP id rAQKOxII001084 for ; Tue, 26 Nov 2013 21:24:59 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny-r255948 (8.14.7/8.14.3/Submit) id rAQKOwJT001083 for freebsd-hackers@freebsd.org; Tue, 26 Nov 2013 21:24:58 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny-r255948: guru set sender to guru@unixarea.de using -f Date: Tue, 26 Nov 2013 21:24:58 +0100 From: Matthias Apitz To: freebsd-hackers@freebsd.org Subject: how to build a liveDVD Message-ID: <20131126202457.GA1065@tiny-r255948> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT r235646 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.154.254 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 20:25:10 -0000 Hello, I've created a lot of times USB keys which acts as a FreeBSD live system, i.e. one can boot it and even start the KDE4 desktop, all without any installation to the diskdrive. Is there some kindo of tutorial to do the same based on a DVD, i.e for producing a bootable DVD which brings the system up in some memory file system? Thanks matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 20:58:10 2013 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 C39838D3; Tue, 26 Nov 2013 20:58:10 +0000 (UTC) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D2752CE7; Tue, 26 Nov 2013 20:58:10 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id rq2so8828605pbb.17 for ; Tue, 26 Nov 2013 12:58:10 -0800 (PST) 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 :message-id:references:to; bh=5hi99TKzq3KiBMGB6vEyj6k8iXFRefQbZ2mEzrnuNiI=; b=PRK7+p61xF3h5arWhR7YnMFosGjenZwOpcG/+c9UZxH0+gN4ioFk5Jsbtq82w6gDAn v+QEOvVqD1RTM1CZg54mNd2J0p4rYybyx5iiFWlYc6fV00zjNB0rcB2D+f14dTXQgLdf UELcqD/lJWxNBnhxpwwJTewmz2NkevRCdGAfaOHi3ty5TtDfS7/kpP+mfOMfzHs+CKWY uj9YFvWRpxDkPmMpUMFqipUj7KR0/072DuPM2lq6IDVWM54JOVPyzkig97uA7fJFIx/A semWScpQ68Eeqe936RIFQPzdE1BO1I3wjBux2jXBGsWwB0IX7Sibks5PXMwYkzUmXOpY lCNQ== X-Received: by 10.68.233.201 with SMTP id ty9mr1369196pbc.72.1385499490130; Tue, 26 Nov 2013 12:58:10 -0800 (PST) Received: from [10.20.30.11] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id g6sm85493403pat.2.2013.11.26.12.58.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 12:58:09 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) From: Jordan Hubbard In-Reply-To: Date: Tue, 26 Nov 2013 12:58:05 -0800 Message-Id: <17AA3DC3-F1C3-4261-AF5C-0FE031A865C6@gmail.com> References: <1934C2F2-C380-4689-A811-61BB0009BA6B@gmail.com> To: Matthew Fleming X-Mailer: Apple Mail (2.1822) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: Rick Macklem , Cedric Blancher , Freebsd hackers list , Richard Yao , Pedro Giffuni , Lionel Cons X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 20:58:10 -0000 On Nov 26, 2013, at 9:17 AM, Matthew Fleming wrote: > Anyone implementing a SMB/CIFS filesystem on top of FreeBSD (e.g. a = vendor) will need to come up with support for ADS. Whether or not any = "FreeBSD" application has use for them is maybe beside the point -- = vendors have a use for support. Though probably every vendor who wants = them has already coded their own variant. Oh, you mean like some provider of a NAS appliance based on FreeBSD? :-) I do take your point, though fortunately (?) there really is only one = "vendor" we all need to concern ourselves with here, and that's Samba. = I doubt that anyone in the BSD world save Apple has the resources to go = their own direction with respect to CIFS. A fair amount of googling around doesn't reveal many folks hacking this = sort of integration into samba. I'll have to ask Jeremy. Now you have = me curious. :-) - Jordan From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 21:38:29 2013 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 A65866AD; Tue, 26 Nov 2013 21:38:29 +0000 (UTC) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 598312038; Tue, 26 Nov 2013 21:38:29 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id b4so5581243qen.1 for ; Tue, 26 Nov 2013 13:38:28 -0800 (PST) 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=Uvg6LAyd7Tneo/GNGJgNqoRoXgl1sFIaKqKx7NJqgRQ=; b=z6sjT94PpB+d3SbMbTbjfeZXwvlTOg813IE9m9dH0zD1QFHMw7InxeDiM4vzgpJvne dpaZsXZU1pgfnm8/JlXBXaE9L4Y2uZBKO/JqT5NIzCaKgIzp+v0a4NlweRKclpe2CN5u CcuOpB+KshBI2t7cGDaoYRtzpcELrQeO+2ANCaAAVlR8Lyk17MHeLThtA06Jh+2dyDYa +xDzypuTPB34ktwkUOl0c8tzhsCXOgsA4UOB9adSIG0M8DLoyLckm25Bml/uvDq5wMNK 3U56SSd30BR+p3ddHuUbr/Zhbtse7LBgqZHY1INAwKs63tJ1Sg9tA0QCrAZapJYlc8E+ 1vww== MIME-Version: 1.0 X-Received: by 10.224.111.197 with SMTP id t5mr60564335qap.49.1385501908467; Tue, 26 Nov 2013 13:38:28 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Tue, 26 Nov 2013 13:38:28 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Nov 2013 13:38:28 -0800 X-Google-Sender-Auth: XzFEph49JqN-2af1I92zOyfs3F4 Message-ID: Subject: Re: 9.1 callout behavior From: Adrian Chadd To: Bret Ketchum Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , Alexander Motin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 21:38:29 -0000 Yup! -a On 26 November 2013 04:10, Bret Ketchum wrote: > > Would there be any benefit in producing an example kernel module which > exhibits this behavior? > > > On Thu, Nov 21, 2013 at 2:19 PM, Adrian Chadd wrote: >> >> Hi, >> >> It sounds like you may have found an interesting test case. >> >> Mav, any ideas? >> >> >> >> -adrian >> >> >> On 21 November 2013 05:20, Bret Ketchum wrote: >> > I've a callout which runs every 100ms and does a bit of accounting >> > using the global ticks variable. This one-shot callout was called fairly >> > consistently in 8.1, every 100ms give or take a few thousand clocks. >> > I've >> > recently upgraded to 9.1 and for the most part the period is consistent. >> > However, periodically the callout function is executed anywhere between >> > 5ms >> > to 20ms after the callout was reset and the function returned while >> > global >> > ticks has increased 8x. The hardware has not changed (using the same >> > timecounter configuration): >> > >> > CPU: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz (2500.05-MHz K8-class CPU) >> > >> > kern.timecounter.hardware: TSC-low >> > kern.timecounter.tick: 1 >> > kern.timecounter.invariant_tsc: 1 >> > kern.timecounter.smp_tsc: 1 >> > >> > And default eventtimer configuration: >> > >> > kern.eventtimer.singlemul: 2 >> > kern.eventtimer.idletick: 0 >> > kern.eventtimer.activetick: 1 >> > kern.eventtimer.timer: LAPIC >> > kern.eventtimer.periodic: 0 >> > >> > If tickless mode is disabled the inconsistency goes away. Is the >> > premature expiration of the callout expected? Is the jump in global >> > ticks >> > typical (say from 100 ticks to 800 ticks in 1.5ms)? >> > >> > Bret >> > _______________________________________________ >> > 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 Tue Nov 26 21:42:13 2013 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 B9CFE7E0; Tue, 26 Nov 2013 21:42:13 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0271B2082; Tue, 26 Nov 2013 21:42:12 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id ii20so4998217qab.9 for ; Tue, 26 Nov 2013 13:42:11 -0800 (PST) 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=W9/xYLMXXthz4IQoAomiVo2BeYcPBcOJ3YTAAaqaTKQ=; b=OprLGjSdTN3uQjxv+cvPnmWlbcBx5bSsYP7Azr8icM4dtjMYlHFZ5xmHy+il9kU7Yt WWY8R79ZbRh8Js/w8advywJz69Us1fcTlN23b6PNj2Mr+Lfr3UoTqxEmSstrrVg93uHA NfzOjF1PqcdrvqFQjKCg9sUkqh8VHUttKVvzk9dZS6YALLsjjp9FYApoDXw3+4LSsM+D 7lZBh17p2xL0Nq7q1p2Q+8m6XO7vsUclNeFcT2CJSnSOg7vuU4Sysj041w6qGLo2Ead0 TKrZO1okWI5P10PqpBDIe8R3P0lhuuhExblkU4c4sMZOp8cmZhnIxs0sNqh5DaUzKKvK Q+6w== MIME-Version: 1.0 X-Received: by 10.224.10.197 with SMTP id q5mr39068456qaq.76.1385502131565; Tue, 26 Nov 2013 13:42:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Tue, 26 Nov 2013 13:42:11 -0800 (PST) In-Reply-To: <5294BDCF.1050702@FreeBSD.org> References: <5287BDB9.10201@FreeBSD.org> <528B7681.6090806@FreeBSD.org> <201311211414.06849.jhb@freebsd.org> <5294BDCF.1050702@FreeBSD.org> Date: Tue, 26 Nov 2013 13:42:11 -0800 X-Google-Sender-Auth: HzsVYTwt3nrz5HNyJkHRnzZ01iY Message-ID: Subject: Re: taskqueue_block From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , Bernhard Schmidt , "freebsd-hackers@freebsd.org" , Aleksandr Rybalko , Andrew Thompson , Pyun YongHyeon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 21:42:13 -0000 Hi, the net80211 semantics are: * all those tasks have to have finished; * no new tasks should've been started whilst we're draining those tasks. waitfor_parent wants to block until all the pending update tasks are done. Ideally it would then stay blocked until the caller does their thing and then unblocks the taskqueue. -adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 21:44:10 2013 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 274A5A60; Tue, 26 Nov 2013 21:44:10 +0000 (UTC) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D0B1520A7; Tue, 26 Nov 2013 21:44:09 +0000 (UTC) Received: by mail-qe0-f43.google.com with SMTP id 2so6379433qeb.2 for ; Tue, 26 Nov 2013 13:44:09 -0800 (PST) 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=/XbsiqT0Vc21TRfepoH9hIwnO6scvgz60PuZdJLXVDE=; b=eyxe46/4ubkOhz6wNKbLOjtHvlBT4vkRjlZ/M0ctnYmUF0gXKpAP8u+AlQQR9Pout2 V3EKitDsJk4GpmQpnNuWydjZREVi5DGloh5ONueKYFO+p0Agknt2P65Rs1RL33Sb1VrQ UnUYixsu02JJL4ufirKeNSY+PUQNv2UErd9KlYSBQMurxy1/1RA2ix5ZQXxvXJkmFltx yPrIjNPVRUXocNdgubW1aF3xYa0oTkr92xWuoaI4mOmCWshbwIrr278uUMHvIeLkLkh+ IJ/nJe7n72HcvQ46dW6IX1786o4JU937SJG/Yd5oLqwAfMadpy4/GszXy41ElQE085vQ Du4w== MIME-Version: 1.0 X-Received: by 10.224.10.197 with SMTP id q5mr39082677qaq.76.1385502249007; Tue, 26 Nov 2013 13:44:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Tue, 26 Nov 2013 13:44:08 -0800 (PST) In-Reply-To: <5295032B.4010200@FreeBSD.org> References: <525519F1.3050703@FreeBSD.org> <5295032B.4010200@FreeBSD.org> Date: Tue, 26 Nov 2013 13:44:08 -0800 X-Google-Sender-Auth: 46gvNv-HTD5V0eUxWReJvkw6v8w Message-ID: Subject: Re: taskqueue_drain_all From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 21:44:10 -0000 Hi, On 26 November 2013 12:23, Andriy Gapon wrote: > on 09/10/2013 11:55 Andriy Gapon said the following: >> >> I would like to propose to extend taskqueue API with taskqueue_drain_all. >> A potential use case: I have a private taskqueue, several kinds of tasks get >> executed via it and then I want to make sure that all of them are completed. >> Obviously, I have a way to ensure that no new ones get enqueued. > > Provided I do not get any no-s or why-s I am going to commit the following > slightly different version soon: > > http://people.freebsd.org/~avg/taskqueue_drain_all.diff > > P.S. > taskqueue_drain_running introduced in the above patch could also be used to add > wait semantics to taskqueue_block. > So you're going to keep taskqueue_drain() semantics of running the tasks if they're queued? -adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 22:42:22 2013 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 26FD1657; Tue, 26 Nov 2013 22:42:22 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id CFC2A23FF; Tue, 26 Nov 2013 22:42:21 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEANcilVKDaFve/2dsb2JhbABZhBKCergJgUF0giUBAQQBI08HBRYYAgINGQIjNgYTG4dUAwkGrkyIcw2IDBeBKYEzihCBOCQBMweCa4FIA4lCjGeMNoIPhTmBaoFcHoEsQg X-IronPort-AV: E=Sophos;i="4.93,778,1378872000"; d="scan'208";a="72602277" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 26 Nov 2013 17:42:15 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 26A73B4061; Tue, 26 Nov 2013 17:42:15 -0500 (EST) Date: Tue, 26 Nov 2013 17:42:15 -0500 (EST) From: Rick Macklem To: Cedric Blancher Message-ID: <1300352912.21429386.1385505735146.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Freebsd hackers list , Richard Yao , Jordan Hubbard , Pedro Giffuni , Lionel Cons X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 22:42:22 -0000 Cedric Blancher wrote: > On 26 November 2013 13:27, Lionel Cons > wrote: > > On 26 November 2013 11:19, Jordan Hubbard > > wrote: > >> > >> On Nov 26, 2013, at 1:51 AM, Cedric Blancher > >> wrote: > >> > >>> 1. You do not need more syscalls. Solaris uses the plain openat() > >>> syscall for this, with the O_XATTR flag passed to the normal > >>> open()/openat() flags to open a named attribute. Likewise read(), > >>> write(), mmap() etc work, too. > >> > >> I don=E2=80=99t know if I=E2=80=99d go so far as to say =E2=80=9Cyou d= o not need more > >> syscalls=E2=80=9D; > >> there are additional functions for manipulating EAs that go well > >> beyond > >> the Solaris extensions to the directory and file I/O functions. > >> Assuming you > >> want to be able to get/set as well as enumerate or remove EAs, > >> then > >> you might just as well add getxattr(2), listxattr(2), > >> removexattr(2), setxattr(2) > >> too and follow the herd (Linux and OS X, so far). > > > > You mean 'follow the lemmings down into the abyss'? :) > > > >> We=E2=80=99re also glossing over ACLs and where they get to live. I d= on=E2=80=99t > >> know if Robert > >> and friends have stuck them in a separate namespace on FreeBSD or > >> if they=E2=80=99re > >> in system-protected EAs, as they are in OS X, but ACL preservation > >> across > >> serialization / deserialization is just as important as it is for > >> EAs. > > > > Could we first agree what we are talking about, please? I'm a bit > > new > > to this thread, but AFAIK we are talking about the Windows > > Alternate > > Data Streams as they appear in networked filesystem like NFSv4 and > > CIFS and physical filesystems like NTFS, ZFS and Solaris UFS, > > right? > > ACLs have no direct relation to those streams. > > > > The attributes support from Linux has been proven (at least from > > CERNs > > viewpoint) as pretty useless because of their size constrains and > > crappy API (i.e. no mmap(), no sparse support, no normal tools can > > access them, ...) so IMHO the herd to follow is the herd which > > implements at least the following requirements: > > 1) A proper implementation, which includes access using the normal > > system utilities (in Solaris there is the runat(1) utility to > > access > > the hidden directory containing the attribute files, and bash4.3 > > and > > ksh have cd -@ to cwd into the hidden directories containing the > > attribute files. From that point on (inside the hidden directory) > > ls(1) and even chown(1) and chmod(1) work as usual. You can even > > stick > > ZFS and NFSv4 ACLs on the files in the hidden directory containing > > the > > attribute files) > > 2) read(), write() and mmap() access, i.e. the normal POSIX API (of > > course with the minor extension to flag an access to an alternate > > data > > stream or the directory containing the alternate data streams) > > 2) Support in networked filesystems (i.e. NFSv4, CIFS) > > 3) No size restrictions (just to explain, at CERN the alternate > > data > > streams are often precompiled caches or index files of the main > > file's > > contents, and can easily in the TB range) > > 4) Support for sparse data (i.e. SEEK_HOLE and SEEK_DATA) > > 5) More than one implementation available > > > > AFAIK Solaris, Nexenta, Illumos (NFSv4, ZFS, UFS) and Windows > > Alternate Data Streams (CIFS, NTFS) fit these requirements. >=20 > +1 >=20 > Other argument pro-Alternate Data Streams: Alternate Data Streams are > a superset of the Linux extended attributes (and can thus be used to > emulate them in libc), have all their strengths but none of their > weaknesses (like the hideously duplicated vfs apis and the lack of > support in POSIX utilities). >=20 Not exactly, as I understand it. Linux (and FreeBSD) extended attributes support atomic replacement of the entire attribute value. At least for NFSv4 named attributes, this cannot be emulated, since the named attribute is replaced by a "Setattr size=3D0, write offset=3D0" and there is no way to do those 2 operations as one atomic operation. I suppose a syscall could be implemented as an atomic update (in FreeBSD an exclusive vnode lock could be used) for local file systems, but since the VOPs for the atomic size limited extended attrbutes already exist, I don't see emulation as useful. The NFSv4 working group seems to have decided to add support for atomically set extended attributes (Linux, FreeBSD style) to a future minor revision, due to it not being possible to accurately emulate them with named attribut= es. rick > IMHO the Solaris/Illumos/Nexenta solution of O_XATTR provides a > better > integration into the Unix filesystem philosophy (everything is a > file) > and already reached such a common market penetration that common of > the shelf shells like bash and ksh integrated support for them. >=20 > Ced > -- > Cedric Blancher > Institute Pasteur >=20 From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 22:53:12 2013 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 4B2428A9; Tue, 26 Nov 2013 22:53:12 +0000 (UTC) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EDF9524A5; Tue, 26 Nov 2013 22:53:11 +0000 (UTC) Received: by mail-vb0-f43.google.com with SMTP id q12so4497560vbe.30 for ; Tue, 26 Nov 2013 14:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2dMIggtpk6AXnAKcBD8l19jC7JJd/3YeRfe5aeTfrYo=; b=Bsse4WaA/sJudunJbh1Q0eYF8JKa1+kNpw7UUc7/fYsSAR/NVbDkjZXCsc5lIZbVnk rZV4ochCyPXjkMu70zUiJ3MOkk1T1l8l8LBzZ+xSuiDtdBRQj+5lON5JD5hOjzKMTSFA QcbU1a1/Nv6p80FO4Bds2NCDGF8wWNSAX+GYME98ROLHFwomEb5AL9WUM0I4C9yymW+Z npcWOVRCJ4ItWAmtahplnnhKe5zw7UlKkMQfV7dqMv9dhXUD1UTA99GkezCmpHEaZ395 cwRrvW+YZXC4RPJWXRmlFRwK88DJdsSoZjNNOgHHLqPnrHBapWhF6eof89SxSMv1prYo BKUA== MIME-Version: 1.0 X-Received: by 10.58.248.198 with SMTP id yo6mr685567vec.40.1385506391010; Tue, 26 Nov 2013 14:53:11 -0800 (PST) Received: by 10.58.96.7 with HTTP; Tue, 26 Nov 2013 14:53:10 -0800 (PST) In-Reply-To: <1300352912.21429386.1385505735146.JavaMail.root@uoguelph.ca> References: <1300352912.21429386.1385505735146.JavaMail.root@uoguelph.ca> Date: Tue, 26 Nov 2013 23:53:10 +0100 Message-ID: Subject: Re: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) From: Joshuah Hurst To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Pedro Giffuni , Cedric Blancher , Freebsd hackers list , Richard Yao , Jordan Hubbard , Lionel Cons X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 22:53:12 -0000 On Tue, Nov 26, 2013 at 11:42 PM, Rick Macklem wrote: > Cedric Blancher wrote: >> On 26 November 2013 13:27, Lionel Cons >> wrote: > The NFSv4 working group seems to have decided to add support for atomically > set extended attributes (Linux, FreeBSD style) to a future minor revision, > due to it not being possible to accurately emulate them with named attributes. ABSOLUTELY not. Any such attempt will be voted down, as of NetApp, Oracle, and others. The extended attributes are nonstandard and not even backed by ANY other standard (e.g. POSIX, Single UNIX Standard). This will not happen, except for vendor-specific extensions not part of any NFSv4 RFC. Whatever shit or FUD Linux may invent, Linux-style extended attributes will NOT be part of the official NFS4.x *standard* Josh From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 23:12:42 2013 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 0D9B4AE3; Tue, 26 Nov 2013 23:12:42 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id ADC712591; Tue, 26 Nov 2013 23:12:41 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAN4plVKDaFve/2dsb2JhbABZgz9Tgnq4CYE/dIIlAQEEASNLCwUWDgoCAg0ZAiM2BhMJh2YDCQYNrkWIdA2IDBeBKYEzihCBPwEBGzQHgmuBSAOJQoxnjDaCD4U5gWqBXB6BNTk X-IronPort-AV: E=Sophos;i="4.93,778,1378872000"; d="scan'208";a="72610680" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 26 Nov 2013 18:12:40 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 51E4FB3F1A; Tue, 26 Nov 2013 18:12:40 -0500 (EST) Date: Tue, 26 Nov 2013 18:12:40 -0500 (EST) From: Rick Macklem To: Joshuah Hurst Message-ID: <931003215.21443193.1385507560325.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Pedro Giffuni , Cedric Blancher , Freebsd hackers list , Richard Yao , Jordan Hubbard , Lionel Cons X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 23:12:42 -0000 Joshuah Hurst wrote: > On Tue, Nov 26, 2013 at 11:42 PM, Rick Macklem > wrote: > > Cedric Blancher wrote: > >> On 26 November 2013 13:27, Lionel Cons > >> wrote: > > The NFSv4 working group seems to have decided to add support for > > atomically > > set extended attributes (Linux, FreeBSD style) to a future minor > > revision, > > due to it not being possible to accurately emulate them with named > > attributes. > > ABSOLUTELY not. Any such attempt will be voted down, as of NetApp, > Oracle, and others. The extended attributes are nonstandard and not > even backed by ANY other standard (e.g. POSIX, Single UNIX Standard). > This will not happen, except for vendor-specific extensions not part > of any NFSv4 RFC. > > Whatever shit or FUD Linux may invent, Linux-style extended > attributes > will NOT be part of the official NFS4.x *standard* > Well, here's a url for one of the messages in the mailing list thread. Several people from Netapp and Oracle participate in the working group and I don't see them complaining about it in the mailing list thread. http://www.ietf.org/mail-archive/web/nfsv4/current/msg12498.html You are welcome to join the working group mailing list and comment, rick > Josh > From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 23:15:53 2013 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 ABD00C0D; Tue, 26 Nov 2013 23:15:53 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2CD7725B5; Tue, 26 Nov 2013 23:15:52 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.7) with ESMTP id rAQN1dBb027714; Wed, 27 Nov 2013 00:01:39 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.7/Submit) with ESMTP id rAQN1dZR027711; Wed, 27 Nov 2013 00:01:39 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 27 Nov 2013 00:01:39 +0100 (CET) From: Wojciech Puchar To: Lionel Cons Subject: Re: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) 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]); Wed, 27 Nov 2013 00:01:39 +0100 (CET) Cc: Rick Macklem , Pedro Giffuni , Cedric Blancher , Freebsd hackers list , Richard Yao , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 23:15:53 -0000 >> there are additional functions for manipulating EAs that go well beyond >> the Solaris extensions to the directory and file I/O functions. Assuming you >> want to be able to get/set as well as enumerate or remove EAs, then >> you might just as well add getxattr(2), listxattr(2), removexattr(2), setxattr(2) >> too and follow the herd (Linux and OS X, so far). > > You mean 'follow the lemmings down into the abyss'? :) seems to. why just not make 2 files when two "data streams" are needed. if compatibility is needed with other OSes (like windows with SMB export) - just add this to samba. From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 26 23:24:34 2013 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 89885D8E; Tue, 26 Nov 2013 23:24:34 +0000 (UTC) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3801A2629; Tue, 26 Nov 2013 23:24:34 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p14so4475403vbm.32 for ; Tue, 26 Nov 2013 15:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mKhUqHv/BvTavks06tPg3lqfGZ7MQK7ACxMB6tpCp7o=; b=arUrpj7mgbo7CxW7LpHrNCpyhH8/YB4RCWXCLyDxSYt6+dRU+GadEBX2Cl4VhOkD4x lObdlBmeAM6zjT+nzF9D8eLODMFp8fcu2bK72lKmevmZ4FSsgSTC0P6geiDpxkmEYrLL snnSJ0N6MKxhGIygOoA2dApy0aRAhyuHN+YK17n3thI1GmKXfQ3VRrxBeBbtUQUUBZfm d9ERQof2MxmFJENZuOGnQtEGBAt+J2lx3+PmQnniXhtyhWpiUZYKYVE9dRk2ijt1N6GJ y2BrGIJTE6GlaAqBtBCX2LGKjIG7+/GCozkEvyyfRRhL5wqy2utieFuSuRxVRCKyg9Tz cKsw== MIME-Version: 1.0 X-Received: by 10.221.40.10 with SMTP id to10mr8464749vcb.22.1385508273307; Tue, 26 Nov 2013 15:24:33 -0800 (PST) Received: by 10.58.96.7 with HTTP; Tue, 26 Nov 2013 15:24:33 -0800 (PST) In-Reply-To: <1300352912.21429386.1385505735146.JavaMail.root@uoguelph.ca> References: <1300352912.21429386.1385505735146.JavaMail.root@uoguelph.ca> Date: Wed, 27 Nov 2013 00:24:33 +0100 Message-ID: Subject: Re: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) From: Joshuah Hurst To: Rick Macklem Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Pedro Giffuni , Cedric Blancher , Freebsd hackers list , Richard Yao , Jordan Hubbard , Lionel Cons X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 23:24:34 -0000 On Tue, Nov 26, 2013 at 11:42 PM, Rick Macklem wrote= : > Cedric Blancher wrote: >> On 26 November 2013 13:27, Lionel Cons >> wrote: >> > On 26 November 2013 11:19, Jordan Hubbard >> > wrote: >> >> >> >> On Nov 26, 2013, at 1:51 AM, Cedric Blancher >> >> wrote: >> >> >> >>> 1. You do not need more syscalls. Solaris uses the plain openat() >> >>> syscall for this, with the O_XATTR flag passed to the normal >> >>> open()/openat() flags to open a named attribute. Likewise read(), >> >>> write(), mmap() etc work, too. >> >> >> >> I don=92t know if I=92d go so far as to say =93you do not need more >> >> syscalls=94; >> >> there are additional functions for manipulating EAs that go well >> >> beyond >> >> the Solaris extensions to the directory and file I/O functions. >> >> Assuming you >> >> want to be able to get/set as well as enumerate or remove EAs, >> >> then >> >> you might just as well add getxattr(2), listxattr(2), >> >> removexattr(2), setxattr(2) >> >> too and follow the herd (Linux and OS X, so far). >> > >> > You mean 'follow the lemmings down into the abyss'? :) >> > >> >> We=92re also glossing over ACLs and where they get to live. I don=92= t >> >> know if Robert >> >> and friends have stuck them in a separate namespace on FreeBSD or >> >> if they=92re >> >> in system-protected EAs, as they are in OS X, but ACL preservation >> >> across >> >> serialization / deserialization is just as important as it is for >> >> EAs. >> > >> > Could we first agree what we are talking about, please? I'm a bit >> > new >> > to this thread, but AFAIK we are talking about the Windows >> > Alternate >> > Data Streams as they appear in networked filesystem like NFSv4 and >> > CIFS and physical filesystems like NTFS, ZFS and Solaris UFS, >> > right? >> > ACLs have no direct relation to those streams. >> > >> > The attributes support from Linux has been proven (at least from >> > CERNs >> > viewpoint) as pretty useless because of their size constrains and >> > crappy API (i.e. no mmap(), no sparse support, no normal tools can >> > access them, ...) so IMHO the herd to follow is the herd which >> > implements at least the following requirements: >> > 1) A proper implementation, which includes access using the normal >> > system utilities (in Solaris there is the runat(1) utility to >> > access >> > the hidden directory containing the attribute files, and bash4.3 >> > and >> > ksh have cd -@ to cwd into the hidden directories containing the >> > attribute files. From that point on (inside the hidden directory) >> > ls(1) and even chown(1) and chmod(1) work as usual. You can even >> > stick >> > ZFS and NFSv4 ACLs on the files in the hidden directory containing >> > the >> > attribute files) >> > 2) read(), write() and mmap() access, i.e. the normal POSIX API (of >> > course with the minor extension to flag an access to an alternate >> > data >> > stream or the directory containing the alternate data streams) >> > 2) Support in networked filesystems (i.e. NFSv4, CIFS) >> > 3) No size restrictions (just to explain, at CERN the alternate >> > data >> > streams are often precompiled caches or index files of the main >> > file's >> > contents, and can easily in the TB range) >> > 4) Support for sparse data (i.e. SEEK_HOLE and SEEK_DATA) >> > 5) More than one implementation available >> > >> > AFAIK Solaris, Nexenta, Illumos (NFSv4, ZFS, UFS) and Windows >> > Alternate Data Streams (CIFS, NTFS) fit these requirements. >> >> +1 >> >> Other argument pro-Alternate Data Streams: Alternate Data Streams are >> a superset of the Linux extended attributes (and can thus be used to >> emulate them in libc), have all their strengths but none of their >> weaknesses (like the hideously duplicated vfs apis and the lack of >> support in POSIX utilities). >> > Not exactly, as I understand it. Linux (and FreeBSD) extended attributes > support atomic replacement of the entire attribute value. At least for > NFSv4 named attributes, this cannot be emulated, since the named attribut= e > is replaced by a "Setattr size=3D0, write offset=3D0" and there is no way > to do those 2 operations as one atomic operation. Sun once proposed a new flag to renameat() to atomically swap two files. That would solve this solution without new syscalls or extra apis. It would even fit into existing NFSv4 requests without major protocol changes. Josh From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 27 04:53:06 2013 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 85274870 for ; Wed, 27 Nov 2013 04:53:06 +0000 (UTC) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C5BE2692 for ; Wed, 27 Nov 2013 04:53:06 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id w10so9102704pde.21 for ; Tue, 26 Nov 2013 20:53:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=efO9Dv/PMGv4GfFc8cHpazbjF2PcZDFUjog4TpmvhA4=; b=RAhGsgCbsMRMl1lRjdhg5Rjxz/BdFTbFxsS3aW8RUkbo5LHP9A9pHVRcrCCz6CV6t0 g4gr6NHr3jaDJiwf3jsMu9GbnaV0Hc991Nd6c6PcmKr68dXYcmZafJ2dWei2eOy8+z5G AB5+CoNql7UnAiGodzDakMAza8Fl+DCCCOFc9Zh/xgoQ16mQxINRJLgtPD0ZdXn5U1db fD4Vk7Sgqf/grdSNAC+CXrXJgFcqb6+sBGxbWMzdHzI9/9FIINBw0H+y1Qdl9xOTaePQ KBkhJXcTkSMTM6jCdUPjPOI9MeTK2su90Umn+gd46+0/hWKG6oYFP7pElq25YqO999nu sd6w== X-Gm-Message-State: ALoCoQkntsnXINp9uIoR/4vZzTu0Cw7VLO+hXPcKdmVKqBnJNZARgrrCgar5IjTxhhWM5F1uTaO4 X-Received: by 10.67.23.71 with SMTP id hy7mr38761817pad.99.1385527980809; Tue, 26 Nov 2013 20:53:00 -0800 (PST) Received: from [192.168.2.123] (99-74-169-43.lightspeed.sntcca.sbcglobal.net. [99.74.169.43]) by mx.google.com with ESMTPSA id oj6sm95985076pab.9.2013.11.26.20.52.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 20:52:59 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: O_XATTR support in FreeBSD? From: Tim Kientzle In-Reply-To: Date: Tue, 26 Nov 2013 20:52:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <706707CA-BD52-4814-BCCE-EB044B062BA6@kientzle.com> References: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> To: Cedric Blancher X-Mailer: Apple Mail (2.1822) Cc: Freebsd hackers list , Richard Yao , Rick Macklem , Pedro Giffuni , Jordan Hubbard X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 04:53:06 -0000 On Nov 26, 2013, at 1:51 AM, Cedric Blancher = wrote: > 5. Support for tar and pax is already there. Its described in > Solaris's fsattr man page, they use a extended header with filename > /dev/null (to prevent older tar versions from tripping over the new > headers) and then have a named attribute header which describes the > attributes names and flags. There are quite a few alternative approaches for storing extended attributes in tar and pax files. I=92ve documented several at: https://github.com/libarchive/libarchive/wiki/TarExtendedAttributes If you have documentation for variations that aren=92t explained there, please let me know. Small sample tar or pax files that can be evaluated are greatly appreciated. Cheers, Tim From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 27 06:07:29 2013 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 3BCB28CE for ; Wed, 27 Nov 2013 06:07:29 +0000 (UTC) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A25822974 for ; Wed, 27 Nov 2013 06:07:28 +0000 (UTC) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-hackers@freebsd.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id rAR67DLM014085; Wed, 27 Nov 2013 13:07:14 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <52958C11.9030107@grosbein.net> Date: Wed, 27 Nov 2013 13:07:13 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Matthias Apitz Subject: Re: how to build a liveDVD References: <20131126202457.GA1065@tiny-r255948> In-Reply-To: <20131126202457.GA1065@tiny-r255948> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eg.sd.rdtc.ru Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 06:07:29 -0000 On 27.11.2013 03:24, Matthias Apitz wrote: > > Hello, > > I've created a lot of times USB keys which acts as a FreeBSD live system, > i.e. one can boot it and even start the KDE4 desktop, all without any > installation to the diskdrive. > > Is there some kindo of tutorial to do the same based on a DVD, i.e for > producing a bootable DVD which brings the system up in some memory file > system? I have created such bootable ISO and written a tutorial but it's in Russian: http://dadv.livejournal.com/89587.html Use Google translate :-) From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 27 07:12:27 2013 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 470F455B for ; Wed, 27 Nov 2013 07:12:27 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D4ADF2C07 for ; Wed, 27 Nov 2013 07:12:26 +0000 (UTC) Received: from scdbackup.webframe.org ([87.167.189.128]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LuxG5-1VcSVd2lsX-0107ZP for ; Wed, 27 Nov 2013 08:12:24 +0100 Date: Wed, 27 Nov 2013 08:11:23 +0100 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org Subject: Re: how to build a liveDVD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <20131126202457.GA1065@tiny-r255948> In-Reply-To: <20131126202457.GA1065@tiny-r255948> Message-Id: <16497640725031909990@scdbackup.webframe.org> X-Provags-ID: V03:K0:tA/Mwuc+gonzFh5vXq2jFAQ1EiS3plrvshrOwMe4Tr7wdzdIh6C L1hDvKtJrVKd8w0qqCaqn1EldXwfxJdCC+Fm+0bSnkwLWCBp1fOE0tBB3hjl88CKpt5cJuH YZVF/QMY+bGJf5qW3iZvo9OyfKtlVdQplwZhA3Q83oPoTJY40nJHfLuobtfiP5dHnAbjpZI /q6KMbE0Lsy+g/tMe+PNA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 07:12:27 -0000 Hi, Matthias Apitz wrote: > I've created a lot of times USB keys which acts as a FreeBSD live system, > [...] Is there some kindo of tutorial to do the same based on a DVD I once exercised my ISO 9660 producing program with this: https://wiki.freebsd.org/AvgLiveCD It booted up to a menu, at least. The difference between booting from USB stick (or hard disk) and CD/DVD/BD is that the BIOS will not start the booting by executing code of the Master Boot Record, but rather lookup the El Torito Boot Catalog to execute the Boot Image file. In the wiki example step 4 the Boot Image is the file boot/cdboot. It obviously was created as /tmp/R/boot/cdboot by the "make" commands in step 2, or else the mkisofs run would not find it and fail. The Boot Catalog gets created by mkisofs. The shown mkisofs options will not only work with mkisofs but also with genisoimage and with my program xorriso (by its emulation: xorriso -as mkisofs ...options...). Have a nice day :) Thomas From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 27 07:42:30 2013 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 C050EF51; Wed, 27 Nov 2013 07:42:30 +0000 (UTC) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 334BA2D40; Wed, 27 Nov 2013 07:42:30 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id o10so5831005eaj.13 for ; Tue, 26 Nov 2013 23:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=d5tP0qQqaNSQr/HrruCwptEtvmB6gUek11zU2XojRNo=; b=COUEoIOgS2w+JnYiamWWqiMmeISNeHWRHXzEBqQ786COh1iho3dLUv/GSjmv0F/Y7+ iz4SvdgbRLHr+JUSXyOCMBVjU/k9qWF6omkNGya5ndnsX+pPY4DxDAQBPmXR80mBvwPV +yhtC9K2mqkyRYQlaOyjyyYGz6WxU7koqi+crYFcMkgJcfMH/OwCdqE/0dQWwCHiXHu7 mfVs61ocs893ZTd8hRJ15qBCJ8B9j3J85tyZ28kfhq79xCrI0LI7t4RlCRYJ1VFmsxGo SY/vgFPJa3GqR4/ikNtlRk+fa90WFvGQQJCOhQP1P/PnA2wc5j5rXENl9iuVJ4l7oCMP TVUA== X-Received: by 10.15.36.197 with SMTP id i45mr16064572eev.31.1385538148639; Tue, 26 Nov 2013 23:42:28 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([178.137.150.35]) by mx.google.com with ESMTPSA id a45sm16712012eem.6.2013.11.26.23.42.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 23:42:27 -0800 (PST) Sender: Alexander Motin Message-ID: <5295A261.2060403@FreeBSD.org> Date: Wed, 27 Nov 2013 09:42:25 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd , Bret Ketchum Subject: Re: 9.1 callout behavior References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 07:42:30 -0000 Hi, Brett, Could you tell more about "ticks has increased 8x"? Tickless mode it is somewhat tricky algorithm to track global ticks counter, but it should not jump that big. Jumps there could easily trigger wrong callout behavior in 9 (in 10 callout code was rewritten and no longer depend on ticks). On 21.11.2013 22:19, Adrian Chadd wrote: > It sounds like you may have found an interesting test case. > > Mav, any ideas? > > On 21 November 2013 05:20, Bret Ketchum wrote: >> I've a callout which runs every 100ms and does a bit of accounting >> using the global ticks variable. This one-shot callout was called fairly >> consistently in 8.1, every 100ms give or take a few thousand clocks. I've >> recently upgraded to 9.1 and for the most part the period is consistent. >> However, periodically the callout function is executed anywhere between 5ms >> to 20ms after the callout was reset and the function returned while global >> ticks has increased 8x. The hardware has not changed (using the same >> timecounter configuration): >> >> CPU: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz (2500.05-MHz K8-class CPU) >> >> kern.timecounter.hardware: TSC-low >> kern.timecounter.tick: 1 >> kern.timecounter.invariant_tsc: 1 >> kern.timecounter.smp_tsc: 1 >> >> And default eventtimer configuration: >> >> kern.eventtimer.singlemul: 2 >> kern.eventtimer.idletick: 0 >> kern.eventtimer.activetick: 1 >> kern.eventtimer.timer: LAPIC >> kern.eventtimer.periodic: 0 >> >> If tickless mode is disabled the inconsistency goes away. Is the >> premature expiration of the callout expected? Is the jump in global ticks >> typical (say from 100 ticks to 800 ticks in 1.5ms)? >> >> Bret >> _______________________________________________ >> 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" -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 27 09:41:25 2013 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 2894ED39; Wed, 27 Nov 2013 09:41:25 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 489BA23F2; Wed, 27 Nov 2013 09:41:23 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA00491; Wed, 27 Nov 2013 11:41:22 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VlbcY-0005IV-2o; Wed, 27 Nov 2013 11:41:22 +0200 Message-ID: <5295BE1E.5090401@FreeBSD.org> Date: Wed, 27 Nov 2013 11:40:46 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: taskqueue_drain_all References: <525519F1.3050703@FreeBSD.org> <5295032B.4010200@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 09:41:25 -0000 on 26/11/2013 23:44 Adrian Chadd said the following: > Hi, > > On 26 November 2013 12:23, Andriy Gapon wrote: >> on 09/10/2013 11:55 Andriy Gapon said the following: >>> >>> I would like to propose to extend taskqueue API with taskqueue_drain_all. >>> A potential use case: I have a private taskqueue, several kinds of tasks get >>> executed via it and then I want to make sure that all of them are completed. >>> Obviously, I have a way to ensure that no new ones get enqueued. >> >> Provided I do not get any no-s or why-s I am going to commit the following >> slightly different version soon: >> >> http://people.freebsd.org/~avg/taskqueue_drain_all.diff >> >> P.S. >> taskqueue_drain_running introduced in the above patch could also be used to add >> wait semantics to taskqueue_block. >> > > So you're going to keep taskqueue_drain() semantics of running the > tasks if they're queued? Yes, of course. Why? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 27 09:48:52 2013 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 C7981F15; Wed, 27 Nov 2013 09:48:52 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BA0552430; Wed, 27 Nov 2013 09:48:50 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA00553; Wed, 27 Nov 2013 11:48:48 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Vlbjk-0005Il-GD; Wed, 27 Nov 2013 11:48:48 +0200 Message-ID: <5295BFC8.6030404@FreeBSD.org> Date: Wed, 27 Nov 2013 11:47:52 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: taskqueue_block References: <5287BDB9.10201@FreeBSD.org> <528B7681.6090806@FreeBSD.org> <201311211414.06849.jhb@freebsd.org> <5294BDCF.1050702@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , Bernhard Schmidt , "freebsd-hackers@freebsd.org" , Aleksandr Rybalko , Andrew Thompson , Pyun YongHyeon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 09:48:52 -0000 on 26/11/2013 23:42 Adrian Chadd said the following: > Hi, > > the net80211 semantics are: > > * all those tasks have to have finished; taskqueue_drain ensures this. > * no new tasks should've been started whilst we're draining those tasks. This is impossible to ensure by anything inside taskqueue implementation. > waitfor_parent wants to block until all the pending update tasks are > done. Ideally it would then stay blocked until the caller does their > thing and then unblocks the taskqueue. As I explained in my original email, these requirements are contradictory. You can not drain pending tasks having disallowed them to be run. Something like this can not be done by means of taskqueue itself. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 27 10:10:09 2013 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 72CF39B5 for ; Wed, 27 Nov 2013 10:10:09 +0000 (UTC) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 39829259A for ; Wed, 27 Nov 2013 10:10:09 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id tp5so11468740ieb.11 for ; Wed, 27 Nov 2013 02:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Uq9XS18GSAKYtCl29HrlOqzn0+W0btco26j6s5VxCEo=; b=GnGUQjNdNVlQBTbIWijAWxJqRUlucC3vAe0M6n6QJWUl98EXV86iaCNaNISCiztNcG Dl0HaGGHTg5de/BlQfPKilNI91Ke4naDUgcsv5/VtAUqX9Ku+b2WSI6hUVG/rkUKq5d5 dlinVUCu6Vl0vphMd7y8TuokAryNw9dL9cfxY= 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=Uq9XS18GSAKYtCl29HrlOqzn0+W0btco26j6s5VxCEo=; b=dCswrgEni+SzgSdgn3yScTtd3+sPOhPP1LyVi+1jfXxVhNjoRzZSrmvIDwDDbt2fID YHGVeS/AfTFW2mSjnWe4PB9pzs28Mutrhs4kub8KWPFeqs2JhiImbcIf3avbe91LPN5D lZOW3IXgk1+c/TRl5HRklpupBEGpFJVD2Jywqm+buzVjYngbg0Bt33eJmLxG8S+tKlh5 Y/xapjFhHUD2/fO58urEFGmrJxKJsfTpg9pwMBe3awenSMxcAjVN4GCAugokAsIfp6l3 nooizNHxBDOPmp/u6VLS4B6N35tJ7lGjqmFKbeP3TEahY+ro2NoTX9XxN6FG2ya0z5oB S7uw== X-Gm-Message-State: ALoCoQkZpo+YbX1TjectR9a36tLTMWo7OZ24c7JBtftgy+hp/Nij7D6DrUJeOl1LIqMjukjTP2gQ X-Received: by 10.43.106.198 with SMTP id dv6mr4926579icc.51.1385547008481; Wed, 27 Nov 2013 02:10:08 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id k6sm37981010igx.8.2013.11.27.02.10.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 02:10:06 -0800 (PST) References: <20131127091313.GB54435@oldfaithful.bebik.local> Mime-Version: 1.0 (1.0) In-Reply-To: <20131127091313.GB54435@oldfaithful.bebik.local> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-C160DC61-34E9-4571-A188-30CA7101E361; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <1C22D1ED-1F81-46F6-92ED-BB76A7B7F781@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: install tcpdump 4.5.1 and libpcap 1.5.1 to filter in/out trafic Date: Wed, 27 Nov 2013 05:10:01 -0500 To: Rodrigo Osorio Cc: "freebsd-net@freebsd.org" , "freebsd-ports@freebsd.org" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 10:10:09 -0000 --Apple-Mail-C160DC61-34E9-4571-A188-30CA7101E361 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Never thought if catch myself saying this butt . . . Push it in please! > On Nov 27, 2013, at 4:13, Rodrigo Osorio wrote: > > Hi all, > > In order to take advantage of the new '-P' switch in > tcpdump to filter in/out trafic from an interface, I > need to move from tcpdump 4.4.0 to 4.5.1. > > http://www.tcpdump.org/tcpdump_man.html > > I did a set of minimal patches to upgrade tcpdump and > its companion libpcap in ports to the latest versions. > > In our tests (FreeBSD-i386-9.1-RELEASE and i386-10.0-BETA1) > tcpdump 4.5.1 works fine and capture the desired trafic. > > I didn't perform any test to check if the deinstall/package > works, this will come with a future PR. > > regards > -rodrigo > > > http://files.bebik.net/patches/tcpdump-4.5.1/tcpdump-patch > http://files.bebik.net/patches/tcpdump-4.5.1/pcap-patch > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --Apple-Mail-C160DC61-34E9-4571-A188-30CA7101E361 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEyNzEwMTAwNFowIwYJKoZIhvcN AQkEMRYEFHDtT6RLRbpgr9MZfsXMIB1TKrk9MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAM4A0Yoz3zkzh0CnIp81G j+wpXvGu254e0Wdnpbv7VX/4YYmQ4ycbZr/MCr1Wy1B1Fu74WMe2p5+8vgpIar6IEx/0oVITuOfr TOHjKbdZ1+T0QB6Wl1kHCCx6v8kF9GXuj0PvBBiresmdNizEWnkUsgEH3WdZM08Vkz5i79dMWDVz hBkUWLHa5lWkHdAiERAHimKMtX/ls/YZvqFS6no3CcH3fkS+J2y1i8S7b6XwchwCCd3YBPJ8l7G6 rp+oeYQgnoujjIfWzys4t5JqIp+DiRjypFE3c5Y3CH4V85p7CdXiAL9Brvfn9ntNWr/qlTtObhnG YFgrMP2scDQZgK2UHAAAAAAAAA== --Apple-Mail-C160DC61-34E9-4571-A188-30CA7101E361-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 27 09:21:04 2013 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 E571179A; Wed, 27 Nov 2013 09:21:04 +0000 (UTC) Received: from smtp2-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599:215:17ff:fe31:fb8]) by mx1.freebsd.org (Postfix) with ESMTP id AAA1422E0; Wed, 27 Nov 2013 09:21:02 +0000 (UTC) Received: from oldfaithful.bebik.local (unknown [82.227.164.69]) by smtp2-g21.free.fr (Postfix) with ESMTP id 252CC4B016D; Wed, 27 Nov 2013 10:20:55 +0100 (CET) Received: by oldfaithful.bebik.local (Postfix, from userid 1001) id 113EC892B98; Wed, 27 Nov 2013 10:13:14 +0100 (CET) Date: Wed, 27 Nov 2013 10:13:14 +0100 From: Rodrigo Osorio To: freebsd-ports@freebsd.org, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: install tcpdump 4.5.1 and libpcap 1.5.1 to filter in/out trafic Message-ID: <20131127091313.GB54435@oldfaithful.bebik.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Wed, 27 Nov 2013 12:32:13 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 09:21:05 -0000 Hi all, In order to take advantage of the new '-P' switch in tcpdump to filter in/out trafic from an interface, I need to move from tcpdump 4.4.0 to 4.5.1. http://www.tcpdump.org/tcpdump_man.html I did a set of minimal patches to upgrade tcpdump and its companion libpcap in ports to the latest versions. In our tests (FreeBSD-i386-9.1-RELEASE and i386-10.0-BETA1) tcpdump 4.5.1 works fine and capture the desired trafic. I didn't perform any test to check if the deinstall/package works, this will come with a future PR. regards -rodrigo http://files.bebik.net/patches/tcpdump-4.5.1/tcpdump-patch http://files.bebik.net/patches/tcpdump-4.5.1/pcap-patch From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 28 11:07:43 2013 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 7673C560 for ; Thu, 28 Nov 2013 11:07:43 +0000 (UTC) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by mx1.freebsd.org (Postfix) with SMTP id D60BC16B4 for ; Thu, 28 Nov 2013 11:07:42 +0000 (UTC) Received: from [98.139.215.142] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2013 11:07:36 -0000 Received: from [98.139.212.209] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 28 Nov 2013 11:07:36 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 28 Nov 2013 11:07:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 295125.40968.bm@omp1018.mail.bf1.yahoo.com Received: (qmail 44616 invoked by uid 60001); 28 Nov 2013 11:07:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1385636856; bh=Fj/I/xKPbyx/lznOwXasQt6wvVZb2MjDVt9yomssn6I=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=dEwDG52G0z9S9X7tfExWGDp9Fv8uXwnONKCEMK1UPaydmNGM6+0Lg7Vkuqp+AtITSNcdwrL7ovT0wyai+ieG2mhVXJT/WE4woOUD3duwFiZIYifQrv0f2eK/gXboiOsBPW++5CZJOTM0wMyIZtM2Vshhu4UA3xfGC22UOKUdbus= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=AlTrzBpyxJBkltYUdjbXwffKbQ2jtIUVXgLEcHBHf1fAWIS1OFtjPGBVOvgEi3zvabSWA2F9y7Blo5I3gZ3iDcGIDsGmGUQWxWEcKhpi775w8hKFQ3fidBHfviMzdrQAmHnZ7ZkeIGj9r2JOO2b6JlOTEIEEy5h4V9RsOfcMjtc=; X-YMail-OSG: Rgm9Z90VM1ntnC_S6YUUuykC3iVR.PqKYRxORyPGoN8qhtd nhApiDV2guNbUHZR.Hq7.mdv5fzE4dVAb9KXw8KOwyJTAD7.pjYwuh9tg9X3 PL.NApgcXtwrMgZgYCY_tpuDQX9vixo98fWpdM3Xedr2soZQCwWWssEHjZ9V 5D96AUoqz4LzXF6MWdP5RIrAQuLS3_eFSfOLFrOfnXMQRUp1PMIsSCGG1PNL 1rtFqBMWMaBgOpgC5f9EubHi2oNI8_QMR4QAww28Q_Qi2ozzit3CuCT2Q4Os Hfyztl4MWwtSNmrf6zVyRuSYTzUUBhdRYS8zqNpOThP6ik4gFg70klYBd.vo iO0rtZ3KnGV43iXWjG.tSDNrfIPQCJgRCrXq67K2bgJUI8OpP7g7gt7igP6M u31b0_OiHbJ2n9mr_JdFZyY157HWQm.7GmXuQLIecnT6ld3f4ngq6.Y7EGXM cNop8LHdPIBcG9vl18KlMmJ.Vek9HvJI.GObES0LPhvCNS.7VB.ygh.PMSy3 G4RV4ZWx_gBlwEOZplTs- Received: from [89.165.120.140] by web162703.mail.bf1.yahoo.com via HTTP; Thu, 28 Nov 2013 03:07:36 PST X-Rocket-MIMEInfo: 002.001, SGkgbGlzdApJIGhhdmUgYXNrZWQgdGhpcyBxdWVzdGlvbiBpbiBhbm90aGVyIG1haWxpbmcgbGlzdCBhbiBJJ20gd2FpdGluZyBvciB0aGVpciByZXNwb25zZS4gSSBqdXN0IHRob3VnaHQgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gYXNrIHRoaXMgcXVlc3Rpb24gaGVyZSB0b28uCkhvdyBjYW4gSSBkbyBzbz8gQnkgaGFyZHdhcmUgaW5mb3JtYXRpb25zIEkgbWVhbiB3aGljaCBjYXJkIGlzIGxvY2F0ZWQgb24gd2hpY2ggc2xvdCwgY2FyZCBzZXJpYWwgbnVtYmVyLCBtYW51ZmFjdHVyZXIgYW5kIC4uLiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.167.602 Message-ID: <1385636856.33202.YahooMailNeo@web162703.mail.bf1.yahoo.com> Date: Thu, 28 Nov 2013 03:07:36 -0800 (PST) From: Nomad Esst Subject: Access to hardware informations from an user-space program To: "freebsd-hackers@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.16 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Nomad Esst List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 11:07:43 -0000 Hi list I have asked this question in another mailing list an I'm waiting or their response. I just thought that it would be better to ask this question here too. How can I do so? By hardware informations I mean which card is located on which slot, card serial number, manufacturer and ... . I know some utils do this e.g. dmesg, pciconf but I want to write something on my own. Any suggestion is appreciated. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 28 15:21:09 2013 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 B4689167 for ; Thu, 28 Nov 2013 15:21:09 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7CDB613E2 for ; Thu, 28 Nov 2013 15:21:09 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id rASFL8gG009152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Nov 2013 09:21:08 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.7]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.03.0158.001; Thu, 28 Nov 2013 09:21:07 -0600 From: "Teske, Devin" To: Nomad Esst Subject: Re: Access to hardware informations from an user-space program Thread-Topic: Access to hardware informations from an user-space program Thread-Index: AQHO7E11U8uBSVEz0Em5bJuhv/tXfQ== Date: Thu, 28 Nov 2013 15:21:07 +0000 Message-ID: References: <1385636856.33202.YahooMailNeo@web162703.mail.bf1.yahoo.com> In-Reply-To: <1385636856.33202.YahooMailNeo@web162703.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <805C23798A179448B8DEC044EF802733@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.72, 1.0.14, 0.0.0000 definitions=2013-11-28_06:2013-11-28,2013-11-28,1970-01-01 signatures=0 Cc: "freebsd-hackers@freebsd.org" , "Teske, Devin" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 15:21:09 -0000 On Nov 28, 2013, at 3:07 AM, Nomad Esst wrote: > Hi list > I have asked this question in another mailing list an I'm waiting or thei= r response. I just thought that it would be better to ask this question her= e too. > How can I do so? By hardware informations I mean which card is located on= which slot, card serial number, manufacturer and ... . I know some utils d= o this e.g. dmesg, pciconf but I want to write something on my own. > Any suggestion is appreciated. dmidecode _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 28 17:50:41 2013 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 B3ABD2BE for ; Thu, 28 Nov 2013 17:50:41 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 32C621B7D for ; Thu, 28 Nov 2013 17:50:40 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.7) with ESMTP id rASHoNZo002439; Thu, 28 Nov 2013 18:50:23 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.7/Submit) with ESMTP id rASHoMX8002436; Thu, 28 Nov 2013 18:50:22 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 28 Nov 2013 18:50:22 +0100 (CET) From: Wojciech Puchar To: Nomad Esst Subject: Re: Access to hardware informations from an user-space program In-Reply-To: <1385636856.33202.YahooMailNeo@web162703.mail.bf1.yahoo.com> Message-ID: References: <1385636856.33202.YahooMailNeo@web162703.mail.bf1.yahoo.com> 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 Nov 2013 18:50:23 +0100 (CET) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 17:50:41 -0000 /var/run/dmesg.boot is world readable. On Thu, 28 Nov 2013, Nomad Esst wrote: > Hi list > I have asked this question in another mailing list an I'm waiting or their response. I just thought that it would be better to ask this question here too. > How can I do so? By hardware informations I mean which card is located on which slot, card serial number, manufacturer and ... . I know some utils do this e.g. dmesg, pciconf but I want to write something on my own. > Any suggestion is appreciated. > _______________________________________________ > 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 Nov 29 08:10:57 2013 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 381D4909 for ; Fri, 29 Nov 2013 08:10:57 +0000 (UTC) Received: from nm10-vm1.bullet.mail.bf1.yahoo.com (nm10-vm1.bullet.mail.bf1.yahoo.com [98.139.213.153]) by mx1.freebsd.org (Postfix) with SMTP id C5D4F15A4 for ; Fri, 29 Nov 2013 08:10:56 +0000 (UTC) Received: from [98.139.215.142] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 29 Nov 2013 08:07:36 -0000 Received: from [98.139.212.211] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 29 Nov 2013 08:07:35 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 29 Nov 2013 08:07:35 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 820402.27841.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 92087 invoked by uid 60001); 29 Nov 2013 08:07:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1385712455; bh=UsTCWP8LdMCXNdbGCz1h7rFjcyRncje1jb60Ikore4c=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CwDU4Wk3SnKTO2k+t9fVt2dk0Z5bYnX4tDZslobrVfatS+XgL/wNhKot0V6DGaoewQ1KtPIxR9Go7vOhVTQgCNr8YekGyml2iVa1gzzxYe8AQ2/Z0oXyHY2X0cPkb56Ix8xrlBbESmKB6oL27cT9mZ2Yvhj7iIp+KS/td8PyrDQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gN2wTELxnutjryArlYNtzlgf6T2MlrGgOQ8++54sui/if81AprAGtujMOH/6wtg9mPOUKM8sCs/UsndnQv1FxKNBl7Oxk9UiP8PcNQD2qPGdzF+mbRAjwa4KcwZBY344IgkQs0TKVgUN7zGyMpNJYfi3hOqwjDc1ScUq3AInGhw=; X-YMail-OSG: ItdIDCkVM1mIZgWfWJ_ng4lzM84KeUfssZ3e6Srr72cPn_I OxAiJIlmkQMvejcZkZFnV2JpF0_W3v85YKyXo5ZbCTr5zH_FTyqCzF9o0eT7 nRb9XmcLMlfL9DTsEqqaefAlGMkHEgwJVjkZDlDxMNtSyZhI0A_YQFR9AAAO BG93ntbLRXHU0M95.KrKot48_kuCDE5ZiSFxNKGpGrfbRQw1YhmPEKjgR_.W rn7k5few_vY_2yD4jVDj28VvveCQk0X_HYaLO27pnukjGyAwmjiMiWKMbL1q P7jOvM_b67fTHf61XZlICLy.U63oQxg.RwIPhuyXhDYxiKeRZV2fsg2QW0x_ Xs3.1JuBVjllIf.BDkOpIHoVQON7DQMSHIwaENQXwx7k2ckZnfxl._pG7xJr Xev6clnrQVh65mRO0vWZi0eslLk_q1v1hf9XOIniiw_eEjKLuUzyoXw3ULoj J9LGPw8y7Wib_tbDrMq6aO3Uq2KSgf3Itn9g5iSN7S7Mbh8mZXyX3QSHsC0i LFg7.tBKJCCChDbsNTuiROgxGuzM. Received: from [151.238.159.5] by web162702.mail.bf1.yahoo.com via HTTP; Fri, 29 Nov 2013 00:07:35 PST X-Rocket-MIMEInfo: 002.001, VGhhbmsgeW91IGFsbCBndXlzLiBJIGtub3cgYWxsIHRoZSBzdHVmZiB5b3UgbWVudGlvbmVkLiBUaGUgdGhpbmcgaXMgSSdtIHRyeWluZyB0byBkZXZlbG9wZSBhIHByb2dyYW0gYW5kIEknbSBsb29raW5nIGZvciBzb21lIGxpYnJhcmllcyBvciBmdW5jdGlvbnMgdG8gYWNjZXNzIGhhcmR3YXJlIGluZm9ybWF0aW9ucwoKCgpPbiBUaHVyc2RheSwgTm92ZW1iZXIgMjgsIDIwMTMgOToyMCBQTSwgV29qY2llY2ggUHVjaGFyIDx3b2p0ZWtAd29qdGVrLnRlbnNvci5nZHluaWEucGw.IHdyb3RlOgogCi92YXIvcnUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.167.602 References: <1385636856.33202.YahooMailNeo@web162703.mail.bf1.yahoo.com> Message-ID: <1385712455.73636.YahooMailNeo@web162702.mail.bf1.yahoo.com> Date: Fri, 29 Nov 2013 00:07:35 -0800 (PST) From: Nomad Esst Subject: Re: Access to hardware informations from an user-space program To: Wojciech Puchar In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.16 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Nomad Esst List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 08:10:57 -0000 Thank you all guys. I know all the stuff you mentioned. The thing is I'm trying to develope a program and I'm looking for some libraries or functions to access hardware informations On Thursday, November 28, 2013 9:20 PM, Wojciech Puchar wrote: /var/run/dmesg.boot is world readable. > >On Thu, 28 Nov 2013, Nomad Esst wrote: > >> Hi list >> I have asked this question in another mailing list an I'm waiting or their response. I just thought that it would be better to ask this question here too. >> How can I do so? By hardware informations I mean which card is located on which slot, card serial number, manufacturer and ... . I know some utils do this e.g. dmesg, pciconf but I want to write something on my own. >> Any suggestion is appreciated. >> _______________________________________________ >> 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" >> >> >_______________________________________________ >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 Nov 29 09:45:50 2013 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 30143E0E for ; Fri, 29 Nov 2013 09:45:50 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id 14FE31A64 for ; Fri, 29 Nov 2013 09:45:49 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type; b=ZY6WP2Db4V3BfO50hi0mQHN9vxMoTqpnizgOM91FCOfvIeNABO244jFKi1KujMtViT03rIlT41FW 5Qd26fmZxCvKLzEyoS8xDC3aRqLAtOQ033uiNx1LCDDwLUEe4dyC Received: from [192.168.2.5] (224-8-237-24.gci.net [24.237.8.224]) by mx.zohomail.com with SMTPS id 1385718344571419.61539046247333; Fri, 29 Nov 2013 01:45:44 -0800 (PST) Message-ID: <52986247.7040503@zoho.com> Date: Fri, 29 Nov 2013 00:45:43 -0900 From: =?UTF-8?B?xYF1a2FzeiBXw7NqY2lr?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Nomad Esst Subject: Re: Access to hardware informations from an user-space program References: <1385636856.33202.YahooMailNeo@web162703.mail.bf1.yahoo.com> <1385712455.73636.YahooMailNeo@web162702.mail.bf1.yahoo.com> In-Reply-To: <1385712455.73636.YahooMailNeo@web162702.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 09:45:50 -0000 On 11/28/2013 23:07, Nomad Esst wrote: > Thank you all guys. I know all the stuff you mentioned. The thing is I'm trying to develope a program and I'm looking for some libraries or functions to access hardware informations > > Best advice you can get is: take a look at the source code of mentioned tools. They're pretty easy to comprehend. That's really the best way you can learn how to access hw information, especially if you want to write your own tool. -LW From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 29 14:27:37 2013 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 05D537A0 for ; Fri, 29 Nov 2013 14:27:37 +0000 (UTC) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id B6E6F1996 for ; Fri, 29 Nov 2013 14:27:36 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 067EC3F44A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kibab.com; s=default; t=1385735249; bh=V8uOeV9EnxN5i2HgfP4gobSsIL4M7yZIkOGTr2a8xHE=; h=Date:From:To:Subject:References:In-Reply-To; b=mdxRDVg/nhob30XleriekoR6dgYdayUlfdbkcgKUdaHQHeX+g+muCOFtpE0fwh4X7 0l49C45Os0Eu6jE+iYToK78PWVksAUnDp7Z9i11dTMmVgiYY95yjc4tG+LkK8a9CmM v0V+Lpd5MH60fwOmeRBJS4o18Yf8VNvMn5m2856Q= Date: Fri, 29 Nov 2013 15:27:29 +0100 From: Ilya Bakulin To: freebsd-hackers@freebsd.org Subject: unbound-control in FreeBSD-CURRENT and stable/10 Message-ID: <20131129142729.GA29580@olymp.kibab.com> References: <20131129142143.GA29437@olymp.kibab.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <20131129142143.GA29437@olymp.kibab.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 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 Nov 2013 14:27:37 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi list, about two months ago DES has imported unbound(1) and a couple of related utilities in FreeBSD-HEAD. This is good, but now unbound-control is being installed in /usr/bin. That means, if the user wants to install Unbound from ports, typing unbound-control will still use FreeBSD-shipped Unbound, not the one from Ports. This will work as long as the unbound-control API is stable and no new commands are added. But at some point this may cause problems. I have tried to contact DES about this several times, but I cannot reach him. Can someone please fix this bug before 10-RELEASE is out? -- Ilya --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlKYpE4ACgkQo9vlj1oadwhIoQCeOzY0FyFMTzqYIyhnrPLyT7IT X9gAoK7nlau2MM3A+WTT42441C2qH/tT =QdKK -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 29 19:27:09 2013 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 1B21EDC3 for ; Fri, 29 Nov 2013 19:27:09 +0000 (UTC) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [IPv6:2607:f2f8:a450::66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00F6D1AC2 for ; Fri, 29 Nov 2013 19:27:09 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2601:7:1680:365:21c:c0ff:fe7f:96ee]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id 4653BE6070; Fri, 29 Nov 2013 11:27:08 -0800 (PST) Received: from [IPv6:2601:7:1680:365:6c84:41a:bb99:ad5e] (unknown [IPv6:2601:7:1680:365:6c84:41a:bb99:ad5e]) by chombo.houseloki.net (Postfix) with ESMTPSA id EC7D38A2; Fri, 29 Nov 2013 11:27:06 -0800 (PST) Message-ID: <5298EA83.30705@bluerosetech.com> Date: Fri, 29 Nov 2013 11:26:59 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ilya Bakulin , freebsd-hackers@freebsd.org Subject: Re: unbound-control in FreeBSD-CURRENT and stable/10 References: <20131129142143.GA29437@olymp.kibab.com> <20131129142729.GA29580@olymp.kibab.com> In-Reply-To: <20131129142729.GA29580@olymp.kibab.com> 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.16 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 Nov 2013 19:27:09 -0000 On 11/29/2013 6:27 AM, Ilya Bakulin wrote: > Hi list, > about two months ago DES has imported unbound(1) and a couple of related > utilities in FreeBSD-HEAD. This is good, but now unbound-control is being > installed in /usr/bin. That means, if the user wants to install Unbound from > ports, typing unbound-control will still use FreeBSD-shipped Unbound, not the > one from Ports. This will work as long as the unbound-control API is stable > and no new commands are added. But at some point this may cause problems. > > I have tried to contact DES about this several times, but I cannot reach him. > Can someone please fix this bug before 10-RELEASE is out? There's really no bug to fix. The base has unbound in it, unbound-control is part of unbound. If you install unbound from ports, you should delete unbound from base. I haven't tried out 10.x yet, but you usually just set a knob like WITHOUT_UNBOUND in /etc/src.conf, then do: # make -C /usr/src delete-old delete-old-libs You can use the check-old target first to list what delete-old and delete-old-libs will remove. If you want to keep a stock, intact base so you can use freebsd-update, you can make your shell run unbound-control from ports by default: Change your PATH to have /usr/local/bin and /usr/local/sbin first. The shell will find /usr/local/bin/unbound-control first and run that. I recommend this in general, since you pretty much always want a name collision to prefer the from-ports program. Alternately, you can alias unbound-control to /usr/local/bin/unbound-control, which will bypass the path search entirely. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 30 08:29:48 2013 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 DE0F6706 for ; Sat, 30 Nov 2013 08:29:48 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 66B8412E7 for ; Sat, 30 Nov 2013 08:29:47 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rAU8TeGT042139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Nov 2013 12:29:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rAU8TdZ2042138; Sat, 30 Nov 2013 12:29:39 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 30 Nov 2013 12:29:39 +0400 From: Gleb Smirnoff To: Ilya Bakulin Subject: Re: unbound-control in FreeBSD-CURRENT and stable/10 Message-ID: <20131130082939.GJ90895@FreeBSD.org> References: <20131129142143.GA29437@olymp.kibab.com> <20131129142729.GA29580@olymp.kibab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131129142729.GA29580@olymp.kibab.com> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 08:29:48 -0000 Ilya, On Fri, Nov 29, 2013 at 03:27:29PM +0100, Ilya Bakulin wrote: I> about two months ago DES has imported unbound(1) and a couple of related I> utilities in FreeBSD-HEAD. This is good, but now unbound-control is being I> installed in /usr/bin. That means, if the user wants to install Unbound from I> ports, typing unbound-control will still use FreeBSD-shipped Unbound, not the I> one from Ports. This will work as long as the unbound-control API is stable I> and no new commands are added. But at some point this may cause problems. Shouldn't /usr/local/bin be earlier in your $PATH than /usr/bin? -- Totus tuus, Glebius.