From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 04:09:30 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E84B8E0; Sun, 26 Oct 2014 04:09:30 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 836BD3A1; Sun, 26 Oct 2014 04:09:28 +0000 (UTC) Received: from freebsd.my.domain (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygCnVzzEc0xUSqicAA--.16125S2; Sun, 26 Oct 2014 12:08:42 +0800 (CST) From: Tiwei Bie To: mjg@freebsd.org Subject: [PATCH] Finish the task 'Temporary buffer in setgroups' Date: Sun, 26 Oct 2014 12:08:19 +0800 Message-Id: <1414296499-55792-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.1.0 X-CM-TRANSID: LkAmygCnVzzEc0xUSqicAA--.16125S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Gw4DXF1xtrWUAF45Zr1UWrg_yoW8JrWfpF 98Wa48tr4UJ3yUt3W7JasYv3yrKF1kZ3Wrua45XrnIqF12gr18ZF1Sqry8WFWDWF43Jas5 Wrn8Aa17Zr1UAr7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUk2b7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVW8XwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxU4GQ6DUUUU X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUJAVQhl8mGEQABsx Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 04:09:30 -0000 Hi, mjg! I have finished the task: Temporary buffer in setgroups [1]. Following is my patch: diff --git a/sys/kern/kern_prot.c b/sys/kern/kern_prot.c index f12468d..73f6ab7 100644 --- a/sys/kern/kern_prot.c +++ b/sys/kern/kern_prot.c @@ -806,17 +806,24 @@ int sys_setgroups(struct thread *td, struct setgroups_args *uap) { gid_t *groups = NULL; + gid_t smallgroups[XU_NGROUPS]; + u_int gidsetsize; int error; - if (uap->gidsetsize > ngroups_max + 1) + gidsetsize = uap->gidsetsize; + if (gidsetsize > ngroups_max + 1) return (EINVAL); - groups = malloc(uap->gidsetsize * sizeof(gid_t), M_TEMP, M_WAITOK); - error = copyin(uap->gidset, groups, uap->gidsetsize * sizeof(gid_t)); + if (gidsetsize > XU_NGROUPS) + groups = malloc(gidsetsize * sizeof(gid_t), M_TEMP, M_WAITOK); + else + groups = smallgroups; + error = copyin(uap->gidset, groups, gidsetsize * sizeof(gid_t)); if (error) goto out; - error = kern_setgroups(td, uap->gidsetsize, groups); + error = kern_setgroups(td, gidsetsize, groups); out: - free(groups, M_TEMP); + if (gidsetsize > XU_NGROUPS) + free(groups, M_TEMP); return (error); } -- 2.1.0 [1] https://wiki.freebsd.org/JuniorJobs#Temporary_buffer_in_setgroups Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 05:42:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 804658B1; Sun, 26 Oct 2014 05:42:19 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6942CDF; Sun, 26 Oct 2014 05:42:18 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id y10so977369wgg.11 for ; Sat, 25 Oct 2014 22:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=PhppBEXOCRBR8wwPDbL3vPANgPy8wwEwNlhHqQv4tu0=; b=Z4tbR/mFCX3OJFecv53HLaB9y3nibVdc7r7WKmNRqC3ToDhO70QnN+OmXK6RasVcJx SHjcckKsJD6eUfH6V43FPrzwHffPNPPA2VyfNaTY0ipL2Zp2igMZpPSirpqZlCkI1C8I mkPnErReQP9yhfhpdngdH4VgLx+KiwTZp4jPWOYLamtOPG4HRHF033JnbqYw8FMT974P Z21dmBesg1VaZLIf/Xrs8V887RdjqmJ73jXOIk8r+g18lLpCZMP/S5px/8akQ0yAzM1f NF07uy1dHdmkGzFkIKyrwelufaK5WPNvOXjOuurPfvehq3zXmNzWGmWoRU0I7rMWAx0h OPCA== X-Received: by 10.181.27.161 with SMTP id jh1mr13306789wid.75.1414302137202; Sat, 25 Oct 2014 22:42:17 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id dq7sm7147817wid.12.2014.10.25.22.42.16 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 25 Oct 2014 22:42:16 -0700 (PDT) Date: Sun, 26 Oct 2014 06:42:14 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: [PATCH] Finish the task 'Temporary buffer in setgroups' Message-ID: <20141026054213.GF19066@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , mjg@freebsd.org, freebsd-hackers@freebsd.org References: <1414296499-55792-1-git-send-email-btw@mail.ustc.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1414296499-55792-1-git-send-email-btw@mail.ustc.edu.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, mjg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 05:42:19 -0000 On Sun, Oct 26, 2014 at 12:08:19PM +0800, Tiwei Bie wrote: > I have finished the task: Temporary buffer in setgroups [1]. > [snip] Thanks, committed: https://svnweb.freebsd.org/base?view=revision&revision=273684 -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 13:24:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68BABA1C; Sun, 26 Oct 2014 13:24:26 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2992E8DB; Sun, 26 Oct 2014 13:24:26 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id vb8so2260329obc.11 for ; Sun, 26 Oct 2014 06:24:25 -0700 (PDT) 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 :content-type; bh=SO9jvO48DbKJtjgPJdKMqoR/q6RECF5nsN8pCYjz4v0=; b=FNDLcKz9wnLgYTUbfu9JnVKyxRY/9J6o+7NsA2TvkbWNOQXhXWB7MLbKYBExb3xP+G kqKjeMQH16Km9dIqCXL+1CQxB2mLI52mP5gAoP0X/Hs9sx7WzTl49AG1BLOZfGk6HQ89 NHb+OgetBDUK0nm8cZvIOTOhTbvJTyU5uZVoq7QLWmCMIYGbCXRD+34Syp1//gkmJllu f1/Dk/XNYQKw9MIPpPCT5KIh63UFX9kShv/FNWZVWaayO1szugwmd2ujDJjQGHOk9lGS x4rVJUOgRN8bXdmzSMqIKunuA1CUSRmBzgWALeI0kzLRGAFRb41L8XJdXMtEb8KODq1b yW+g== MIME-Version: 1.0 X-Received: by 10.182.20.195 with SMTP id p3mr2177198obe.42.1414329864966; Sun, 26 Oct 2014 06:24:24 -0700 (PDT) Received: by 10.182.251.135 with HTTP; Sun, 26 Oct 2014 06:24:24 -0700 (PDT) In-Reply-To: <20141025204536.GD19066@dft-labs.eu> References: <20141025204536.GD19066@dft-labs.eu> Date: Sun, 26 Oct 2014 15:24:24 +0200 Message-ID: Subject: Re: junior kernel tasks From: Anastasios Mag To: Mateusz Guzik , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 13:24:26 -0000 Nice info... On Sat, Oct 25, 2014 at 11:45 PM, Mateusz Guzik wrote: > Hello, > > In short, nice kernel tasks people with C language skills can do in few > evenings. > > https://wiki.freebsd.org/JuniorJobs > > It is assumed you know how to obtain sources and build the kernel. > > What you can get in return: > - your own code in FreeBSD tree > - eternal glory [1] > - fun [2] > > If you are not interested, but know someone who does, please pass it > down. > > [1] - not really, no > [2] - well, I guess that's subjective, so that's not a "no" > > Cheers, > -- > Mateusz Guzik > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Mageirias Anastasios www.junkbytes.com From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 13:29:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FB24B67; Sun, 26 Oct 2014 13:29:14 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id B0D6F8FD; Sun, 26 Oct 2014 13:29:12 +0000 (UTC) Received: from freebsd.my.domain (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygAnL8sg90xUWAieAA--.2346S2; Sun, 26 Oct 2014 21:29:08 +0800 (CST) From: Tiwei Bie To: mjg@freebsd.org Subject: [PATCH] Finish the task 'Replace loginclass mutex with rwlock' Date: Sun, 26 Oct 2014 21:28:46 +0800 Message-Id: <1414330126-20098-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.1.0 X-CM-TRANSID: LkAmygAnL8sg90xUWAieAA--.2346S2 X-Coremail-Antispam: 1UD129KBjvJXoWxuF48Jr4UurW7JF1DCr13twb_yoWrAw1rpF ySkr4UG3y7u3Z7Wr9rCFWqvFyDKw43Ja17A3yUKr18ArWxZr9rWF17ur1UuF15Xr429rs8 XF45Gr1UAr4DZrDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUk2b7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Gr0_Cr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVW5GwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUxNtxUUUUU X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUJAVQhl8mGEQAGs2 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 13:29:14 -0000 Hi, Mateusz! I have finished the task: Replace loginclass mutex with rwlock [1]. Following is my patch: diff --git a/sys/kern/kern_loginclass.c b/sys/kern/kern_loginclass.c index b20f60b..1c2f81d 100644 --- a/sys/kern/kern_loginclass.c +++ b/sys/kern/kern_loginclass.c @@ -51,13 +51,13 @@ __FBSDID("$FreeBSD$"); #include #include #include -#include #include #include #include #include #include #include +#include #include #include @@ -68,8 +68,8 @@ LIST_HEAD(, loginclass) loginclasses; /* * Lock protecting loginclasses list. */ -static struct mtx loginclasses_lock; -MTX_SYSINIT(loginclasses_init, &loginclasses_lock, "loginclasses lock", MTX_DEF); +static struct rwlock loginclasses_lock; +RW_SYSINIT(loginclasses_init, &loginclasses_lock, "loginclasses lock"); void loginclass_hold(struct loginclass *lc) @@ -87,16 +87,33 @@ loginclass_free(struct loginclass *lc) if (old > 1 && atomic_cmpset_int(&lc->lc_refcount, old, old - 1)) return; - mtx_lock(&loginclasses_lock); + rw_wlock(&loginclasses_lock); if (refcount_release(&lc->lc_refcount)) { racct_destroy(&lc->lc_racct); LIST_REMOVE(lc, lc_next); - mtx_unlock(&loginclasses_lock); + rw_wunlock(&loginclasses_lock); free(lc, M_LOGINCLASS); return; } - mtx_unlock(&loginclasses_lock); + rw_wunlock(&loginclasses_lock); +} + +/* + * Look up a loginclass struct for the parameter name. + * loginclasses_lock must be locked. + */ +static struct loginclass * +loginclass_lookup(const char *name) +{ + struct loginclass *lc; + + rw_assert(&loginclasses_lock, RA_LOCKED); + LIST_FOREACH(lc, &loginclasses, lc_next) + if (strcmp(name, lc->lc_name) == 0) + break; + + return (lc); } /* @@ -109,34 +126,39 @@ loginclass_free(struct loginclass *lc) struct loginclass * loginclass_find(const char *name) { - struct loginclass *lc, *newlc; + struct loginclass *lc, *oldlc; if (name[0] == '\0' || strlen(name) >= MAXLOGNAME) return (NULL); - newlc = malloc(sizeof(*newlc), M_LOGINCLASS, M_ZERO | M_WAITOK); - racct_create(&newlc->lc_racct); - - mtx_lock(&loginclasses_lock); - LIST_FOREACH(lc, &loginclasses, lc_next) { - if (strcmp(name, lc->lc_name) != 0) - continue; - - /* Found loginclass with a matching name? */ - loginclass_hold(lc); - mtx_unlock(&loginclasses_lock); - racct_destroy(&newlc->lc_racct); - free(newlc, M_LOGINCLASS); - return (lc); + rw_rlock(&loginclasses_lock); + lc = loginclass_lookup(name); + if (lc == NULL) { + rw_runlock(&loginclasses_lock); + lc = malloc(sizeof(*lc), M_LOGINCLASS, M_ZERO | M_WAITOK); + racct_create(&lc->lc_racct); + rw_wlock(&loginclasses_lock); + /* + * There's a chance someone created our loginclass while we + * were in malloc and not holding the lock, so we have to + * make sure we don't insert a duplicate loginclass. + */ + if ((oldlc = loginclass_lookup(name)) != NULL) { + /* Someone else beat us to it. */ + racct_destroy(&lc->lc_racct); + free(lc, M_LOGINCLASS); + lc = oldlc; + } else { + /* Add new loginclass. */ + strcpy(lc->lc_name, name); + refcount_init(&lc->lc_refcount, 1); + LIST_INSERT_HEAD(&loginclasses, lc, lc_next); + } } - /* Add new loginclass. */ - strcpy(newlc->lc_name, name); - refcount_init(&newlc->lc_refcount, 1); - LIST_INSERT_HEAD(&loginclasses, newlc, lc_next); - mtx_unlock(&loginclasses_lock); - - return (newlc); + loginclass_hold(lc); + rw_unlock(&loginclasses_lock); + return (lc); } /* @@ -222,8 +244,8 @@ loginclass_racct_foreach(void (*callback)(struct racct *racct, { struct loginclass *lc; - mtx_lock(&loginclasses_lock); + rw_rlock(&loginclasses_lock); LIST_FOREACH(lc, &loginclasses, lc_next) (callback)(lc->lc_racct, arg2, arg3); - mtx_unlock(&loginclasses_lock); + rw_runlock(&loginclasses_lock); } -- 2.1.0 [1] https://wiki.freebsd.org/JuniorJobs#Replace_loginclass_mutex_with_rwlock Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 13:47:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDC22FED; Sun, 26 Oct 2014 13:47:29 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 12BC7A71; Sun, 26 Oct 2014 13:47:27 +0000 (UTC) Received: from freebsd.my.domain (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygC3Zzxo+0xU6BOeAA--.16335S2; Sun, 26 Oct 2014 21:47:25 +0800 (CST) From: Tiwei Bie To: mjg@freebsd.org Subject: Questions with 'MPASS(ngrp <= ngroups_max)' assertion in kern_setgroups() Date: Sun, 26 Oct 2014 21:47:01 +0800 Message-Id: <1414331221-29048-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.1.0 X-CM-TRANSID: LkAmygC3Zzxo+0xU6BOeAA--.16335S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUY07k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26w1j 6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4UJVWxJr1l84ACjcxK6I8E87Iv67AKxV W0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAa Y2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4 A2jsIE14v26r4j6F4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Av z4vE14v_Xr4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4 xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17 MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I 0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AK xVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07 jxKsUUUUUU= X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUJAVQhl8mGEQAIs4 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 13:47:29 -0000 Hello, Mateusz! The check in kern_setgroups's callers is: if (gidsetsize > ngroups_max + 1) return (EINVAL); So, gidsetsize could be (ngroups_max + 1). And under this condition, the assertion MPASS(ngrp <= ngroups_max); in kern_setgroups() will fail. One of them should be fixed. Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 14:26:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EAC9648; Sun, 26 Oct 2014 14:26:10 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B129FD7B; Sun, 26 Oct 2014 14:26:09 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id l18so3901322wgh.28 for ; Sun, 26 Oct 2014 07:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=7OhqeKtSH1FvoZeOsEcvqDZ/RJ6x1DGMAJs4Ec9jeLk=; b=a7JUzTbWHjIVsjqqxHwEl+nnXpOhaM2vVLOM5sldhX/ZOeiAflNKdiNeRg2ljxfctN 6wsX03urQsQrHtzZRSgA00dTs9e+RfaCGZEJBR2NN+XUC+ztRafuCqrrwoqROV6r7jsx +07/WixAWiqN3m1/puwUMV4KMqJhVOtxH+CmBGToBjAsVSsDt8pkJyJ4s/i9HqNWf2v1 4El2eU1s81/nvwYiPrnoZ/rc3ZLfn9fGvaUdyC3f1+CsA/STCWON674WHjSauEO5JGgW ZYBiRKWvNbL7JCgNDwKyEtQ2iMVioxlxw38dGDdvoz1e/BLGZQC6aTUuRTrAgEsw3gso cGPw== X-Received: by 10.180.104.229 with SMTP id gh5mr15257887wib.42.1414333567934; Sun, 26 Oct 2014 07:26:07 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id fu5sm12174095wjb.26.2014.10.26.07.26.06 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 26 Oct 2014 07:26:07 -0700 (PDT) Date: Sun, 26 Oct 2014 15:26:04 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: Questions with 'MPASS(ngrp <= ngroups_max)' assertion in kern_setgroups() Message-ID: <20141026142604.GA30512@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , mjg@freebsd.org, freebsd-hackers@freebsd.org References: <1414331221-29048-1-git-send-email-btw@mail.ustc.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1414331221-29048-1-git-send-email-btw@mail.ustc.edu.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, mjg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 14:26:10 -0000 On Sun, Oct 26, 2014 at 09:47:01PM +0800, Tiwei Bie wrote: > Hello, Mateusz! > > The check in kern_setgroups's callers is: > > if (gidsetsize > ngroups_max + 1) > return (EINVAL); > > So, gidsetsize could be (ngroups_max + 1). And under this condition, the assertion > > MPASS(ngrp <= ngroups_max); > > in kern_setgroups() will fail. One of them should be fixed. > > Indeed, thanks. Fixed in r273691. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 17:50:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96B45131; Sun, 26 Oct 2014 17:50:17 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6B71140; Sun, 26 Oct 2014 17:50:16 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id gm9so3298160lab.32 for ; Sun, 26 Oct 2014 10:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=EMG8dy3/bWuxqoYN4J/E6BKquCh3EJDFqrlY3P5XLAk=; b=o+/jWN+AWDw7pqAYmbcIjFlhTofX34jO0nl7IZ7ZEA4BhnqB0poSrCts1tOqdK8BZz MZZDqgzI772JeYoLD+QTKW3X16FgQqn3jaCQEw65pFlpHjhS+S9bN6eMEoDtwGcdR77U zleT6YThlZ8Tcrd8yXNSgqRvdvQr0VJsNY11J9Q5ugtAYjLOMcwepbKuTOGxgNMK69Hn CwZqug5vqhwQQpwbjMg8Y4bpiQCXnKPgsyTu7xZq2ph8RvlAA14Thhk3R3LPclyg/NYC 5PxU+jIs6i8PBA/SnxBI4HPkXJSlinDdpdBmUrl6REG8QLh3JAxsG0AurM34JJWfGzB8 JPIQ== MIME-Version: 1.0 X-Received: by 10.152.5.169 with SMTP id t9mr3679645lat.90.1414345814870; Sun, 26 Oct 2014 10:50:14 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.84.197 with HTTP; Sun, 26 Oct 2014 10:50:14 -0700 (PDT) In-Reply-To: <20141025204536.GD19066@dft-labs.eu> References: <20141025204536.GD19066@dft-labs.eu> Date: Sun, 26 Oct 2014 10:50:14 -0700 X-Google-Sender-Auth: lSBKNHZ2epheJUJxEH0fI_AstB4 Message-ID: Subject: Re: junior kernel tasks From: Craig Rodrigues To: Mateusz Guzik , "freebsd-hackers@freebsd.org" , freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 17:50:17 -0000 On Sat, Oct 25, 2014 at 1:45 PM, Mateusz Guzik wrote: > Hello, > > In short, nice kernel tasks people with C language skills can do in few > evenings. > > https://wiki.freebsd.org/JuniorJobs > > Thanks for making that list. I was looking at some other projects, and noticed that on the front page of http://www.dragonflybsd.org/ , they have a "Now Hiring" section with multiple links to Code Bounties, Summer of Code, etc., to help attract new people to the project. We need something like that on the front page of freebsd.org, to help attract new blood to the project. We have all the info, but it is just scattered across many different web pages, and is often outdated and not maintained. -- Craig From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 17:59:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7DDC763 for ; Sun, 26 Oct 2014 17:59:43 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D2F8243 for ; Sun, 26 Oct 2014 17:59:43 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi2so1081782wib.1 for ; Sun, 26 Oct 2014 10:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=L6LlQcdDany49pEsuAxJo2mu3CBbCdQiokjBECKNCTY=; b=VTRTl29RVNpxYZky76/tAebtz4alDfeggt2Eomr5quCWt345ohIQAsxFasWbvNaSSO vs2ZnpbVWQNAVAPqI0aGHbBv8UHTr9PK4kzZogYaZ/JLj6gLlTtRBgPciJJa4y0MeUso 7rr5KVqA6Z8uT6rFMUJGEq1s1HbdeEiIYg4rt1g2W3NN6bLTz6dVr0iQ+ASutVgM9V6S n1dy03v45jnCRm+n9jfZfUvnjSYBWbd0XheVPkgBPvr5XuPsd+q7anJBABkR/kRke7gw 81cNgyyMoX6vS9wPdepMXzdwBMZfiW+8b/ZpgSVrfb9w7d3OTSA+C3h+EikFVYm77nMI z2fw== X-Received: by 10.180.104.198 with SMTP id gg6mr16457493wib.76.1414346381593; Sun, 26 Oct 2014 10:59:41 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id y5sm9092596wix.10.2014.10.26.10.59.40 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 26 Oct 2014 10:59:40 -0700 (PDT) Date: Sun, 26 Oct 2014 18:59:38 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: [PATCH] Finish the task 'Replace loginclass mutex with rwlock' Message-ID: <20141026175938.GB30512@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org References: <1414330126-20098-1-git-send-email-btw@mail.ustc.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1414330126-20098-1-git-send-email-btw@mail.ustc.edu.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 17:59:43 -0000 On Sun, Oct 26, 2014 at 09:28:46PM +0800, Tiwei Bie wrote: In general I see the change mirrors uifind & friends and seems correct. However, I think we can alter the code so that it looks nicer. Equivalent treatment can be done to uifind et al in a separate patch. > diff --git a/sys/kern/kern_loginclass.c b/sys/kern/kern_loginclass.c > index b20f60b..1c2f81d 100644 > --- a/sys/kern/kern_loginclass.c > +++ b/sys/kern/kern_loginclass.c > @@ -51,13 +51,13 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > -#include > #include > #include > #include > #include > #include > #include > +#include > #include > #include > > @@ -68,8 +68,8 @@ LIST_HEAD(, loginclass) loginclasses; > /* > * Lock protecting loginclasses list. > */ > -static struct mtx loginclasses_lock; > -MTX_SYSINIT(loginclasses_init, &loginclasses_lock, "loginclasses lock", MTX_DEF); > +static struct rwlock loginclasses_lock; > +RW_SYSINIT(loginclasses_init, &loginclasses_lock, "loginclasses lock"); > > void > loginclass_hold(struct loginclass *lc) > @@ -87,16 +87,33 @@ loginclass_free(struct loginclass *lc) > if (old > 1 && atomic_cmpset_int(&lc->lc_refcount, old, old - 1)) > return; > > - mtx_lock(&loginclasses_lock); > + rw_wlock(&loginclasses_lock); > if (refcount_release(&lc->lc_refcount)) { > racct_destroy(&lc->lc_racct); > LIST_REMOVE(lc, lc_next); > - mtx_unlock(&loginclasses_lock); > + rw_wunlock(&loginclasses_lock); > free(lc, M_LOGINCLASS); > > return; > } > - mtx_unlock(&loginclasses_lock); > + rw_wunlock(&loginclasses_lock); > +} > + > +/* > + * Look up a loginclass struct for the parameter name. > + * loginclasses_lock must be locked. > + */ > +static struct loginclass * > +loginclass_lookup(const char *name) > +{ > + struct loginclass *lc; > + > + rw_assert(&loginclasses_lock, RA_LOCKED); > + LIST_FOREACH(lc, &loginclasses, lc_next) > + if (strcmp(name, lc->lc_name) == 0) > + break; > + > + return (lc); > } This could hold lc before returning it. > > /* > @@ -109,34 +126,39 @@ loginclass_free(struct loginclass *lc) > struct loginclass * > loginclass_find(const char *name) > { > - struct loginclass *lc, *newlc; > + struct loginclass *lc, *oldlc; > > if (name[0] == '\0' || strlen(name) >= MAXLOGNAME) > return (NULL); > > - newlc = malloc(sizeof(*newlc), M_LOGINCLASS, M_ZERO | M_WAITOK); > - racct_create(&newlc->lc_racct); > - > - mtx_lock(&loginclasses_lock); > - LIST_FOREACH(lc, &loginclasses, lc_next) { > - if (strcmp(name, lc->lc_name) != 0) > - continue; > - > - /* Found loginclass with a matching name? */ > - loginclass_hold(lc); > - mtx_unlock(&loginclasses_lock); > - racct_destroy(&newlc->lc_racct); > - free(newlc, M_LOGINCLASS); > - return (lc); > + rw_rlock(&loginclasses_lock); > + lc = loginclass_lookup(name); > + if (lc == NULL) { Here it would be nicer to lc != NULL and handle short case first. Then we don't have to indent the longer block. > + rw_runlock(&loginclasses_lock); > + lc = malloc(sizeof(*lc), M_LOGINCLASS, M_ZERO | M_WAITOK); > + racct_create(&lc->lc_racct); > + rw_wlock(&loginclasses_lock); > + /* > + * There's a chance someone created our loginclass while we > + * were in malloc and not holding the lock, so we have to > + * make sure we don't insert a duplicate loginclass. > + */ > + if ((oldlc = loginclass_lookup(name)) != NULL) { > + /* Someone else beat us to it. */ > + racct_destroy(&lc->lc_racct); > + free(lc, M_LOGINCLASS); > + lc = oldlc; > + } else { > + /* Add new loginclass. */ > + strcpy(lc->lc_name, name); > + refcount_init(&lc->lc_refcount, 1); This could be done prior to taking the lock. > + LIST_INSERT_HEAD(&loginclasses, lc, lc_next); > + } > } > > - /* Add new loginclass. */ > - strcpy(newlc->lc_name, name); > - refcount_init(&newlc->lc_refcount, 1); > - LIST_INSERT_HEAD(&loginclasses, newlc, lc_next); > - mtx_unlock(&loginclasses_lock); > - > - return (newlc); > + loginclass_hold(lc); > + rw_unlock(&loginclasses_lock); > + return (lc); > } > > /* > @@ -222,8 +244,8 @@ loginclass_racct_foreach(void (*callback)(struct racct *racct, > { > struct loginclass *lc; > > - mtx_lock(&loginclasses_lock); > + rw_rlock(&loginclasses_lock); > LIST_FOREACH(lc, &loginclasses, lc_next) > (callback)(lc->lc_racct, arg2, arg3); > - mtx_unlock(&loginclasses_lock); > + rw_runlock(&loginclasses_lock); > } > -- > 2.1.0 > > [1] https://wiki.freebsd.org/JuniorJobs#Replace_loginclass_mutex_with_rwlock > > Tiwei Bie > -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 20:48:08 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C1B2C83 for ; Sun, 26 Oct 2014 20:48:08 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 344E53B9 for ; Sun, 26 Oct 2014 20:48:08 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id b13so4339854wgh.22 for ; Sun, 26 Oct 2014 13:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=7lqH10tVOgSIUU8wQpiCxpApjX9VWkLy0cllv6vgibY=; b=ee0KGEb7lzVR9QeDg9z9yG/yXOAHOa53vLCABdkTGis5tFcdLuqDBXVUkQXfs8mwvc /7w5wLpGdd7cJCCU5XEWED8FsU52rMG698hRLRevsEV1PZjGSF/qPoqS0DNYvP8pJwA+ w1oPB4DjnQT1cD0jfzAs7w6N4hpUIWls99hlXKk0giBBts67aelz8e1N6ubKsgHGBsGL DUIEdw8XL3+kdw9t4JAKpAeANI4Fmq4pufuU98owDD4OiRpyr2bJPc1Ccx+8cf3n0E5A aOn5Gx2sYBqEDgL9/mkBQRF3Q/QfcII/puntV40PaKsPvK9n2YvPqMMspI1+pHC6x4ax BCyQ== X-Received: by 10.180.219.66 with SMTP id pm2mr11923794wic.5.1414356486436; Sun, 26 Oct 2014 13:48:06 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id cw6sm13241501wjb.18.2014.10.26.13.48.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Oct 2014 13:48:05 -0700 (PDT) Sender: Baptiste Daroussin Date: Sun, 26 Oct 2014 21:48:03 +0100 From: Baptiste Daroussin To: hackers@FreeBSD.org Subject: libminipkg in base? Message-ID: <20141026204803.GB55021@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZfOjI3PrQbgiZnxM" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 20:48:08 -0000 --ZfOjI3PrQbgiZnxM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, I have been hacking on snmp_hostres.c to provide the list of packages again. Because pkg is not in base and will never be I have been directly calling pkg to gather the list it works pretty well: https://people.freebsd.org/~bapt/bsnmp-pkg.diff after thinking again about it (and discussing with zi@) about it. I start thinking that a stable libminipkg that will only do the basic stuff which we know are stable: Parsing pkg.conf (to at least be able to discover where the local db should be in case it is not in /var/db/pkg) and provide basic query (name of packages, version, timestamp, etc). So any application just willing to do some basic query (hear bsnmpd, net-snmp and so) will be able to rely on a stable ABI/API. For that I will need to import sqlite into base (which anyway is already there hidden in 3 places svnlite, kerberos) and make it a private lib Any thought? Better idea? regards, Bapt --ZfOjI3PrQbgiZnxM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRNXgMACgkQ8kTtMUmk6EzOIQCfconSYchXBykxZpmluIxT5qo8 vL8An2dYx+hGhYQXiJBg6/CGwNkftJsW =O0gz -----END PGP SIGNATURE----- --ZfOjI3PrQbgiZnxM-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 26 23:44:48 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8F61F4D; Sun, 26 Oct 2014 23:44:48 +0000 (UTC) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F95F7E5; Sun, 26 Oct 2014 23:44:48 +0000 (UTC) Received: by mail-yh0-f47.google.com with SMTP id i57so823316yha.20 for ; Sun, 26 Oct 2014 16:44:47 -0700 (PDT) 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=zGghEkumMK5EJXvaD3kV6Zv+qdEsUZSfsJ7aYk1lEMo=; b=PXXTlO1Ojs/TcmNj6w9q8j+IVKP8JbkqRAWs/XVF7yhWG+x/VQPt7tAbD7/X4v6lEG Mrzzb1MQMbubM2C5f60iuM56I8sSPHGosFbpJhjxbeHRN9sxg5j6Z8q6bs+WZEXQPcvd DvHqj9tNbz+GQmFm3pE9/ymAkHo1+LgryOtzPf3Y+kLyKJtnumm2W9RsfuPGsyepbjvN fsiEq8bcqGii5OPM6Qyx5ACV7pRWZ+pYbZTLc2co6c9nTRmGcXbOBLa1Ox71jhuiLXBa wALe/hEouYlfLKIKlIW+shrxPMxaUJliksATBlXazQ7dFakDBGPK9grZrivYoDtRS6N3 ma2A== MIME-Version: 1.0 X-Received: by 10.170.137.193 with SMTP id e184mr18483768ykc.94.1414367087517; Sun, 26 Oct 2014 16:44:47 -0700 (PDT) Received: by 10.170.118.21 with HTTP; Sun, 26 Oct 2014 16:44:47 -0700 (PDT) In-Reply-To: <20141026204803.GB55021@ivaldir.etoilebsd.net> References: <20141026204803.GB55021@ivaldir.etoilebsd.net> Date: Sun, 26 Oct 2014 16:44:47 -0700 Message-ID: Subject: Re: libminipkg in base? From: Mehmet Erol Sanliturk To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 23:44:48 -0000 On Sun, Oct 26, 2014 at 1:48 PM, Baptiste Daroussin wrote: > Hi all, > > I have been hacking on snmp_hostres.c to provide the list of packages > again. > > Because pkg is not in base and will never be I have been directly calling > pkg > to gather the list it works pretty well: > https://people.freebsd.org/~bapt/bsnmp-pkg.diff > > after thinking again about it (and discussing with zi@) about it. I start > thinking that a stable libminipkg that will only do the basic stuff which > we > know are stable: > Parsing pkg.conf (to at least be able to discover where the local db > should be > in case it is not in /var/db/pkg) > and provide basic query (name of packages, version, timestamp, etc). > > So any application just willing to do some basic query (hear bsnmpd, > net-snmp > and so) will be able to rely on a stable ABI/API. > > For that I will need to import sqlite into base (which anyway is already > there > hidden in 3 places svnlite, kerberos) and make it a private lib > > Any thought? > Better idea? > > regards, > Bapt > Important problem is "Installation Structure of FreeBSD" : During installs , after bsdinstall , ONLY base is installed and the rest is left to the user . If this part is modified to install a selected number of packages during installation ( by asking to the user or automatically ) to produce an easily usable installed system there is no any need to move such parts into the base . Otherwise , the user is becoming at some points helpless . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 00:49:36 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE780BB5; Mon, 27 Oct 2014 00:49:36 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id B227DCED; Mon, 27 Oct 2014 00:49:35 +0000 (UTC) Received: from freebsd.my.domain (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygBXORZulk1Uf8WfAA--.15438S2; Mon, 27 Oct 2014 08:48:51 +0800 (CST) From: Tiwei Bie To: mjg@freebsd.org Subject: Re: Re: [PATCH] Finish the task 'Replace loginclass mutex with rwlock' Date: Mon, 27 Oct 2014 08:48:28 +0800 Message-Id: <1414370908-34925-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.1.0 References: <20141026175938.GB30512@dft-labs.eu> In-Reply-To: <20141026175938.GB30512@dft-labs.eu> X-CM-TRANSID: LkAmygBXORZulk1Uf8WfAA--.15438S2 X-Coremail-Antispam: 1UD129KBjvJXoWxuF4ftrWfKrWUtrWxJFykAFb_yoWrKr4UpF ySkr4UGrW7uan7Wr9rCrWqvFyDKw43Ja1UA3yUKr18ArWxZr97WF17Cr1UuF15Jr429rs8 XF45Kr1UAr4DZFDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkab7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E FcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr 0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVWDMxAI w28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr 4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxG rwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8Jw CI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY 6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jzzuAUUUUU= X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUJAVQhl8mGEQASsi Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 00:49:37 -0000 > In general I see the change mirrors uifind & friends and seems correct. > > However, I think we can alter the code so that it looks nicer. Yeah! I have made some modifications to this patch. ;-) #1. in loginclass_free(): I removed an unnecessary rw_wunlock(&loginclasses_lock) call; #2. in loginclass_find(): The newly allocated 'lc' could be freed if someone else has created the loginclass. But I couldn't find a simple way to avoid this. Because we could not call racct_create() which could sleep while holding the wlock[1]. And this is the code that could sleep in racct_create(): *racctp = uma_zalloc(racct_zone, M_WAITOK | M_ZERO); Following is my new patch: diff --git a/sys/kern/kern_loginclass.c b/sys/kern/kern_loginclass.c index b20f60b..986c51b 100644 --- a/sys/kern/kern_loginclass.c +++ b/sys/kern/kern_loginclass.c @@ -51,13 +51,13 @@ __FBSDID("$FreeBSD$"); #include #include #include -#include #include #include #include #include #include #include +#include #include #include @@ -68,8 +68,8 @@ LIST_HEAD(, loginclass) loginclasses; /* * Lock protecting loginclasses list. */ -static struct mtx loginclasses_lock; -MTX_SYSINIT(loginclasses_init, &loginclasses_lock, "loginclasses lock", MTX_DEF); +static struct rwlock loginclasses_lock; +RW_SYSINIT(loginclasses_init, &loginclasses_lock, "loginclasses lock"); void loginclass_hold(struct loginclass *lc) @@ -87,16 +87,30 @@ loginclass_free(struct loginclass *lc) if (old > 1 && atomic_cmpset_int(&lc->lc_refcount, old, old - 1)) return; - mtx_lock(&loginclasses_lock); + rw_wlock(&loginclasses_lock); if (refcount_release(&lc->lc_refcount)) { racct_destroy(&lc->lc_racct); LIST_REMOVE(lc, lc_next); - mtx_unlock(&loginclasses_lock); free(lc, M_LOGINCLASS); - - return; } - mtx_unlock(&loginclasses_lock); + rw_wunlock(&loginclasses_lock); +} + +/* + * Look up a loginclass struct for the parameter name. + * loginclasses_lock must be locked. + */ +static struct loginclass * +loginclass_lookup(const char *name) +{ + struct loginclass *lc; + + rw_assert(&loginclasses_lock, RA_LOCKED); + LIST_FOREACH(lc, &loginclasses, lc_next) + if (strcmp(name, lc->lc_name) == 0) + break; + + return (lc); } /* @@ -109,34 +123,39 @@ loginclass_free(struct loginclass *lc) struct loginclass * loginclass_find(const char *name) { - struct loginclass *lc, *newlc; + struct loginclass *lc, *oldlc; if (name[0] == '\0' || strlen(name) >= MAXLOGNAME) return (NULL); - newlc = malloc(sizeof(*newlc), M_LOGINCLASS, M_ZERO | M_WAITOK); - racct_create(&newlc->lc_racct); - - mtx_lock(&loginclasses_lock); - LIST_FOREACH(lc, &loginclasses, lc_next) { - if (strcmp(name, lc->lc_name) != 0) - continue; - - /* Found loginclass with a matching name? */ - loginclass_hold(lc); - mtx_unlock(&loginclasses_lock); - racct_destroy(&newlc->lc_racct); - free(newlc, M_LOGINCLASS); - return (lc); + rw_rlock(&loginclasses_lock); + lc = loginclass_lookup(name); + if (lc == NULL) { + rw_runlock(&loginclasses_lock); + lc = malloc(sizeof(*lc), M_LOGINCLASS, M_ZERO | M_WAITOK); + racct_create(&lc->lc_racct); + rw_wlock(&loginclasses_lock); + /* + * There's a chance someone created our loginclass while we + * were in malloc and not holding the lock, so we have to + * make sure we don't insert a duplicate loginclass. + */ + if ((oldlc = loginclass_lookup(name)) != NULL) { + /* Someone else beat us to it. */ + racct_destroy(&lc->lc_racct); + free(lc, M_LOGINCLASS); + lc = oldlc; + } else { + /* Add new loginclass. */ + strcpy(lc->lc_name, name); + refcount_init(&lc->lc_refcount, 1); + LIST_INSERT_HEAD(&loginclasses, lc, lc_next); + } } - /* Add new loginclass. */ - strcpy(newlc->lc_name, name); - refcount_init(&newlc->lc_refcount, 1); - LIST_INSERT_HEAD(&loginclasses, newlc, lc_next); - mtx_unlock(&loginclasses_lock); - - return (newlc); + loginclass_hold(lc); + rw_unlock(&loginclasses_lock); + return (lc); } /* @@ -222,8 +241,8 @@ loginclass_racct_foreach(void (*callback)(struct racct *racct, { struct loginclass *lc; - mtx_lock(&loginclasses_lock); + rw_rlock(&loginclasses_lock); LIST_FOREACH(lc, &loginclasses, lc_next) (callback)(lc->lc_racct, arg2, arg3); - mtx_unlock(&loginclasses_lock); + rw_runlock(&loginclasses_lock); } -- 2.1.0 [1] https://www.freebsd.org/cgi/man.cgi?query=rwlock&sektion=9 Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 01:49:41 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3390F4D1 for ; Mon, 27 Oct 2014 01:49:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1695A260 for ; Mon, 27 Oct 2014 01:49:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s9R1neO8066841 for ; Mon, 27 Oct 2014 01:49:40 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s9R1ne4s066840 for hackers@FreeBSD.org; Mon, 27 Oct 2014 01:49:40 GMT (envelope-from bdrewery) Received: (qmail 57115 invoked from network); 26 Oct 2014 20:49:38 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 26 Oct 2014 20:49:38 -0500 Message-ID: <544DA4B0.8040102@FreeBSD.org> Date: Sun, 26 Oct 2014 20:49:36 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Baptiste Daroussin , hackers@FreeBSD.org Subject: Re: libminipkg in base? References: <20141026204803.GB55021@ivaldir.etoilebsd.net> In-Reply-To: <20141026204803.GB55021@ivaldir.etoilebsd.net> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WRmDBD53Lh1b2t8KkSFj8WAscvnHH5qpW" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 01:49:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WRmDBD53Lh1b2t8KkSFj8WAscvnHH5qpW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/26/2014 3:48 PM, Baptiste Daroussin wrote: > Parsing pkg.conf (to at least be able to discover where the local db sh= ould be > in case it is not in /var/db/pkg) > and provide basic query (name of packages, version, timestamp, etc). How could these ever be stable? So far every major release of Pkg has changes the repo format or db schema. Perhaps you need to be more specific about how you will implement it. Currently I don't see how this is any different than just importing the full libpkg. --=20 Regards, Bryan Drewery --WRmDBD53Lh1b2t8KkSFj8WAscvnHH5qpW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUTaSwAAoJEDXXcbtuRpfP9XQH+gLGK6dlkp4dHlNyZ68eVq+U FliiRerYManYqnJIyF8trpPC+/wezfiIYQOANkQbzBo76I3WK/xtyNiWzmSFHnwc qkvzNPy/ZVIKZYk+HmtzRuHpOx3INhERZ8Lg+J66KPcCEeuvBnPghgnr8RnmC0rh pvchVv3gAFt/N2wSoGys0e9QDCq/4cd2JF25gkYl8NqXjqwvVuirSu0g6baCpd+y mMbZcv5KpcoaacSR5E4PW4hPaXcE9FPG36qUPiniXENIhY/p79oddCtzG4GoVxWT ir7bKju8ygkNAQ7dCM366uTZpWo8RBjb07WBaW35joeldnvYthRzIaIb6Ts3qo8= =/yL5 -----END PGP SIGNATURE----- --WRmDBD53Lh1b2t8KkSFj8WAscvnHH5qpW-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 06:30:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AF42CCB; Mon, 27 Oct 2014 06:30:53 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4E7182; Mon, 27 Oct 2014 06:30:52 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id y10so4828045wgg.15 for ; Sun, 26 Oct 2014 23:30:51 -0700 (PDT) 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 :content-type; bh=a6kGT3NPK1iEHsoKkgGZLfze++/y5U61OJRgcbvDnwA=; b=qYimyVf+pp+EF8ATlv7he3RTt2K6vWYB8KiZJD5xaBOMS25JOi78m30f0x6Rw9RZ4Q Vu4ROF4NO8+z2pe0kMjC8T/ksO9k9Iiz5rKytUCYSF+5aMlWDf2RGHjrHpmJEy1sqHCj MWGewfbMVtXqEbJe8oX6GcNXJERsDfhATYRtx7xCdhKgs/ZR+/qTjqPKOGJECBBvvnLW dvbCT1vA2uiDL7ZDXoSbBqiZhlzB0QxaUPW4Dkl8USMxvNgJwydPC2LK/EPhxajOAjTZ X3X+TmpY6DUeY91bFc9TnpNQtltIj0gXqW2t5Z4LQeMIYjhhL25qaKHs/HgBVj6dzHV5 oQeA== MIME-Version: 1.0 X-Received: by 10.194.77.199 with SMTP id u7mr823594wjw.92.1414391450910; Sun, 26 Oct 2014 23:30:50 -0700 (PDT) Received: by 10.180.8.8 with HTTP; Sun, 26 Oct 2014 23:30:50 -0700 (PDT) Received: by 10.180.8.8 with HTTP; Sun, 26 Oct 2014 23:30:50 -0700 (PDT) In-Reply-To: <20141025204536.GD19066@dft-labs.eu> References: <20141025204536.GD19066@dft-labs.eu> Date: Mon, 27 Oct 2014 07:30:50 +0100 Message-ID: Subject: Re: junior kernel tasks From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= To: FreeBSD Hackers , Mateusz Guzik , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 06:30:53 -0000 El 25/10/2014 22:46, "Mateusz Guzik" escribi=C3=B3: > > Hello, > > In short, nice kernel tasks people with C language skills can do in few > evenings. It would be nice if this page lists other junior tasks in base, documentation, etc, not just the kernel. Cheers. > > https://wiki.freebsd.org/JuniorJobs > > It is assumed you know how to obtain sources and build the kernel. > > What you can get in return: > - your own code in FreeBSD tree > - eternal glory [1] > - fun [2] > > If you are not interested, but know someone who does, please pass it > down. > > [1] - not really, no > [2] - well, I guess that's subjective, so that's not a "no" > > Cheers, > -- > Mateusz Guzik > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 11:44:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4B87C9D; Mon, 27 Oct 2014 11:44:28 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AE91A12; Mon, 27 Oct 2014 11:44:28 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xieib-000NwJ-V4; Mon, 27 Oct 2014 11:27:58 +0400 Message-ID: <544E2FA4.8080003@FreeBSD.org> Date: Mon, 27 Oct 2014 15:42:28 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: faith(4) / faithd(8) removal Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 11:44:28 -0000 Hello everyone. I'd like to remove faith (IPv6/v4 translator) from base. * It does not seem like a proper way to translate between IPv4/IPv6 traffic. There are several well-documented (and already implemented) technologies: Stateful/stateless NAT64 (rfc 6146, 6145), 464XLAT (6877). Unfortunately, we don't have in-kernel NAT64 implementation, but there are some userland-base one, like net/tayga64. * It does complicate IPv6 processing path * It does not seem to be used: last non-trivial commit was 10 years ago (126781). * OpenBSD removed it in 2013: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/Attic/if_faith.c If there are no objections I'll remove it in a week. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 13:13:10 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AA93E14 for ; Mon, 27 Oct 2014 13:13:10 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3805863A for ; Mon, 27 Oct 2014 13:13:10 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id o8so1852114qcw.10 for ; Mon, 27 Oct 2014 06:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=y5MZIq6JMHpQimIxmjGY2TfCq7pvkrG8eeX2Guh6fDI=; b=cqLAm/W8iZEm7F0u7kbwewfjjV0L/MQ6AOeEepHrdiL585HUWiuNm6mN9fM11kI1Sk GQGNhLrgV1JBQXIG61p+LMC7JpCetief28S+kzqh8PcuFSyaROcPlI+1syooG9yaewN3 kGT7dfgebKCbVs/p6BNaHygbWj867HKlARcLsCZpEyEXPAAvZ02NhxaZmnzhJBFQqGTF sO9EPpJLSV+akns17S/aOKGrvdViKp8LS2xcV5lFNAQ2LcnVcMP2WIGlcb5uOO59Dg+t I2TE7obefZWDm5HWQPmuWOcahUF7mF8NpscmoDLShynd6UwINjmXvHKhZkadPN2WeoP2 KRnA== X-Received: by 10.140.98.234 with SMTP id o97mr31569215qge.49.1414415589221; Mon, 27 Oct 2014 06:13:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.89.133 with HTTP; Mon, 27 Oct 2014 06:12:48 -0700 (PDT) In-Reply-To: References: <4EA9EE9C-5049-4C50-B361-07F58FA19896@langille.org> From: "B. Estrade" Date: Mon, 27 Oct 2014 08:12:48 -0500 Message-ID: Subject: Re: perl isvaliddate function To: Dan Langille Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 13:13:10 -0000 use POSIX qw/strftime/; sub IsValidDate($) { my $string =3D shift; my ($year, $mon, $mday) =3D split /-/, $string; my $test =3D strftime("%Y-%m-%d", 0, 0, 0, $mday, $mon - 1, $year - 1900)= ; return ($test eq $string) ? $string : undef; } my $a =3D '2014-11-30 unless *coin ports remain unfixed'; if (IsValidDate($a)) { print "'$a' is a valid date\n"; } else { print "'$a' is NOT a valid date\n"; } my $b =3D '2014-02-30'; if (IsValidDate($b)) { print "'$b' is a valid date\n"; } else { print "'$b' is NOT a valid date\n"; } my $c =3D '2014-02-28'; if (IsValidDate($c)) { print "'$c' is a valid date\n"; } else { print "'$c' is NOT a valid date\n"; } On Sat, Oct 25, 2014 at 2:50 PM, Dan Langille wrote: > On Oct 25, 2014, at 2:21 PM, B. Estrade wrote: > > > Looks fine to just get it working. If you wanted to be more efficient, = I > believe there is a way to use the core POSIX::strfmtime in a way that wou= ld > verify that the date you start with is the same date as the one returned > after the format. This core function is also very useful for date additi= on > and subtraction. > > > > I don't have time at this moment to create a proof of concept, but if > you're interested let me know and I will when I have a minute. > > Yes, please, when you have time, please try that proof for me. I would > appreciate that. > > FYI: I believe all dates within the ports tree must be YYYY-MM-DD so usin= g > something like that would be useful. > > Comparing the starting date to the supplied date is good too, to catch > edge cases like the first example. > > =E2=80=94 > Dan Langille > > From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 27 16:14:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A075E215; Mon, 27 Oct 2014 16:14:32 +0000 (UTC) Received: from strudel.ki.iif.hu (strudel.ki.iif.hu [IPv6:2001:738:0:411:20f:1fff:fe6e:ec1e]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA5ECEA; Mon, 27 Oct 2014 16:14:32 +0000 (UTC) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by strudel.ki.iif.hu (Postfix) with ESMTP id C125B461; Mon, 27 Oct 2014 17:14:30 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from strudel.ki.iif.hu ([IPv6:::ffff:193.6.222.244]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id deyEp0f2TuRT; Mon, 27 Oct 2014 17:14:27 +0100 (CET) Received: by strudel.ki.iif.hu (Postfix, from userid 9002) id 0FFA85C7; Mon, 27 Oct 2014 17:14:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by strudel.ki.iif.hu (Postfix) with ESMTP id 0273B461; Mon, 27 Oct 2014 17:14:27 +0100 (CET) Date: Mon, 27 Oct 2014 17:14:26 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@strudel.ki.iif.hu To: "Alexander V. Chernikov" Subject: Re: faith(4) / faithd(8) removal In-Reply-To: <544E2FA4.8080003@FreeBSD.org> Message-ID: References: <544E2FA4.8080003@FreeBSD.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-net@freebsd.org" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:14:32 -0000 Dear Alexander, On Mon, 27 Oct 2014, Alexander V. Chernikov wrote: > Hello everyone. > > I'd like to remove faith (IPv6/v4 translator) from base. > > * It does not seem like a proper way to translate between IPv4/IPv6 traffic. It is a proper way to translate between IPv4 and IPv6 TCP as defined in https://tools.ietf.org/html/rfc3142 However if there no need for TRT among the FreeBSD users it is completely acceptable to remove from the system. Best Regards, Janos Mohacsi > There are several well-documented (and already implemented) technologies: > Stateful/stateless NAT64 (rfc 6146, 6145), 464XLAT (6877). > Unfortunately, we don't have in-kernel NAT64 implementation, but there > are > some userland-base one, like net/tayga64. > * It does complicate IPv6 processing path > * It does not seem to be used: last non-trivial commit was 10 years ago > (126781). > * OpenBSD removed it in 2013: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/Attic/if_faith.c > > If there are no objections I'll remove it in a week. > > > _______________________________________________ > 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 Oct 27 16:16:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0361C5AC for ; Mon, 27 Oct 2014 16:16:06 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA38FD1E for ; Mon, 27 Oct 2014 16:16:05 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id s9RGHKVm020191 for ; Mon, 27 Oct 2014 09:17:20 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: References: <4EA9EE9C-5049-4C50-B361-07F58FA19896@langille.org>, From: "Chris H" Subject: Re: perl isvaliddate function Date: Mon, 27 Oct 2014 09:17:20 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <11ae82fc8cb55d5f932b24be655b6c6e@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:16:06 -0000 On Sat, 25 Oct 2014 13:21:35 -0500 "B. Estrade" wrote > On Sat, Oct 25, 2014 at 11:56 AM, Dan Langille wrote: > > > I’m coding up a sanity check for FreshPorts. It will verify that field > > that should be dates are dates. > > > > Feedback welcome. The system is already using the DATE module, so I’m > > leveraging that. > > > > Pasted at http://dpaste.com/1H0Q8RR.txt but included below, because. > > > > $ cat test-date.pl > > #!/usr/bin/perl > > > > use Date::Parse qw( str2time ); > > > > sub IsValidDate($) { > > my ($string) = @_; > > > > my $Date = str2time($string); > > > > return defined($Date); > > } > > > > my $a = '2014-11-30 unless *coin ports remain unfixed'; > > > > if (IsValidDate($a)) { > > print "'$a' is a valid date\n"; > > } else { > > print "'$a' is NOT a valid date\n"; > > } > > > > my $b = '2014-02-30'; > > > > if (IsValidDate($b)) { > > print "'$b' is a valid date\n"; > > } else { > > print "'$b' is NOT a valid date\n"; > > } > > > > my $c = '2014-02-28'; > > > > if (IsValidDate($c)) { > > print "'$c' is a valid date\n"; > > } else { > > print "'$c' is NOT a valid date\n"; > > } > > > > > > $ perl test-date.pl > > '2014-11-30 unless *coin ports remain unfixed' is NOT a valid date > > '2014-02-30' is NOT a valid date > > '2014-02-28' is a valid date > > $ > > > > — > > Dan Langille > > > > > Looks fine to just get it working. If you wanted to be more efficient, I > believe there is a way to use the core POSIX::strfmtime in a way that would > verify that the date you start with is the same date as the one returned > after the format. This core function is also very useful for date addition > and subtraction. > > I don't have time at this moment to create a proof of concept, but if > you're interested let me know and I will when I have a minute. > > Cheers, > Brett > I also felt inclined to recommend POSIX::strfmtime. I also thought you might save some cycles modifying your conditional from: if (IsValidDate($b)) { print "'$b' is a valid date\n"; } else { print "'$b' is NOT a valid date\n"; } to: unless (IsValidDate($b)) { print "'$b' is NOT a valid date\n"; } you could even introduce my $ok = "Everything looks AOK"; at the beginning, and revise your whole script to close with the $ok, unless any of the 'unless' s fired. Just my 2¢. :) --Chris > _______________________________________________ > 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 Oct 27 21:15:59 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D068CEFB; Mon, 27 Oct 2014 21:15:59 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 410315EE; Mon, 27 Oct 2014 21:15:59 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id b13so6686537wgh.22 for ; Mon, 27 Oct 2014 14:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=qutvhoPLQI81QvXVum+NMfJt4j1vaYYQs6f6f06v4Og=; b=Uw1QskX0MaxOP65jF8oONYdMNFflyqNXS7F3Gf/rnXrJ9HYPbGFfssM4FykFWnT7Xs 039z3hjmbBeNymtZjrOWaaYrNOrrh2Ps8jv3wSebbmWOalUdub/o6d3Xwnl5R/CXVCjz YjNNP9x0AsOo7VZ+SEit1QJlge5asTZ9gKfB2D25HQj95lE7P72na9ZQ8EZ422M/yx4h 4WIC5xoqLIL0Pu+22ZnAl8D+04MBCL1YfjH2l8WR2NyomD8hypy3GiyvfEuC48Jm+ZCJ 7Q0jVvOho56NyT4/SZPQOK57JjIlo+vd4O5AQb4dUFRiyOBXos4R1w8/9dZKEK1uawwh QW1A== X-Received: by 10.194.187.77 with SMTP id fq13mr25811346wjc.14.1414444557529; Mon, 27 Oct 2014 14:15:57 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id ic4sm13143401wid.19.2014.10.27.14.15.56 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 27 Oct 2014 14:15:56 -0700 (PDT) Date: Mon, 27 Oct 2014 22:15:53 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: Re: [PATCH] Finish the task 'Replace loginclass mutex with rwlock' Message-ID: <20141027211553.GB28049@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , mjg@freebsd.org, freebsd-hackers@freebsd.org References: <20141026175938.GB30512@dft-labs.eu> <1414370908-34925-1-git-send-email-btw@mail.ustc.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1414370908-34925-1-git-send-email-btw@mail.ustc.edu.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, mjg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:16:00 -0000 On Mon, Oct 27, 2014 at 08:48:28AM +0800, Tiwei Bie wrote: > > In general I see the change mirrors uifind & friends and seems correct. > > > > However, I think we can alter the code so that it looks nicer. > > Yeah! I have made some modifications to this patch. ;-) > Well, I made some annotations to the patch in my previous mail, I guess you missed them. > #1. in loginclass_free(): > > I removed an unnecessary rw_wunlock(&loginclasses_lock) call; > This means more work done is with the lock held. Whether that's good, bad or acceptable is arguable, I personally don't like it. > #2. in loginclass_find(): > > The newly allocated 'lc' could be freed if someone else has created the > loginclass. But I couldn't find a simple way to avoid this. Because we > could not call racct_create() which could sleep while holding the wlock[1]. > And this is the code that could sleep in racct_create(): > > *racctp = uma_zalloc(racct_zone, M_WAITOK | M_ZERO); That's a totally standard situation. Anyway, previously I suggested some changes and now impleented them in another file here: https://svnweb.freebsd.org/changeset/base/273746 Care to alter your patch in similar manner? > > Following is my new patch: > > diff --git a/sys/kern/kern_loginclass.c b/sys/kern/kern_loginclass.c > index b20f60b..986c51b 100644 > --- a/sys/kern/kern_loginclass.c > +++ b/sys/kern/kern_loginclass.c > @@ -51,13 +51,13 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > -#include > #include > #include > #include > #include > #include > #include > +#include > #include > #include > > @@ -68,8 +68,8 @@ LIST_HEAD(, loginclass) loginclasses; > /* > * Lock protecting loginclasses list. > */ > -static struct mtx loginclasses_lock; > -MTX_SYSINIT(loginclasses_init, &loginclasses_lock, "loginclasses lock", MTX_DEF); > +static struct rwlock loginclasses_lock; > +RW_SYSINIT(loginclasses_init, &loginclasses_lock, "loginclasses lock"); > > void > loginclass_hold(struct loginclass *lc) > @@ -87,16 +87,30 @@ loginclass_free(struct loginclass *lc) > if (old > 1 && atomic_cmpset_int(&lc->lc_refcount, old, old - 1)) > return; > > - mtx_lock(&loginclasses_lock); > + rw_wlock(&loginclasses_lock); > if (refcount_release(&lc->lc_refcount)) { > racct_destroy(&lc->lc_racct); > LIST_REMOVE(lc, lc_next); > - mtx_unlock(&loginclasses_lock); > free(lc, M_LOGINCLASS); > - > - return; > } > - mtx_unlock(&loginclasses_lock); > + rw_wunlock(&loginclasses_lock); > +} > + > +/* > + * Look up a loginclass struct for the parameter name. > + * loginclasses_lock must be locked. > + */ > +static struct loginclass * > +loginclass_lookup(const char *name) > +{ > + struct loginclass *lc; > + > + rw_assert(&loginclasses_lock, RA_LOCKED); > + LIST_FOREACH(lc, &loginclasses, lc_next) > + if (strcmp(name, lc->lc_name) == 0) > + break; > + > + return (lc); > } > > /* > @@ -109,34 +123,39 @@ loginclass_free(struct loginclass *lc) > struct loginclass * > loginclass_find(const char *name) > { > - struct loginclass *lc, *newlc; > + struct loginclass *lc, *oldlc; > > if (name[0] == '\0' || strlen(name) >= MAXLOGNAME) > return (NULL); > > - newlc = malloc(sizeof(*newlc), M_LOGINCLASS, M_ZERO | M_WAITOK); > - racct_create(&newlc->lc_racct); > - > - mtx_lock(&loginclasses_lock); > - LIST_FOREACH(lc, &loginclasses, lc_next) { > - if (strcmp(name, lc->lc_name) != 0) > - continue; > - > - /* Found loginclass with a matching name? */ > - loginclass_hold(lc); > - mtx_unlock(&loginclasses_lock); > - racct_destroy(&newlc->lc_racct); > - free(newlc, M_LOGINCLASS); > - return (lc); > + rw_rlock(&loginclasses_lock); > + lc = loginclass_lookup(name); > + if (lc == NULL) { > + rw_runlock(&loginclasses_lock); > + lc = malloc(sizeof(*lc), M_LOGINCLASS, M_ZERO | M_WAITOK); > + racct_create(&lc->lc_racct); > + rw_wlock(&loginclasses_lock); > + /* > + * There's a chance someone created our loginclass while we > + * were in malloc and not holding the lock, so we have to > + * make sure we don't insert a duplicate loginclass. > + */ > + if ((oldlc = loginclass_lookup(name)) != NULL) { > + /* Someone else beat us to it. */ > + racct_destroy(&lc->lc_racct); > + free(lc, M_LOGINCLASS); > + lc = oldlc; > + } else { > + /* Add new loginclass. */ > + strcpy(lc->lc_name, name); > + refcount_init(&lc->lc_refcount, 1); > + LIST_INSERT_HEAD(&loginclasses, lc, lc_next); > + } > } > > - /* Add new loginclass. */ > - strcpy(newlc->lc_name, name); > - refcount_init(&newlc->lc_refcount, 1); > - LIST_INSERT_HEAD(&loginclasses, newlc, lc_next); > - mtx_unlock(&loginclasses_lock); > - > - return (newlc); > + loginclass_hold(lc); > + rw_unlock(&loginclasses_lock); > + return (lc); > } > > /* > @@ -222,8 +241,8 @@ loginclass_racct_foreach(void (*callback)(struct racct *racct, > { > struct loginclass *lc; > > - mtx_lock(&loginclasses_lock); > + rw_rlock(&loginclasses_lock); > LIST_FOREACH(lc, &loginclasses, lc_next) > (callback)(lc->lc_racct, arg2, arg3); > - mtx_unlock(&loginclasses_lock); > + rw_runlock(&loginclasses_lock); > } > -- > 2.1.0 > > [1] https://www.freebsd.org/cgi/man.cgi?query=rwlock&sektion=9 > > Tiwei Bie > -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 02:50:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C97D8A3A for ; Tue, 28 Oct 2014 02:50:28 +0000 (UTC) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AC67CAE for ; Tue, 28 Oct 2014 02:50:28 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id id10so1020936vcb.0 for ; Mon, 27 Oct 2014 19:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VGXYsdJ2C1LCFctxb3O3jbKTJYEp0h5JIP5CiIWBXTs=; b=r9ihPEZLgWWDwG6KEkNVApsP0d5ANg1EhLW64P7opMYqHBNJtmCCXCc4u6xadc3zbT WpU4+g1kc61VwzP03rQnsbw+mIczFFR5XHduP8VJK69a4oUas/U2dJMiTxX7tF7OBVjh 2Qy+tV5dYkv01zF0IIJ+2LEaA7Wg40x5FOVd73/2KBQ4ypO/2zhHLw06YR2Chp+ddfUr 2iGHKZ49+6KfOEKQLDs70k6E2aMDrB/sIJl20V9TfetmGZQR9MWIJqO6BTghsuvALl7R Vy5iPHrDW4wu3GWGCs0um4AfsiBMG3TL9HN7UpAgdF40J5KWuee/XX9hadPwX8Gtrz2L 0jjQ== MIME-Version: 1.0 X-Received: by 10.220.47.210 with SMTP id o18mr222457vcf.1.1414464627437; Mon, 27 Oct 2014 19:50:27 -0700 (PDT) Received: by 10.220.58.136 with HTTP; Mon, 27 Oct 2014 19:50:27 -0700 (PDT) Date: Mon, 27 Oct 2014 19:50:27 -0700 Message-ID: Subject: USB stack driver options for the receive side question From: Nidal Khalil To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 02:50:28 -0000 Hello All, I am setting up usb to transfer 3 frames on the bulk read desriptor but all I get is one frame transferred? However if I use .short_frames_ok = 1, then the transfer will pend till the three frames are received. This code is part of a network driver I would like to receive the one buffer it i the only one availble and at most three buffers at a time if the transfer is complete. Is this a limitation of FreeBSD. I searched all the drivers in the 9.3 release and I can not find a driver that is setup to recieve multiple buffers? Below is my sample code: BWL_BULK_RD] = { .type = UE_BULK, .endpoint = UE_ADDR_ANY, .direction = UE_DIR_IN, .bufsize = 2000 * HW_IN_PENDING_FRAMES, .flags = { .pipe_bof = 1, .short_xfer_ok = 1, .ext_buffer = 1 }, .callback = dbus_usbos_recv_callback, .timeout = 0, /* no timeout */ .frames = HW_IN_PENDING_FRAMES }, static void dbus_usbos_recv_callback(CALLBACK_ARGS) { usbos_info_t *usbos_info = usbd_xfer_softc(xfer); struct bwl_rx_data *data; int actlen, sumlen, aframes, nframes, datalen, nr_frames; uint8 *buf; struct timespec tp; DBUSTRACE(("%s(): Enter \n", __FUNCTION__)); usbd_xfer_status(xfer, &actlen, &sumlen, &aframes, &nframes); switch (USB_GET_STATE(xfer)) { case USB_ST_TRANSFERRED: for (nr_frames = 0; nr_frames != aframes; nr_frames++) { FETCH_LIST_HEAD_ITEM(rx_q_lock, rx_q); if (!data) { DBUSERR(("got xfer frame but the rx_q till end ?? \n")); ASSERT(0); } usbd_xfer_frame_data(xfer, nr_frames, (void**)&buf, &datalen); kern_clock_gettime(curthread, CLOCK_UPTIME_PRECISE, &tp); mylog(&glog, "T %p: %d-%d:%u\n", buf, datalen, tp.tv_sec, tp.tv_nsec); if ((data->rxirb->buf != buf) || (data->rxirb->buf_len < datalen)) { DBUSERR(("the buff or data length not match ?? \n")); ASSERT(0); } MUTEX_UNLOCK(usbos_info); dbus_usbos_recv_complete(data, datalen, DBUS_OK); MUTEX_LOCK(usbos_info); } __transfered += nr_frames; /* no break, FALLTHROUGH */ case USB_ST_SETUP: SET_UP_XFER: nr_frames = 0; mtx_lock(&usbos_info->rx_q_lock); STAILQ_FOREACH(data, &usbos_info->rx_q, next) { if (data->rxirb == NULL) break; kern_clock_gettime(curthread, CLOCK_UPTIME_PRECISE, &tp); mylog(&glog, "S %p:%d-%d:%u\n", data->rxirb->buf, data->rxirb->buf_len, tp.tv_sec, tp.tv_nsec); usbd_xfer_set_frame_data(xfer, nr_frames, data->rxirb->buf, data->rxirb->buf_len); ++nr_frames; if (nr_frames >= BCMWL_HW_IN_PENDING_FRAMES) break; /* break out from STAILQ_FOREACH */ } mtx_unlock(&usbos_info->rx_q_lock); if (nr_frames) { usbd_xfer_set_frames(xfer, nr_frames); usbd_transfer_submit(xfer); } else { printf("%s(): end of rx_q \n", __FUNCTION__); } __setup += nr_frames; break; default: DBUSERR(("%s(): error = %s with %d bytes transfered\n", __FUNCTION__, usbd_errstr(error), actlen)); if (error == USB_ERR_STALLED || error == USB_ERR_IOERROR) { printf("%s(): calling DBUS_STATE_DOWN for %s\n", __FUNCTION__, usbd_errstr(error)); dbus_usbos_state_change(usbos_info, DBUS_STATE_DOWN); } if ((error != USB_ERR_CANCELLED) && (error != USB_ERR_STALLED)) { usbd_xfer_set_stall(xfer); goto SET_UP_XFER; } else { /* return all rxirb in the queue */ MUTEX_UNLOCK(usbos_info); mtx_lock(&usbos_info->rx_q_lock); while ((data = STAILQ_FIRST(&usbos_info->rx_q)) != NULL) { STAILQ_REMOVE_HEAD(&usbos_info->rx_q, next); dbus_usbos_recv_complete(data, 0, DBUS_ERR_RXFAIL); } STAILQ_INIT(&usbos_info->rx_q); mtx_unlock(&usbos_info->rx_q_lock); MUTEX_LOCK(usbos_info); } break; } } From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 04:10:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09CD2BCC for ; Tue, 28 Oct 2014 04:10:49 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 456F88E8 for ; Tue, 28 Oct 2014 04:10:47 +0000 (UTC) Received: from freebsd (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygAX+hY9F09UUnumAA--.16661S2; Tue, 28 Oct 2014 12:10:43 +0800 (CST) Date: Tue, 28 Oct 2014 12:10:17 +0800 From: Tiwei Bie To: Mateusz Guzik Subject: Re: Re: [PATCH] Finish the task 'Replace loginclass mutex with rwlock' Message-ID: <20141028041017.GA2205@freebsd> References: <20141026175938.GB30512@dft-labs.eu> <1414370908-34925-1-git-send-email-btw@mail.ustc.edu.cn> <20141027211553.GB28049@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141027211553.GB28049@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-CM-TRANSID: LkAmygAX+hY9F09UUnumAA--.16661S2 X-Coremail-Antispam: 1UD129KBjvJXoW3GF4fGw47JF47KFyrZw18Xwb_yoWxXw1DpF ySkr4UG3y7uan7Wr9rC3yqqFykKw4xJa1UA3y5KryxArWxZr97Ww17ur1UuFy5Xr429r4D XF45Kr17Ar4kZa7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVW8JVWxJw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc2xSY4AK67AK6r45MxAIw28IcxkI 7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY 6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6x AIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv 6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07b2nQUUUUUU= X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQULAVQhl8pP8wAAsa Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 04:10:49 -0000 On Mon, Oct 27, 2014 at 10:15:53PM +0100, Mateusz Guzik wrote: > On Mon, Oct 27, 2014 at 08:48:28AM +0800, Tiwei Bie wrote: > > > In general I see the change mirrors uifind & friends and seems correct. > > > > > > However, I think we can alter the code so that it looks nicer. > > > > Yeah! I have made some modifications to this patch. ;-) > > > > Well, I made some annotations to the patch in my previous mail, I guess > you missed them. > Sorry, I misunderstood your annotations. ;-( > > #1. in loginclass_free(): > > > > I removed an unnecessary rw_wunlock(&loginclasses_lock) call; > > > > This means more work done is with the lock held. Whether that's good, > bad or acceptable is arguable, I personally don't like it. > I don't like it either. In this case, I thought the free() operation could be finished quickly, so the overhead could be trivial and removing this call could make the codes shorter. > > #2. in loginclass_find(): > > > > The newly allocated 'lc' could be freed if someone else has created the > > loginclass. But I couldn't find a simple way to avoid this. Because we > > could not call racct_create() which could sleep while holding the wlock[1]. > > And this is the code that could sleep in racct_create(): > > > > *racctp = uma_zalloc(racct_zone, M_WAITOK | M_ZERO); > > That's a totally standard situation. > > Anyway, previously I suggested some changes and now impleented them in > another file here: https://svnweb.freebsd.org/changeset/base/273746 > > Care to alter your patch in similar manner? > Yeah, of course! It's my honor! Thank you very much! This is my new patch: diff --git a/sys/kern/kern_loginclass.c b/sys/kern/kern_loginclass.c index b20f60b..92eb3cf 100644 --- a/sys/kern/kern_loginclass.c +++ b/sys/kern/kern_loginclass.c @@ -51,13 +51,13 @@ __FBSDID("$FreeBSD$"); #include #include #include -#include #include #include #include #include #include #include +#include #include #include @@ -68,8 +68,8 @@ LIST_HEAD(, loginclass) loginclasses; /* * Lock protecting loginclasses list. */ -static struct mtx loginclasses_lock; -MTX_SYSINIT(loginclasses_init, &loginclasses_lock, "loginclasses lock", MTX_DEF); +static struct rwlock loginclasses_lock; +RW_SYSINIT(loginclasses_init, &loginclasses_lock, "loginclasses lock"); void loginclass_hold(struct loginclass *lc) @@ -87,16 +87,37 @@ loginclass_free(struct loginclass *lc) if (old > 1 && atomic_cmpset_int(&lc->lc_refcount, old, old - 1)) return; - mtx_lock(&loginclasses_lock); - if (refcount_release(&lc->lc_refcount)) { - racct_destroy(&lc->lc_racct); - LIST_REMOVE(lc, lc_next); - mtx_unlock(&loginclasses_lock); - free(lc, M_LOGINCLASS); - + rw_wlock(&loginclasses_lock); + if (!refcount_release(&lc->lc_refcount)) { + rw_wunlock(&loginclasses_lock); return; } - mtx_unlock(&loginclasses_lock); + + racct_destroy(&lc->lc_racct); + LIST_REMOVE(lc, lc_next); + rw_wunlock(&loginclasses_lock); + + free(lc, M_LOGINCLASS); +} + +/* + * Look up a loginclass struct for the parameter name. + * loginclasses_lock must be locked. + * Increase refcount on loginclass struct returned. + */ +static struct loginclass * +loginclass_lookup(const char *name) +{ + struct loginclass *lc; + + rw_assert(&loginclasses_lock, RA_LOCKED); + LIST_FOREACH(lc, &loginclasses, lc_next) + if (strcmp(name, lc->lc_name) == 0) { + loginclass_hold(lc); + break; + } + + return (lc); } /* @@ -109,34 +130,39 @@ loginclass_free(struct loginclass *lc) struct loginclass * loginclass_find(const char *name) { - struct loginclass *lc, *newlc; + struct loginclass *lc, *new_lc; if (name[0] == '\0' || strlen(name) >= MAXLOGNAME) return (NULL); - newlc = malloc(sizeof(*newlc), M_LOGINCLASS, M_ZERO | M_WAITOK); - racct_create(&newlc->lc_racct); - - mtx_lock(&loginclasses_lock); - LIST_FOREACH(lc, &loginclasses, lc_next) { - if (strcmp(name, lc->lc_name) != 0) - continue; - - /* Found loginclass with a matching name? */ - loginclass_hold(lc); - mtx_unlock(&loginclasses_lock); - racct_destroy(&newlc->lc_racct); - free(newlc, M_LOGINCLASS); + rw_rlock(&loginclasses_lock); + lc = loginclass_lookup(name); + rw_runlock(&loginclasses_lock); + if (lc != NULL) return (lc); - } - /* Add new loginclass. */ - strcpy(newlc->lc_name, name); - refcount_init(&newlc->lc_refcount, 1); - LIST_INSERT_HEAD(&loginclasses, newlc, lc_next); - mtx_unlock(&loginclasses_lock); + new_lc = malloc(sizeof(*new_lc), M_LOGINCLASS, M_ZERO | M_WAITOK); + racct_create(&new_lc->lc_racct); + refcount_init(&new_lc->lc_refcount, 1); + strcpy(new_lc->lc_name, name); + + rw_wlock(&loginclasses_lock); + /* + * There's a chance someone created our loginclass while we + * were in malloc and not holding the lock, so we have to + * make sure we don't insert a duplicate loginclass. + */ + if ((lc = loginclass_lookup(name)) == NULL) { + LIST_INSERT_HEAD(&loginclasses, new_lc, lc_next); + rw_wunlock(&loginclasses_lock); + lc = new_lc; + } else { + rw_wunlock(&loginclasses_lock); + racct_destroy(&new_lc->lc_racct); + free(new_lc, M_LOGINCLASS); + } - return (newlc); + return (lc); } /* @@ -222,8 +248,8 @@ loginclass_racct_foreach(void (*callback)(struct racct *racct, { struct loginclass *lc; - mtx_lock(&loginclasses_lock); + rw_rlock(&loginclasses_lock); LIST_FOREACH(lc, &loginclasses, lc_next) (callback)(lc->lc_racct, arg2, arg3); - mtx_unlock(&loginclasses_lock); + rw_runlock(&loginclasses_lock); } -- 2.1.0 PS. I found a bug in my previous patches. I initialized lc->lc_refcount to 1 and called loginclass_hold(lc) again. Sorry. LoL.. PPS. In loginclass_free(), I checked the return value of refcount_release() with the following code: if (!refcount_release(&lc->lc_refcount)) { rw_wunlock(&loginclasses_lock); return; } Instead of if (refcount_release(&lc->lc_refcount) == 0) { rw_wunlock(&loginclasses_lock); return; } Because the retval is a bool value. And I think if (!refcount_release(&lc->lc_refcount)) could be read as 'if not release lc'. Tiwei Bie From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 04:35:05 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 569F3173 for ; Tue, 28 Oct 2014 04:35:05 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE3FBAF0 for ; Tue, 28 Oct 2014 04:35:04 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so2812734wgg.29 for ; Mon, 27 Oct 2014 21:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=qwfCe2SdIXaF8xi14LebfqsMrGx4qCZ13W5mRXS02oA=; b=Ales1asoEgcXqeXaBDuT6nzUVBZc/oJRIbvmNIla36uF5laR2FVMaKYWekNxyOmATr mkoUTpPTpwkrhMjlP/vjbVFx79BNyB3uIix8imSz4tnOz/IwwrlsTBJ+3xyTu/p5xJHF wZLzW+4TaDoxaY/L92jfOagZhh8xJ+Btbkc7lYb+fO5c6PuyMhF4+x38Ba7lR68lIemR oziscDsbF6eW8rnjBRHIHnJ5tFPi2JzXggsLeBrcf8gij9aatRV7/PL0b9uiiNHxdlxO xAaa5ef9cFL/JdTVGLV/veHiiotb8P0hAou6uNGqoH1EYkq5jrovm+yMy1JU93aLp6tD /gSw== X-Received: by 10.194.90.210 with SMTP id by18mr1004207wjb.34.1414470903123; Mon, 27 Oct 2014 21:35:03 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id vm6sm396779wjc.16.2014.10.27.21.35.02 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 27 Oct 2014 21:35:02 -0700 (PDT) Date: Tue, 28 Oct 2014 05:35:00 +0100 From: Mateusz Guzik To: Tiwei Bie Subject: Re: Re: [PATCH] Finish the task 'Replace loginclass mutex with rwlock' Message-ID: <20141028043500.GB19223@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Tiwei Bie , freebsd-hackers@freebsd.org References: <20141026175938.GB30512@dft-labs.eu> <1414370908-34925-1-git-send-email-btw@mail.ustc.edu.cn> <20141027211553.GB28049@dft-labs.eu> <20141028041017.GA2205@freebsd> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141028041017.GA2205@freebsd> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 04:35:05 -0000 On Tue, Oct 28, 2014 at 12:10:17PM +0800, Tiwei Bie wrote: > > Anyway, previously I suggested some changes and now impleented them in > > another file here: https://svnweb.freebsd.org/changeset/base/273746 > > > > Care to alter your patch in similar manner? > > > > Yeah, of course! It's my honor! Thank you very much! > Thanks, went in as https://svnweb.freebsd.org/changeset/base/273763 . -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 05:25:45 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59E918CF; Tue, 28 Oct 2014 05:25:45 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A504F79; Tue, 28 Oct 2014 05:25:44 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id y10so7094673wgg.3 for ; Mon, 27 Oct 2014 22:25:42 -0700 (PDT) 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=7NaODbzKAlXkDmwaNPW4fQCyQEJy5qH2KL6CLIjj2CA=; b=P7Rhf0G7wXju4uyFFDUjqfNZ4R+QSXWr6HyfAayS9iQZc01lH3xkMrAOZMmMH4q1gj /MnR+VOvr//6EVfdf0MI4z1qUHCrSLR5fofpMAfXBPcFgFn5m2nLTBjnFqjhOA2mhqr4 643n7xyqgrVUHcYaa2e5tUCrBGnnUNLkbjAJhu4sfZQFBxPzxaHH6PAueokFEVmR2mQw C1/C6SfPBmPTDI2dKdgxUjGOm9LgE4IPRDB9f2UZ0qIyojHODdnV2gf7l8xg1C/1G6pz PvUJ5YChlrAbu701ZYWdQh8B6TqJW1+CnJpAz9lOyeDKV7ckrnhBZWccKg9GMRdqh9Ji tM9Q== MIME-Version: 1.0 X-Received: by 10.180.109.17 with SMTP id ho17mr1875183wib.4.1414473942623; Mon, 27 Oct 2014 22:25:42 -0700 (PDT) Received: by 10.180.87.4 with HTTP; Mon, 27 Oct 2014 22:25:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Oct 2014 09:25:42 +0400 Message-ID: Subject: Fwd: Android Emulator for FreeBSD + FreeBSD/ARM port From: Alexander Tarasikov To: Gavin Atkinson Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , freebsd-emulation@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 05:25:45 -0000 Hi! I'm forwarding the message I sent directly to Gavin some time ago Also, I've pushed a small fix for the kernel compilation error and replaced a couple of __linux__ ifdefs with __FreeBSD__ in the emulator. I also think it is necessary to mount libprocfs even if using a FreeBSD build because the emulator uses /proc to find its binary The result is that I now have the emulator running on FreeBSD which has X11/Framebuffer working. Here is a screenshot in which I connect to a FreeBSD host using "ssh -Y" in Mac OS X and run the emulator https://drive.google.com/file/d/0B7wcN-tOkdeRZTlzdWh3V0d0VGM/view?usp=sharing https://github.com/astarasikov/freebsd https://github.com/astarasikov/qemu/tree/l-preview-freebsd ---------- Forwarded message ---------- From: Alexander Tarasikov Date: Tue, Oct 7, 2014 at 3:16 PM Subject: Re: Android Emulator for FreeBSD + FreeBSD/ARM port To: Gavin Atkinson On Sun, Oct 5, 2014 at 9:58 PM, Gavin Atkinson wrote: > On Sun, 7 Sep 2014, Alexander Tarasikov wrote: >> During summer as part of GSoC program I was working on porting FreeBSD >> to the Android Emulator. >> Besides, I have ported Android Emulator to run natively on x86_64 as opposed to >> using linuxulator for 32-bit support. >> >> As for the kernel side, I have implemented the support for the >> following hardware: >> *IRQ, Timer, UART >> *MMC >> *Ethernet >> *Framebuffer (using NEWCONS) >> >> It allows to mount rootfs and boot up to login prompt with raspberry >> pi sd card image. > > I'm now in a position where I'm starting to look at getting this in shape > ready to push it into the main tree. Hi! That's interesting > >> As for the emulator, it's a bit complicated. FreeBSD boots fine if you >> launch the emulator on Linux or Mac OS X. I have fixed some parts of >> the build system and headers to make it compile and pass the tests on >> FreeBSD. Unfortunately, the GUI doesn't work right now and only >> console output (virtual UART) works. > > Firstly, I'd like to get the emulator into the ports tree. I was > originally planning on using the Linux binary (I've been doing all of my > testing so far with the Linux binary) but if you have patches for FreeBSD > I think that's likely the best way forward, or it may make sense to import > both? It's complicated. Afaiu, linux compatibility mode only supports 32-bit binaries. So we'll need to rebuild the emulator on 32-bit linux (to get a 'git' version which works). If we run the emulator on Linux or OS X, everything works including framebuffer, mmc and network. As for running natively on FreeBSD, it currently supports the UART and GUI fails at some X11 call. I think we will get it working by removing some unnecessary ifdefffery. > > Then, I'd like to get the Goldfish code into the main FreeBSD tree. It > would be nice to get at least bidirectional UART working before we can do > that, are there any issues with the emulator that would prevent this? > I've also not managed to get ethernet or the framebuffer working, though > I've not looked deep into this and especially for the network interface it > may be related to how I'm running the emulator - I guess you have been > passing through a device into the emulator? > > I think once we can get the bidirectional UART fully functional, we can > push this into the tree. Also, goldfish_mmc.c is missing a copyright > statement - can you add one please? Okay, I will look into it. I will be present at irc on weekends. > > Thanks, > > Gavin -- Regards, Alexander -- Regards, Alexander From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 18:26:29 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D80FCE3A; Tue, 28 Oct 2014 18:26:29 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B060321D; Tue, 28 Oct 2014 18:26:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 27419B96E; Tue, 28 Oct 2014 14:26:28 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: junior kernel tasks Date: Tue, 28 Oct 2014 13:21:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141025204536.GD19066@dft-labs.eu> In-Reply-To: <20141025204536.GD19066@dft-labs.eu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201410281321.31986.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Oct 2014 14:26:28 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, Mateusz Guzik , bugmeister@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 18:26:29 -0000 On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: > Hello, > > In short, nice kernel tasks people with C language skills can do in few > evenings. > > https://wiki.freebsd.org/JuniorJobs > > It is assumed you know how to obtain sources and build the kernel. > > What you can get in return: > - your own code in FreeBSD tree > - eternal glory [1] > - fun [2] > > If you are not interested, but know someone who does, please pass it > down. > > [1] - not really, no > [2] - well, I guess that's subjective, so that's not a "no" Even though our bugmeisters have decided that we should not have wishlist items in our bug tracker, I really wish we could store the various idea lists (we have several) in an issue tracker instead. This would allow for folks to comment on ideas, vote for them, etc. It would also make it easier for more people to submit new ideas. It also provides a better place to store metadata about the issue itself (wikis are kind of poor for that). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 20:42:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A339850; Tue, 28 Oct 2014 20:42:11 +0000 (UTC) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E0F03E5; Tue, 28 Oct 2014 20:42:10 +0000 (UTC) Received: from [80.67.16.118] (helo=webmailfront01.ispgateway.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1XjDUE-0003QF-PY; Tue, 28 Oct 2014 21:35:26 +0100 Received: from a89-182-206-145.net-htp.de (a89-182-206-145.net-htp.de [89.182.206.145]) by webmail.df.eu (Horde Framework) with HTTP; Tue, 28 Oct 2014 21:35:26 +0100 Date: Tue, 28 Oct 2014 21:35:26 +0100 Message-ID: <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> From: Marcus von Appen To: John Baldwin Subject: Re: junior kernel tasks References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> In-Reply-To: <201410281321.31986.jhb@freebsd.org> Reply-to: mva@freebsd.org User-Agent: Internet Messaging Program (IMP) H5 (6.0.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Df-Sender: ZnJlZWJzZEBzeXNmYXVsdC5vcmc= Cc: Mateusz Guzik , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, bugmeister@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:42:11 -0000 Quoting John Baldwin : > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: >> Hello, >> >> In short, nice kernel tasks people with C language skills can do in few >> evenings. >> >> https://wiki.freebsd.org/JuniorJobs >> >> It is assumed you know how to obtain sources and build the kernel. >> >> What you can get in return: >> - your own code in FreeBSD tree >> - eternal glory [1] >> - fun [2] >> >> If you are not interested, but know someone who does, please pass it >> down. >> >> [1] - not really, no >> [2] - well, I guess that's subjective, so that's not a "no" > > Even though our bugmeisters have decided that we should not have wishlist > items in our bug tracker, I really wish we could store the various idea lists > (we have several) in an issue tracker instead. This would allow for folks to > comment on ideas, vote for them, etc. It would also make it easier for more > people to submit new ideas. > Speaking not strictly with the bugmeister hat, but from experience, please do not let us go down the road of (ab)using a bug tracking solution as task and idea management system. I think that using the tasks feature of phabricator (our reviews instance) would provide better workflow support for those things, starting out from sketching out rough ideas, discussing them, breaking them up in seperate tasks (linked to and dependent on each other) and collaborating on them (take a look at https://developer.blender.org/T42339 for a brief example). Having said this, let's keep the bug tracker a bug tracker. Cheers Marcus From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 22:14:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7E2794E; Tue, 28 Oct 2014 22:14:19 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8E13EEF; Tue, 28 Oct 2014 22:14:18 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id n12so2002208wgh.2 for ; Tue, 28 Oct 2014 15:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=BkMvX47UN2mFxPgp6F7+H5NnXxrAeU5v2/a0k81slKE=; b=sAiqoGNYOWCX1xw5sWkcJWek4QZFOv4jQG90F8Sf/OMa+8npGWOthByG2wKEL5OWQk QhNG6Nqd96Kz0c0SKjkYziE2EAhHz6D4F6iip53aB/sZcWc5kz+sVX0PNS7au2OnCsJp EjTB/bdmq9ZqDSVlXiFvMvQ6ALBSX6Q1kj27ubIsVeylKvfi7koJH0X1AvdTI8/Wu4+G 0sPUnhLXObxqcqA8teL6YGiMWihS+6VueoMMhS/QkppydRhsAkl2brKxHQZOKsp3VUs0 d/Or5XCvF2PJzCzDpq3r6tfiafvEHYnc/oGcBEKNud4jGk4Pbj6BNYFTsyzmcp1vsNmi I9QQ== X-Received: by 10.194.123.69 with SMTP id ly5mr7357936wjb.9.1414534456976; Tue, 28 Oct 2014 15:14:16 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id td9sm3583023wic.15.2014.10.28.15.14.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Oct 2014 15:14:15 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 28 Oct 2014 23:14:13 +0100 From: Baptiste Daroussin To: Marcus von Appen Subject: Re: junior kernel tasks Message-ID: <20141028221413.GF26796@ivaldir.etoilebsd.net> References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ni93GHxFvA+th69W" Content-Disposition: inline In-Reply-To: <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, Mateusz Guzik , bugmeister@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:14:20 -0000 --ni93GHxFvA+th69W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: >=20 > Quoting John Baldwin : >=20 > > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: > >> Hello, > >> > >> In short, nice kernel tasks people with C language skills can do in few > >> evenings. > >> > >> https://wiki.freebsd.org/JuniorJobs > >> > >> It is assumed you know how to obtain sources and build the kernel. > >> > >> What you can get in return: > >> - your own code in FreeBSD tree > >> - eternal glory [1] > >> - fun [2] > >> > >> If you are not interested, but know someone who does, please pass it > >> down. > >> > >> [1] - not really, no > >> [2] - well, I guess that's subjective, so that's not a "no" > > > > Even though our bugmeisters have decided that we should not have wishli= st > > items in our bug tracker, I really wish we could store the various idea= lists > > (we have several) in an issue tracker instead. This would allow for fo= lks to > > comment on ideas, vote for them, etc. It would also make it easier for= more > > people to submit new ideas. > > >=20 > Speaking not strictly with the bugmeister hat, but from experience, pleas= e do > not let us go down the road of (ab)using a bug tracking solution as task = and > idea management system. I think that using the tasks feature of phabricat= or > (our reviews instance) would provide better workflow support for those th= ings, > starting out from sketching out rough ideas, discussing them, breaking th= em up > in seperate tasks (linked to and dependent on each other) and collaborati= ng > on them (take a look at https://developer.blender.org/T42339 for a =20 > brief example). >=20 > Having said this, let's keep the bug tracker a bug tracker. >=20 > Cheers > Marcus >=20 >=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" I disabled the tasks on phabricator to avoid having it a duplicate of bugzi= lla, but if we have a use for it I can activate it! Actually I do like the idea of the bug tracker aka bugzilla being only for = bugs and uxe phabricator for tracking the tasks regards, Bapt --ni93GHxFvA+th69W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRQFTUACgkQ8kTtMUmk6Eyb1gCcDkSG6z4tvBjF/wwf4VaJSrNL gsgAn1uQ0po05HWKqbaMoG8HtZDYcrNn =DylX -----END PGP SIGNATURE----- --ni93GHxFvA+th69W-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 28 23:08:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7103A79 for ; Tue, 28 Oct 2014 23:08:03 +0000 (UTC) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EAF76B2 for ; Tue, 28 Oct 2014 23:08:03 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id f51so1423316qge.30 for ; Tue, 28 Oct 2014 16:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MRAxFpAKZrgNB6SfjtE8ZGfYeohxt9d8LVMU8XHD3x8=; b=C17gBRI3J2gjvSAAwT+kuEquSdp9Za1XbGsSuq0imUXG3ycWUZZwOxKn5ksDDO/wu8 F9+wYvlRuEulMsoaVmRam7kiuFMxn8aLCZCVV2/OEQo3Ajy8EQwe39Rhv/rwXuZJi4fs Ec4boq4CzxKtQIJX9xmBl6FMutZ9JDguapaIY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MRAxFpAKZrgNB6SfjtE8ZGfYeohxt9d8LVMU8XHD3x8=; b=c/aTcv2RkMRbdjbkmtLckDyUIG/WmqRkDv334TY5c5zdmWwp5xFiN2uzQB0Htow6JG V/kDh//h4fLpCuVZkBi3lA3IRw12MWtXmc1oWh0/YMWlUV24+XZd+97UIHQo2M4xfAnp ga0HOPmPfLt0YBVGeN9Djsuv0BNsRUevsWj2cyXwmuBSPcBRaUdI+jAMamGoJIdi7WeB g7UZgfE6mUyUF/6HN2AVUc+v9D8Tngtt5DAQLdannYV8PcE33/R6CM8S4GIIcWB9spRp 3g1utdSEACZmGbqQH8QtisJkRe9VCQ+BVm4ygCVqOwqzW3nPXduJMMODLFH3oOCS6WXQ GRhg== X-Gm-Message-State: ALoCoQkmj9tB14I19xceXF3+DgkADCBy/pKGVeelkityaDWVKYn0IwWikFo4Fg74nrbmxuD8VpR6 X-Received: by 10.224.130.71 with SMTP id r7mr9942597qas.69.1414537682143; Tue, 28 Oct 2014 16:08:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.92.200 with HTTP; Tue, 28 Oct 2014 16:07:31 -0700 (PDT) In-Reply-To: <20141028221413.GF26796@ivaldir.etoilebsd.net> References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> From: Eitan Adler Date: Tue, 28 Oct 2014 16:07:31 -0700 Message-ID: Subject: Re: junior kernel tasks To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 Cc: Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , freebsd-current Current , Marcus von Appen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 23:08:03 -0000 On 28 October 2014 15:14, Baptiste Daroussin wrote: > On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: >> >> Quoting John Baldwin : >> >> > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: >> >> Hello, >> >> >> >> In short, nice kernel tasks people with C language skills can do in few >> >> evenings. >> >> >> >> https://wiki.freebsd.org/JuniorJobs >> >> >> >> It is assumed you know how to obtain sources and build the kernel. >> >> >> >> What you can get in return: >> >> - your own code in FreeBSD tree >> >> - eternal glory [1] >> >> - fun [2] >> >> >> >> If you are not interested, but know someone who does, please pass it >> >> down. >> >> >> >> [1] - not really, no >> >> [2] - well, I guess that's subjective, so that's not a "no" >> > >> > Even though our bugmeisters have decided that we should not have wishlist >> > items in our bug tracker, I really wish we could store the various idea lists >> > (we have several) in an issue tracker instead. This would allow for folks to >> > comment on ideas, vote for them, etc. It would also make it easier for more >> > people to submit new ideas. >> > >> >> Speaking not strictly with the bugmeister hat, but from experience, please do >> not let us go down the road of (ab)using a bug tracking solution as task and >> idea management system. I think that using the tasks feature of phabricator >> (our reviews instance) would provide better workflow support for those things, >> starting out from sketching out rough ideas, discussing them, breaking them up >> in seperate tasks (linked to and dependent on each other) and collaborating >> on them (take a look at https://developer.blender.org/T42339 for a >> brief example). >> >> Having said this, let's keep the bug tracker a bug tracker. >> >> Cheers >> Marcus >> >> >> _______________________________________________ >> 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" > > I disabled the tasks on phabricator to avoid having it a duplicate of bugzilla, > but if we have a use for it I can activate it! > > Actually I do like the idea of the bug tracker aka bugzilla being only for bugs > and uxe phabricator for tracking the tasks having disparate trackers for "wishlist" and "bugs" is quite harmful and splits the conversations. It makes people learn multiple systems and search multiple places - especially if the feature ends up being submitted as a patch to the bug tracker. I'd rather keep wishlist items in the bug tracker than split them into two. (also, fwiw, I'd rather keep the tasks number space clean should we ever decide to import from bugzilla -> phabricator) -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 15:15:45 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E14D3DB2 for ; Wed, 29 Oct 2014 15:15:45 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EAAC77A for ; Wed, 29 Oct 2014 15:15:45 +0000 (UTC) Received: from mbpro-rtxv.cs.huji.ac.il ([132.65.80.91]) by kabab.cs.huji.ac.il with esmtp id 1XjUyB-0000CO-TV; Wed, 29 Oct 2014 17:15:31 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Mellanox 10gb driver? From: Daniel Braniss In-Reply-To: <9452A1B7-CA45-45D3-A0B4-FF9158C7F42B@cs.huji.ac.il> Date: Wed, 29 Oct 2014 17:15:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E84DE52-902D-4A04-9419-6723888E8818@cs.huji.ac.il> References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> <53EF0260.9030806@selasky.org> <7D49FD54-AA37-4F04-952E-5A07754762E5@cs.huji.ac.il> <53EF09DC.60601@selasky.org> <8FD6967F-E130-4FBC-B93B-D5D508279E11@cs.huji.ac.il> <76068BC4-886A-46F9-A535-EB2109FE1ECF@cs.huji.ac.il> <5405AD1B.90208@selasky.org> <9452A1B7-CA45-45D3-A0B4-FF9158C7F42B@cs.huji.ac.il> To: Hans Petter Selasky , Meny Yossefi X-Mailer: Apple Mail (2.1990.1) Cc: Mark Saad , "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:15:46 -0000 hi all, it took some time, but today I received 2 mlnx cards, (not engineering = preview :-) I can=92t get the iPXE stuff to work, will need to spend some time with = wireshark to figure out what=92s going on. other than that seems to work, though have some issues, which get fixed by turning off TSO btw, when sending stuff, I get many: <6>mlx4_en: mlxen0: Link Up how is the MFC going on? I=92m still running 9.3-stable. thanks, danny > On Sep 2, 2014, at 3:50 PM, Daniel Braniss = wrote: >=20 >=20 > On Sep 2, 2014, at 2:42 PM, Hans Petter Selasky = wrote: >>>=20 >>> I ran into an issue with intel 10gb cards where the twinax cables = from Cisco would not work with the intel nics . You issue could be = related , double check the twinax cables are supported . Truth be told = it's the integrated sfp+ that is the issue . >=20 > I got the 15m Twinax to work!, the problem was not in the cable/gibic = but with > DHCP which seems to be troublesome. >=20 >=20 >>>=20 >>> -- >>> Mark saad | mark.saad@longcount.org >>>=20 >>=20 >> FYI: >>=20 >> Snapshot of coming MLXEN FreeBSD driver for those that want to try: >>> = http://www.mellanox.com/page/products_dyn?product_family=3D193&mtag=3Dfree= bsd_driver >>=20 >=20 > and will be MFC=92ed to 9.3 =85? >=20 > danny >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 15:24:27 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 987BE1DF for ; Wed, 29 Oct 2014 15:24:27 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53C1688C for ; Wed, 29 Oct 2014 15:24:27 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id EE2141FE022; Wed, 29 Oct 2014 16:24:23 +0100 (CET) Message-ID: <545106B1.6070507@selasky.org> Date: Wed, 29 Oct 2014 16:24:33 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Daniel Braniss , Meny Yossefi Subject: Re: Mellanox 10gb driver? References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> <53EF0260.9030806@selasky.org> <7D49FD54-AA37-4F04-952E-5A07754762E5@cs.huji.ac.il> <53EF09DC.60601@selasky.org> <8FD6967F-E130-4FBC-B93B-D5D508279E11@cs.huji.ac.il> <76068BC4-886A-46F9-A535-EB2109FE1ECF@cs.huji.ac.il> <5405AD1B.90208@selasky.org> <9452A1B7-CA45-45D3-A0B4-FF9158C7F42B@cs.huji.ac.il> <5E84DE52-902D-4A04-9419-6723888E8818@cs.huji.ac.il> In-Reply-To: <5E84DE52-902D-4A04-9419-6723888E8818@cs.huji.ac.il> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Mark Saad , "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:24:27 -0000 On 10/29/14 16:15, Daniel Braniss wrote: > hi all, > it took some time, but today I received 2 mlnx cards, (not engineering preview :-) > I can’t get the iPXE stuff to work, will need to spend some time with wireshark > to figure out what’s going on. > other than that seems to work, though have some issues, which get > fixed by turning off TSO > btw, when sending stuff, I get many: > <6>mlx4_en: mlxen0: Link Up > > how is the MFC going on? I’m still running 9.3-stable. > > thanks, > danny > Hi, The latest MLX code is in 11-current. Can you by chance install an 11-current kernel on your system? An MFC for 9-stable is planned, but needs to be tested more. --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 15:41:16 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B323B9B for ; Wed, 29 Oct 2014 15:41:16 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D6AEB13 for ; Wed, 29 Oct 2014 15:41:16 +0000 (UTC) Received: from mbpro-rtxv.cs.huji.ac.il ([132.65.80.91]) by kabab.cs.huji.ac.il with esmtp id 1XjVN3-0000kj-1v; Wed, 29 Oct 2014 17:41:13 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Mellanox 10gb driver? From: Daniel Braniss In-Reply-To: <545106B1.6070507@selasky.org> Date: Wed, 29 Oct 2014 17:41:13 +0200 Message-Id: <2BDEA1CD-36F7-41CB-B465-FA9AF4F6BAE6@cs.huji.ac.il> References: <5FA0CF8C-2C93-4639-AA6C-40D3C278FE0F@cs.huji.ac.il> <53EDF13D.5050206@selasky.org> <0E7861FF-AB45-421F-8BA0-0EAD02B85AF0@cs.huji.ac.il> <3E7F3970-0541-402F-B855-EDA299B5BBC1@cs.huji.ac.il> <53EF0260.9030806@selasky.org> <7D49FD54-AA37-4F04-952E-5A07754762E5@cs.huji.ac.il> <53EF09DC.60601@selasky.org> <8FD6967F-E130-4FBC-B93B-D5D508279E11@cs.huji.ac.il> <76068BC4-886A-46F9-A535-EB2109FE1ECF@cs.huji.ac.il> <5405AD1B.90208@selasky.org> <9452A1B7-CA45-45D3-A0B4-FF9158C7F42B@cs.huji.ac.il> <5E84DE52-902D-4A04-9419-6723888E8818@cs.huji.ac.il> <545106B1.6070507@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1990.1) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "hackers@freebsd.org" , Mark Saad , Meny Yossefi X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 15:41:16 -0000 > On Oct 29, 2014, at 5:24 PM, Hans Petter Selasky = wrote: >=20 > On 10/29/14 16:15, Daniel Braniss wrote: >> hi all, >> it took some time, but today I received 2 mlnx cards, (not = engineering preview :-) >> I can=92t get the iPXE stuff to work, will need to spend some time = with wireshark >> to figure out what=92s going on. >> other than that seems to work, though have some issues, which get >> fixed by turning off TSO >> btw, when sending stuff, I get many: >> <6>mlx4_en: mlxen0: Link Up >>=20 >> how is the MFC going on? I=92m still running 9.3-stable. >>=20 >> thanks, >> danny >>=20 >=20 > Hi, >=20 > The latest MLX code is in 11-current. Can you by chance install an = 11-current kernel on your system? >=20 > An MFC for 9-stable is planned, but needs to be tested more. well, it will take me some time to have an 11 up and running - we have = some changes in user land that need to get ported/checked first. lets see which comes first, your = MFC or me upgrade to 11. danny >=20 > --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 16:02:22 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BB64F40; Wed, 29 Oct 2014 16:02:22 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01087DF1; Wed, 29 Oct 2014 16:02:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C721AB986; Wed, 29 Oct 2014 12:02:20 -0400 (EDT) From: John Baldwin To: Eitan Adler Subject: Re: junior kernel tasks Date: Wed, 29 Oct 2014 11:55:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141025204536.GD19066@dft-labs.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201410291155.53950.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 29 Oct 2014 12:02:20 -0400 (EDT) Cc: Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , freebsd-current Current , Marcus von Appen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:02:22 -0000 On Tuesday, October 28, 2014 7:07:31 pm Eitan Adler wrote: > On 28 October 2014 15:14, Baptiste Daroussin wrote: > > On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: > >> > >> Quoting John Baldwin : > >> > >> > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: > >> >> Hello, > >> >> > >> >> In short, nice kernel tasks people with C language skills can do in few > >> >> evenings. > >> >> > >> >> https://wiki.freebsd.org/JuniorJobs > >> >> > >> >> It is assumed you know how to obtain sources and build the kernel. > >> >> > >> >> What you can get in return: > >> >> - your own code in FreeBSD tree > >> >> - eternal glory [1] > >> >> - fun [2] > >> >> > >> >> If you are not interested, but know someone who does, please pass it > >> >> down. > >> >> > >> >> [1] - not really, no > >> >> [2] - well, I guess that's subjective, so that's not a "no" > >> > > >> > Even though our bugmeisters have decided that we should not have wishlist > >> > items in our bug tracker, I really wish we could store the various idea lists > >> > (we have several) in an issue tracker instead. This would allow for folks to > >> > comment on ideas, vote for them, etc. It would also make it easier for more > >> > people to submit new ideas. > >> > > >> > >> Speaking not strictly with the bugmeister hat, but from experience, please do > >> not let us go down the road of (ab)using a bug tracking solution as task and > >> idea management system. I think that using the tasks feature of phabricator > >> (our reviews instance) would provide better workflow support for those things, > >> starting out from sketching out rough ideas, discussing them, breaking them up > >> in seperate tasks (linked to and dependent on each other) and collaborating > >> on them (take a look at https://developer.blender.org/T42339 for a > >> brief example). > >> > >> Having said this, let's keep the bug tracker a bug tracker. > >> > >> Cheers > >> Marcus > > > > I disabled the tasks on phabricator to avoid having it a duplicate of bugzilla, > > but if we have a use for it I can activate it! > > > > Actually I do like the idea of the bug tracker aka bugzilla being only for bugs > > and uxe phabricator for tracking the tasks > > having disparate trackers for "wishlist" and "bugs" is quite harmful > and splits the conversations. It makes people learn multiple systems > and search multiple places - especially if the feature ends up being > submitted as a patch to the bug tracker. > > I'd rather keep wishlist items in the bug tracker than split them into two. > > (also, fwiw, I'd rather keep the tasks number space clean should we > ever decide to import from bugzilla -> phabricator) I'm not tied to a specific issue tracker to use for this and am happy to other folks debate which implementation is best, but what I would prefer is a system to let us manage "ideas to implement" like the ideas page for GSoC and this wiki page. The desired output is a list of vetted tasks. A task might start out as a wishlist entry, but someone has to step up and say "yes, this is a good idea and I will review it / shepherd it, etc." for it to become a "vetted task". Being able to store conversation about each task and tag it with other meta data (e.g. tagging the person who "owns" the task and will do the review / sheperding as well as being able to categorize them, etc.) However, I do think one important thing is that when a new idea is submitted, it has a built-in sunset. If no one grabs it after time X it becomes closed instead of remaining an open wishlist forever. Similarly if the "owner" of a task drops ownership, the timer would start while waiting for a new owner. However, this does feel very much like an issue tracker. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 16:04:43 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FD6832D for ; Wed, 29 Oct 2014 16:04:43 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21EA8E2B for ; Wed, 29 Oct 2014 16:04:42 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id hl2so2446740igb.16 for ; Wed, 29 Oct 2014 09:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webassign.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JIqT8nlbrphK3sI9MwqjRnrHiAbD2bNqW5jCQb3zWEU=; b=WK92Wq3LexuvbIYKP3PtaZ9Z4W25ViR/OKU+N4g7pzHyS8lxolTVogBNaDsStDRWQO RINY+OlqBi6Kx54MwIHHzre0Gnk23ZRsQH1ALfzECFuOX/asb31uz7oE3rASkU7crrBv JzetODCFEEPK3aPq9wGLdgPC8Owl6iRGtAWKg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JIqT8nlbrphK3sI9MwqjRnrHiAbD2bNqW5jCQb3zWEU=; b=QjvgdgdaBy6n3zMHY2wXg0/4YM6Ppd7s8J8cPj8i5ahYpsLBesplR/VDCZb8blyDGG M5ZHirQuv1S/rPyuGgWORpyR5iV83lUNElnrUppxO46pFhTWr1/UABjzE82H6GVaLTdy Uxj5PjdNcocU/Jqq3Fi262XY/zReROvA2oyzM9jkEJN5kwQDo82gUYLVha0kI746AveO noDVNE6XicdfmmUwfKDPAl4j+kfAZBbA0URZWtsh8sztXww2xpBhu3XBSIhaEaFboBAe HbR31Y8YqCdteVXHwWOUR7QVdAQjeeAW17gA93xFRnVd5PKSxHgTaUwkTteIspbz9eae bZcQ== X-Gm-Message-State: ALoCoQlpJSKEhSmKhcfDsM8SuQJYAPAxqJS27nNUU3TvaNAmXYG2rdrAF5l60q7PPYvO0Qy+qVEC X-Received: by 10.50.4.4 with SMTP id g4mr13855993igg.22.1414598682307; Wed, 29 Oct 2014 09:04:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.240.116 with HTTP; Wed, 29 Oct 2014 09:04:21 -0700 (PDT) In-Reply-To: <201410291155.53950.jhb@freebsd.org> References: <20141025204536.GD19066@dft-labs.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> <201410291155.53950.jhb@freebsd.org> From: Hunter Satterwhite Date: Wed, 29 Oct 2014 12:04:21 -0400 Message-ID: Subject: Re: junior kernel tasks To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , Eitan Adler , freebsd-current Current , Marcus von Appen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:04:43 -0000 GitHub + Gitter? https://gitter.im/ On Wed, Oct 29, 2014 at 11:55 AM, John Baldwin wrote: > On Tuesday, October 28, 2014 7:07:31 pm Eitan Adler wrote: > > On 28 October 2014 15:14, Baptiste Daroussin wrote: > > > On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: > > >> > > >> Quoting John Baldwin : > > >> > > >> > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: > > >> >> Hello, > > >> >> > > >> >> In short, nice kernel tasks people with C language skills can do > in few > > >> >> evenings. > > >> >> > > >> >> https://wiki.freebsd.org/JuniorJobs > > >> >> > > >> >> It is assumed you know how to obtain sources and build the kernel. > > >> >> > > >> >> What you can get in return: > > >> >> - your own code in FreeBSD tree > > >> >> - eternal glory [1] > > >> >> - fun [2] > > >> >> > > >> >> If you are not interested, but know someone who does, please pass > it > > >> >> down. > > >> >> > > >> >> [1] - not really, no > > >> >> [2] - well, I guess that's subjective, so that's not a "no" > > >> > > > >> > Even though our bugmeisters have decided that we should not have > wishlist > > >> > items in our bug tracker, I really wish we could store the various > idea lists > > >> > (we have several) in an issue tracker instead. This would allow > for folks to > > >> > comment on ideas, vote for them, etc. It would also make it easier > for more > > >> > people to submit new ideas. > > >> > > > >> > > >> Speaking not strictly with the bugmeister hat, but from experience, > please do > > >> not let us go down the road of (ab)using a bug tracking solution as > task and > > >> idea management system. I think that using the tasks feature of > phabricator > > >> (our reviews instance) would provide better workflow support for > those things, > > >> starting out from sketching out rough ideas, discussing them, > breaking them up > > >> in seperate tasks (linked to and dependent on each other) and > collaborating > > >> on them (take a look at https://developer.blender.org/T42339 for a > > >> brief example). > > >> > > >> Having said this, let's keep the bug tracker a bug tracker. > > >> > > >> Cheers > > >> Marcus > > > > > > I disabled the tasks on phabricator to avoid having it a duplicate of > bugzilla, > > > but if we have a use for it I can activate it! > > > > > > Actually I do like the idea of the bug tracker aka bugzilla being only > for bugs > > > and uxe phabricator for tracking the tasks > > > > having disparate trackers for "wishlist" and "bugs" is quite harmful > > and splits the conversations. It makes people learn multiple systems > > and search multiple places - especially if the feature ends up being > > submitted as a patch to the bug tracker. > > > > I'd rather keep wishlist items in the bug tracker than split them into > two. > > > > (also, fwiw, I'd rather keep the tasks number space clean should we > > ever decide to import from bugzilla -> phabricator) > > I'm not tied to a specific issue tracker to use for this and am happy to > other > folks debate which implementation is best, but what I would prefer is a > system > to let us manage "ideas to implement" like the ideas page for GSoC and this > wiki page. The desired output is a list of vetted tasks. A task might > start > out as a wishlist entry, but someone has to step up and say "yes, this is > a good > idea and I will review it / shepherd it, etc." for it to become a "vetted > task". > Being able to store conversation about each task and tag it with other meta > data (e.g. tagging the person who "owns" the task and will do the review / > sheperding as well as being able to categorize them, etc.) However, I do > think > one important thing is that when a new idea is submitted, it has a built-in > sunset. If no one grabs it after time X it becomes closed instead of > remaining > an open wishlist forever. Similarly if the "owner" of a task drops > ownership, > the timer would start while waiting for a new owner. However, this does > feel > very much like an issue tracker. > > -- > John Baldwin > _______________________________________________ > 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" > -- Hunter Satterwhite Systems Engineer, Technical Operations (TechOps) From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 20:53:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 821FA497; Wed, 29 Oct 2014 20:53:47 +0000 (UTC) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B111B5E2; Wed, 29 Oct 2014 20:53:46 +0000 (UTC) Received: from [89.182.109.102] (helo=localhost) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1XjaFN-0003yV-VV; Wed, 29 Oct 2014 21:53:38 +0100 Date: Wed, 29 Oct 2014 21:53:36 +0100 From: Marcus von Appen To: Eitan Adler Subject: Re: junior kernel tasks Message-ID: <20141029205336.GA1303@medusa.sysfault.org> Reply-To: Marcus von Appen Mail-Followup-To: Eitan Adler , Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , freebsd-current Current References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Df-Sender: MTEyNTc0Mg== Cc: FreeBSD Hackers , Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , freebsd-current Current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:53:47 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On, Wed Oct 29, 2014, Eitan Adler wrote: > On 28 October 2014 15:14, Baptiste Daroussin wrote: > > On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: > >> > >> Quoting John Baldwin : > >> > >> > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: > >> >> Hello, > >> >> > >> >> In short, nice kernel tasks people with C language skills can do in few > >> >> evenings. > >> >> > >> >> https://wiki.freebsd.org/JuniorJobs > >> >> > >> >> It is assumed you know how to obtain sources and build the kernel. > >> >> > >> >> What you can get in return: > >> >> - your own code in FreeBSD tree > >> >> - eternal glory [1] > >> >> - fun [2] > >> >> > >> >> If you are not interested, but know someone who does, please pass it > >> >> down. > >> >> > >> >> [1] - not really, no > >> >> [2] - well, I guess that's subjective, so that's not a "no" > >> > > >> > Even though our bugmeisters have decided that we should not have wishlist > >> > items in our bug tracker, I really wish we could store the various idea lists > >> > (we have several) in an issue tracker instead. This would allow for folks to > >> > comment on ideas, vote for them, etc. It would also make it easier for more > >> > people to submit new ideas. > >> > > >> > >> Speaking not strictly with the bugmeister hat, but from experience, please do > >> not let us go down the road of (ab)using a bug tracking solution as task and > >> idea management system. I think that using the tasks feature of phabricator > >> (our reviews instance) would provide better workflow support for those things, > >> starting out from sketching out rough ideas, discussing them, breaking them up > >> in seperate tasks (linked to and dependent on each other) and collaborating > >> on them (take a look at https://developer.blender.org/T42339 for a > >> brief example). > >> > >> Having said this, let's keep the bug tracker a bug tracker. > >> > >> Cheers > >> Marcus > >> > >> > >> _______________________________________________ > >> 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" > > > > I disabled the tasks on phabricator to avoid having it a duplicate of bugzilla, > > but if we have a use for it I can activate it! > > > > Actually I do like the idea of the bug tracker aka bugzilla being only for bugs > > and uxe phabricator for tracking the tasks > > having disparate trackers for "wishlist" and "bugs" is quite harmful > and splits the conversations. It makes people learn multiple systems > and search multiple places - especially if the feature ends up being > submitted as a patch to the bug tracker. We have this situation right now with reviews and the bug tracker. reviews is used by the committers only right now, and both loosely interact with each other. Opening reviews to the public won't improve the situation of having two disparate systems to look into. Same goes for the Wiki and bug tracker, mailing lists, etc. The more relevant question thus would be: how do we point people to the correct location and at which point of time? This will call for a more tight integration in the foresesable future (e.g. search abilities for reviews, that can be triggered from the bug tracker and vice versa). > I'd rather keep wishlist items in the bug tracker than split them into two. > > (also, fwiw, I'd rather keep the tasks number space clean should we > ever decide to import from bugzilla -> phabricator) > Fair enough. If we are going to do that, the area however should be separate from typical "bugs", so people do not confuse wishes with bugs and vice versa. Also, to avoid long and misleading comment trails, we would need the ability to hide/remove errornous (bug-related) comments in the wishlist (a feature wished for independent of this, but a necessary prerequisite [probably coming soon]). Wishlist items thus should not belong to a currently existing product or component, but should be clearly classified in an own product and/or component category. Except from that, what else would be required and desired to have a suitable wishlist? The bug tracker right now features: - tags - keywords - links to internal bugs/items (dependencies and blockers) - links to external systems - links to svn commits and reviews - attachments - flags to request/confirm/deny things Cheers Marcus --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRRU9AACgkQi68/ErJnpkc9UQCdGZ/MoEDqs/Sa8MalLiTs3j7K rWEAni9Kmig1t+j6WjwRC7tkanCHIu0H =hunL -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 23:00:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EEF6A6C; Wed, 29 Oct 2014 23:00:32 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1984A75A; Wed, 29 Oct 2014 23:00:32 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id v10so3813256pde.8 for ; Wed, 29 Oct 2014 16:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=SRZgvvQvTtjTmY5IchGB+MjrPu044eEBWDzwfdscOq0=; b=OdtVnolMg9jTKAlW1V2G+LVkmcBNrAbUusNwD1reSDIyDRe28Nb27mFjTz59rgCKrJ R7ZBpAMtD9ZUCw7CrspzYFYNrOotjIw+byK+0wltJ3yhFGxMmobTmUSVXQ/d3ipPt5Zg YCXL8jM/rrm0JTx6/58MsfF2DTTZKmLuqsoKy5GYzcwU4V4JwrXxOwexbWQV4NRYrtnb TejBTAfByG/EaLCAplSCfBcCDHPLrw5FrGP+QkZK28jrutFcMy873NZj0CE6aOEC/h/B ZndZHbniNDw5XNH8ussmAUQsmsuwbJCI0FUh1vieoHNvvy0TWsOoK+8WCA7MxsEI4rES sabQ== X-Received: by 10.67.14.129 with SMTP id fg1mr13091404pad.114.1414623631669; Wed, 29 Oct 2014 16:00:31 -0700 (PDT) Received: from [10.222.96.105] (mobile-166-171-121-185.mycingular.net. [166.171.121.185]) by mx.google.com with ESMTPSA id lr4sm5293908pab.42.2014.10.29.16.00.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 16:00:31 -0700 (PDT) References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> <20141029205336.GA1303@medusa.sysfault.org> Mime-Version: 1.0 (1.0) In-Reply-To: <20141029205336.GA1303@medusa.sysfault.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Tracking enhancements/wishlist items (was "junior kernel tasks") Date: Wed, 29 Oct 2014 16:00:29 -0700 To: Marcus von Appen X-Mailman-Approved-At: Wed, 29 Oct 2014 23:34:29 +0000 Cc: Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , Eitan Adler , freebsd-current Current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 23:00:32 -0000 > On Oct 29, 2014, at 13:53, Marcus von Appen wrote: ... If we are going to do that, the area however should be > separate from typical "bugs", so people do not confuse wishes with bugs > and vice versa. Also, to avoid long and misleading comment trails, we > would need the ability to hide/remove errornous (bug-related) comments > in the wishlist (a feature wished for independent of this, but a > necessary prerequisite [probably coming soon]). >=20 > Wishlist items thus should not belong to a currently existing product or > component, but should be clearly classified in an own product and/or > component category. >=20 > Except from that, what else would be required and desired to have a > suitable wishlist? The bug tracker right now features: >=20 > - tags > - keywords > - links to internal bugs/items (dependencies and blockers) > - links to external systems > - links to svn commits and reviews > - attachments > - flags to request/confirm/deny things At $work we use Enhancement in the severity field to generally denote these k= inds of items. However, we could always use wishlist in the Keywords field. All I ask for is a centralized place to track this or easy way to look this u= p instead of 10+ wiki pages and doc pages full of outdated/incorrect materia= l.= From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 23:35:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E77037F6 for ; Wed, 29 Oct 2014 23:35:11 +0000 (UTC) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "nyi.unixathome.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1B29AD5 for ; Wed, 29 Oct 2014 23:35:11 +0000 (UTC) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id CE9FB5084A; Wed, 29 Oct 2014 23:34:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by nyi.unixathome.org (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdttCUNM1HHg; Wed, 29 Oct 2014 23:34:52 +0000 (UTC) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 1D8345082B ; Wed, 29 Oct 2014 23:34:51 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: perl isvaliddate function From: Dan Langille In-Reply-To: Date: Wed, 29 Oct 2014 19:34:59 -0400 Message-Id: <310ADD44-3897-44F6-8D82-49AD66011FFA@langille.org> References: <4EA9EE9C-5049-4C50-B361-07F58FA19896@langille.org> To: "B. Estrade" X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 23:35:12 -0000 Thank you. This is now in use at http://dev.freshports.org and will = move to production later. On Oct 27, 2014, at 9:12 AM, B. Estrade wrote: > use POSIX qw/strftime/; >=20 > sub IsValidDate($) { > my $string =3D shift; > my ($year, $mon, $mday) =3D split /-/, $string; > my $test =3D strftime("%Y-%m-%d", 0, 0, 0, $mday, $mon - 1, $year - = 1900); > return ($test eq $string) ? $string : undef; > } >=20 > my $a =3D '2014-11-30 unless *coin ports remain unfixed'; >=20 > if (IsValidDate($a)) { > print "'$a' is a valid date\n"; > } else { > print "'$a' is NOT a valid date\n"; > } >=20 > my $b =3D '2014-02-30'; >=20 > if (IsValidDate($b)) { > print "'$b' is a valid date\n"; > } else { > print "'$b' is NOT a valid date\n"; > } >=20 > my $c =3D '2014-02-28'; >=20 > if (IsValidDate($c)) { > print "'$c' is a valid date\n"; > } else { > print "'$c' is NOT a valid date\n"; > } >=20 >=20 > On Sat, Oct 25, 2014 at 2:50 PM, Dan Langille = wrote: > On Oct 25, 2014, at 2:21 PM, B. Estrade wrote: >=20 > > Looks fine to just get it working. If you wanted to be more = efficient, I believe there is a way to use the core POSIX::strfmtime in = a way that would verify that the date you start with is the same date as = the one returned after the format. This core function is also very = useful for date addition and subtraction. > > > > I don't have time at this moment to create a proof of concept, but = if you're interested let me know and I will when I have a minute. >=20 > Yes, please, when you have time, please try that proof for me. I = would appreciate that. >=20 > FYI: I believe all dates within the ports tree must be YYYY-MM-DD so = using something like that would be useful. >=20 > Comparing the starting date to the supplied date is good too, to catch = edge cases like the first example. >=20 > =97 > Dan Langille >=20 >=20 =97=20 Dan Langille From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 01:22:20 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1CADC3A for ; Thu, 30 Oct 2014 01:22:20 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6ABB07A6 for ; Thu, 30 Oct 2014 01:22:20 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id x12so2597996wgg.31 for ; Wed, 29 Oct 2014 18:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-type:content-disposition:user-agent; bh=e0KJW92dDY7s4c6HDQFqIEletGMe2wQC9+7L/FzQrrY=; b=S88qfonIMGK4KpeuwNXIwlON/ld1Z1O8IixexzA4qg9zbit1RAQtX/fsDA1Bf0vUgQ E4cKxaHyyDwv09LPxoiB8oHEm2hzIS9gdCCY+cVuGq7tsC/M7nF0VJdW1eV8FLvHD0lV FntHFFEff+eTVdjJS/F93YmxNR3zkDlp9ueZ7r7PyyZDhJSvEbJc/ub8nXpei9flxPEY RuJPd9ESbyqh9EtTU6HMCNG2yIIC/NvZeSpzQClRU+u0xo/zB0m7aLDyJ8P7PfrF8qzy rWgaRNAIP3FgsuxCg0fcsoXQggGK0gtb7WuATvo2x4tUkv1JwTSzrER7F76YvbnltPyj oNUA== X-Received: by 10.180.90.65 with SMTP id bu1mr16242083wib.71.1414632138632; Wed, 29 Oct 2014 18:22:18 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id hu3sm6976537wjb.17.2014.10.29.18.22.17 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 29 Oct 2014 18:22:17 -0700 (PDT) Date: Thu, 30 Oct 2014 02:22:15 +0100 From: Mateusz Guzik To: freebsd-hackers@freebsd.org Subject: struct filedesc0 eats > 1024 bytes Message-ID: <20141030012215.GB25368@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 01:22:20 -0000 Since it is allocated from general slab and is > 1024 bytes in size, it actually occupies 2048 bytes. NDFILE is 20. struct filedesc0 { struct filedesc fd_fd; SLIST_HEAD(, freetable) fd_free; struct filedescent fd_dfiles[NDFILE]; NDSLOTTYPE fd_dmap[NDSLOTS(NDFILE)]; }; (kgdb) p sizeof(struct filedesc) $1 = 120 (kgdb) p sizeof(struct filedesc0) $2 = 1096 (kgdb) p sizeof(struct filedescent) $3 = 48 Unfotunately there is no way to reoder elements in included structs to gain enough space (or at least I didn't find any). Maybe it may be a good idea to reconsider going back to "capability fd" which is an intermediate object in the future. Next allocation is at 32 fds and that eats over 1500 bytes. In the meantime I propose decreasing NDFILE by 2. This gives sizeof = 1000 and leaves 24 bytes for possible future additions. In linux they use 32 as their default, which would still keep us within this 2KB object. But it seems similarly arbitrary. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 01:25:13 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B353FD3E for ; Thu, 30 Oct 2014 01:25:13 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C6817BE for ; Thu, 30 Oct 2014 01:25:13 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id l6so3385520qcy.8 for ; Wed, 29 Oct 2014 18:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=oADfy4BhS/gCFXZ4U1BtFDRkKeJEttppy5mSxVbEQMI=; b=PVSYCVyYOw5Me0s0FrQ2IxjaMO7oMEigvBN9dRlvW3wyMP6+wDZdBzB0qQ4JPVta/A bSVxphOU5jvYadFEtChbdwEmC7r6l8PCGVdDg51GY2YFK8c2+8KKL+YiHAlIh+WY/Osv /3PONGKmvbRVzFWGtpRHOxWQdKD+7ekBRupvlubZFnOIulT4kqBx/6JZIETUjyNvHLmc 73d0f3JG9q8O932UsTVNFfAB5Ej1B2Shq4dW9OuRmtBHOlhOTMN8WyIZPRzfeuluFpPe jnmif2wx/gBUqOyjnPHYBJZBPjY738YMndXx22X7Y4Pldpzq8+M9Gk0q01Bvi0pPFBC6 my+g== X-Received: by 10.140.81.210 with SMTP id f76mr20343297qgd.60.1414632312558; Wed, 29 Oct 2014 18:25:12 -0700 (PDT) Received: from [192.168.1.14] (h68.79.89.75.dynamic.ip.windstream.net. [75.89.79.68]) by mx.google.com with ESMTPSA id 40sm3847816qgi.47.2014.10.29.18.25.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 18:25:12 -0700 (PDT) References: <4EA9EE9C-5049-4C50-B361-07F58FA19896@langille.org> <310ADD44-3897-44F6-8D82-49AD66011FFA@langille.org> Mime-Version: 1.0 (1.0) In-Reply-To: <310ADD44-3897-44F6-8D82-49AD66011FFA@langille.org> Message-Id: X-Mailer: iPhone Mail (12B411) From: "B. Estrade" Subject: Re: perl isvaliddate function Date: Wed, 29 Oct 2014 20:25:09 -0500 To: Dan Langille Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 01:25:13 -0000 It was the very least I could do. All the thanks really goes to YOU :) Cheers, Brett Sent from my iPhone > On Oct 29, 2014, at 6:34 PM, Dan Langille wrote: >=20 > Thank you. This is now in use at http://dev.freshports.org and will move t= o production later. >=20 >> On Oct 27, 2014, at 9:12 AM, B. Estrade wrote: >>=20 >> use POSIX qw/strftime/; >>=20 >> sub IsValidDate($) { >> my $string =3D shift; >> my ($year, $mon, $mday) =3D split /-/, $string; >> my $test =3D strftime("%Y-%m-%d", 0, 0, 0, $mday, $mon - 1, $year - 190= 0); >> return ($test eq $string) ? $string : undef; >> } >>=20 >> my $a =3D '2014-11-30 unless *coin ports remain unfixed'; >>=20 >> if (IsValidDate($a)) { >> print "'$a' is a valid date\n"; >> } else { >> print "'$a' is NOT a valid date\n"; >> } >>=20 >> my $b =3D '2014-02-30'; >>=20 >> if (IsValidDate($b)) { >> print "'$b' is a valid date\n"; >> } else { >> print "'$b' is NOT a valid date\n"; >> } >>=20 >> my $c =3D '2014-02-28'; >>=20 >> if (IsValidDate($c)) { >> print "'$c' is a valid date\n"; >> } else { >> print "'$c' is NOT a valid date\n"; >> } >>=20 >>=20 >>> On Sat, Oct 25, 2014 at 2:50 PM, Dan Langille wrote: >>> On Oct 25, 2014, at 2:21 PM, B. Estrade wrote: >>>=20 >>> > Looks fine to just get it working. If you wanted to be more efficient,= I believe there is a way to use the core POSIX::strfmtime in a way that wou= ld verify that the date you start with is the same date as the one returned a= fter the format. This core function is also very useful for date addition a= nd subtraction. >>> > >>> > I don't have time at this moment to create a proof of concept, but if y= ou're interested let me know and I will when I have a minute. >>>=20 >>> Yes, please, when you have time, please try that proof for me. I would a= ppreciate that. >>>=20 >>> FYI: I believe all dates within the ports tree must be YYYY-MM-DD so usi= ng something like that would be useful. >>>=20 >>> Comparing the starting date to the supplied date is good too, to catch e= dge cases like the first example. >>>=20 >>> =E2=80=94 >>> Dan Langille >=20 > =E2=80=94=20 > Dan Langille >=20 From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 06:19:54 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 177A3754 for ; Thu, 30 Oct 2014 06:19:54 +0000 (UTC) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A667B826 for ; Thu, 30 Oct 2014 06:19:53 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id q107so3521756qgd.28 for ; Wed, 29 Oct 2014 23:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4hHdKiUZMR8yQgL45C06/kKdvKAA0YK5plBoYmPnYWc=; b=JAZAopk5cK3rf9PfSm1HkMDSeAch5HabDNKbJS4JSgu2+vevbPwzwtOSU261H1BAu6 TgKvh7cl9R+I+V04i9KpA2wzrjCq0LQlSVEeRKvpFY0zxFTsplnZCPB1xUGLB/w3QWnD HPwdDoWlZe5QBuurDeP2HpFnkSWS+9JCtxlp4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4hHdKiUZMR8yQgL45C06/kKdvKAA0YK5plBoYmPnYWc=; b=j4U3JkmHMItQDXxIHlSzTz1z+hs3N4TO0eu0LoNE+m4auOxpKquJiNG++7hA0OGwlJ b4RDNBCmr8nQVNnYT+Sv0eLzH76FwHjE3vCDrX4CJgpdihYKUrMnnBhCH5yj1U1kJmnp OcUB7K98TFepKoz2LO5cowmkVtLGWtojLa+4ZwHmXNxtAh7on/OfJcTn8Ix8SfAk86ZV kygf2Ff/8bSsXJjpO1I+9t3VeLxIgM9w4ZmbFRCsk7+tZa1Io49D8uFpYrGQ+A29arxj DCeiXUeUbsXE7EE9i34BCpl4DeGmZaMRObh4BiNLux2ECAHZ5B9dhH1oqARwr461kLmd lZ9A== X-Gm-Message-State: ALoCoQl4PG5bTssCU6d+hG7rBMclml0UT8mOVZiKFp/y3bcE9YDVEn4XJAsTPihze0mPAzCjQPi2 X-Received: by 10.229.53.133 with SMTP id m5mr23197891qcg.28.1414649992583; Wed, 29 Oct 2014 23:19:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.131 with HTTP; Wed, 29 Oct 2014 23:19:22 -0700 (PDT) In-Reply-To: References: <20141025204536.GD19066@dft-labs.eu> <201410281321.31986.jhb@freebsd.org> <20141028213526.Horde.WmTRslgo-hNbim44HjeQAA6@webmail.df.eu> <20141028221413.GF26796@ivaldir.etoilebsd.net> <20141029205336.GA1303@medusa.sysfault.org> From: Eitan Adler Date: Wed, 29 Oct 2014 23:19:22 -0700 Message-ID: Subject: Re: Tracking enhancements/wishlist items (was "junior kernel tasks") To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Cc: Baptiste Daroussin , Mateusz Guzik , "bugmeister@freebsd.org" , FreeBSD Hackers , freebsd-current Current , Marcus von Appen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 06:19:54 -0000 On 29 October 2014 16:00, Garrett Cooper wrote: > >> On Oct 29, 2014, at 13:53, Marcus von Appen wrote: > > ... > > If we are going to do that, the area however should be >> separate from typical "bugs", so people do not confuse wishes with bugs >> and vice versa. Also, to avoid long and misleading comment trails, we >> would need the ability to hide/remove errornous (bug-related) comments >> in the wishlist (a feature wished for independent of this, but a >> necessary prerequisite [probably coming soon]). >> >> Wishlist items thus should not belong to a currently existing product or >> component, but should be clearly classified in an own product and/or >> component category. >> >> Except from that, what else would be required and desired to have a >> suitable wishlist? The bug tracker right now features: >> >> - tags >> - keywords >> - links to internal bugs/items (dependencies and blockers) >> - links to external systems >> - links to svn commits and reviews >> - attachments >> - flags to request/confirm/deny things > > At $work we use Enhancement in the severity field to generally denote these kinds of items. However, we could always use wishlist in the Keywords field. > > All I ask for is a centralized place to track this or easy way to look this up instead of 10+ wiki pages and doc pages full of outdated/incorrect material. I don't object to an 'Enhancement' section of the bug tracker. This is far better than split trackers. Generally, I've found that using bug trackers for wishlist items leads to other discoverability problems, but if we manage to solve that, then it isn't terrible. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 12:32:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93CEBFF4; Thu, 30 Oct 2014 12:32:34 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A8B83F9; Thu, 30 Oct 2014 12:32:33 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id ex7so4379393wid.2 for ; Thu, 30 Oct 2014 05:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=4gpFkc9aIVg9uza1gVEI8MMLj+IRQaa6kKxP64rST4E=; b=qS61e8dJISxCnfgwV1STRtesKXj8iKGj/8ko7ACu8SbJm8RWY5NxFmpusjAFOTu8uY eVR873q/KMrcHWMQ4SEXFN2mAIEcy2+17g8qxvUjd4MhpdmH7Yz6By3o8PWUThjCQb0G vVGLPjd3F0YaUoW79x+UhRbFFxHzpYF1dl+qZs5METgNh2VM1peQVKufm9ZWZVR8TBM4 Ey1LdjhCtKRm2TuZaGCRY1WO+DtWda5oN4omDqf1+1wSdEzZLicgq0XOosngjiU/kwtW jnx4iAwDcvm3cfqcAvAN2y1IQWhOHbPj2ApT3Dj5ksWixm7YfMMnu3iwLgXt8A3d+JVw PEbQ== X-Received: by 10.194.61.99 with SMTP id o3mr19787083wjr.54.1414672352373; Thu, 30 Oct 2014 05:32:32 -0700 (PDT) Received: from localhost ([82.193.208.225]) by mx.google.com with ESMTPSA id n4sm8191720wjb.40.2014.10.30.05.32.31 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 30 Oct 2014 05:32:31 -0700 (PDT) Date: Thu, 30 Oct 2014 13:32:30 +0100 From: To: Allan Jude , freebsd-hackers@freebsd.org Subject: Re: tar behavior 9.* -> 10.* Message-ID: <20141030133230.00004204@gmail.com> In-Reply-To: <544A6595.2070204@freebsd.org> References: <20141024141552.000048ac@gmail.com> <544A6595.2070204@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:32:34 -0000 On Fri, 24 Oct 2014 10:43:33 -0400 Allan Jude wrote: > On 2014-10-24 08:15, rank1seeker@gmail.com wrote: > > https://forums.freebsd.org/threads/tar-errors-when-file-content-extracted-to-stdout-is-piped.48626/ > > > > Bug? > > _______________________________________________ > What happens if you pipe it to something that doesn't close the pipe > prematurely > > try: > > tar ... | cat - > > It makes sense that it throws an error when you pipe to head, which > then closes the pipe before the file has finished being written. > Even in it's "cleanest form" it hangs: # tar -xOf src.txz usr/src/UPDATING Outputed complete content immidieatly to STDOUT and then hanged for 56 seconds! With your code situation is same. To cut it short, this is a non critical bug fixed in 9.*, aka tar regression. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 13:36:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48A3ED93; Thu, 30 Oct 2014 13:36:09 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C628BDC; Thu, 30 Oct 2014 13:36:08 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjptR-000C8V-Li; Thu, 30 Oct 2014 13:36:01 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9UDa0x6083096; Thu, 30 Oct 2014 07:36:00 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+ExP6DFmp1Q5yj0EHDLALf X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: tar behavior 9.* -> 10.* From: Ian Lepore To: rank1seeker@gmail.com In-Reply-To: <20141030133230.00004204@gmail.com> References: <20141024141552.000048ac@gmail.com> <544A6595.2070204@freebsd.org> <20141030133230.00004204@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Oct 2014 07:36:00 -0600 Message-ID: <1414676160.17308.151.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Allan Jude X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:36:09 -0000 On Thu, 2014-10-30 at 13:32 +0100, rank1seeker@gmail.com wrote: > On Fri, 24 Oct 2014 10:43:33 -0400 > Allan Jude wrote: > > > On 2014-10-24 08:15, rank1seeker@gmail.com wrote: > > > https://forums.freebsd.org/threads/tar-errors-when-file-content-extracted-to-stdout-is-piped.48626/ > > > > > > Bug? > > > _______________________________________________ > > > What happens if you pipe it to something that doesn't close the pipe > > prematurely > > > > try: > > > > tar ... | cat - > > > > It makes sense that it throws an error when you pipe to head, which > > then closes the pipe before the file has finished being written. > > > > Even in it's "cleanest form" it hangs: > # tar -xOf src.txz usr/src/UPDATING > Outputed complete content immidieatly to STDOUT and then hanged for 56 > seconds! > This is a completely different case, not at all related to what you reported earlier. It is doing exactly what it is supposed to. With the arguments you gave it, it must scan (and thus decompress) the entire archive, because there could be a newer version of UPDATING later in the archive (think tar --append). If you want it to quit as soon as it has found the first copy of usr/src/UPDATING, add -q (or --fast-read). -- Ian > With your code situation is same. > > To cut it short, this is a non critical bug fixed in 9.*, aka tar > regression. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 17:24:21 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37B282B3 for ; Thu, 30 Oct 2014 17:24:21 +0000 (UTC) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "nyi.unixathome.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06F44900 for ; Thu, 30 Oct 2014 17:24:20 +0000 (UTC) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 849935084C for ; Thu, 30 Oct 2014 17:24:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by nyi.unixathome.org (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48qQ_AbNcyik for ; Thu, 30 Oct 2014 17:24:09 +0000 (UTC) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id F09965082B for ; Thu, 30 Oct 2014 17:24:08 +0000 (UTC) From: Dan Langille Content-Type: multipart/signed; boundary="Apple-Mail=_18F394BA-F0C7-4EAE-B5D1-A8997B4718F4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: smartd --attributelog : parsing the output Message-Id: <77D92C82-4793-4C7E-9AE5-D2A16C806A37@langille.org> Date: Thu, 30 Oct 2014 13:24:16 -0400 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:24:21 -0000 --Apple-Mail=_18F394BA-F0C7-4EAE-B5D1-A8997B4718F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Have you played with the output from =97attributelog smartd? It looks = very suitable for parsing and logging to a database. Here is a sample from my own drives: 2014-10-30 16:56:26; 1;100;0; 2;139;73; = 3;149;34384445834; 4;100;27; 5;100;0; 7;100;0; = 8;124;33; 9;99;11183; 10;100;0; 12;100;27; = 192;100;27; 193;100;27; 194;193;201864642591; 196;100;0; = 197;100;0; 198;100;0; 199;200;0; The first field of each semicolon separated triplet is the ID of the = S.M.A.R.T. attribute in question. I haven=92t found any existing code which parses this data, so I=92m = very keen to start coding this mini-project, but before I did, I figured = I would post here in case any of you had seen something. I can see parsing and storing this data in a database for logging, = review, and graphing purposes. I think this format is much easier to = parse than the text fields supplied by smartctl re: = https://www.freebsd.org/cgi/man.cgi?query=3Dsmartd&manpath=3DFreeBSD+9.0-R= ELEASE+and+Ports&format=3Dhtml = https://www.freebsd.org/cgi/man.cgi?query=3Dsmartctl&manpath=3DFreeBSD+9.0= -RELEASE+and+Ports&format=3Dhtml https://en.wikipedia.org/wiki/S.M.A.R.T.#ATA_S.M.A.R.T._attributes =97=20 Dan Langille --Apple-Mail=_18F394BA-F0C7-4EAE-B5D1-A8997B4718F4 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----- Comment: GPGTools - http://gpgtools.org iKYEARECAGYFAlRSdEBfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDA3REZBQjJGRUQ3NEE5QkE0NTNGOUJCNzBB MEIxNzE0Q0ZGQjlEM0MACgkQCgsXFM/7nTxclQCcDja5A5ix74asJzHKVlBSSKyH Cu4An18kq5y3c7VnXpjBKYo1jL3//+qz =iPmv -----END PGP SIGNATURE----- --Apple-Mail=_18F394BA-F0C7-4EAE-B5D1-A8997B4718F4-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 15:58:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 520DD747 for ; Thu, 30 Oct 2014 15:58:09 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC32DC90 for ; Thu, 30 Oct 2014 15:58:08 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9UFw5mF079021 for ; Thu, 30 Oct 2014 16:58:05 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 123543D95; Thu, 30 Oct 2014 16:58:04 +0100 (CET) Message-ID: <5452600C.5030003@omnilan.de> Date: Thu, 30 Oct 2014 16:58:04 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs References: <20140415233133.GA14686@ambrisko.com> In-Reply-To: <20140415233133.GA14686@ambrisko.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF48E2C289B4AEEC87964F705" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 30 Oct 2014 16:58:05 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-Mailman-Approved-At: Thu, 30 Oct 2014 18:45:58 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:58:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF48E2C289B4AEEC87964F705 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, first sorry for the missing thread references in the header, I'm not subscribed to hackers@. bdrewery@ pointed me to this discussion in response to my question to stable@ (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.html) Last promising post I found: > |/ > I have a new patch at: > /|/ > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch > /|/ > that I tested against head. This should be pretty close to commi= ting > /|/ > unless people find some issues with it. > /|/=20 > /|/ In sys/kern/vfs_mount.c: > /|/ + mp->mnt_path =3D malloc(strlen(fspath), M_MOUNT, M_WAITOK); > /|/ + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); > /|/=20 > /|/ This always strips the last byte off the fspath. > /|/=20 > /|/ I like that this only touches the kernel, so it does not break anyt= hing > /|/ regarding mount/umount of filesystems with short paths, including > /|/ (NFS) filesystems that do not respond. > /|/=20 > /|/ The patch does not enlarge f_mntfromname which may be a problem for= > /|/ nullfs. It is certainly a step forwards for poudriere but [ENAMETOO= LONG] > /|/ errors could still occur in more extreme situations. > / > Good point on nullfs. I'll look at fixing that. To do that I'm > changing mnt_path to mnt_topath so then I can have a mnt_frompath. > I'll add nullfs to my test cases. I'll need to run through the uses > of f_mntfromname. It was pretty easy with f_mntonname since it was > only allocated in one place just used a bunch of other place. I assume= > that mount root would be short. Thanks a lot so far for working hard on that problem! Is there anything newer than "mount_bigger_2.patch", which considers potential nullfs problems? I'm heavily using nullfs (without poudriere), but I'd give it a try on my rather lightly loaded local 10.1 storage box =E2=80=93 almost all snap= shots are useless, can't access them in case of the case; which happens frequently :-( Would I have to expect any nullfs regressions with the april (mount_bigger_2) patch?? Thanks, -Harry --------------enigF48E2C289B4AEEC87964F705 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRSYAwACgkQLDqVQ9VXb8ir2wCferAaRr0Zc86cFqifNQDc3+6U 9ysAoMeuk84ezCMsllfM6SHRu7ojUJsG =JLEc -----END PGP SIGNATURE----- --------------enigF48E2C289B4AEEC87964F705-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 21:01:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF8533E1 for ; Thu, 30 Oct 2014 21:01:41 +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 97355217 for ; Thu, 30 Oct 2014 21:01:41 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAGimUlSDaFve/2dsb2JhbABchD6DAopgr3iXAwEJgT0BAQEBAX2ELIELAg0ZAl+IVKZPj0KUbgEBCAEBAQEBHYEsjy+DMoFUBaphiVOEFCGBd4EDAQEB X-IronPort-AV: E=Sophos;i="5.07,288,1413259200"; d="scan'208";a="164859198" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 30 Oct 2014 17:01:16 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2C60CB4080 for ; Thu, 30 Oct 2014 17:01:16 -0400 (EDT) Date: Thu, 30 Oct 2014 17:01:16 -0400 (EDT) From: Rick Macklem To: Freebsd hackers list Message-ID: <439339249.2551223.1414702876172.JavaMail.root@uoguelph.ca> Subject: how to kernel printf a int64_t? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 21:01:42 -0000 Hi, I feel kinda dumb asking this, but... int64_t i; printf("%qd\n", (u_quad_t)i); works but looks dorky, to put it technically;-). Is there a better way to printf() a int64_t in the kernel? Thanks for any answers, rick From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 00:53:57 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A59A57CB for ; Fri, 31 Oct 2014 00:53:57 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 87BE3BEC for ; Fri, 31 Oct 2014 00:53:57 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 382D156467; Thu, 30 Oct 2014 19:53:50 -0500 (CDT) Message-ID: <5452DD9D.6060508@vangyzen.net> Date: Thu, 30 Oct 2014 20:53:49 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Rick Macklem , Freebsd hackers list Subject: Re: how to kernel printf a int64_t? References: <439339249.2551223.1414702876172.JavaMail.root@uoguelph.ca> In-Reply-To: <439339249.2551223.1414702876172.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 00:53:57 -0000 On 10/30/2014 17:01, Rick Macklem wrote: > I feel kinda dumb asking this, but... > int64_t i; > > printf("%qd\n", (u_quad_t)i); > > works but looks dorky, to put it technically;-). > Is there a better way to printf() a int64_t in the kernel? The ANSI C way would be: #include int64_t i; printf("%"PRId64"\n", i); It's probably bad form to directly #include a file name with an underscore into an implementation file, but I don't see any other way. Maybe we could create a that #includes the necessary files to be a kernel equivalent of . Eric From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 05:10:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABB477C9 for ; Fri, 31 Oct 2014 05:10:16 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F4EF626 for ; Fri, 31 Oct 2014 05:10:16 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kx10so6969384pab.12 for ; Thu, 30 Oct 2014 22:10:09 -0700 (PDT) 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=R5znHJRsCXwfTND2wigREdLP6cKbMb1BKhbDeTnfLpw=; b=cJdz76FEbCeFcW+mUDbPkKzPH8ONEkMXf3rhqEaa350nSqBAl5E1hyMDUxzbjKSRv/ zK9tAzd7nquddCcffzjqrCbRZj0Ssw2Vbv/wQUC9iOyqL67GP9jOEsS0dpPtN9Y8ABVD xsxPZk+UgJwGhowbZzTetA9iP1IKRKCmUH8cPExFxfqrQSUoDncAFkKzjhTr8vYrILZU ARP69R882dvqRApHeWxpmwMhltiyNRJHXclHq57Ih/1N/Z9+4bijIZxyr8VBa0rkfY0Z g+4yqSlZEtfflORwgyAYqhduzRkZsmPaJZm9x2e26SBHKb1i8Ex0syl3gsjk6DFqll0v aIbQ== X-Gm-Message-State: ALoCoQlyG6FQwdk5YeOVT+xvT2hFgc9P1RsoiGodCxb3crcBI/DgLufHIuT35q8XLIqMxsYktLBA X-Received: by 10.66.145.234 with SMTP id sx10mr10488134pab.130.1414732209148; Thu, 30 Oct 2014 22:10:09 -0700 (PDT) Received: from [192.168.1.100] (c-24-6-220-224.hsd1.ca.comcast.net. [24.6.220.224]) by mx.google.com with ESMTPSA id s9sm8689609pdp.1.2014.10.30.22.10.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 22:10:07 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: how to kernel printf a int64_t? From: Tim Kientzle In-Reply-To: <439339249.2551223.1414702876172.JavaMail.root@uoguelph.ca> Date: Thu, 30 Oct 2014 22:09:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <97A82163-E78D-457E-B649-B243B41A6C6F@kientzle.com> References: <439339249.2551223.1414702876172.JavaMail.root@uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1878.6) Cc: Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 05:10:16 -0000 On Oct 30, 2014, at 2:01 PM, Rick Macklem wrote: > Hi, >=20 > I feel kinda dumb asking this, but... > int64_t i; >=20 > printf("%qd\n", (u_quad_t)i); >=20 > works but looks dorky, to put it technically;-). > Is there a better way to printf() a int64_t in the kernel? I often use the following to print large integers: printf(=93%jd\n=94, (intmax_t)i); Tim From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 12:42:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3C45A6F; Fri, 31 Oct 2014 12:42:08 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0339CC0A; Fri, 31 Oct 2014 12:42:07 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id q5so1180607wiv.3 for ; Fri, 31 Oct 2014 05:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=VL9pXPPWRX+hEscQBg3X8cg9j3iIzCmVGdEB1TUmBxc=; b=GsN7d7fuY04VRQe+bA0U51JwrWOYWKt4OXgFkiZ//qXFADwMuGt81fLpYFgi0iJeAi UrOsh023+WmyxZ+couEEY45MNR2WBqDMz4E9PfXomk4D8JpG/itqGafy4RVcGkovZ8m6 AGK3QkPpZoGcGK48wk0DOHO30gvRwLtoLOgzE3j2G63FS4b0iLMWz+EqclJj8BsAqH6P AuP5VJYl0hA/AhgH4ujljl2rzOx7So1yyKS/0N3NojY6YWIzfLNmqtrKmx00qrStAD6q PH12gsQX3t5zEg/QdYNBtkccOzTJmnW2OXXTnjE/eOs/M1M+7tuqt62y1G+3uNwoSLep KVAg== X-Received: by 10.180.187.130 with SMTP id fs2mr3646785wic.24.1414759326299; Fri, 31 Oct 2014 05:42:06 -0700 (PDT) Received: from localhost ([82.193.208.225]) by mx.google.com with ESMTPSA id gt7sm25473678wib.18.2014.10.31.05.42.05 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 31 Oct 2014 05:42:05 -0700 (PDT) Date: Fri, 31 Oct 2014 13:42:01 +0100 From: To: Ian Lepore Subject: Re: tar behavior 9.* -> 10.* Message-ID: <20141031134201.00000127@gmail.com> In-Reply-To: <1414676160.17308.151.camel@revolution.hippie.lan> References: <20141024141552.000048ac@gmail.com> <544A6595.2070204@freebsd.org> <20141030133230.00004204@gmail.com> <1414676160.17308.151.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Allan Jude X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 12:42:08 -0000 On Thu, 30 Oct 2014 07:36:00 -0600 Ian Lepore wrote: > On Thu, 2014-10-30 at 13:32 +0100, rank1seeker@gmail.com wrote: > > On Fri, 24 Oct 2014 10:43:33 -0400 > > Allan Jude wrote: > > > > > On 2014-10-24 08:15, rank1seeker@gmail.com wrote: > > > > https://forums.freebsd.org/threads/tar-errors-when-file-content-extracted-to-stdout-is-piped.48626/ > > > > > > > > Bug? > > > > _______________________________________________ > > > > > What happens if you pipe it to something that doesn't close the > > > pipe prematurely > > > > > > try: > > > > > > tar ... | cat - > > > > > > It makes sense that it throws an error when you pipe to head, > > > which then closes the pipe before the file has finished being > > > written. > > > > > > > Even in it's "cleanest form" it hangs: > > # tar -xOf src.txz usr/src/UPDATING > > Outputed complete content immidieatly to STDOUT and then hanged for > > 56 seconds! > > > > This is a completely different case, not at all related to what you > reported earlier. It is doing exactly what it is supposed to. With > the arguments you gave it, it must scan (and thus decompress) the > entire archive, because there could be a newer version of UPDATING > later in the archive (think tar --append). If you want it to quit as > soon as it has found the first copy of usr/src/UPDATING, add -q (or > --fast-read). > > -- Ian Thank you Ian. It did a trick. However, if you've looked at a link, you would see I've reported 2 issues of which 1 is now solved. It is tar's pipe problem, which started to occur in 10.* # tar -qxOf src.txz usr/src/UPDATING | head ... expected output ... ./usr/src/UPDATING: Write error tar: Error exit delayed from previous errors. Exits with 1 (fail) > > > With your code situation is same. > > > > To cut it short, this is a non critical bug fixed in 9.*, aka tar > > regression. > > From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 14:05:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05E09CC3; Fri, 31 Oct 2014 14:05:15 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC8E06D6; Fri, 31 Oct 2014 14:05:14 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XkCp9-000McP-Bv; Fri, 31 Oct 2014 14:05:07 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9VE562m085237; Fri, 31 Oct 2014 08:05:06 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+H5bm1wuVhTPdWKPVAj6Dh X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: tar behavior 9.* -> 10.* From: Ian Lepore To: rank1seeker@gmail.com In-Reply-To: <20141031134201.00000127@gmail.com> References: <20141024141552.000048ac@gmail.com> <544A6595.2070204@freebsd.org> <20141030133230.00004204@gmail.com> <1414676160.17308.151.camel@revolution.hippie.lan> <20141031134201.00000127@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 31 Oct 2014 08:05:05 -0600 Message-ID: <1414764305.17308.190.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Allan Jude X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 14:05:15 -0000 On Fri, 2014-10-31 at 13:42 +0100, rank1seeker@gmail.com wrote: > On Thu, 30 Oct 2014 07:36:00 -0600 > Ian Lepore wrote: > > > On Thu, 2014-10-30 at 13:32 +0100, rank1seeker@gmail.com wrote: > > > On Fri, 24 Oct 2014 10:43:33 -0400 > > > Allan Jude wrote: > > > > > > > On 2014-10-24 08:15, rank1seeker@gmail.com wrote: > > > > > https://forums.freebsd.org/threads/tar-errors-when-file-content-extracted-to-stdout-is-piped.48626/ > > > > > > > > > > Bug? > > > > > _______________________________________________ > > > > > > > What happens if you pipe it to something that doesn't close the > > > > pipe prematurely > > > > > > > > try: > > > > > > > > tar ... | cat - > > > > > > > > It makes sense that it throws an error when you pipe to head, > > > > which then closes the pipe before the file has finished being > > > > written. > > > > > > > > > > Even in it's "cleanest form" it hangs: > > > # tar -xOf src.txz usr/src/UPDATING > > > Outputed complete content immidieatly to STDOUT and then hanged for > > > 56 seconds! > > > > > > > This is a completely different case, not at all related to what you > > reported earlier. It is doing exactly what it is supposed to. With > > the arguments you gave it, it must scan (and thus decompress) the > > entire archive, because there could be a newer version of UPDATING > > later in the archive (think tar --append). If you want it to quit as > > soon as it has found the first copy of usr/src/UPDATING, add -q (or > > --fast-read). > > > > -- Ian > > > Thank you Ian. > It did a trick. However, if you've looked at a link, you would see I've > reported 2 issues of which 1 is now solved. > > It is tar's pipe problem, which started to occur in 10.* > # tar -qxOf src.txz usr/src/UPDATING | head > ... expected output ... > ./usr/src/UPDATING: Write error > tar: Error exit delayed from previous errors. > > Exits with 1 (fail) > When it comes to the original report, if anything I'd be inclined to say the old behavior was buggy and now it works right. It used to ignore some output errors and now it doesn't. If you were restoring a backup rather than browsing a readme, you'd certainly want to know that it failed to write some of the output. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 15:56:04 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1BEF85F; Fri, 31 Oct 2014 15:56:03 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FDBC3DF; Fri, 31 Oct 2014 15:56:02 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id w7so6391133lbi.12 for ; Fri, 31 Oct 2014 08:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=mm+N0hv8caqJFzBcMqSKM9S2VV1+cgT8NnN9RXoyxL0=; b=M5Hf0e8/CUWmFWBbjaXV7VkaEaylsCAcmjgWQgiTIcfuYsmd9qgvhjM7OUtvOMQFjF 6zg+b9K7A3A2/Gyejwo7Lks7l0RghZSr4PYqnxDA1rp2jXVxVuE1AhYoukV8mCqvvppd ho1GGrMUsoUfN+rD3gGcAIfAYXeBkJaxwqGaLmPCDxpN/HIkOpFZHX+tOOp+1/uyjXSd C1zAwdqig4ynvYELYmgTV4Nu6jSLoQlFcUy2+nMyCJwcKpOZ90bQpP96kEoCHevZ/Ogp gO+uXRrqQXN9ieYKGNzsbTDNP7SaN65jIe/xsDFAfvJbSr7IagJmgDKNybSopGZSgC5k OMjA== X-Received: by 10.152.87.18 with SMTP id t18mr23121018laz.0.1414770960982; Fri, 31 Oct 2014 08:56:00 -0700 (PDT) Received: from localhost ([82.193.208.225]) by mx.google.com with ESMTPSA id r4sm4585962lar.3.2014.10.31.08.55.59 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 31 Oct 2014 08:56:00 -0700 (PDT) Date: Fri, 31 Oct 2014 16:55:55 +0100 From: To: Ian Lepore Subject: Re: tar behavior 9.* -> 10.* Message-ID: <20141031165555.000048ec@gmail.com> In-Reply-To: <1414764305.17308.190.camel@revolution.hippie.lan> References: <20141024141552.000048ac@gmail.com> <544A6595.2070204@freebsd.org> <20141030133230.00004204@gmail.com> <1414676160.17308.151.camel@revolution.hippie.lan> <20141031134201.00000127@gmail.com> <1414764305.17308.190.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Allan Jude X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 15:56:04 -0000 On Fri, 31 Oct 2014 08:05:05 -0600 Ian Lepore wrote: > On Fri, 2014-10-31 at 13:42 +0100, rank1seeker@gmail.com wrote: > > On Thu, 30 Oct 2014 07:36:00 -0600 > > Ian Lepore wrote: > > > > > On Thu, 2014-10-30 at 13:32 +0100, rank1seeker@gmail.com wrote: > > > > On Fri, 24 Oct 2014 10:43:33 -0400 > > > > Allan Jude wrote: > > > > > > > > > On 2014-10-24 08:15, rank1seeker@gmail.com wrote: > > > > > > https://forums.freebsd.org/threads/tar-errors-when-file-content-extracted-to-stdout-is-piped.48626/ > > > > > > > > > > > > Bug? > > > > > > _______________________________________________ > > > > > > > > > What happens if you pipe it to something that doesn't close > > > > > the pipe prematurely > > > > > > > > > > try: > > > > > > > > > > tar ... | cat - > > > > > > > > > > It makes sense that it throws an error when you pipe to head, > > > > > which then closes the pipe before the file has finished being > > > > > written. > > > > > > > > > > > > > Even in it's "cleanest form" it hangs: > > > > # tar -xOf src.txz usr/src/UPDATING > > > > Outputed complete content immidieatly to STDOUT and then hanged > > > > for 56 seconds! > > > > > > > > > > This is a completely different case, not at all related to what > > > you reported earlier. It is doing exactly what it is supposed > > > to. With the arguments you gave it, it must scan (and thus > > > decompress) the entire archive, because there could be a newer > > > version of UPDATING later in the archive (think tar --append). > > > If you want it to quit as soon as it has found the first copy of > > > usr/src/UPDATING, add -q (or --fast-read). > > > > > > -- Ian > > > > > > Thank you Ian. > > It did a trick. However, if you've looked at a link, you would see > > I've reported 2 issues of which 1 is now solved. > > > > It is tar's pipe problem, which started to occur in 10.* > > # tar -qxOf src.txz usr/src/UPDATING | head > > ... expected output ... > > ./usr/src/UPDATING: Write error > > tar: Error exit delayed from previous errors. > > > > Exits with 1 (fail) > > > > When it comes to the original report, if anything I'd be inclined to > say the old behavior was buggy and now it works right. It used to > ignore some output errors and now it doesn't. If you were restoring > a backup rather than browsing a readme, you'd certainly want to know > that it failed to write some of the output. > > -- Ian > I see ..., sounds like a "feature or a bug?" Ok, I agree with this fix. Thanks for explanation. Domagoj From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 31 22:42:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8606892E for ; Fri, 31 Oct 2014 22:42:28 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 69B91EB1 for ; Fri, 31 Oct 2014 22:42:28 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 31 Oct 2014 15:46:00 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id s9VMgMQi077997 for ; Fri, 31 Oct 2014 15:42:22 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id s9VMgMZK077995 for freebsd-hackers@freebsd.org; Fri, 31 Oct 2014 15:42:22 -0700 (PDT) (envelope-from ambrisko) Date: Fri, 31 Oct 2014 15:42:22 -0700 From: Doug Ambrisko To: freebsd-hackers@freebsd.org Subject: UEFI PXE booting bug? Message-ID: <20141031224222.GA76176@ambrisko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 22:42:28 -0000 I've been testing UEFI PXE booting on a couple of machines. The loader.efi works just fine on a Dell R710 ... the kernel has issues but the loader.efi works fine. On two other machines it fails and hangs after the 2nd NFS lookup (the 2nd being the .gz format of the file). If I add a debug line as follows then it works instead of failing. I was wondering if anyone might see the obvious problem. Here is the patch: Index: open.c =================================================================== --- open.c (revision 273823) +++ open.c (working copy) @@ -146,6 +146,11 @@ f->f_dev->dv_close(f); if (error) devclose(f); +//printf("HELLO fail: %s %d %s\n",__FUNCTION__,__LINE__,fname); // works +//printf("fail: %s\n",fname); // works +printf(fname); // works +//printf("/boot/defaults/loader.conf\n"); // fails +//printf("/boot/defaults/loader.conf jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj\n"); // fails err: f->f_flags = 0; Notice that combinations of printf and fname works. Just a printf fails. I haven't dumped the resulting assembler code etc. This is on -current. I was wondering if someone might know what the issue could be? FYI, the -current kernel fails to boot but a FreeBSD 9.2 with old UEFI support back ported to it works. Thanks, Doug A. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 1 15:40:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC417F1A for ; Sat, 1 Nov 2014 15:40:06 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id BEEC02DD for ; Sat, 1 Nov 2014 15:40:06 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 01 Nov 2014 08:43:42 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id sA1Fe4Sb040806; Sat, 1 Nov 2014 08:40:04 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id sA1Fe4TU040804; Sat, 1 Nov 2014 08:40:04 -0700 (PDT) (envelope-from ambrisko) Date: Sat, 1 Nov 2014 08:40:04 -0700 From: Doug Ambrisko To: Harald Schmalzbauer Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20141101154004.GA40398@ambrisko.com> References: <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5452600C.5030003@omnilan.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 15:40:06 -0000 I should be able to resume working on this since things are starting to slow down. It shouldn't be much more work to get it finished off to put up for review. Doug A. On Thu, Oct 30, 2014 at 04:58:04PM +0100, Harald Schmalzbauer wrote: | Hello, | | first sorry for the missing thread references in the header, I'm not | subscribed to hackers@. | | bdrewery@ pointed me to this discussion in response to my question to | stable@ | (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.html) | | Last promising post I found: | | > |/ > I have a new patch at: | > /|/ > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch | > /|/ > that I tested against head. This should be pretty close to commiting | > /|/ > unless people find some issues with it. | > /|/ | > /|/ In sys/kern/vfs_mount.c: | > /|/ + mp->mnt_path = malloc(strlen(fspath), M_MOUNT, M_WAITOK); | > /|/ + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); | > /|/ | > /|/ This always strips the last byte off the fspath. | > /|/ | > /|/ I like that this only touches the kernel, so it does not break anything | > /|/ regarding mount/umount of filesystems with short paths, including | > /|/ (NFS) filesystems that do not respond. | > /|/ | > /|/ The patch does not enlarge f_mntfromname which may be a problem for | > /|/ nullfs. It is certainly a step forwards for poudriere but [ENAMETOOLONG] | > /|/ errors could still occur in more extreme situations. | > / | > Good point on nullfs. I'll look at fixing that. To do that I'm | > changing mnt_path to mnt_topath so then I can have a mnt_frompath. | > I'll add nullfs to my test cases. I'll need to run through the uses | > of f_mntfromname. It was pretty easy with f_mntonname since it was | > only allocated in one place just used a bunch of other place. I assume | > that mount root would be short. | | Thanks a lot so far for working hard on that problem! | Is there anything newer than "mount_bigger_2.patch", which considers | potential nullfs problems? | I'm heavily using nullfs (without poudriere), but I'd give it a try on | my rather lightly loaded local 10.1 storage box ??? almost all snapshots | are useless, can't access them in case of the case; which happens | frequently :-( | Would I have to expect any nullfs regressions with the april | (mount_bigger_2) patch?? | | Thanks, | | -Harry | |