From owner-freebsd-sparc64@freebsd.org Mon Nov 16 01:18:12 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 031FAA2F33E for ; Mon, 16 Nov 2015 01:18:12 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DA4731353 for ; Mon, 16 Nov 2015 01:18:11 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D7009A2F33C; Mon, 16 Nov 2015 01:18:11 +0000 (UTC) Delivered-To: sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCBF0A2F339; Mon, 16 Nov 2015 01:18:11 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0B371351; Mon, 16 Nov 2015 01:18:11 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tAG1HeFC025825 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 15 Nov 2015 17:17:41 -0800 Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Justin Hibbits , Marius Strobl References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> Cc: sbruno@freebsd.org, freebsd-arch , sparc64@freebsd.org From: Nathan Whitehorn Message-ID: <56492EB4.1080307@freebsd.org> Date: Sun, 15 Nov 2015 17:17:40 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaXlyTcvSKUeK34kIATMPzVvr98eH+yLwlejlQgMjhOLvxzkTIy0JViFEX1hqRNy496m8IzL441MCSdjXF/ybgeYPyRrGanO50= X-Sonic-ID: C;2Imc1P+L5RGCOL0U9jFv0A== M;fEz51P+L5RGCOL0U9jFv0A== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 01:18:12 -0000 On 11/08/15 12:46, Justin Hibbits wrote: > On 11/8/15, Marius Strobl wrote: > >> As for getting forward, the FreeBSD Software License Policy >> (https://www.freebsd.org/internal/software-license.html) >> specifically allows for existing GPLv2 licensed software in >> the FreeBSD source tree to be updated to GPLv3 licensed one. >> The initial, longer draft of this policy posted by brooks@ to >> developers@ even explicitly mentioned key technologies such >> as toolchains of other licenses being allowed when no mature >> BSD-licensed alternative exists. So I propose just that: >> Let's upgrade binutils and GCC in base to recent versions. >> Seriously. That way we 1) don't need to get external toolchain >> support into shape, 2) don't need to solve the chicken-and-egg >> problem of getting a toolchain onto a machine installed from >> a distribution built with an external toolchain and 3) once >> clang becomes mature on additional architectures, we have an >> upgrade path. Don't get me wrong, I'm only proposing that >> for !arm and !x86. >> As a side note: A while back I talked to grehan@ and marcel@ >> regarding the immaturities of clang and - as expected -, a >> GPL'ed toolchain just is no problem for either NetApp or >> Juniper as the binaries they ship don't include the toolchain >> itself. With the possible exception of the current incarnation >> of SCO which apparently sells a FreeBSD-based OS likely having >> a system compiler, for the same reason I can't think of why a >> GPLv3 licensed toolchain would matter for any of the commercial >> downstream consumers of FreeBSD. Thus, I really can't understand >> all that aggression regarding making FreeBSD 11 clang-only. >> > > > I 100% agree with you on this. If we can update binutils to the > latest and greatest, I believe powerpc64 would be able to work with > clang. I've backported several patches, with IBM's permission, to > binutils for handling new relocations, etc. However, not all patches > are straight forward, and currently we're missing something, which is > causing odd segfaults in ld(1), when linking as(1). No other binary, > only as(1). I've tried looking through it, but the binutils code is a > mess. I'm sure the bug that's getting hit was fixed with newer > binutils, but have had a very hard time trying to test with it. > > TL;DR, let's update binutils at the very least, and gcc if it makes > sense. We shouldn't be relying on external toolchain for some archs, > and internal for others. It completely snubs already second class > citizens. Just look at the various build failures we've had because > to some people All The World is clang/x86. > This would be super valuable. It would restore the upgrade path to clang broken at 3.5, allow us to use modern ABIs, everything. Is this something that is actually politically/legal doable? -Nathan From owner-freebsd-sparc64@freebsd.org Mon Nov 16 18:44:31 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3552A305A8 for ; Mon, 16 Nov 2015 18:44:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 8E4FB1A79 for ; Mon, 16 Nov 2015 18:44:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAGIiVR5095801 for ; Mon, 16 Nov 2015 18:44:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-sparc64@FreeBSD.org Subject: [Bug 204527] security/openssl 1.0.2, when compiled WITH_ASM on sparc64 generates illegal instructions Date: Mon, 16 Nov 2015 18:44:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dinoex@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dinoex@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback- merge-quarterly? X-Bugzilla-Changed-Fields: bug_status flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 18:44:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204527 Dirk Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress Flags|maintainer-feedback?(dinoex |maintainer-feedback- |@FreeBSD.org) | --- Comment #2 from Dirk Meyer --- please run cd /usr/ports/security/openssl && make clean test and report when the test fails. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-sparc64@freebsd.org Mon Nov 16 19:14:46 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC76BA30DA8 for ; Mon, 16 Nov 2015 19:14:45 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C87F11974 for ; Mon, 16 Nov 2015 19:14:45 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id C7D39A30DA6; Mon, 16 Nov 2015 19:14:45 +0000 (UTC) Delivered-To: sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE06CA30DA5; Mon, 16 Nov 2015 19:14:45 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-yk0-x242.google.com (mail-yk0-x242.google.com [IPv6:2607:f8b0:4002:c07::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 692A11973; Mon, 16 Nov 2015 19:14:45 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by ykba77 with SMTP id a77so25406440ykb.2; Mon, 16 Nov 2015 11:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1UwCbrVJfGphtXYocT1kovcrc89WcjfgXHWyTK3+64s=; b=Il5HZXXLgm35vQ67uzLOqnxTaBO2WQxxh6kVKfC9M99RyUkvT8HhBocnCJb8KZzp9b LTJNtKldE7YXbR2pCx5/QV3xrqLVZTUDw47CoBsZzNN1j2guUFMp2tdz2fe306BA9slZ GKTUQVbZHZj4Tn2gwxw9w9d7uNnDe5pc8S9Q3lBp3pDWjwnYAS42UQV8L4DB5SVGOHSG sj8+nMzUqYSpLjgKNQo0vXT/SrQlA8LRckSc77eNTJfikYxSqMJL8jdtyMu9tHoVz2bE d2sFNZMTLNV1nMcqVoqD7pLXSj7inTEzsYzxGBHB5IFOAQhf+gQvU2XH5uhX+fWw6nuX V7CQ== MIME-Version: 1.0 X-Received: by 10.129.135.7 with SMTP id x7mr36501575ywf.95.1447701284682; Mon, 16 Nov 2015 11:14:44 -0800 (PST) Received: by 10.103.9.195 with HTTP; Mon, 16 Nov 2015 11:14:44 -0800 (PST) In-Reply-To: <56492EB4.1080307@freebsd.org> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <56492EB4.1080307@freebsd.org> Date: Mon, 16 Nov 2015 14:14:44 -0500 Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Joe Nosay To: Nathan Whitehorn Cc: Justin Hibbits , Marius Strobl , Sean Bruno , sparc64@freebsd.org, freebsd-arch Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 19:14:46 -0000 Will there be a project using Z-RAM and other technologies as such? SPARC64 processors should be capable of holding a database for fourth, fifth, and sixth dimensional graphs based on time. (Fourth is the single point in time, fifth is the path of least resistance, sixth would be variations known as experiential. NASA already released a virtual program "4S" for this. Performance of RISC over CISC has always been for the former. SPARC64 is practical in audio applications which call for access to such a database. Each architecture has a specific purpose. Think about it. ARM32/64 non-mmu temporary memory, sampling, data input. POWER32/64- cache for instructions and not trash, AI, repetitive instructions, graphics, audio. SPARC32/64 - scalability, complex databases AMD64/i386 complex compression, algorithms. Performance on each differs with kernel hertz, OS choice, etc. You use them together such as parts of a biological brain. Seeing that memory is now becoming three dimensional in form, we probably should be looking towards working these together. NFS and 9p - if still around - would create two types of accessible bootstrapping methods - applications/binaries and data. On Sun, Nov 15, 2015 at 8:17 PM, Nathan Whitehorn wrote: > > > On 11/08/15 12:46, Justin Hibbits wrote: > >> On 11/8/15, Marius Strobl wrote: >> >> >>> As for getting forward, the FreeBSD Software License Policy >>> (https://www.freebsd.org/internal/software-license.html) >>> specifically allows for existing GPLv2 licensed software in >>> the FreeBSD source tree to be updated to GPLv3 licensed one. >>> The initial, longer draft of this policy posted by brooks@ to >>> developers@ even explicitly mentioned key technologies such >>> as toolchains of other licenses being allowed when no mature >>> BSD-licensed alternative exists. So I propose just that: >>> Let's upgrade binutils and GCC in base to recent versions. >>> Seriously. That way we 1) don't need to get external toolchain >>> support into shape, 2) don't need to solve the chicken-and-egg >>> problem of getting a toolchain onto a machine installed from >>> a distribution built with an external toolchain and 3) once >>> clang becomes mature on additional architectures, we have an >>> upgrade path. Don't get me wrong, I'm only proposing that >>> for !arm and !x86. >>> As a side note: A while back I talked to grehan@ and marcel@ >>> regarding the immaturities of clang and - as expected -, a >>> GPL'ed toolchain just is no problem for either NetApp or >>> Juniper as the binaries they ship don't include the toolchain >>> itself. With the possible exception of the current incarnation >>> of SCO which apparently sells a FreeBSD-based OS likely having >>> a system compiler, for the same reason I can't think of why a >>> GPLv3 licensed toolchain would matter for any of the commercial >>> downstream consumers of FreeBSD. Thus, I really can't understand >>> all that aggression regarding making FreeBSD 11 clang-only. >>> >>> >> >> I 100% agree with you on this. If we can update binutils to the >> latest and greatest, I believe powerpc64 would be able to work with >> clang. I've backported several patches, with IBM's permission, to >> binutils for handling new relocations, etc. However, not all patches >> are straight forward, and currently we're missing something, which is >> causing odd segfaults in ld(1), when linking as(1). No other binary, >> only as(1). I've tried looking through it, but the binutils code is a >> mess. I'm sure the bug that's getting hit was fixed with newer >> binutils, but have had a very hard time trying to test with it. >> >> TL;DR, let's update binutils at the very least, and gcc if it makes >> sense. We shouldn't be relying on external toolchain for some archs, >> and internal for others. It completely snubs already second class >> citizens. Just look at the various build failures we've had because >> to some people All The World is clang/x86. >> >> > This would be super valuable. It would restore the upgrade path to clang > broken at 3.5, allow us to use modern ABIs, everything. Is this something > that is actually politically/legal doable? > -Nathan > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" > From owner-freebsd-sparc64@freebsd.org Tue Nov 17 01:53:34 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2511A30722 for ; Tue, 17 Nov 2015 01:53:33 +0000 (UTC) (envelope-from bright@mu.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D66A117BD for ; Tue, 17 Nov 2015 01:53:33 +0000 (UTC) (envelope-from bright@mu.org) Received: by mailman.ysv.freebsd.org (Postfix) id D3153A30720; Tue, 17 Nov 2015 01:53:33 +0000 (UTC) Delivered-To: sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0C2AA3071F; Tue, 17 Nov 2015 01:53:33 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id AAB0517B8; Tue, 17 Nov 2015 01:53:33 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8004:7515:6d56:aa8e:b437:27b3]) by elvis.mu.org (Postfix) with ESMTPSA id 947C4345A916; Mon, 16 Nov 2015 17:53:32 -0800 (PST) Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Warner Losh , Elizabeth Myers References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> Cc: Anna Wilcox , "Brian McGovern (bmcgover)" , freebsd-arch , Marius Strobl , Sean Bruno , "sparc64@freebsd.org" , Jordan Hubbard From: Alfred Perlstein Message-ID: <564A889C.9070209@mu.org> Date: Mon, 16 Nov 2015 17:53:32 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 01:53:34 -0000 On 11/14/15 9:16 AM, Warner Losh wrote: > On Fri, Nov 13, 2015 at 11:15 PM, Elizabeth Myers > wrote: > >> You are seriously going to use "we're not NetBSD" as an argument? > > You noticed I didn't reply to it. The argument is completely lame. FreeBSD > runs > today in a variety of markets. Some new, some not so new. The thing that > makes > each of these areas unique is that there's a thriving community around them, > FreeBSD still runs well enough on these machines to get something done, and > when things break, they get fixed in a timely manner. > > Alpha was removed because it got broken by some changes, and stayed broken > for a long time despite repeated requests to fix it. Sparc64 is on the cusp > of that: > some minor things are broken, but have been fixed. The current crisis is > due to > the end of life of gcc in the tree and its fallout coupled with some > neglect of the > port due to time constraints. > > At first I was all for removal. With more data, I'm less sure. If the > promises are kept > made in this thread, it looks to remain viable for a while, though the lack > of a > qemu-user solution means that packages for a slow platform (where they are > really quite useful) will remain limited. Maybe there's enough hardware > around > that third-party pkg repos can fill the gap, maybe not. I think we should > experiment > with this model and see what it produces. Give the branching of 11 as the > deadline > to show something viable... One of the things I never understood about FreeBSD's method of maintaining a port was the way the platform porting was done. We really do things in a different manner than what my perception of other OSes is. My impression (please do correct me if I'm wrong) was that other OSes such as NetBSD and Linux had "platform maintainers". These maintainers were around to: 1) keep the ship sailing on those platforms 2) guide the general code base from becoming non-portable to other architectures (within reason). 3) drive the release of the architecture in question, helping the release engineer with image building and release testing. For point 1 above, what that meant to me was that let's say Linus or NetBSD in general wanted to do a major or minor change on a tier 1 platform, then it was the responsibility of the *platform maintainers* to do the work on the non tier-1 platforms to keep them up to date. Those "platform maintainers" kept those ships sailing and in return they got to be called "the $arch maintainer" which looks plenty good on a resume and also feels good for those that get excited for status. For point 2, let's say someone had a change that pushed some form of *completely* non-portable code into the base which would break a reasonable to support platform, then the "platform maintainer" would speak up and tell the general community "uh no, you can't do X on this platform, we need to rethink this". For point 3, there may be a lag between release of the OS for tier 1 (x86/x64) and the secondary architectures, but that is OK because the maintainer will eventually provide images themselves or in collaboration with the release engineer. FreeBSD seems to take a different approach. This approach is that someone (or some people) form a team to port to a platform. These "platform porter" groups sole responsibility is to get a new architecture running. After it's mostly running they are mostly without responsibility, however we tend to give them the right of change-set veto in perpetuity of the marginal relevance of the ported to platform. What this means is that instead of a assigning a title and ownership of the platform to someone, who maintains the status as "maintainer" by keeping that platform working. By keeping the platform working I am saying that they would do items 1, 2 and 3 from the NetBSD/Linux list. However, instead nearly immediately hoist the "platform maintenance" onto the general community of people that may not have access to the hardware in question. Maybe this is just my perception, but it would seem to make a ton more sense to follow the NetBSD/Linux model which implies a somewhat decoupled release model (not all arches must come out on the same day) and assigning ownership and responsibility in exchange for status based on being the "platform maintainer". Finally it would be pretty obvious when everyone steps down or just doesn't participate in the release process that it may be time to sunset a platform. -Alfred From owner-freebsd-sparc64@freebsd.org Tue Nov 17 01:57:56 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 557F4A307CE for ; Tue, 17 Nov 2015 01:57:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD9219D4 for ; Tue, 17 Nov 2015 01:57:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2C50EA307CB; Tue, 17 Nov 2015 01:57:56 +0000 (UTC) Delivered-To: sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1202EA307CA; Tue, 17 Nov 2015 01:57:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC91819D2; Tue, 17 Nov 2015 01:57:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioek191 with SMTP id k191so455577ioe.3; Mon, 16 Nov 2015 17:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NI7EEh4VpBKHkd5+JpRrOXqI/61eSad3bf0PIxd3ixc=; b=DJu01wTD+vXJLGDMph4XRamNd/su46mY2FfR29M2OmUKh9Dom8TLDzIJs2z8drL/ua 55pYYbW3nKvUzF8f4U2hj6ho2X5z1SUQfTlz3ZUa1R/kp8Hn90MW4k+bU0scvr0e+ePK 0LqXZBRUheuPw5rm/jGEMRzhZyGx63znYXZ/UZPud04ETQ0Nie+RInoB7w3gpKvV5A7q l4KnP3X+eZ75KvOXKUi3uDWVth1qWacIsvuwkk4OmvJDWctcFEa6A+GuUMUZTKnXwpDo VyKcAd4NLa4syAW0tmwINSu1qxa+E3tOG4pCWHhM0zoLTN+ksi5VlLbo0V7NmrqVGx6y y3tA== MIME-Version: 1.0 X-Received: by 10.107.162.21 with SMTP id l21mr7575815ioe.123.1447725475279; Mon, 16 Nov 2015 17:57:55 -0800 (PST) Received: by 10.36.217.196 with HTTP; Mon, 16 Nov 2015 17:57:55 -0800 (PST) In-Reply-To: <564A889C.9070209@mu.org> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> <564A889C.9070209@mu.org> Date: Mon, 16 Nov 2015 17:57:55 -0800 Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Adrian Chadd To: Alfred Perlstein Cc: Warner Losh , Elizabeth Myers , Anna Wilcox , freebsd-arch , Marius Strobl , Sean Bruno , "sparc64@freebsd.org" , Jordan Hubbard Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 01:57:56 -0000 On 16 November 2015 at 17:53, Alfred Perlstein wrote: > > > > On 11/14/15 9:16 AM, Warner Losh wrote: >> >> On Fri, Nov 13, 2015 at 11:15 PM, Elizabeth Myers >> >> wrote: >> >>> You are seriously going to use "we're not NetBSD" as an argument? >> >> >> You noticed I didn't reply to it. The argument is completely lame. FreeBSD >> runs >> today in a variety of markets. Some new, some not so new. The thing that >> makes >> each of these areas unique is that there's a thriving community around >> them, >> FreeBSD still runs well enough on these machines to get something done, >> and >> when things break, they get fixed in a timely manner. >> >> Alpha was removed because it got broken by some changes, and stayed broken >> for a long time despite repeated requests to fix it. Sparc64 is on the >> cusp >> of that: >> some minor things are broken, but have been fixed. The current crisis is >> due to >> the end of life of gcc in the tree and its fallout coupled with some >> neglect of the >> port due to time constraints. >> >> At first I was all for removal. With more data, I'm less sure. If the >> promises are kept >> made in this thread, it looks to remain viable for a while, though the >> lack >> of a >> qemu-user solution means that packages for a slow platform (where they are >> really quite useful) will remain limited. Maybe there's enough hardware >> around >> that third-party pkg repos can fill the gap, maybe not. I think we should >> experiment >> with this model and see what it produces. Give the branching of 11 as the >> deadline >> to show something viable... > > > One of the things I never understood about FreeBSD's method of maintaining a > port was the way the platform porting was done. We really do things in a > different manner than what my perception of other OSes is. > > My impression (please do correct me if I'm wrong) was that other OSes such > as NetBSD and Linux had "platform maintainers". > > These maintainers were around to: > 1) keep the ship sailing on those platforms > 2) guide the general code base from becoming non-portable to other > architectures (within reason). > 3) drive the release of the architecture in question, helping the release > engineer with image building and release testing. > > For point 1 above, what that meant to me was that let's say Linus or NetBSD > in general wanted to do a major or minor change on a tier 1 platform, then > it was the responsibility of the *platform maintainers* to do the work on > the non tier-1 platforms to keep them up to date. Those "platform > maintainers" kept those ships sailing and in return they got to be called > "the $arch maintainer" which looks plenty good on a resume and also feels > good for those that get excited for status. > > For point 2, let's say someone had a change that pushed some form of > *completely* non-portable code into the base which would break a reasonable > to support platform, then the "platform maintainer" would speak up and tell > the general community "uh no, you can't do X on this platform, we need to > rethink this". > > For point 3, there may be a lag between release of the OS for tier 1 > (x86/x64) and the secondary architectures, but that is OK because the > maintainer will eventually provide images themselves or in collaboration > with the release engineer. > > FreeBSD seems to take a different approach. This approach is that someone > (or some people) form a team to port to a platform. These "platform porter" > groups sole responsibility is to get a new architecture running. After it's > mostly running they are mostly without responsibility, however we tend to > give them the right of change-set veto in perpetuity of the marginal > relevance of the ported to platform. > > What this means is that instead of a assigning a title and ownership of the > platform to someone, who maintains the status as "maintainer" by keeping > that platform working. By keeping the platform working I am saying that > they would do items 1, 2 and 3 from the NetBSD/Linux list. However, instead > nearly immediately hoist the "platform maintenance" onto the general > community of people that may not have access to the hardware in question. > > Maybe this is just my perception, but it would seem to make a ton more sense > to follow the NetBSD/Linux model which implies a somewhat decoupled release > model (not all arches must come out on the same day) and assigning ownership > and responsibility in exchange for status based on being the "platform > maintainer". > > Finally it would be pretty obvious when everyone steps down or just doesn't > participate in the release process that it may be time to sunset a platform. +1 -a From owner-freebsd-sparc64@freebsd.org Tue Nov 17 05:14:43 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFA62A31ACA for ; Tue, 17 Nov 2015 05:14:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 953AA11BD for ; Tue, 17 Nov 2015 05:14:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAH5EhLH032076 for ; Tue, 17 Nov 2015 05:14:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-sparc64@FreeBSD.org Subject: [Bug 204527] security/openssl 1.0.2, when compiled WITH_ASM on sparc64 generates illegal instructions Date: Tue, 17 Nov 2015 05:14:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: lidl@pix.net X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dinoex@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback- merge-quarterly? X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 05:14:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204527 --- Comment #3 from lidl@pix.net --- Created attachment 163230 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163230&action=edit typescript of 'make clean test' session Captured output from 'make clean test' after configuring with ASM again. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-sparc64@freebsd.org Tue Nov 17 06:22:35 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A896A30515 for ; Tue, 17 Nov 2015 06:22:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EAF001ACE for ; Tue, 17 Nov 2015 06:22:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id E84E1A30513; Tue, 17 Nov 2015 06:22:34 +0000 (UTC) Delivered-To: sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD080A3050D for ; Tue, 17 Nov 2015 06:22:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 767F81ACB for ; Tue, 17 Nov 2015 06:22:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkfo3 with SMTP id o3so126832898qkf.1 for ; Mon, 16 Nov 2015 22:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dKk2eNnyXsy5DJ397r4P8+ziAZJ+fKOjQqEuyizWLVw=; b=kr7BUTzNQ+ONsJo8BBEoSF8YTst5T0JIF4iXHFsavgMgzlQ1sr8STnFZxDv4O1dUXr BdxrLHsY3KPLires2UFD1wnv40SYKXRIBD/ZOFDnL2ljeyWADP3WZ63YLHLDqoljMDDb Q+uUwG4xQBc3w8+H28cfxyLMqJIfZTcDfAp7IXZSc3j2pjKLZEfAJB2BoLhQ/rtwZEog BR8GvWRune+oJfaddiMMS3JpTDsSS07qYfTc1nisQtp+ic818sLRMQ0ZHdzujzZtaJal HT5ZD2tz7OJ0ApMJyNi5Ke0+tSxhFcAGSoOJA6LcsNPA4wUd2K2FWRBwKQYtrVb48oH1 7hsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dKk2eNnyXsy5DJ397r4P8+ziAZJ+fKOjQqEuyizWLVw=; b=DAYQcTpTyyqSMLAyglASFXCctqSZvnTf3R5++Ikvea5SIy3If0Qbbae4h5LXlWb5yg 7u9u0E1ihfK8CEKHNRLrG9ozM0n6ZZtA8FhaobctU7CkC5sLNLjYuHM5yihAKkBbR9CM TvEMkRtQzjPHnnjOe3eEHhKzSFzzTBUA7XTrTCPTydHhSW8MNTSvGCKq9JGuFxQWN/Yn BE9bbh7v6BLD8dTHJUa0Py4NJWmperj0Dd+UxEYR/IJKScgZ0rz0QH9s1mwPnmA+eChD 51BZnEB/4j0JprfmJM9TRKGQ70KQvs16jaFYv/7ttne9AaeSMiNT6j3L494Grohsndcv Ykiw== X-Gm-Message-State: ALoCoQlNHHnLoKBsJNUCJt5V6pswKOami7LwR2uaS9pJHq+Ry2kp3D9NDr+w+fTHukWAPiU22b1I MIME-Version: 1.0 X-Received: by 10.55.33.40 with SMTP id h40mr39744971qkh.77.1447741353261; Mon, 16 Nov 2015 22:22:33 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Mon, 16 Nov 2015 22:22:32 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <564A889C.9070209@mu.org> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> <564A889C.9070209@mu.org> Date: Mon, 16 Nov 2015 23:22:32 -0700 X-Google-Sender-Auth: g4TgqM2p3Vub1dt8tyQjJIkzAS8 Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Warner Losh To: Alfred Perlstein Cc: Elizabeth Myers , Anna Wilcox , "Brian McGovern (bmcgover)" , freebsd-arch , Marius Strobl , Sean Bruno , "sparc64@freebsd.org" , Jordan Hubbard Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 06:22:35 -0000 On Mon, Nov 16, 2015 at 6:53 PM, Alfred Perlstein wrote: > > > > On 11/14/15 9:16 AM, Warner Losh wrote: > >> On Fri, Nov 13, 2015 at 11:15 PM, Elizabeth Myers < >> elizabeth@interlinked.me> >> wrote: >> >> You are seriously going to use "we're not NetBSD" as an argument? >>> >> >> You noticed I didn't reply to it. The argument is completely lame. FreeBSD >> runs >> today in a variety of markets. Some new, some not so new. The thing that >> makes >> each of these areas unique is that there's a thriving community around >> them, >> FreeBSD still runs well enough on these machines to get something done, >> and >> when things break, they get fixed in a timely manner. >> >> Alpha was removed because it got broken by some changes, and stayed broken >> for a long time despite repeated requests to fix it. Sparc64 is on the >> cusp >> of that: >> some minor things are broken, but have been fixed. The current crisis is >> due to >> the end of life of gcc in the tree and its fallout coupled with some >> neglect of the >> port due to time constraints. >> >> At first I was all for removal. With more data, I'm less sure. If the >> promises are kept >> made in this thread, it looks to remain viable for a while, though the >> lack >> of a >> qemu-user solution means that packages for a slow platform (where they are >> really quite useful) will remain limited. Maybe there's enough hardware >> around >> that third-party pkg repos can fill the gap, maybe not. I think we should >> experiment >> with this model and see what it produces. Give the branching of 11 as the >> deadline >> to show something viable... >> > > One of the things I never understood about FreeBSD's method of maintaining > a port was the way the platform porting was done. We really do things in a > different manner than what my perception of other OSes is. > > My impression (please do correct me if I'm wrong) was that other OSes such > as NetBSD and Linux had "platform maintainers". > > These maintainers were around to: > 1) keep the ship sailing on those platforms > 2) guide the general code base from becoming non-portable to other > architectures (within reason). > 3) drive the release of the architecture in question, helping the release > engineer with image building and release testing. > > For point 1 above, what that meant to me was that let's say Linus or > NetBSD in general wanted to do a major or minor change on a tier 1 > platform, then it was the responsibility of the *platform maintainers* to > do the work on the non tier-1 platforms to keep them up to date. Those > "platform maintainers" kept those ships sailing and in return they got to > be called "the $arch maintainer" which looks plenty good on a resume and > also feels good for those that get excited for status. > I'm not sure how the people that actually take care of these things on FreeBSD differ. There are people recognized as go-to people for the different ports that are fairly active in the on-going issues that come up with kernel code. Userland code doesn't seem to matter that much given the platforms we support. For PowerPC, you have Nathan W and Justin Hibbits. For mips, there's Adrian, myself, Julie Mallet and a few others. For arm there's a long cast of characters. For PC98 there's Takahashi-san. For sparc64 there's Marius. These people keep the ship sailing (or in some cases they remove the ship form the tree). They advise discussions about issues that are relevant to the platform, like cache lines and cache coherence, they call people out when they break these platforms or when people used to big systems adjust the tuning and break small systems. > For point 2, let's say someone had a change that pushed some form of > *completely* non-portable code into the base which would break a reasonable > to support platform, then the "platform maintainer" would speak up and tell > the general community "uh no, you can't do X on this platform, we need to > rethink this". > People generally don't push this kind of code into the tree these days. When they do, they get called out on it. Some of them even listen to the calling out and fix things, others don't and one of the platform maintainers has to fix the stupid pushed into the tree. Sometimes this happens right away and sometimes there's a lag. sometimes it's code for newer versions of the platform that break older versions (or vice versa). Other times there's code from another platform that breaks things. USB is a textbook example of this happening. It went in, and didn't worth a damn on arm or mips. The ports maintainers of the arm and mips platforms tried to explain what the issues were. It took some time, but it got mostly worked out as the embedded folks got to know USB issues, and hps got to understand the issues with embedded hardware. > For point 3, there may be a lag between release of the OS for tier 1 > (x86/x64) and the secondary architectures, but that is OK because the > maintainer will eventually provide images themselves or in collaboration > with the release engineer. > For this point, we've pushed the knowledge of how to build the images into the release engineer. The folks that are around that are using the port test the images. Sometimes it's the port maintainers, but recently it has been a large cast of characters for popular platforms. > FreeBSD seems to take a different approach. This approach is that someone > (or some people) form a team to port to a platform. These "platform > porter" groups sole responsibility is to get a new architecture running. > After it's mostly running they are mostly without responsibility, however > we tend to give them the right of change-set veto in perpetuity of the > marginal relevance of the ported to platform. > so like when did this actually happen? > What this means is that instead of a assigning a title and ownership of > the platform to someone, who maintains the status as "maintainer" by > keeping that platform working. By keeping the platform working I am saying > that they would do items 1, 2 and 3 from the NetBSD/Linux list. However, > instead nearly immediately hoist the "platform maintenance" onto the > general community of people that may not have access to the hardware in > question. > Do you have a specific example of when we've done this? As far as I know, based on powerpc, arm and mips anyway, the people claiming to be maintainers are actively doing 1, 2 and helping RE do number 3 to varying degrees. As far as I know, they all have access to some or all of the hardware they are maintaining, and many of our power users participate in the process as well. > Maybe this is just my perception, but it would seem to make a ton more > sense to follow the NetBSD/Linux model which implies a somewhat decoupled > release model (not all arches must come out on the same ) and assigning > ownership and responsibility in exchange for status based on being the > "platform maintainer". > So, rather than generalizations, be specific. Who do you think is claiming to be a port maintainer, blocking progress and needs to be replaced? And what, beyond what the re@ does today, would you do differently? What do we gain over what we do for tier 1 platforms? Is there a platform wanting a release that isn't getting one? mips has two different groups that have put out releases for it, with one of them fading into the background. Adiran is making wifi builds available, already following this model you say we should adopt. The japanese user groups are putting out PC98 releases now that the re@ has dropped them (they never really stopped in the mean time). sparc64, powerpc, arm, i386 and amd64 are all released by re@. ia64 has been removed from the tree. What other platforms are there? What else needs to be done. > Finally it would be pretty obvious when everyone steps down or just > doesn't participate in the release process that it may be time to sunset a > platform. That's why we are having the conversation about sparc64. It looked like it might no longer be participating in the normal process. Now, while there are some issues that were identified with sparc64, some of them are real (see qemu and difficulties building in the cluster). Some of them were just perception (the reduced numbers of commits to sparc64 didn't seem to represent a problem with the platform and the perceived issues had been cleared up) So what, specific, actionable items do we as a project actually need to do here? I'm sure there are some and that we can improve our process. I'm having trouble teasing out what I, as someone who dabbles in arm and mips to varying degrees of 'maintainership' for different parts, can do better or different. Warner > > -Alfred > From owner-freebsd-sparc64@freebsd.org Tue Nov 17 06:44:04 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CECECA30A25 for ; Tue, 17 Nov 2015 06:44:04 +0000 (UTC) (envelope-from bright@mu.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id ACD59139C for ; Tue, 17 Nov 2015 06:44:04 +0000 (UTC) (envelope-from bright@mu.org) Received: by mailman.ysv.freebsd.org (Postfix) id AC20BA30A23; Tue, 17 Nov 2015 06:44:04 +0000 (UTC) Delivered-To: sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB81FA30A22; Tue, 17 Nov 2015 06:44:04 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2C2139B; Tue, 17 Nov 2015 06:44:04 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8004:7515:6d56:aa8e:b437:27b3]) by elvis.mu.org (Postfix) with ESMTPSA id B6705345A920; Mon, 16 Nov 2015 22:44:03 -0800 (PST) Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Warner Losh References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> <564A889C.9070209@mu.org> Cc: Elizabeth Myers , Anna Wilcox , "Brian McGovern (bmcgover)" , freebsd-arch , Marius Strobl , Sean Bruno , "sparc64@freebsd.org" , Jordan Hubbard From: Alfred Perlstein Message-ID: <564ACCB3.4070603@mu.org> Date: Mon, 16 Nov 2015 22:44:03 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 06:44:04 -0000 Warner, thanks for addressing this email. I think I wasn't clear which lead to some misunderstanding. I'll keep this reply succinct and the rest of it inline. Please don't take the succinctness as anything other than getting to the point. On 11/16/15 10:22 PM, Warner Losh wrote: > > > On Mon, Nov 16, 2015 at 6:53 PM, Alfred Perlstein > wrote: > > > > > On 11/14/15 9:16 AM, Warner Losh wrote: > > On Fri, Nov 13, 2015 at 11:15 PM, Elizabeth Myers > > > wrote: > > You are seriously going to use "we're not NetBSD" as an > argument? > > > You noticed I didn't reply to it. The argument is completely > lame. FreeBSD > runs > today in a variety of markets. Some new, some not so new. The > thing that > makes > each of these areas unique is that there's a thriving > community around them, > FreeBSD still runs well enough on these machines to get > something done, and > when things break, they get fixed in a timely manner. > > Alpha was removed because it got broken by some changes, and > stayed broken > for a long time despite repeated requests to fix it. Sparc64 > is on the cusp > of that: > some minor things are broken, but have been fixed. The current > crisis is > due to > the end of life of gcc in the tree and its fallout coupled > with some > neglect of the > port due to time constraints. > > At first I was all for removal. With more data, I'm less sure. > If the > promises are kept > made in this thread, it looks to remain viable for a while, > though the lack > of a > qemu-user solution means that packages for a slow platform > (where they are > really quite useful) will remain limited. Maybe there's enough > hardware > around > that third-party pkg repos can fill the gap, maybe not. I > think we should > experiment > with this model and see what it produces. Give the branching > of 11 as the > deadline > to show something viable... > > > One of the things I never understood about FreeBSD's method of > maintaining a port was the way the platform porting was done. We > really do things in a different manner than what my perception of > other OSes is. > > My impression (please do correct me if I'm wrong) was that other > OSes such as NetBSD and Linux had "platform maintainers". > > These maintainers were around to: > 1) keep the ship sailing on those platforms > 2) guide the general code base from becoming non-portable to other > architectures (within reason). > 3) drive the release of the architecture in question, helping the > release engineer with image building and release testing. > > For point 1 above, what that meant to me was that let's say Linus > or NetBSD in general wanted to do a major or minor change on a > tier 1 platform, then it was the responsibility of the *platform > maintainers* to do the work on the non tier-1 platforms to keep > them up to date. Those "platform maintainers" kept those ships > sailing and in return they got to be called "the $arch maintainer" > which looks plenty good on a resume and also feels good for those > that get excited for status. > > > I'm not sure how the people that actually take care of these things on > FreeBSD differ. There are people > recognized as go-to people for the different ports that are fairly > active in the on-going issues that come > up with kernel code. Userland code doesn't seem to matter that much > given the platforms we support. > > For PowerPC, you have Nathan W and Justin Hibbits. For mips, there's > Adrian, myself, Julie Mallet and a few > others. For arm there's a long cast of characters. For PC98 there's > Takahashi-san. For sparc64 there's Marius. > These people keep the ship sailing (or in some cases they remove the > ship form the tree). They advise > discussions about issues that are relevant to the platform, like cache > lines and cache coherence, This is how we diverge: > they call people out when they break these platforms or when people > used to big systems adjust the > tuning and break small systems. That is not done as far as I can tell in NetBSD/Linux. In Linux/NetBSD it is the job of the maintainer to keep the platform up to date, not to call out when someone breaks it. Meaning ideal: "Oh someone broke alignment in this struct on my platform, let me ask them how to fix it." As opposed to (not ideal): "Something broke my platform, let me track that guy down and make them fix it." > > For point 2, let's say someone had a change that pushed some form > of *completely* non-portable code into the base which would break > a reasonable to support platform, then the "platform maintainer" > would speak up and tell the general community "uh no, you can't do > X on this platform, we need to rethink this". > > > People generally don't push this kind of code into the tree these > days. When they do, they get called > out on it. Some of them even listen to the calling out and fix things, > others don't and one of the > platform maintainers has to fix the stupid pushed into the tree. > Sometimes this happens right away > and sometimes there's a lag. sometimes it's code for newer versions of > the platform that break older > versions (or vice versa). Other times there's code from another > platform that breaks things. > > USB is a textbook example of this happening. It went in, and didn't > worth a damn on arm or mips. > The ports maintainers of the arm and mips platforms tried to explain > what the issues were. It took > some time, but it got mostly worked out as the embedded folks got to > know USB issues, and hps > got to understand the issues with embedded hardware. > > For point 3, there may be a lag between release of the OS for tier > 1 (x86/x64) and the secondary architectures, but that is OK > because the maintainer will eventually provide images themselves > or in collaboration with the release engineer. > > > For this point, we've pushed the knowledge of how to build the images > into the release engineer. The > folks that are around that are using the port test the images. > Sometimes it's the port maintainers, > but recently it has been a large cast of characters for popular platforms. > > FreeBSD seems to take a different approach. This approach is that > someone (or some people) form a team to port to a platform. These > "platform porter" groups sole responsibility is to get a new > architecture running. After it's mostly running they are mostly > without responsibility, however we tend to give them the right of > change-set veto in perpetuity of the marginal relevance of the > ported to platform. > > > so like when did this actually happen? Well, earlier in this email you said this exact thing: > they call people out when they break these platforms or when people > used to big systems adjust the > tuning and break small systems. That's how I see the difference. > What this means is that instead of a assigning a title and > ownership of the platform to someone, who maintains the status as > "maintainer" by keeping that platform working. By keeping the > platform working I am saying that they would do items 1, 2 and 3 > from the NetBSD/Linux list. However, instead nearly immediately > hoist the "platform maintenance" onto the general community of > people that may not have access to the hardware in question. > > > Do you have a specific example of when we've done this? As far as I > know, based on powerpc, arm and > mips anyway, the people claiming to be maintainers are actively doing > 1, 2 and helping RE do number > 3 to varying degrees. As far as I know, they all have access to some > or all of the hardware they are > maintaining, and many of our power users participate in the process as > well. > Maybe this is just my perception, but it would seem to make a ton > more sense to follow the NetBSD/Linux model which implies a > somewhat decoupled release model (not all arches must come out on > the same ) and assigning ownership and responsibility in exchange > for status based on being the "platform maintainer". > > > So, rather than generalizations, be specific. Who do you think is > claiming to be a port maintainer, blocking > progress and needs to be replaced? > > And what, beyond what the re@ does today, would you do differently? > What do we gain over what we do > for tier 1 platforms? Is there a platform wanting a release that isn't > getting one? mips has two different > groups that have put out releases for it, with one of them fading into > the background. Adiran is making > wifi builds available, already following this model you say we should > adopt. The japanese user groups are > putting out PC98 releases now that the re@ has dropped them (they > never really stopped in the mean > time). sparc64, powerpc, arm, i386 and amd64 are all released by re@. > ia64 has been removed from the > tree. What other platforms are there? What else needs to be done. > > Finally it would be pretty obvious when everyone steps down or > just doesn't participate in the release process that it may be > time to sunset a platform. > > > That's why we are having the conversation about sparc64. It looked > like it might no longer be > participating in the normal process. Now, while there are some issues > that were identified with > sparc64, some of them are real (see qemu and difficulties building in > the cluster). Some of them > were just perception (the reduced numbers of commits to sparc64 didn't > seem to represent > a problem with the platform and the perceived issues had been cleared up) > > So what, specific, actionable items do we as a project actually need > to do here? I'm sure there are some > and that we can improve our process. I'm having trouble teasing out > what I, as someone who dabbles > in arm and mips to varying degrees of 'maintainership' for different > parts, can do better or different. > Three things: 1) I am wondering if core (or the community in general) should have some way of nominating a particular person as a platform maintainer. This would give accolades to that person and at the same time give us a point person. I believe part of the problem is that we don't give enough status to the port maintainers, are they on the website? How would I know who is the "king of mips" right now? Does someone get to put in on their resume with backing from the project? If not, then the maintainer will be grumbly as opposed to facilitating. 2) The role of platform maintainer needs not to be a blocking role, but rather a continual porting role. Specifically to avoid the "calling out" (sorry for the quotes here, but just want to get the point across) and instead function as a do-er/facilitator. Meaning if something breaks a secondary platform it's a shared responsibility of the port maintainer and developer to fix it, but solely the developer. 3) Tight coupling of the system. While it's good to cross train release engineering with various platforms and even more so it's REALLY great that this is being well received, the end result is a very tight coupling of the system that can lead to frustrations and logjams when things go wrong. Something that FreeBSD very often gets wrong is the strong unification of its various parts, you can see this in so many aspects of how we do things (releases, VFS, platforms) as opposed to other projects. It is an admirable aspiration, however it results in much lock-step of the entire project and doesn't scale. -Alfred From owner-freebsd-sparc64@freebsd.org Tue Nov 17 07:06:39 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE26EA30F40 for ; Tue, 17 Nov 2015 07:06:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 852AE1BF0 for ; Tue, 17 Nov 2015 07:06:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 81C8EA30F3C; Tue, 17 Nov 2015 07:06:39 +0000 (UTC) Delivered-To: sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6776CA30F38 for ; Tue, 17 Nov 2015 07:06:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 101271BEE for ; Tue, 17 Nov 2015 07:06:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by igbxm8 with SMTP id xm8so7124956igb.1 for ; Mon, 16 Nov 2015 23:06:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=ByHKHu4ejnDY1O0kwAh5PZO3+2EgV/haiaUFcVzB3p0=; b=JHMb8M3XjTG+4cix5rtMA553eFRh6nkKchok7qb3j68cUcsNbjRJTVWv2YMZtWJbzi rc8NxdUHq3tIdQEO1UZMvT1g+F63auRpN2DVgzPIwoV5+5oa2DmrHTB8+W8HzCxweLY3 m9VQvRVYeQHdWf1deFJlE2cEvNfXDAJGfLHRGWf0Y7qqhmlzkUcKr3QqyE9jmGgJWpXj QERTdovhKyhKurVpE9luOEi+n+Z2FCZhbESV6FRWasShMfJ7fMqg/4E1ehP9gYZS9RYO VkKSwx/uIJGdbgMZZ/jLSycrZV4U/TeuNJHqscR4V/+Q1jlwFF3NPFahNjW9wOofsx26 GPSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=ByHKHu4ejnDY1O0kwAh5PZO3+2EgV/haiaUFcVzB3p0=; b=TvC2EwWC0Bl3RvjPTxGVXXGbtBVQ6H2McSCIFaGtEzoVDpN/4wU26s/dAlZXtAva2v oxXTQOxcoiMByQ0m7Jm9l86Wvv+Xu/YGzaR1IaqT6/Bi5Y8Nlw9W5R0ON+LJT5XzOsZE 8DjY8/yyFquAlVbtFsJLcemUhIk9lH89G94sRs1ZM9dM9aB5YmTSp4CZJgwcY/AqdE4+ HbiLRiPvMCQswDVnxIRVoreSUgN3B9ig1lGwGT2XPTVfsCJ1Pa8ecz2+7ZjHa4ikI1xr mb0y0V4aE6wEhIEhdxtgNzeY3k2EZN2nf0FP3qZYUAzYPlUnbx5PrtICG/vlGZ7eJAoQ eqxQ== X-Gm-Message-State: ALoCoQkjxC8QsYhh9QtfILMxChG7dhq8utpr/YR9kJt8+fVUQRat2cw1wcnUJMuQmBUe4nPItD5Q X-Received: by 10.50.59.211 with SMTP id b19mr399558igr.36.1447743998038; Mon, 16 Nov 2015 23:06:38 -0800 (PST) Received: from ?IPv6:2601:280:4900:3700:a49c:fa0f:af5a:6678? ([2601:280:4900:3700:a49c:fa0f:af5a:6678]) by smtp.gmail.com with ESMTPSA id ht2sm7658521igb.22.2015.11.16.23.06.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Nov 2015 23:06:37 -0800 (PST) Sender: Warner Losh Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FA5B2277-28B9-4431-A79E-40E7FA0627D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <564ACCB3.4070603@mu.org> Date: Tue, 17 Nov 2015 00:06:35 -0700 Cc: Elizabeth Myers , Anna Wilcox , "Brian McGovern (bmcgover)" , freebsd-arch , Marius Strobl , Sean Bruno , "sparc64@freebsd.org" , Jordan Hubbard Message-Id: References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> <564A889C.9070209@mu.org> <564ACCB3.4070603@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 07:06:39 -0000 --Apple-Mail=_FA5B2277-28B9-4431-A79E-40E7FA0627D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 16, 2015, at 11:44 PM, Alfred Perlstein wrote: >=20 > Warner, thanks for addressing this email. I think I wasn't clear = which lead to some misunderstanding. I'll keep this reply succinct and = the rest of it inline. Please don't take the succinctness as anything = other than getting to the point. >=20 > On 11/16/15 10:22 PM, Warner Losh wrote: >>=20 >>=20 >> On Mon, Nov 16, 2015 at 6:53 PM, Alfred Perlstein = wrote: >>=20 >>=20 >>=20 >> On 11/14/15 9:16 AM, Warner Losh wrote: >> On Fri, Nov 13, 2015 at 11:15 PM, Elizabeth Myers = >> wrote: >>=20 >> You are seriously going to use "we're not NetBSD" as an argument? >>=20 >> You noticed I didn't reply to it. The argument is completely lame. = FreeBSD >> runs >> today in a variety of markets. Some new, some not so new. The thing = that >> makes >> each of these areas unique is that there's a thriving community = around them, >> FreeBSD still runs well enough on these machines to get something = done, and >> when things break, they get fixed in a timely manner. >>=20 >> Alpha was removed because it got broken by some changes, and stayed = broken >> for a long time despite repeated requests to fix it. Sparc64 is on = the cusp >> of that: >> some minor things are broken, but have been fixed. The current crisis = is >> due to >> the end of life of gcc in the tree and its fallout coupled with some >> neglect of the >> port due to time constraints. >>=20 >> At first I was all for removal. With more data, I'm less sure. If the >> promises are kept >> made in this thread, it looks to remain viable for a while, though = the lack >> of a >> qemu-user solution means that packages for a slow platform (where = they are >> really quite useful) will remain limited. Maybe there's enough = hardware >> around >> that third-party pkg repos can fill the gap, maybe not. I think we = should >> experiment >> with this model and see what it produces. Give the branching of 11 as = the >> deadline >> to show something viable... >>=20 >> One of the things I never understood about FreeBSD's method of = maintaining a port was the way the platform porting was done. We really = do things in a different manner than what my perception of other OSes = is. >>=20 >> My impression (please do correct me if I'm wrong) was that other OSes = such as NetBSD and Linux had "platform maintainers". >>=20 >> These maintainers were around to: >> 1) keep the ship sailing on those platforms >> 2) guide the general code base from becoming non-portable to other = architectures (within reason). >> 3) drive the release of the architecture in question, helping the = release engineer with image building and release testing. >>=20 >> For point 1 above, what that meant to me was that let's say Linus or = NetBSD in general wanted to do a major or minor change on a tier 1 = platform, then it was the responsibility of the *platform maintainers* = to do the work on the non tier-1 platforms to keep them up to date. = Those "platform maintainers" kept those ships sailing and in return they = got to be called "the $arch maintainer" which looks plenty good on a = resume and also feels good for those that get excited for status. >>=20 >> I'm not sure how the people that actually take care of these things = on FreeBSD differ. There are people >> recognized as go-to people for the different ports that are fairly = active in the on-going issues that come >> up with kernel code. Userland code doesn't seem to matter that much = given the platforms we support. >>=20 >> For PowerPC, you have Nathan W and Justin Hibbits. For mips, there's = Adrian, myself, Julie Mallet and a few >> others. For arm there's a long cast of characters. For PC98 there's = Takahashi-san. For sparc64 there's Marius. >> These people keep the ship sailing (or in some cases they remove the = ship form the tree). They advise >> discussions about issues that are relevant to the platform, like = cache lines and cache coherence, >=20 > This is how we diverge: >> they call people out when they break these platforms or when people = used to big systems adjust the >> tuning and break small systems. > That is not done as far as I can tell in NetBSD/Linux. In = Linux/NetBSD it is the job of the maintainer to keep the platform up to = date, not to call out when someone breaks it. >=20 > Meaning ideal: > "Oh someone broke alignment in this struct on my platform, let me ask = them how to fix it." >=20 > As opposed to (not ideal): > "Something broke my platform, let me track that guy down and make them = fix it.=E2=80=9D The person that broke it is often the best person to fix it. If they = don=E2=80=99t fix it themselves the maintainers fix it for them. It=E2=80=99s common courtesy. I think = you=E2=80=99re making too fine a distinction here to actually be useful. And if you know anything about NetBSD, you=E2=80=99ll know they do = exactly the same thing when someone does something that breaks a particular platform. The port = maintainers, who build and run the stuff the most (though they aren=E2=80=99t listed = in any file) notice and complain, often times within hours of the commit. They generally ask the = original committer to fix it, just like we do. And just like we do, those = suggestions sometimes come in the form of a patch or a general description of what to do and = why. Tell me, who are the NetBSD/hpcmips maintainers? Who are the = NetBSD/hpcarm folks that are still active? I just did a search, and couldn=E2=80=99t = find this information. You could look at the hpcmips or hpcarm trees, but they are rather quiet = these last few years, and many of the folks that contributed code there have = wandered off. >>=20 >> For point 2, let's say someone had a change that pushed some form of = *completely* non-portable code into the base which would break a = reasonable to support platform, then the "platform maintainer" would = speak up and tell the general community "uh no, you can't do X on this = platform, we need to rethink this". >>=20 >> People generally don't push this kind of code into the tree these = days. When they do, they get called >> out on it. Some of them even listen to the calling out and fix = things, others don't and one of the >> platform maintainers has to fix the stupid pushed into the tree. = Sometimes this happens right away >> and sometimes there's a lag. sometimes it's code for newer versions = of the platform that break older >> versions (or vice versa). Other times there's code from another = platform that breaks things. >>=20 >> USB is a textbook example of this happening. It went in, and didn't = worth a damn on arm or mips. >> The ports maintainers of the arm and mips platforms tried to explain = what the issues were. It took >> some time, but it got mostly worked out as the embedded folks got to = know USB issues, and hps >> got to understand the issues with embedded hardware. >>=20 >> For point 3, there may be a lag between release of the OS for tier 1 = (x86/x64) and the secondary architectures, but that is OK because the = maintainer will eventually provide images themselves or in collaboration = with the release engineer. >>=20 >> For this point, we've pushed the knowledge of how to build the images = into the release engineer. The >> folks that are around that are using the port test the images. = Sometimes it's the port maintainers, >> but recently it has been a large cast of characters for popular = platforms. >>=20 >> FreeBSD seems to take a different approach. This approach is that = someone (or some people) form a team to port to a platform. These = "platform porter" groups sole responsibility is to get a new = architecture running. After it's mostly running they are mostly without = responsibility, however we tend to give them the right of change-set = veto in perpetuity of the marginal relevance of the ported to platform. >>=20 >> so like when did this actually happen? > Well, earlier in this email you said this exact thing: >=20 >> they call people out when they break these platforms or when people = used to big systems adjust the >> tuning and break small systems. > That's how I see the difference. First step is always education. That=E2=80=99s a strength, not a = weakness. You educate people that break things because more often than not, those people didn=E2=80=99t bother to ask = for a review. Part of the education is needing to make sure people social changes appropriately. If that=E2=80=99s *ALL* maintainers did, I=E2=80=99d agree with you. = However, there=E2=80=99s much proactive education that also happens, which is exactly your number 2: everybody working together to = make sure that new changes fit will with the platform set. That is real. It happens every day. = Focusing on only one, narrow situation that happens maybe once a month and saying we=E2=80=99re doing that = wrong seems petty and wrong-headed and would actually break more than it fixes if we changed it. So because you have a world view that doesn=E2=80=99t match what=E2=80=99s= going on, you want to change what=E2=80=99s going on to match some ideal from another project when this project is = actually doing that idea? I still don=E2=80=99t get it. >=20 >>=20 >> What this means is that instead of a assigning a title and ownership = of the platform to someone, who maintains the status as "maintainer" by = keeping that platform working. By keeping the platform working I am = saying that they would do items 1, 2 and 3 from the NetBSD/Linux list. = However, instead nearly immediately hoist the "platform maintenance" = onto the general community of people that may not have access to the = hardware in question. >>=20 >> Do you have a specific example of when we've done this? As far as I = know, based on powerpc, arm and >> mips anyway, the people claiming to be maintainers are actively doing = 1, 2 and helping RE do number >> 3 to varying degrees. As far as I know, they all have access to some = or all of the hardware they are >> maintaining, and many of our power users participate in the process = as well. >=20 >>=20 >> Maybe this is just my perception, but it would seem to make a ton = more sense to follow the NetBSD/Linux model which implies a somewhat = decoupled release model (not all arches must come out on the same ) and = assigning ownership and responsibility in exchange for status based on = being the "platform maintainer". >>=20 >> So, rather than generalizations, be specific. Who do you think is = claiming to be a port maintainer, blocking >> progress and needs to be replaced? >>=20 >> And what, beyond what the re@ does today, would you do differently? = What do we gain over what we do >> for tier 1 platforms? Is there a platform wanting a release that = isn't getting one? mips has two different >> groups that have put out releases for it, with one of them fading = into the background. Adiran is making >> wifi builds available, already following this model you say we should = adopt. The japanese user groups are >> putting out PC98 releases now that the re@ has dropped them (they = never really stopped in the mean >> time). sparc64, powerpc, arm, i386 and amd64 are all released by re@. = ia64 has been removed from the >> tree. What other platforms are there? What else needs to be done. >>=20 >> Finally it would be pretty obvious when everyone steps down or just = doesn't participate in the release process that it may be time to sunset = a platform. >>=20 >> That's why we are having the conversation about sparc64. It looked = like it might no longer be >> participating in the normal process. Now, while there are some issues = that were identified with >> sparc64, some of them are real (see qemu and difficulties building in = the cluster). Some of them >> were just perception (the reduced numbers of commits to sparc64 = didn't seem to represent >> a problem with the platform and the perceived issues had been cleared = up) >>=20 >> So what, specific, actionable items do we as a project actually need = to do here? I'm sure there are some >> and that we can improve our process. I'm having trouble teasing out = what I, as someone who dabbles >> in arm and mips to varying degrees of 'maintainership' for different = parts, can do better or different. >>=20 > Three things: > 1) I am wondering if core (or the community in general) should have = some way of nominating a particular person as a platform maintainer. = This would give accolades to that person and at the same time give us a = point person. I believe part of the problem is that we don't give = enough status to the port maintainers, are they on the website? How = would I know who is the "king of mips" right now? Does someone get to = put in on their resume with backing from the project? If not, then the = maintainer will be grumbly as opposed to facilitating. We don=E2=80=99t have a =E2=80=9Cking of the kernel=E2=80=9D or =E2=80=9Ck= ing of mips=E2=80=9D or anything like that. We document that you send = mail to mips@ when you don=E2=80=99t know the right person to send. As for status reports: I agree with you on that. As for putting things on one=E2=80=99s resume: I never needed the = project=E2=80=99s blessing to claim to have done a lot with = FreeBSD/mips, FreeBSD/arm, CardBus, PC Card, SD, MMC, PCI, etc. I just = did it. The lack of a stamp from the project hasn=E2=80=99t really been an issue. > 2) The role of platform maintainer needs not to be a blocking role, = but rather a continual porting role. Specifically to avoid the "calling = out" (sorry for the quotes here, but just want to get the point across) = and instead function as a do-er/facilitator. Meaning if something = breaks a secondary platform it's a shared responsibility of the port = maintainer and developer to fix it, but solely the developer. To the best of my knowledge, it isn=E2=80=99t a blocking role today. All = the people working on arm, mips and powerpc that I interact with already do that. Rather than fix the stupid mistake = people make, educating them not to make them again in the future is the best way to keep them from repeating. That = sure as hell sounds like a shared responsibility to me. I fail to see any evidence to support your assertion that port = maintainers just whine when things break. I don=E2=80=99t see that in the commit logs (although they are full of hundreds of = commits from people that do complain). I don=E2=80=99t see that in the interactions I=E2=80=99ve had. > 3) Tight coupling of the system. While it's good to cross train = release engineering with various platforms and even more so it's = REALLY great that this is being well received, the end result is a very = tight coupling of the system that can lead to frustrations and logjams = when things go wrong. Something that FreeBSD very often gets wrong is = the strong unification of its various parts, you can see this in so many = aspects of how we do things (releases, VFS, platforms) as opposed to = other projects. It is an admirable aspiration, however it results in = much lock-step of the entire project and doesn't scale. I can=E2=80=99t recall any release ever being held up for longer than it = takes to build on the slowest hardware the RE has used to cut the release. I can recall many times a release wasn=E2=80=99t = held, or I wasn=E2=80=99t allowed to put changes into a secondary platform because they might affect the primary one too close = to a release. Absent any evidence of when, where and how these things happen, I=E2=80=99m having a hard time = seeing that the actual situation on the ground matches the supposed one you are complaining about, at least as it comes = to other platforms. What logjams are they causing? I=E2=80=99ve not seen any. Do you have specific examples? Warner --Apple-Mail=_FA5B2277-28B9-4431-A79E-40E7FA0627D3 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 - https://gpgtools.org iQIcBAEBCgAGBQJWStH7AAoJEGwc0Sh9sBEAtKUQAMc5aDF/jmGZfV3/wwvQWdrD Kv34ABnKF2i2kpvW7ADWrLuetZ/JFmrKOX8Szru9JGDHF/Rd63vXxJuLjv5bX/5n sawlGo4MhNczAeqg2xmYUT2KXkNi9qTnX7DgNb960iLg7VM65PiTX2yj/CXoYGss Kc3b4AyCyv4TG3PYyHZj1WtIOdlNV/TVuCT1fcRitufItI4RbkkxKul4HuCZqN9u PNeh1eQ50gbJIEissRgLTLJKwhaeLs0Iqma6nGFbFUnTfeelCu+cgyhHjg6t4jQn wJaqzuEVIyIlhFhnO1z9NzmB0tezqiGfrPW7fgCAV2oiNPSWp5vhLiztpRK9DBRf oyhr2EHbZBuPnvhX7e5G869QkrAgLUAr0wARC+/KIjN+3cg2Vq2bS+NupiRTc9wc Qnq4OFt7Znkll+uMjuYtuNbLhY894WJ81dh8mUUbOItjkyOcExgzYnhIoRbacsU3 VQTsCfVW+UU/KVhwua/9OrxkF/n0GEq3lyjsbEt0fjDICltiWsuWCCISrZJS/RR/ gUPPbDrUjIsUSl/F7glr+iIVgJhMwnQGGia+SZ6tiA4uxKZWAMCx7tZ5a254UQfc 4O2fMyLsvexKDURCOvZcxu/TURVJ0THccq8/j4DpUdFoFqQCsstdtlbn4/KAtGix 14dWVaouwbiWgBjhJ9+E =GPrS -----END PGP SIGNATURE----- --Apple-Mail=_FA5B2277-28B9-4431-A79E-40E7FA0627D3-- From owner-freebsd-sparc64@freebsd.org Tue Nov 17 09:35:37 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F5FFA30BF7 for ; Tue, 17 Nov 2015 09:35:37 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E8EBC1C94 for ; Tue, 17 Nov 2015 09:35:36 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mailman.ysv.freebsd.org (Postfix) id E78D1A30BF1; Tue, 17 Nov 2015 09:35:36 +0000 (UTC) Delivered-To: sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6023A30BEF; Tue, 17 Nov 2015 09:35:36 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [66.135.54.68]) by mx1.freebsd.org (Postfix) with ESMTP id C33AB1C92; Tue, 17 Nov 2015 09:35:36 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id F1BF25607A; Tue, 17 Nov 2015 03:27:03 -0600 (CST) Date: Tue, 17 Nov 2015 03:27:03 -0600 From: Mark Linimon To: Warner Losh Cc: Alfred Perlstein , Anna Wilcox , "Brian McGovern (bmcgover)" , Marius Strobl , Sean Bruno , "sparc64@freebsd.org" , freebsd-arch , Jordan Hubbard , Elizabeth Myers Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 Message-ID: <20151117092703.GA30582@lonesome.com> References: <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> <564A889C.9070209@mu.org> <564ACCB3.4070603@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Tue, 17 Nov 2015 12:20:25 +0000 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 09:35:37 -0000 On Tue, Nov 17, 2015 at 12:06:35AM -0700, Warner Losh wrote: > We don’t have a “king of the kernel” or “king of mips” or anything > like that. We document that you send mail to mips@ when you don’t > know the right person to send. And I don't see why we should. What would we gain from this administrative overhead? What we lose is: dealing with people who have the title not doing work, or people not having the title, doing the work, being irritated by not having the title. svn can, with a little effort, demonstrate who is looking after what. All I see is cost and no benefit. This isn't an "org chart" kind of issue IMHO. In FreeBSD, why delegate responsibility to anyone other than those who take it by their own initiative? mcl From owner-freebsd-sparc64@freebsd.org Tue Nov 17 12:52:09 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B30DA3104B for ; Tue, 17 Nov 2015 12:52:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 126711875 for ; Tue, 17 Nov 2015 12:52:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAHCq8Ad097177 for ; Tue, 17 Nov 2015 12:52:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-sparc64@FreeBSD.org Subject: [Bug 204527] security/openssl 1.0.2, when compiled WITH_ASM on sparc64 generates illegal instructions Date: Tue, 17 Nov 2015 12:52:09 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dinoex@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback+ merge-quarterly? X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 12:52:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204527 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|maintainer-feedback- |maintainer-feedback+ -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-sparc64@freebsd.org Tue Nov 17 12:52:43 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99BAAA3108A for ; Tue, 17 Nov 2015 12:52:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 84B7418E7 for ; Tue, 17 Nov 2015 12:52:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tAHCqh7D097827 for ; Tue, 17 Nov 2015 12:52:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-sparc64@FreeBSD.org Subject: [Bug 204527] security/openssl: 1.0.2 generates illegal instructions when compiled WITH_ASM on sparc64 Date: Tue, 17 Nov 2015 12:52:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dinoex@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback+ merge-quarterly? X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 12:52:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204527 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|security/openssl 1.0.2, |security/openssl: 1.0.2 |when compiled WITH_ASM on |generates illegal |sparc64 generates illegal |instructions when compiled |instructions |WITH_ASM on sparc64 -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-sparc64@freebsd.org Tue Nov 17 16:44:14 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D03DA31C3A for ; Tue, 17 Nov 2015 16:44:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 158891D55; Tue, 17 Nov 2015 16:44:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcph11 with SMTP id ph11so82836470igc.1; Tue, 17 Nov 2015 08:44:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8kIe+rUZ7UL7GCesg2u3MMNIxdNI+6Jsh6D+xkJdtGw=; b=NcPFKHgVvfLyRfm+ZT8sgrOK88F8oX2tM/9uMrJ5aDB8RUlQpDwdIiUTOVY6+4l0bG p5310hbzmDeL+7Kt0kOf4pthjsKzaH0GuYA7fE6G4UgA66Vc4klfvvjhy6pgzRLx2kFC JJQgrTArny1x5VuJSKKCpGesSUlvw0Q5LOaiWr1MdhpTaxFQsXIXJaEYCU3E0n+LnvGZ +xu8cHRugPt1JHf6EiwRWZZ38U2IjHm4G0jin8+vdJ7KF8t3ajBSXOEoLehnTeYxvejj hdJ2a9JSNKYBo/yYBBxEGzrKLY6RTMYy8x7aIhUWehAm/h4Cgu0WHZHI6VLZ1xKw/p2J BEvA== MIME-Version: 1.0 X-Received: by 10.50.6.36 with SMTP id x4mr2718885igx.61.1447778653503; Tue, 17 Nov 2015 08:44:13 -0800 (PST) Received: by 10.36.217.196 with HTTP; Tue, 17 Nov 2015 08:44:13 -0800 (PST) In-Reply-To: <56462A41.4030707@ilande.co.uk> References: <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> <20150917082817.GA71811@FreeBSD.org> <55FBB662.4080708@ilande.co.uk> <20150919211420.GK18789@alchemy.franken.de> <55FDEA3C.1010804@ilande.co.uk> <20150920043630.GA36162@FreeBSD.org> <20150922221404.GA81100@alchemy.franken.de> <563F8722.9050503@ilande.co.uk> <56462A41.4030707@ilande.co.uk> Date: Tue, 17 Nov 2015 08:44:13 -0800 Message-ID: Subject: Re: PCI range checking under qemu-system-sparc64 From: Adrian Chadd To: Mark Cave-Ayland Cc: Marius Strobl , Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 16:44:14 -0000 Hi so at this point it's just hanging, right? You can break into the debugger, but that's it? What do I do to get freebsd-head sparc64 to this point myself? :) thanks, -adrian On 13 November 2015 at 10:21, Mark Cave-Ayland wrote: > On 08/11/15 17:32, Mark Cave-Ayland wrote: > >> I now have a small patchset for QEMU git master that fixes the timer >> issues (as well as implementing the NPT bit properly) and it gets to the >> same point as you did above, so that's progress :) >> >> QEMU is currently in freeze in preparation for the next release, so >> while the timer work won't be there for 2.5 in the meantime I shall tidy >> them up and push to github. I should add that the ebus enumeration >> patches related to the device tree properties (minus the addition of the >> keyboard device that crashes Linux) are already upstream and will appear >> in 2.5. > > FYI I've just posted my patches for upstream review at > https://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg03359.html > for the adventurous/foolhardy ;) > > With the patches applied to QEMU git master I now see the same > corruption that you did: > > > $ ./qemu-system-sparc64 -cdrom sparc64.iso -boot d -nographic > OpenBIOS for Sparc64 > Configuration device id QEMU version 1 machine id 0 > kernel cmdline > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.1 built on Oct 27 2015 23:43 > Type 'help' for detailed information > Trying cdrom:f... > Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > > Jumping to entry point 0000000000004000 for type 0000000000000005... > switching to new context: entry point 0x4000 stack 0x00000000ffe8aa09 > >>> FreeBSD/sparc64 boot block > Boot path: /pci@1fe,0/pci-ata@5/ide1@8200/cdrom@0:f > Boot loader: /boot/loader > Consoles: Open Firmware console > > FreeBSD/sparc64 bootstrap loader, Revision 1.0 > (mca@freebsd, Thu Sep 24 00:27:19 BST 2015) > bootpath="/pci@1fe,0/pci-ata@5/ide1@8200/cdrom@0:a" > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0xd893c0+0x20ffd8 syms=[0x8+0xdc578+0x8+0xcb349] > \ > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > jumping to kernel entry at 0xc00b0000. > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2015 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #0 1eb7424(master): Thu Sep 24 06:41:18 BST 2015 > > mca@freebsd:/usr/home/mca/obj/sparc64.sparc64/usr/home/mca/src/sys/GENERIC > sparc64 > gcc version 4.2.1 20070831 patched [FreeBSD] > WARNING: WITNESS option enabled, expect reduced performance. > VT: init without driver. > real memory = 134217728 (128 MB) > avail memory = 98312192 (93 MB) > cpu0: Sun Microsystems UltraSparc-IIi Processor (100.00 MHz CPU) > random: entropy device external interface > kbd0 at kbdmux0 > nexus0: > nexus0: : incomplete > pcib0: mem 0x1fe00000000-0x1fe01ffffff irq > 2032,2030,2031,2021 on nexus0 > pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 33MHz > pcib0: DVMA map: 0xc0000000 to 0xc3ffffff 8192 entries > pcib0: [GIANT-LOCKED] > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pcib2: at device 1.1 on pci0 > pci2: on pcib2 > ebus0: port 0x4000-0x7fff mem 0x3000000-0x3ffffff at > device 3.0 on pci0 > vgapci0: mem > 0x1000000-0x1ffffff,0x2000000-0x2000fff at device 2.0 on pci0 > vgapci0: Boot video device > eeprom0: addr 0x1400002000-0x1400003fff on ebus0 > eeprom0: model mk48t59 > ebus0: addr 0 (no driver attached) > uart0: <16550 or compatible> addr 0x14000003f8-0x14000003ff irq 43 on ebus0 > uart0: console (9600,n,8,1) > ebus0: addr 0x1400000060-0x1400000067 (no driver attached) > pci0: at device 4.0 (no driver attached) > atapci0: port > 0x8100-0x8107,0x8180-0x8183,0x8200-0x8207,0x8280-0x8283,0x8300-0x830f at > device 5.0 on pci0 > ata2: at channel 0 on atapci0 > ata3: at channel 1 on atapci0 > cryptosoft0: on nexus0 > nexus0: type unknown (no driver attached) > Timecounter "tick" frequency 100000000 Hz quality 1000 > Event timer "tick" frequency 100000000 Hz quality 1000 > Timecounters tick every 1.000 msec > IPsec: Initialized Security Association Processing. > cd0 at ata3 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: Serial Number QM00003 > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: cd present [250560 x 2048 byte records] > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from cd9660:/dev/iso9660/TEST [ro]... > [ thread pid 17 tid 100035 ] > Stopped at tl1_trap+0x24: stx %o0, [%sp + 0x997] > db> > > > > > ATB, > > Mark. > > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" From owner-freebsd-sparc64@freebsd.org Tue Nov 17 20:57:53 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDFF6A3178D for ; Tue, 17 Nov 2015 20:57:53 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 764151CF8; Tue, 17 Nov 2015 20:57:52 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from host31-50-169-61.range31-50.btcentralplus.com ([31.50.169.61] helo=[192.168.1.65]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZynJv-0005TG-5T; Tue, 17 Nov 2015 20:57:44 +0000 Message-ID: <564B94A9.70003@ilande.co.uk> Date: Tue, 17 Nov 2015 20:57:13 +0000 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Adrian Chadd CC: Marius Strobl , Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" References: <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> <20150917082817.GA71811@FreeBSD.org> <55FBB662.4080708@ilande.co.uk> <20150919211420.GK18789@alchemy.franken.de> <55FDEA3C.1010804@ilande.co.uk> <20150920043630.GA36162@FreeBSD.org> <20150922221404.GA81100@alchemy.franken.de> <563F8722.9050503@ilande.co.uk> <56462A41.4030707@ilande.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 31.50.169.61 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on s16892447.onlinehome-server.info X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=ham version=3.3.2 Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: Yes (on s16892447.onlinehome-server.info) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 20:57:53 -0000 On 17/11/15 16:44, Adrian Chadd wrote: > Hi > > so at this point it's just hanging, right? You can break into the > debugger, but that's it? Well it traps into the debugger by itself, but the debugger seems operable so it should be easy enough for someone with a bit of kernel knowledge to add some strategic breakpoints to an unstripped kernel at figure out at what point it starts to go wrong... > What do I do to get freebsd-head sparc64 to this point myself? :) I've just pushed the branch to https://github.com/mcayland/qemu.git (branch freebsd-sparc64) if you're interested to take a look. I normally cross-build a -CURRENT ISO with debug enabled and then boot QEMU with the ISO like this: ./qemu-system-sparc64 -cdrom freebsd.iso -boot d -nographic ATB, Mark. From owner-freebsd-sparc64@freebsd.org Tue Nov 17 23:13:00 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADA54A31622 for ; Tue, 17 Nov 2015 23:13:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77E2F12D8; Tue, 17 Nov 2015 23:13:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbxm8 with SMTP id xm8so25800581igb.1; Tue, 17 Nov 2015 15:12:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mg/NtWaq7i2rxvqdKWMig0l/imvTLcDFUePES6geIcA=; b=rGezArvNX7MLbeakdt2XtwDwXOe4iQRsz3/m3fLz6o6TVjtPKqzbCrdyBU7P7BMYDs d9Q0oUuygC6PvzOPADkdu7uGM4yYfvl2A1wkFydspJgyEtOHtqHyWdEFsnyCzg8aTkU8 Vk9MgVmyvzwBskPypyU0cAcXLpumqZXzdPWKU3VPjORs5jHBWTpUO8hb3PIYuB4uf3Iz uhJlAEUUYhmHbq/8G39/7I1L9vcGPB2861CHt0gnu6EwKdpmcNVAsewV5ZcDut7uDtg8 SF3eoz/zKgkzaM65mURqVr8icogNeMROBOV39FsSoYRNbVO3yLmM6kBZHvWK2qJABkbE waZA== MIME-Version: 1.0 X-Received: by 10.50.62.104 with SMTP id x8mr105699igr.22.1447801979769; Tue, 17 Nov 2015 15:12:59 -0800 (PST) Received: by 10.36.217.196 with HTTP; Tue, 17 Nov 2015 15:12:59 -0800 (PST) In-Reply-To: <564B94A9.70003@ilande.co.uk> References: <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> <20150917082817.GA71811@FreeBSD.org> <55FBB662.4080708@ilande.co.uk> <20150919211420.GK18789@alchemy.franken.de> <55FDEA3C.1010804@ilande.co.uk> <20150920043630.GA36162@FreeBSD.org> <20150922221404.GA81100@alchemy.franken.de> <563F8722.9050503@ilande.co.uk> <56462A41.4030707@ilande.co.uk> <564B94A9.70003@ilande.co.uk> Date: Tue, 17 Nov 2015 15:12:59 -0800 Message-ID: Subject: Re: PCI range checking under qemu-system-sparc64 From: Adrian Chadd To: Mark Cave-Ayland Cc: Marius Strobl , Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 23:13:00 -0000 cool, thanks! can you do "show registers" and "bt" there? Do we know what's going on? -a From owner-freebsd-sparc64@freebsd.org Wed Nov 18 00:20:40 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5C36A323E5 for ; Wed, 18 Nov 2015 00:20:40 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 783211B23; Wed, 18 Nov 2015 00:20:40 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from host31-50-169-61.range31-50.btcentralplus.com ([31.50.169.61] helo=[192.168.1.65]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZyqUG-0006DM-Ty; Wed, 18 Nov 2015 00:20:37 +0000 Message-ID: <564BC437.4020909@ilande.co.uk> Date: Wed, 18 Nov 2015 00:20:07 +0000 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Adrian Chadd CC: Marius Strobl , Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" References: <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de> <20150917082817.GA71811@FreeBSD.org> <55FBB662.4080708@ilande.co.uk> <20150919211420.GK18789@alchemy.franken.de> <55FDEA3C.1010804@ilande.co.uk> <20150920043630.GA36162@FreeBSD.org> <20150922221404.GA81100@alchemy.franken.de> <563F8722.9050503@ilande.co.uk> <56462A41.4030707@ilande.co.uk> <564B94A9.70003@ilande.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 31.50.169.61 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on s16892447.onlinehome-server.info X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: Yes (on s16892447.onlinehome-server.info) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 00:20:41 -0000 On 17/11/15 23:12, Adrian Chadd wrote: > cool, thanks! > > can you do "show registers" and "bt" there? Do we know what's going on? WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from cd9660:/dev/iso9660/TEST [ro]... [ thread pid 1 tid 100002 ] Stopped at tl1_trap+0x24: stx %o0, [%sp + 0x997] db> show registers g0 0xfffff800015e84d0 g1 0xc0c8ab38 g2 0xc0c8a800 g3 0x1 g4 0xfffff800015efb80 g5 0x2d7400 g6 0xc3a6d980 g7 0xc0f791d0 pcpu0+0x1800 i0 0x11 pcpup+0xa i1 0x1 i2 0 i3 0 i4 0 i5 0 i6 0 i7 0x101264 tnpc 0xc00b0fe8 tl1_trap+0x28 tpc 0xc00b0fe4 tl1_trap+0x24 tstate 0x9958001507 tl1_trap+0x24: stx %o0, [%sp + 0x997] db> bt Tracing pid 1 tid 100002 td 0xfffff800015e84d0 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc05743e0 -- sched_clock() at sched_clock+0x94 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- panic: longjmp botch cpuid = -1012475520 KDB: stack backtrace: Uptime: 22s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. Definitely looks like the stack is corrupted here. ATB, Mark. From owner-freebsd-sparc64@freebsd.org Thu Nov 19 21:46:52 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35DD5A332E2 for ; Thu, 19 Nov 2015 21:46:52 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9BC1585 for ; Thu, 19 Nov 2015 21:46:52 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0BD59A332E0; Thu, 19 Nov 2015 21:46:52 +0000 (UTC) Delivered-To: sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A2B1A332DF; Thu, 19 Nov 2015 21:46:52 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-yk0-x244.google.com (mail-yk0-x244.google.com [IPv6:2607:f8b0:4002:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE4151584; Thu, 19 Nov 2015 21:46:51 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by ykay124 with SMTP id y124so10460745yka.1; Thu, 19 Nov 2015 13:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SSJr9N6hq7Yewpo2UKh8aO11czqq6LSHUQ7o/OcIcJQ=; b=My6fObmneB46Jc5JgvmvwwVEMrDqFZyewjj0Cws6sUUua3uOW1n8LXLQE6dUfHsRWb Vsrf+zwkXU97oCHnvhcganoc5HQwGaQQmiMrK6iz8GTVLlbDAZzDYjbsjHEjy+twLxSS qeBuxON0fPGDwwPW0INfKR3m90nwxKeYsc3UilzzHtTpkNWgUvMZtsgVgGIOssFxtjVo EsJHDACXy/S0t1dxuApMEWTCy1RIKFGeteBj5R01vNMW2kFNoSHJL79DWqnROvZnM8Ix xqHyXBndnqNznTit0volF/cLXr+NetVcqrkeRHDljUwvIE2QaoU77rLtiTevpZ2FQ8zK CjqA== MIME-Version: 1.0 X-Received: by 10.129.53.132 with SMTP id c126mr9276369ywa.108.1447969610779; Thu, 19 Nov 2015 13:46:50 -0800 (PST) Received: by 10.103.9.195 with HTTP; Thu, 19 Nov 2015 13:46:50 -0800 (PST) In-Reply-To: <20151117092703.GA30582@lonesome.com> References: <56417100.5050600@Wilcox-Tech.com> <39947478-4710-47D8-BAB1-FC93979570B6@mail.turbofuzz.com> <5646D19C.9010304@interlinked.me> <564A889C.9070209@mu.org> <564ACCB3.4070603@mu.org> <20151117092703.GA30582@lonesome.com> Date: Thu, 19 Nov 2015 16:46:50 -0500 Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Joe Nosay To: Mark Linimon Cc: Warner Losh , Anna Wilcox , freebsd-arch , Alfred Perlstein , Marius Strobl , Sean Bruno , "sparc64@freebsd.org" , Jordan Hubbard , Elizabeth Myers X-Mailman-Approved-At: Thu, 19 Nov 2015 22:45:53 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 21:46:52 -0000 Is it possible to have the instruction sets moved from one architecture to another? Would this require more registers? Since there are Open Architectures, it should be possible to create a CPU with shared instruction sets. On Tue, Nov 17, 2015 at 4:27 AM, Mark Linimon wrote: > On Tue, Nov 17, 2015 at 12:06:35AM -0700, Warner Losh wrote: > > We don=E2=80=99t have a =E2=80=9Cking of the kernel=E2=80=9D or =E2=80= =9Cking of mips=E2=80=9D or anything > > like that. We document that you send mail to mips@ when you don=E2=80= =99t > > know the right person to send. > > And I don't see why we should. What would we gain from this administrati= ve > overhead? > > What we lose is: dealing with people who have the title not doing work, > or people not having the title, doing the work, being irritated by not > having the title. > > svn can, with a little effort, demonstrate who is looking after what. > > All I see is cost and no benefit. This isn't an "org chart" kind of > issue IMHO. > > In FreeBSD, why delegate responsibility to anyone other than those who > take it by their own initiative? > > mcl > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org= " > From owner-freebsd-sparc64@freebsd.org Fri Nov 20 14:23:52 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C150A340BB for ; Fri, 20 Nov 2015 14:23:52 +0000 (UTC) (envelope-from AmericanExpress@welcome.aexp.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA1E100C for ; Fri, 20 Nov 2015 14:23:52 +0000 (UTC) (envelope-from AmericanExpress@welcome.aexp.com) Received: by freefall.freebsd.org (Postfix) id 0D1661CA9; Fri, 20 Nov 2015 14:23:52 +0000 (UTC) Delivered-To: freebsd-sparc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by freefall.freebsd.org (Postfix) with ESMTP id E679C1CA0 for ; Fri, 20 Nov 2015 14:23:51 +0000 (UTC) (envelope-from AmericanExpress@welcome.aexp.com) Received: from lb4.webmarketingexperts.com.au (vmh17521.hosting24.com.au [111.67.12.199]) (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 8760C1FF3 for ; Fri, 20 Nov 2015 14:23:51 +0000 (UTC) (envelope-from AmericanExpress@welcome.aexp.com) Received: from [23.227.196.51] (port=51457 helo=Monodc7138) by lb4.webmarketingexperts.com.au with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1ZzkwJ-000DLA-BQ for freebsd-sparc@freebsd.org; Fri, 20 Nov 2015 23:37:20 +1100 MIME-Version: 1.0 Date: Fri, 20 Nov 2015 13:17:26 +0100 X-Priority: Normal Subject: Account Alert: Update Required X-Mailer: Rapid Email Sender To: "freebsd-sparc" From: "American Express" Message-ID: <028D019660F3A1C7E750D46C1AB98B09ADE3822B@MONODC7138> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - lb4.webmarketingexperts.com.au X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - welcome.aexp.com X-Get-Message-Sender-Via: lb4.webmarketingexperts.com.au: authenticated_id: high@solutionspluspartnership.com.au X-Authenticated-Sender: lb4.webmarketingexperts.com.au: high@solutionspluspartnership.com.au Content-Type: text/plain; charset="windows-1257"; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 14:23:52 -0000 Important Notification Please note that starting from November 27, 2015 we will be introducing new= login authentication procedures in order to protect the information of our= customers. You are required to complete our account verification process and confirm t= he details you have registered with us as you will not be able to have acce= ss to your account until this has been completed, please click the link bel= ow to get started Get Started Please Note: It is essential you complete this process in order for us to s= afeguard your account, failure to do so may lead to permanent restrictions = being place on your account Best regards, American Express Customer Services Copyright =A9 2015 - Please do not reply directly to this email American E= xpress Company