From owner-freebsd-arch@FreeBSD.ORG Sun Jan 15 04:16:01 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C739B106564A for ; Sun, 15 Jan 2012 04:16:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79CD08FC12 for ; Sun, 15 Jan 2012 04:16:01 +0000 (UTC) Received: by vcbfl17 with SMTP id fl17so641715vcb.13 for ; Sat, 14 Jan 2012 20:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2QUz+RhUNcmbBmL8aY/sHNeoBAYWqUt5DqUmtvqmoYc=; b=NSLQoD6dC4DkNgEyMlgdetybqt+AMNEJEJ2Oz6uqbRRE/W8Rintf6EyD/FVTBdfpy3 IKK8AWSVOlnDsv8TacnNVNMNYaavNsgzVB6vS10L8O8vNvIB6SegyXcV5OgaMAfe9Fex fc4V1Mf3V9Ht11o2Iw+XASIioYg//yj8OQyLU= MIME-Version: 1.0 Received: by 10.220.156.134 with SMTP id x6mr4264151vcw.17.1326600960855; Sat, 14 Jan 2012 20:16:00 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Sat, 14 Jan 2012 20:16:00 -0800 (PST) In-Reply-To: <20120111193738.GB44286@alchemy.franken.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> Date: Sat, 14 Jan 2012 20:16:00 -0800 X-Google-Sender-Auth: fBWwf5Nty4WEyJEAtD-hkkaix8U Message-ID: From: Adrian Chadd To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: Stefan Bethke , freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 04:16:01 -0000 Hi Marius, etc; Does the miibus code actually obey newbus at the moment? Or is it also cutting corners somehow? Adrian From owner-freebsd-arch@FreeBSD.ORG Sun Jan 15 05:16:25 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9AC4106566B; Sun, 15 Jan 2012 05:16:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 58C6B8FC08; Sun, 15 Jan 2012 05:16:25 +0000 (UTC) Received: from [192.168.4.2] ([64.134.52.75]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q0F5Dj0w066708 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 14 Jan 2012 22:13:47 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 14 Jan 2012 22:13:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8BCA297C-BED9-44E9-8BE0-E718780DCFEC@bsdimp.com> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 14 Jan 2012 22:13:49 -0700 (MST) Cc: freebsd-arch@freebsd.org, Stefan Bethke , Marius Strobl Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 05:16:25 -0000 On Jan 14, 2012, at 9:16 PM, Adrian Chadd wrote: > Does the miibus code actually obey newbus at the moment? Or is it also > cutting corners somehow? It actually mostly obeys newbus at the moment. Any places that may seem = to be cutting corners are actually interfacing to lower-layers that = don't participate in newbus (like if_media). dcphy is also a little = weird because it isn't really a PHY connected via a MII bus at all. = There may also be a few allowances made since it has been ported (and = reported) to and from NetBSD and BSD/os a few times. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jan 16 15:42:19 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BA68106566C; Mon, 16 Jan 2012 15:42:19 +0000 (UTC) (envelope-from maxim@freebsd.org) Received: from mp2.macomnet.net (ipv6.irc.int.ru [IPv6:2a02:28:1:2::1b:2]) by mx1.freebsd.org (Postfix) with ESMTP id 8372D8FC0A; Mon, 16 Jan 2012 15:42:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.14.5/8.14.5) with ESMTP id q0GFgGuY080213; Mon, 16 Jan 2012 19:42:16 +0400 (MSK) (envelope-from maxim@freebsd.org) Date: Mon, 16 Jan 2012 19:42:16 +0400 (MSK) From: Maxim Konovalov To: Kostik Belousov In-Reply-To: Message-ID: References: <20111122124410.GP50300@deviant.kiev.zoral.com.ua> <20111122154357.GI95664@mdounin.ru> <20111122154935.GR50300@deviant.kiev.zoral.com.ua> <20111124202945.GR50300@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: arch@freebsd.org, Maxim Dounin , current@freebsd.org, igor@sysoev.ru Subject: Re: RLIMIT_DATA and malloc(3) use of mmap(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 15:42:19 -0000 Hi Kostik, On Fri, 9 Dec 2011, 13:56+0400, Maxim Konovalov wrote: > On Fri, 25 Nov 2011, 22:21+0400, Maxim Konovalov wrote: > > > [...] > > > Fixed patch is available at > > > http://people.freebsd.org/~kib/misc/map_datalimit.2.patch > > > > > Works as expected without any glitches. > > > I understand that you are busy with the release. But is there a > plan to commit this code somewhere in the near future? > Are there any news? -- Maxim Konovalov From owner-freebsd-arch@FreeBSD.ORG Mon Jan 16 21:16:44 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DD611065686 for ; Mon, 16 Jan 2012 21:16:44 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 182A18FC13 for ; Mon, 16 Jan 2012 21:16:43 +0000 (UTC) Received: by ggki1 with SMTP id i1so3620657ggk.13 for ; Mon, 16 Jan 2012 13:16:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.195.129 with SMTP id ie1mr14221717igc.29.1326747180805; Mon, 16 Jan 2012 12:53:00 -0800 (PST) Received: by 10.42.140.196 with HTTP; Mon, 16 Jan 2012 12:53:00 -0800 (PST) Date: Mon, 16 Jan 2012 12:53:00 -0800 Message-ID: From: Jos Backus To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 21:16:44 -0000 http://cr.yp.to/distributors.html says: "What are the distribution terms for daemontools? 2007.12.28: I hereby place the daemontools package (in particular, daemontools-0.76.tar.gz, with MD5 checksum 1871af2453d6e464034968a0fbcb2bfc) into the public domain. The package is no longer copyrighted." FreeBSD could use a lightweight, robust service management framework so we can finally get rid of the messy and unreliable pidfile concept. UNIX already provides a much more elegant solution using fork()/exec()/wait() in combination with the process table. daemontools provides a solid, time-tested implementation of said mechanism. There's also an updated version of daemontools by Bruce Guenter at http://untroubled.org/daemontools-encore/ which among other improvements has support for finish script functionality, which is very useful for alerting/monitoring of service crashes. Its LICENSE file suggests that it is released under a BSD-like license. Thoughts? -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 02:53:55 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id AD6BD106566B for ; Tue, 17 Jan 2012 02:53:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 125D81A5EBD; Tue, 17 Jan 2012 02:53:05 +0000 (UTC) Message-ID: <4F14E291.5090803@FreeBSD.org> Date: Mon, 16 Jan 2012 18:53:05 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Jos Backus References: In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 02:53:55 -0000 On 01/16/2012 12:53, Jos Backus wrote: > > Thoughts? This is already available in ports. -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 03:41:16 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7395106564A for ; Tue, 17 Jan 2012 03:41:16 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 83F208FC18 for ; Tue, 17 Jan 2012 03:41:16 +0000 (UTC) Received: by iagz16 with SMTP id z16so6899763iag.13 for ; Mon, 16 Jan 2012 19:41:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.152.65 with SMTP id h1mr4669725icw.50.1326771675909; Mon, 16 Jan 2012 19:41:15 -0800 (PST) Received: by 10.42.140.196 with HTTP; Mon, 16 Jan 2012 19:41:15 -0800 (PST) Received: by 10.42.140.196 with HTTP; Mon, 16 Jan 2012 19:41:15 -0800 (PST) In-Reply-To: <4F14E291.5090803@FreeBSD.org> References: <4F14E291.5090803@FreeBSD.org> Date: Mon, 16 Jan 2012 19:41:15 -0800 Message-ID: From: Jos Backus To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 03:41:16 -0000 On Jan 16, 2012 6:53 PM, "Doug Barton" wrote: > > On 01/16/2012 12:53, Jos Backus wrote: > > > > Thoughts? > > This is already available in ports. I realize that. If FreeBSD had a solid solution out of the box, all this pidfile hackery in the base system wouldn't be necessary. I always thought FreeBSD was about good engineering. Perpetuating the pidfile mess in the base is not a sign of good engineering. Jos > -- > > It's always a long day; 86400 doesn't fit into a short. > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 05:10:39 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 365DB106564A for ; Tue, 17 Jan 2012 05:10:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 789E9152AC7; Tue, 17 Jan 2012 05:10:38 +0000 (UTC) Message-ID: <4F1502CD.90409@FreeBSD.org> Date: Mon, 16 Jan 2012 21:10:37 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Jos Backus References: <4F14E291.5090803@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 05:10:39 -0000 On 01/16/2012 19:41, Jos Backus wrote: > On Jan 16, 2012 6:53 PM, "Doug Barton" wrote: >> >> On 01/16/2012 12:53, Jos Backus wrote: >>> >>> Thoughts? >> >> This is already available in ports. > > I realize that. Good, then we're done. :) > If FreeBSD had a solid solution out of the box, all this pidfile hackery in > the base system wouldn't be necessary. We don't do religious wars here. We especially don't do trollbait from djb acolytes. The "pidfile hackery" that we currently have works just fine in the vast majority of cases. The fact that it doesn't meet some people's ideas of architectural purity is totally beside the point. > I always thought FreeBSD was about > good engineering. Perpetuating the pidfile mess in the base is not a sign > of good engineering. FreeBSD is about giving people choices. Those who want to use daemontools can do that. And lest people think that I'm just hating on daemontools, I'm not. I use it for some things. But converting everything in the base to use it is a non-starter, even if we wanted to import it, which I don't see any need to do. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 06:32:03 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 386CA106566B; Tue, 17 Jan 2012 06:32:03 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED9E08FC19; Tue, 17 Jan 2012 06:32:02 +0000 (UTC) Received: by iagz16 with SMTP id z16so7218871iag.13 for ; Mon, 16 Jan 2012 22:32:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.152.65 with SMTP id h1mr5108921icw.50.1326781922188; Mon, 16 Jan 2012 22:32:02 -0800 (PST) Received: by 10.42.140.196 with HTTP; Mon, 16 Jan 2012 22:32:02 -0800 (PST) In-Reply-To: <4F1502CD.90409@FreeBSD.org> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> Date: Mon, 16 Jan 2012 22:32:02 -0800 Message-ID: From: Jos Backus To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 06:32:03 -0000 Hi Doug, On Mon, Jan 16, 2012 at 9:10 PM, Doug Barton wrote: > On 01/16/2012 19:41, Jos Backus wrote: > > On Jan 16, 2012 6:53 PM, "Doug Barton" wrote: > >> > >> On 01/16/2012 12:53, Jos Backus wrote: > >>> > >>> Thoughts? > >> > >> This is already available in ports. > > > > I realize that. > > Good, then we're done. :) > Heh :) > > > If FreeBSD had a solid solution out of the box, all this pidfile hackery > in > > the base system wouldn't be necessary. > > We don't do religious wars here. We especially don't do trollbait from > djb acolytes. The "pidfile hackery" that we currently have works just > fine in the vast majority of cases. The fact that it doesn't meet some > people's ideas of architectural purity is totally beside the point. > > I want/need a solution that works in (nearly) all cases and is devoid of complex code trying to track state that is already represented elsewhere in the system (the process table and the parent/child process relationship). I want a solution that can reliably handle a crashing server that doesn't clean up its pidfile (the finish script functionality in daemontools-encore provides this), and I want a unified control interface for the services running on a box, a la launchd or what have you. This isn't about religion but about missing base system functionality - the ability to reliably control services running on a box. > > I always thought FreeBSD was about > > good engineering. Perpetuating the pidfile mess in the base is not a sign > > of good engineering. > > FreeBSD is about giving people choices. Those who want to use > daemontools can do that. > I thought the motto was "tools, not policies" ;) > > And lest people think that I'm just hating on daemontools, I'm not. I > use it for some things. But converting everything in the base to use it > is a non-starter, even if we wanted to import it, which I don't see any > need to do. > Straw man. I'm asking for FreeBSD to *support* this functionality out of the box, just like OS X, Solaris, AIX and some Linux versions (with systemd). The closest FreeBSD has today is init, and it's not flexible enough to do the job. ISTR the last time I mentioned this, the debate was all about the code's license, not about the functionality. I'm glad we at least now can discuss whether this functionality belongs in the base system, as the license should no longer be an issue (it's public domain). Jos -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 07:14:32 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D24A8106566B; Tue, 17 Jan 2012 07:14:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 628FA8FC0C; Tue, 17 Jan 2012 07:14:32 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q0H7AUOA092289 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 17 Jan 2012 00:10:32 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4F1502CD.90409@FreeBSD.org> Date: Tue, 17 Jan 2012 00:10:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 17 Jan 2012 00:10:32 -0700 (MST) Cc: freebsd-arch@FreeBSD.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 07:14:32 -0000 On Jan 16, 2012, at 10:10 PM, Doug Barton wrote: > On 01/16/2012 19:41, Jos Backus wrote: >> On Jan 16, 2012 6:53 PM, "Doug Barton" wrote: >>>=20 >>> On 01/16/2012 12:53, Jos Backus wrote: >>>>=20 >>>> Thoughts? >>>=20 >>> This is already available in ports. >>=20 >> I realize that. >=20 > Good, then we're done. :) Not necessarily... >> If FreeBSD had a solid solution out of the box, all this pidfile = hackery in >> the base system wouldn't be necessary. >=20 > We don't do religious wars here. We especially don't do trollbait from > djb acolytes. The "pidfile hackery" that we currently have works just > fine in the vast majority of cases. The fact that it doesn't meet some > people's ideas of architectural purity is totally beside the point. This isn't a religious war. This is someone coming to us and saying = that it might be a good idea to clean up the mess by importing a tiny = bit of extra code into the base. Seems like how we've always done = things :) >> I always thought FreeBSD was about >> good engineering. Perpetuating the pidfile mess in the base is not a = sign >> of good engineering. >=20 > FreeBSD is about giving people choices. Those who want to use > daemontools can do that. >=20 > And lest people think that I'm just hating on daemontools, I'm not. I > use it for some things. But converting everything in the base to use = it > is a non-starter, even if we wanted to import it, which I don't see = any > need to do. I'm not convinced it is a non-starter. I'd fully support Jos if he = wanted to commit the code and had done the leg work to do it. I = wouldn't support just importing the daemontools and leaving it at that. = If that's the plan, then leaving it in ports is the best bet. Let's not dismiss this out of hand. Warner= From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 07:34:15 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id F3D171065676 for ; Tue, 17 Jan 2012 07:34:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id CD1C2176D69; Tue, 17 Jan 2012 07:34:13 +0000 (UTC) Message-ID: <4F152475.50503@FreeBSD.org> Date: Mon, 16 Jan 2012 23:34:13 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Warner Losh References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 07:34:15 -0000 On 01/16/2012 23:10, Warner Losh wrote: > > On Jan 16, 2012, at 10:10 PM, Doug Barton wrote: > >> On 01/16/2012 19:41, Jos Backus wrote: >>> On Jan 16, 2012 6:53 PM, "Doug Barton" >>> wrote: >>>> >>>> On 01/16/2012 12:53, Jos Backus wrote: >>>>> >>>>> Thoughts? >>>> >>>> This is already available in ports. >>> >>> I realize that. >> >> Good, then we're done. :) > > Not necessarily... > >>> If FreeBSD had a solid solution out of the box, all this pidfile >>> hackery in the base system wouldn't be necessary. >> >> We don't do religious wars here. We especially don't do trollbait >> from djb acolytes. The "pidfile hackery" that we currently have >> works just fine in the vast majority of cases. The fact that it >> doesn't meet some people's ideas of architectural purity is totally >> beside the point. > > This isn't a religious war. You obviously haven't spent a lot of time dealing with djb'ites. Your warning sign should have been "messy and unreliable pidfile concept" from the OP, or "pidfile hackery" above. > This is someone coming to us and saying that it might be a good idea > to clean up the mess by importing a tiny bit of extra code That's not even close to an accurate description of what this project would entail. Have you ever used daemontools? > I'm not convinced it is a non-starter. I'd fully support Jos if he > wanted to commit the code and had done the leg work to do it. One would hope that it would take more than just your support to entirely change the way that we start and manage services in FreeBSD. Also, see my followup to Jos' subsequent post. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 07:50:39 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id EA574106564A for ; Tue, 17 Jan 2012 07:50:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6843414F37F; Tue, 17 Jan 2012 07:50:38 +0000 (UTC) Message-ID: <4F15284D.7010806@FreeBSD.org> Date: Mon, 16 Jan 2012 23:50:37 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Jos Backus References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 07:50:40 -0000 On 01/16/2012 22:32, Jos Backus wrote: > I want/need a solution that works in (nearly) all cases and is devoid of > complex code trying to track state that is already represented elsewhere > in the system (the process table and the parent/child process > relationship). I want a solution that can reliably handle a crashing > server that doesn't clean up its pidfile (the finish script > functionality in daemontools-encore provides this), We get it, you want daemontools. It's in the ports, you can have it. > and I want a unified > control interface for the services running on a box, rc.d provides that, and service(8) makes that easier. > a la launchd or what have you. We've looked at importing launchd, or something like it. It's not a bad idea, it's just way more complex than it sounds. And a lot more work than "hey, let's import daemontools." If we were going to do something like this I think we should properly spec out what the goals should be, what the available solutions are, and what we want our ultimate solution to look like when we're done. > This isn't about religion but about missing base system > functionality - the ability to reliably control services running on a box. And my argument is that we already have that in the base, it's just not the one you want; and since it's not the one you want you're redefining "reliably" to suit your needs. > I thought the motto was "tools, not policies" ;) Right now you have options (or tools if you will). If the base were redesigned to use daemontools it would be very difficult to retain those options. > And lest people think that I'm just hating on daemontools, I'm not. I > use it for some things. But converting everything in the base to use it > is a non-starter, even if we wanted to import it, which I don't see any > need to do. > > > Straw man. I'm asking for FreeBSD to *support* this functionality out of > the box, just like OS X, Solaris, AIX and some Linux versions (with > systemd). If you can come up with patches to make both options possible out of the box, I'm sure that people would be interested in reviewing them. -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 08:50:05 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0EEE106564A; Tue, 17 Jan 2012 08:50:05 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 68BBE8FC0A; Tue, 17 Jan 2012 08:50:05 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 564F96B10; Tue, 17 Jan 2012 08:50:04 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 3714C8742; Tue, 17 Jan 2012 09:50:04 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jos Backus References: <4F14E291.5090803@FreeBSD.org> Date: Tue, 17 Jan 2012 09:50:04 +0100 In-Reply-To: (Jos Backus's message of "Mon, 16 Jan 2012 19:41:15 -0800") Message-ID: <86mx9msog3.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 08:50:05 -0000 Jos Backus writes: > If FreeBSD had a solid solution out of the box, all this pidfile hackery = in > the base system wouldn't be necessary. I always thought FreeBSD was about > good engineering. Perpetuating the pidfile mess in the base is not a sign > of good engineering. Software written by DJB hardly qualifies as "good engineering". PID files are well-known and well-tested, we have a solid implementation with a simple API (pidfile(3)), and a lot of our infrastructure depends on them (/etc/rc, newsyslog etc.) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 09:00:27 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDBE3106564A; Tue, 17 Jan 2012 09:00:27 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AA0E38FC14; Tue, 17 Jan 2012 09:00:27 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id BD3536B14; Tue, 17 Jan 2012 09:00:26 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 79A1B8746; Tue, 17 Jan 2012 10:00:26 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Warner Losh References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> Date: Tue, 17 Jan 2012 10:00:26 +0100 In-Reply-To: (Warner Losh's message of "Tue, 17 Jan 2012 00:10:30 -0700") Message-ID: <86ipkasnyt.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , freebsd-arch@FreeBSD.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 09:00:28 -0000 Warner Losh writes: > I'm not convinced it is a non-starter. I'd fully support Jos if he > wanted to commit the code and had done the leg work to do it. I > wouldn't support just importing the daemontools and leaving it at > that. If that's the plan, then leaving it in ports is the best bet. If we ever want to move in that direction, we should look at launchd, not daemontools. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 09:25:37 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C62FA106566C; Tue, 17 Jan 2012 09:25:37 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 870598FC0C; Tue, 17 Jan 2012 09:25:37 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 8006D6B1A; Tue, 17 Jan 2012 09:25:36 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 601B4874A; Tue, 17 Jan 2012 10:25:36 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jos Backus References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> Date: Tue, 17 Jan 2012 10:25:36 +0100 In-Reply-To: (Jos Backus's message of "Mon, 16 Jan 2012 22:32:02 -0800") Message-ID: <86boq2smsv.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 09:25:37 -0000 Jos Backus writes: > I want/need a solution that works in (nearly) all cases and is devoid of > complex code trying to track state that is already represented elsewhere = in > the system (the process table and the parent/child process > relationship). Please show me the complex code required to handle pidfiles. > I want a solution that can reliably handle a crashing server that > doesn't clean up its pidfile That's a strawman. Whatever tool you use needs to be able to handle stale pidfiles anyway. > I want a unified control interface for the services running on a box, > a la launchd or what have you. So extend service(8) to support enabling / disabling services through /etc/rc.conf.d/. Probably no more than an afternoon's work. > This isn't about religion but about missing base system functionality > - the ability to reliably control services running on a box. The onus is on you to show that we don't already have that. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 11:43:20 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8AC0106567B; Tue, 17 Jan 2012 11:43:20 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0E02D8FC1B; Tue, 17 Jan 2012 11:43:19 +0000 (UTC) Received: by qaea17 with SMTP id a17so359932qae.13 for ; Tue, 17 Jan 2012 03:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KTYTXnYsmDMHMtnhPZRu/mDR7RjC8FQ3hqAHQijSvBQ=; b=SxhH4mgLeaykc5mI29TBbe3ooWb4dUOAI+OBmBGvm/63BjIzpmyuxADwESqsaSGsNc 9sW3Oa7e/uqnvzuC4I2PQ10t0sN4GMPouO3nIlLi4VC7KVK6tSrciVlAbkGHq5oserNv vDRWCDGXYHGFMK2fO/m1nXYP0duVDHRI5bt4Q= MIME-Version: 1.0 Received: by 10.224.175.2 with SMTP id v2mr19222577qaz.69.1326800599198; Tue, 17 Jan 2012 03:43:19 -0800 (PST) Sender: giovanni.trematerra@gmail.com Received: by 10.229.237.130 with HTTP; Tue, 17 Jan 2012 03:43:19 -0800 (PST) In-Reply-To: <20120110153807.H943@besplex.bde.org> References: <20120110005155.S2378@besplex.bde.org> <20120110153807.H943@besplex.bde.org> Date: Tue, 17 Jan 2012 12:43:19 +0100 X-Google-Sender-Auth: 645caFxRq1bqn0vB0s802y97i4M Message-ID: From: Giovanni Trematerra To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jilles@freebsd.org, Attilio Rao , flo@freebsd.org, Konstantin Belousov , freebsd-arch@freebsd.org Subject: Re: pipe/fifo code merged. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 11:43:20 -0000 On Tue, Jan 10, 2012 at 10:41 AM, Bruce Evans wrote: > On Mon, 9 Jan 2012, Giovanni Trematerra wrote: > >> On Mon, Jan 9, 2012 at 3:34 PM, Bruce Evans wrote= : >>> >>> >>> I would go the other way, and pessimize pipes to be like fifos. =A0Then >>> optimize the socket layer under both. =A0Fifos are not important, but >>> they are implemented on top of the socket layer which is important. >>> Pipes are important. ... >>> ... >>> >>> Linux-2.6.10 implements fifos as a small wrapper around pipes, while >>> FreeBSD implements them as a large wrapper around sockets. =A0I hope th= e >>> former is what you do -- share most pipe code, without making it more >>> complicated, and with making the fifo wrapper much simpler. =A0The Linu= x >>> code is much simpler and smaller, since for pipes it it doesn't >>> implement direct mode, and for sockets it doesn't have to interact with >>> the complicated socket layer. >> >> >> If you read the patch, as I think you didn't, you'd see that there's no >> wrapper >> at all. fifo's code is just fifo_open, fifo_close and another couple of >> helper >> functions to deal with VFS, all the remaining code is shared with pipes >> and >> no complicated code was added. > > > I think you don't want me to read the patch, since I would see too much > detail starting with style bugs. =A0Anyway.. Did you agree that this patch http://www.trematerra.net/patches/pipefifo_merge2.4.diff doesn't introduce any further regressions while it fixes - style bugs you pointed out. - pipe_stat now use underlying filesystem information for pipes. - comment about pipeinfo was intended for. - race into pipe_poll (look at fifo_iseof line). I want to work on the other problems you outlined in order to get all the regression test passing, more posix compliance and so on but on a separate patchset. Thank you -- Gianni From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 12:53:38 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFC03106564A; Tue, 17 Jan 2012 12:53:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6908FC19; Tue, 17 Jan 2012 12:53:38 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q0HCrW2g012689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jan 2012 23:53:33 +1100 Date: Tue, 17 Jan 2012 23:53:32 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Doug Barton In-Reply-To: <4F15284D.7010806@FreeBSD.org> Message-ID: <20120117235025.O2762@besplex.bde.org> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F15284D.7010806@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 12:53:38 -0000 On Mon, 16 Jan 2012, Doug Barton wrote: > On 01/16/2012 22:32, Jos Backus wrote: > ... >> I thought the motto was "tools, not policies" ;) > > Right now you have options (or tools if you will). If the base were > redesigned to use daemontools it would be very difficult to retain those > options. >> ... >> Straw man. I'm asking for FreeBSD to *support* this functionality out of >> the box, just like OS X, Solaris, AIX and some Linux versions (with >> systemd). > > If you can come up with patches to make both options possible out of the > box, I'm sure that people would be interested in reviewing them. Nah, he must also maintain both versions forever :-). Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 12:55:18 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E22ED1065673; Tue, 17 Jan 2012 12:55:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id 5A0BB8FC19; Tue, 17 Jan 2012 12:55:18 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q0HCtFSp022734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jan 2012 23:55:16 +1100 Date: Tue, 17 Jan 2012 23:55:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Giovanni Trematerra In-Reply-To: Message-ID: <20120117235344.X2762@besplex.bde.org> References: <20120110005155.S2378@besplex.bde.org> <20120110153807.H943@besplex.bde.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-729530840-1326804915=:2762" Cc: flo@freebsd.org, Attilio Rao , Konstantin Belousov , freebsd-arch@freebsd.org, jilles@freebsd.org Subject: Re: pipe/fifo code merged. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 12:55:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-729530840-1326804915=:2762 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 17 Jan 2012, Giovanni Trematerra wrote: > On Tue, Jan 10, 2012 at 10:41 AM, Bruce Evans wrot= e: >> ... >> I think you don't want me to read the patch, since I would see too much >> detail starting with style bugs. =A0Anyway.. > > Did you agree that this patch > http://www.trematerra.net/patches/pipefifo_merge2.4.diff > > doesn't introduce any further regressions while it fixes I haven't had time to review the newer version. Will try to find some. Bruce --0-729530840-1326804915=:2762-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 14:55:04 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EC5E1065670; Tue, 17 Jan 2012 14:55:04 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id 75C068FC16; Tue, 17 Jan 2012 14:55:04 +0000 (UTC) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by hapkido.dreamhost.com (Postfix) with ESMTP id B1AF8188B9D; Tue, 17 Jan 2012 06:24:32 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 56ABC438079; Tue, 17 Jan 2012 06:24:32 -0800 (PST) Received: from lab (ip72-219-240-45.dc.dc.cox.net [72.219.240.45]) (Authenticated sender: trhodes@fbsdsecure.org) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id B4C4E43806C; Tue, 17 Jan 2012 06:24:31 -0800 (PST) Date: Tue, 17 Jan 2012 09:24:22 -0500 From: Tom Rhodes To: Doug Barton Message-Id: <20120117092422.5f8b0018.trhodes@FreeBSD.org> In-Reply-To: <4F15284D.7010806@FreeBSD.org> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F15284D.7010806@FreeBSD.org> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 14:55:04 -0000 On Mon, 16 Jan 2012 23:50:37 -0800 Doug Barton wrote: > On 01/16/2012 22:32, Jos Backus wrote: > > > I want/need a solution that works in (nearly) all cases and is devoid of > > complex code trying to track state that is already represented elsewhere > > in the system (the process table and the parent/child process > > relationship). I want a solution that can reliably handle a crashing > > server that doesn't clean up its pidfile (the finish script > > functionality in daemontools-encore provides this), > > We get it, you want daemontools. It's in the ports, you can have it. > > > and I want a unified > > control interface for the services running on a box, > > rc.d provides that, and service(8) makes that easier. > > > a la launchd or what have you. > > We've looked at importing launchd, or something like it. It's not a bad > idea, it's just way more complex than it sounds. And a lot more work > than "hey, let's import daemontools." > > If we were going to do something like this I think we should properly > spec out what the goals should be, what the available solutions are, and > what we want our ultimate solution to look like when we're done. > > > This isn't about religion but about missing base system > > functionality - the ability to reliably control services running on a box. > > And my argument is that we already have that in the base, it's just not > the one you want; and since it's not the one you want you're redefining > "reliably" to suit your needs. Just use/improve my fscd. I meant to import it but have just ended up getting too busy. Now, I'm way too busy and would be more than happy to help anyone bring it in. That said, happy new year. :P -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 17:31:16 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D039D106567A; Tue, 17 Jan 2012 17:31:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 77FA48FC1B; Tue, 17 Jan 2012 17:31:16 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q0HHTxYl098952 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 17 Jan 2012 10:30:00 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4F152475.50503@FreeBSD.org> Date: Tue, 17 Jan 2012 10:29:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 17 Jan 2012 10:30:01 -0700 (MST) Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:31:17 -0000 On Jan 17, 2012, at 12:34 AM, Doug Barton wrote: > On 01/16/2012 23:10, Warner Losh wrote: >>=20 >> On Jan 16, 2012, at 10:10 PM, Doug Barton wrote: >>=20 >>> On 01/16/2012 19:41, Jos Backus wrote: >>>> On Jan 16, 2012 6:53 PM, "Doug Barton" >>>> wrote: >>>>>=20 >>>>> On 01/16/2012 12:53, Jos Backus wrote: >>>>>>=20 >>>>>> Thoughts? >>>>>=20 >>>>> This is already available in ports. >>>>=20 >>>> I realize that. >>>=20 >>> Good, then we're done. :) >>=20 >> Not necessarily... >>=20 >>>> If FreeBSD had a solid solution out of the box, all this pidfile >>>> hackery in the base system wouldn't be necessary. >>>=20 >>> We don't do religious wars here. We especially don't do trollbait >>> from djb acolytes. The "pidfile hackery" that we currently have >>> works just fine in the vast majority of cases. The fact that it >>> doesn't meet some people's ideas of architectural purity is totally >>> beside the point. >>=20 >> This isn't a religious war. >=20 > You obviously haven't spent a lot of time dealing with djb'ites. Your > warning sign should have been "messy and unreliable pidfile concept" > from the OP, or "pidfile hackery" above. I have spent time with djb-ites in other areas. I tend to ignore their = ranker and focus on the technical issues. I've had issues with pidfiles = and such in the past. There are a lot of hacks to get around those = issues, and things mostly work. If there's a good alternative that can = be demonstrated to work and gain us additional functionality, I'm all = for it. I've fought with init() to make it keep important daemons = around should they die. I've worked with other systems that make it = easy to do and miss that on FreeBSD. It is possible, but not easy. If = daemontools makes it easy, we should evaluate it. >> This is someone coming to us and saying that it might be a good idea >> to clean up the mess by importing a tiny bit of extra code >=20 > That's not even close to an accurate description of what this project > would entail. Have you ever used daemontools? I haven't. However, without a fully formed set of patches to test and = evaluate technically, it is hard to know if this is a good idea or a bad = idea. >> I'm not convinced it is a non-starter. I'd fully support Jos if he >> wanted to commit the code and had done the leg work to do it.=20 >=20 > One would hope that it would take more than just your support to > entirely change the way that we start and manage services in FreeBSD. >=20 > Also, see my followup to Jos' subsequent post. And one would hope your pig-headdednes also doesn't keep it out of = FreeBSD. Neither you nor I are the final arbiter of what's good for = FreeBSD. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 18:15:59 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FD4D1065670; Tue, 17 Jan 2012 18:15:59 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6393E8FC0A; Tue, 17 Jan 2012 18:15:59 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 9BDC422840; Tue, 17 Jan 2012 10:55:03 -0700 (MST) Received: by night.db.net (Postfix, from userid 1000) id 8E8E85C5B; Tue, 17 Jan 2012 13:00:44 -0500 (EST) Date: Tue, 17 Jan 2012 13:00:44 -0500 From: Diane Bruce To: Warner Losh Message-ID: <20120117180044.GB43278@night.db.net> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:15:59 -0000 On Tue, Jan 17, 2012 at 10:29:53AM -0700, Warner Losh wrote: > ... > > I have spent time with djb-ites in other areas. I tend to ignore their rancor and focus on the technical issues. I've had issues with pidfiles and such in the past. There are a lot of hacks to get around those issues, and things mostly work. If there's a good alternative that can be demonstrated to work and gain us additional functionality, I'm all for it. I've fought with init() to make it keep important daemons around should they die. I've worked with other systems that make it easy to do and miss that on FreeBSD. It is possible, but not easy. If daemontools makes it easy, we should evaluate it. It would be more useful to see what is offered with other systems and see if we can provide the same or similar functionality with some sort of 'standard' (I know impossible). How much work would it be to simply add a few scripts as Doug suggests? etc. etc. Instead of just saying "lets import everything in daemontools", what really is proposed? How would it impact an embedded system? Is it yet more bloat that should be delegated to the same pile of important ports as sendmail, bind etc. that some of us have been trying to get out of base? - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 18:28:21 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E59F6106566C for ; Tue, 17 Jan 2012 18:28:21 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B13BB8FC0C for ; Tue, 17 Jan 2012 18:28:21 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q0HIG2S1096424 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 Jan 2012 10:16:04 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F15BB21.50905@freebsd.org> Date: Tue, 17 Jan 2012 10:17:05 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Warner Losh References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> In-Reply-To: <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:28:22 -0000 On 1/17/12 9:29 AM, Warner Losh wrote: > I have spent time with djb-ites in other areas. I tend to ignore > their ranker and focus on the technical issues. I've had issues with > pidfiles and such in the past. There are a lot of hacks to get around > those issues, and things mostly work. If there's a good alternative > that can be demonstrated to work and gain us additional > functionality, I'm all for it. I've fought with init() to make it > keep important daemons around should they die. I've worked with other > systems that make it easy to do and miss that on FreeBSD. It is > possible, but not easy. If daemontools makes it easy, we should > evaluate it. don't forget other alternatives.. for example we have launchd from apple which is quite a well tested entry in the "init" space of solutions. From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 19:14:55 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66381106564A; Tue, 17 Jan 2012 19:14:55 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 361B38FC13; Tue, 17 Jan 2012 19:14:55 +0000 (UTC) Received: by dady13 with SMTP id y13so3153916dad.13 for ; Tue, 17 Jan 2012 11:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MLY2Lep3uebkAE7Cnz6D1d+jFngri/i7sSWwHwVyfmw=; b=pFK1fASw6nWzE8MkltpT+3TMf0d6GKshg1GLEkO7zKCPDWzK4XdntFHnWVct0/U/iJ fSJtnV5me2kT6GomkdUPKyagwWtsdLxccmbbd/SRt7zIQlv/HLaSE+SnfPmuh5y+l0ap T9LUt8s5Yg7dryNg5hLRZWfD9UfxtfEyZOV4E= MIME-Version: 1.0 Received: by 10.68.74.4 with SMTP id p4mr36157700pbv.123.1326826269959; Tue, 17 Jan 2012 10:51:09 -0800 (PST) Received: by 10.68.71.201 with HTTP; Tue, 17 Jan 2012 10:51:09 -0800 (PST) In-Reply-To: <4F15BB21.50905@freebsd.org> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> <4F15BB21.50905@freebsd.org> Date: Tue, 17 Jan 2012 10:51:09 -0800 Message-ID: From: Peter Wemm To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 19:14:55 -0000 On Tue, Jan 17, 2012 at 10:17 AM, Julian Elischer wrot= e: > On 1/17/12 9:29 AM, Warner Losh wrote: >> >> =A0I have spent time with djb-ites in other areas. I tend to ignore >> =A0their ranker and focus on the technical issues. I've had issues with >> =A0pidfiles and such in the past. There are a lot of hacks to get around >> =A0those issues, and things mostly work. If there's a good alternative >> =A0that can be demonstrated to work and gain us additional >> =A0functionality, I'm all for it. I've fought with init() to make it >> =A0keep important daemons around should they die. I've worked with other >> =A0systems that make it easy to do and miss that on FreeBSD. It is >> =A0possible, but not easy. If daemontools makes it easy, we should >> =A0evaluate it. > > > > don't forget other alternatives.. > > for example we have launchd from apple which is quite a well > tested entry in the "init" space of solutions. At the risk of prolonging the discussion.. We use daemontools at work and I find it horrid to work with. Really horri= d. However, I do miss a real, pluggable services manager/starter/etc. launchd springs to mind, if only it wasn't .plist based. Linux seems to be standardizing on systemd (think of launchd except made to smell like linux software) as a replacement for everything including init (just like apple replaced init with launchd). There has got to be something better and less obnoxious than daemontools. We don't need another file system abuser like that one. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 19:37:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFEE01065688 for ; Tue, 17 Jan 2012 19:37:10 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B6AD8FC14 for ; Tue, 17 Jan 2012 19:37:10 +0000 (UTC) Received: by iagz16 with SMTP id z16so8615557iag.13 for ; Tue, 17 Jan 2012 11:37:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.152.65 with SMTP id h1mr7416414icw.50.1326829030060; Tue, 17 Jan 2012 11:37:10 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 11:37:09 -0800 (PST) In-Reply-To: References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> <4F15BB21.50905@freebsd.org> Date: Tue, 17 Jan 2012 11:37:09 -0800 Message-ID: From: Jos Backus To: Peter Wemm Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 19:37:10 -0000 Hi Peter, Thanks for chiming in. On Tue, Jan 17, 2012 at 10:51 AM, Peter Wemm wrote: > On Tue, Jan 17, 2012 at 10:17 AM, Julian Elischer > wrote: > > On 1/17/12 9:29 AM, Warner Losh wrote: > >> > >> I have spent time with djb-ites in other areas. I tend to ignore > >> their ranker and focus on the technical issues. I've had issues with > >> pidfiles and such in the past. There are a lot of hacks to get around > >> those issues, and things mostly work. If there's a good alternative > >> that can be demonstrated to work and gain us additional > >> functionality, I'm all for it. I've fought with init() to make it > >> keep important daemons around should they die. I've worked with other > >> systems that make it easy to do and miss that on FreeBSD. It is > >> possible, but not easy. If daemontools makes it easy, we should > >> evaluate it. > > > > > > > > don't forget other alternatives.. > > > > for example we have launchd from apple which is quite a well > > tested entry in the "init" space of solutions. > > At the risk of prolonging the discussion.. > > We use daemontools at work and I find it horrid to work with. Really > horrid. > > However, I do miss a real, pluggable services manager/starter/etc. > launchd springs to mind, if only it wasn't .plist based. > > Linux seems to be standardizing on systemd (think of launchd except > made to smell like linux software) as a replacement for everything > including init (just like apple replaced init with launchd). > > There has got to be something better and less obnoxious than > daemontools. We don't need another file system abuser like that one. > I guess this is a matter of taste. I have automated deployments using daemontools and found it to integrate quite well with tools like Puppet. Apache and rsync can now run under it because I argued for it with patches. But I agree with you otherwise. It doesn't have to be daemontools as long as there's something which covers most of its functionality, including the run/finish script stuff, and not having to deal with pidfiles. Jos > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; > KI6FJV > "All of this is for nothing if we don't go to the stars" - JMS/B5 > "If Java had true garbage collection, most programs would delete > themselves upon execution." -- Robert Sewell > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 20:18:11 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4A291065670; Tue, 17 Jan 2012 20:18:11 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7B8B58FC14; Tue, 17 Jan 2012 20:18:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0HKIBlh038348; Tue, 17 Jan 2012 20:18:11 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0HKIBNi038346; Tue, 17 Jan 2012 20:18:11 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Tue, 17 Jan 2012 21:18:07 +0100 From: Baptiste Daroussin To: Peter Wemm Message-ID: <20120117201807.GJ4729@azathoth.lan> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> <4F15BB21.50905@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+Hr//EUsa8//ouuB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Julian Elischer , freebsd-arch@FreeBSD.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 20:18:11 -0000 --+Hr//EUsa8//ouuB Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 17, 2012 at 10:51:09AM -0800, Peter Wemm wrote: > On Tue, Jan 17, 2012 at 10:17 AM, Julian Elischer wr= ote: > > On 1/17/12 9:29 AM, Warner Losh wrote: > >> > >> =A0I have spent time with djb-ites in other areas. I tend to ignore > >> =A0their ranker and focus on the technical issues. I've had issues with > >> =A0pidfiles and such in the past. There are a lot of hacks to get arou= nd > >> =A0those issues, and things mostly work. If there's a good alternative > >> =A0that can be demonstrated to work and gain us additional > >> =A0functionality, I'm all for it. I've fought with init() to make it > >> =A0keep important daemons around should they die. I've worked with oth= er > >> =A0systems that make it easy to do and miss that on FreeBSD. It is > >> =A0possible, but not easy. If daemontools makes it easy, we should > >> =A0evaluate it. > > > > > > > > don't forget other alternatives.. > > > > for example we have launchd from apple which is quite a well > > tested entry in the "init" space of solutions. >=20 > At the risk of prolonging the discussion.. >=20 > We use daemontools at work and I find it horrid to work with. Really hor= rid. >=20 > However, I do miss a real, pluggable services manager/starter/etc. > launchd springs to mind, if only it wasn't .plist based. >=20 Shouldn't be hard to plug a better format to launchd, something like yaml (= Yes I do like yaml :)) for example. what was the final statement of the launchd port summer of code? Can we have something as simple as the current rc with launchd? (for end us= ers) regards, Bapt --+Hr//EUsa8//ouuB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8V138ACgkQ8kTtMUmk6EyX7wCcC3EmTqffz6+yppfh3FBbRFlh gVUAn2EceIG2Eok7mNvlUm6cEvOm2ZpE =yFov -----END PGP SIGNATURE----- --+Hr//EUsa8//ouuB-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 20:43:05 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D43F1065675; Tue, 17 Jan 2012 20:43:05 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 417B28FC16; Tue, 17 Jan 2012 20:43:04 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so3941302obc.13 for ; Tue, 17 Jan 2012 12:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GP+z9dz3OUj1l9sb53o2K4YqbeVS1Rm2gelBJ2NvYsI=; b=hug0O+vXqauhSM1U8XJlYLGS7mzV579vJZfyGyD7CYTzK7F8X71nL7TpenFLxBBOry 2o3pL4lGQzscVmeUd+QqH9nY91vF7+DAorNW0aSUTxVur/Q/aG2ZA4GvjE5xwdcZ+UxZ L7i+RBMyV1h/LIsHWV3zRM6sVYW4rKLiCCUpk= MIME-Version: 1.0 Received: by 10.182.117.97 with SMTP id kd1mr16274535obb.50.1326831572894; Tue, 17 Jan 2012 12:19:32 -0800 (PST) Received: by 10.182.67.163 with HTTP; Tue, 17 Jan 2012 12:19:32 -0800 (PST) In-Reply-To: <20120117201807.GJ4729@azathoth.lan> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> <4F15BB21.50905@freebsd.org> <20120117201807.GJ4729@azathoth.lan> Date: Tue, 17 Jan 2012 12:19:32 -0800 Message-ID: From: Xin LI To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 20:43:05 -0000 On Tue, Jan 17, 2012 at 12:18 PM, Baptiste Daroussin wro= te: > On Tue, Jan 17, 2012 at 10:51:09AM -0800, Peter Wemm wrote: >> On Tue, Jan 17, 2012 at 10:17 AM, Julian Elischer w= rote: >> > On 1/17/12 9:29 AM, Warner Losh wrote: >> >> >> >> =C2=A0I have spent time with djb-ites in other areas. I tend to ignor= e >> >> =C2=A0their ranker and focus on the technical issues. I've had issues= with >> >> =C2=A0pidfiles and such in the past. There are a lot of hacks to get = around >> >> =C2=A0those issues, and things mostly work. If there's a good alterna= tive >> >> =C2=A0that can be demonstrated to work and gain us additional >> >> =C2=A0functionality, I'm all for it. I've fought with init() to make = it >> >> =C2=A0keep important daemons around should they die. I've worked with= other >> >> =C2=A0systems that make it easy to do and miss that on FreeBSD. It is >> >> =C2=A0possible, but not easy. If daemontools makes it easy, we should >> >> =C2=A0evaluate it. >> > >> > >> > >> > don't forget other alternatives.. >> > >> > for example we have launchd from apple which is quite a well >> > tested entry in the "init" space of solutions. >> >> At the risk of prolonging the discussion.. >> >> We use daemontools at work and I find it horrid to work with. =C2=A0Real= ly horrid. >> >> However, I do miss a real, pluggable services manager/starter/etc. >> launchd springs to mind, if only it wasn't .plist based. >> > > Shouldn't be hard to plug a better format to launchd, something like yaml= (Yes I > do like yaml :)) for example. > > what was the final statement of the launchd port summer of code? This has to be redone since launchd was later rewritten... Cheers, --=20 Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 21:28:19 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2267A1065670; Tue, 17 Jan 2012 21:28:19 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C534C8FC0C; Tue, 17 Jan 2012 21:28:18 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so4010708obc.13 for ; Tue, 17 Jan 2012 13:28:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.10.199 with SMTP id k7mr12936369igb.25.1326835698229; Tue, 17 Jan 2012 13:28:18 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 13:28:18 -0800 (PST) In-Reply-To: <20120117201807.GJ4729@azathoth.lan> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> <4F15BB21.50905@freebsd.org> <20120117201807.GJ4729@azathoth.lan> Date: Tue, 17 Jan 2012 13:28:18 -0800 Message-ID: From: Jos Backus To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:28:19 -0000 On Tue, Jan 17, 2012 at 12:18 PM, Baptiste Daroussin wrote: > Shouldn't be hard to plug a better format to launchd, something like yaml > (Yes I > do like yaml :)) for example. > I like YAML, too :) > > what was the final statement of the launchd port summer of code? > > Can we have something as simple as the current rc with launchd? (for end > users) > That would be cool... Jos > > regards, > Bapt > -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 21:29:53 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD85D106566C; Tue, 17 Jan 2012 21:29:53 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 71B5B8FC14; Tue, 17 Jan 2012 21:29:53 +0000 (UTC) Received: by iagz16 with SMTP id z16so8797066iag.13 for ; Tue, 17 Jan 2012 13:29:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.152.65 with SMTP id h1mr7734387icw.50.1326835792961; Tue, 17 Jan 2012 13:29:52 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 13:29:52 -0800 (PST) In-Reply-To: References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> <4F15BB21.50905@freebsd.org> <20120117201807.GJ4729@azathoth.lan> Date: Tue, 17 Jan 2012 13:29:52 -0800 Message-ID: From: Jos Backus To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Baptiste Daroussin , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:29:53 -0000 On Tue, Jan 17, 2012 at 12:19 PM, Xin LI wrote: > This has to be redone since launchd was later rewritten... > How much work would this be, you think? Doesn't launchd rely on some kernel functionality that FreeBSD doesn't have? Maybe I misremember. Jos -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 21:33:51 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99213106564A; Tue, 17 Jan 2012 21:33:51 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3BF8FC0A; Tue, 17 Jan 2012 21:33:51 +0000 (UTC) Received: by iagz16 with SMTP id z16so8803655iag.13 for ; Tue, 17 Jan 2012 13:33:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.180.9 with SMTP id bs9mr15620348icb.0.1326836030743; Tue, 17 Jan 2012 13:33:50 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 13:33:50 -0800 (PST) In-Reply-To: References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> Date: Tue, 17 Jan 2012 13:33:50 -0800 Message-ID: From: Jos Backus To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:33:51 -0000 On Mon, Jan 16, 2012 at 11:10 PM, Warner Losh wrote: > > On Jan 16, 2012, at 10:10 PM, Doug Barton wrote: > > > On 01/16/2012 19:41, Jos Backus wrote: > >> On Jan 16, 2012 6:53 PM, "Doug Barton" wrote: > >>> > >>> On 01/16/2012 12:53, Jos Backus wrote: > >>>> > >>>> Thoughts? > >>> > >>> This is already available in ports. > >> > >> I realize that. > > > > Good, then we're done. :) > > Not necessarily... > > >> If FreeBSD had a solid solution out of the box, all this pidfile > hackery in > >> the base system wouldn't be necessary. > > > > We don't do religious wars here. We especially don't do trollbait from > > djb acolytes. The "pidfile hackery" that we currently have works just > > fine in the vast majority of cases. The fact that it doesn't meet some > > people's ideas of architectural purity is totally beside the point. > > This isn't a religious war. This is someone coming to us and saying that > it might be a good idea to clean up the mess by importing a tiny bit of > extra code into the base. Seems like how we've always done things :) > > >> I always thought FreeBSD was about > >> good engineering. Perpetuating the pidfile mess in the base is not a > sign > >> of good engineering. > > > > FreeBSD is about giving people choices. Those who want to use > > daemontools can do that. > > > > And lest people think that I'm just hating on daemontools, I'm not. I > > use it for some things. But converting everything in the base to use it > > is a non-starter, even if we wanted to import it, which I don't see any > > need to do. > > I'm not convinced it is a non-starter. I'd fully support Jos if he wanted > to commit the code and had done the leg work to do it. I wouldn't support > just importing the daemontools and leaving it at that. If that's the plan, > then leaving it in ports is the best bet. > > Let's not dismiss this out of hand. > Thanks, Warner. I'm perfectly willing to make an effort moving FreeBSD forward in this area once we can achieve consensus on what moving forward means. I don't care about the implementation so much as having the functionality available out of the box. Porting launchd sounds like a good plan. Jos > Warner -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 21:47:22 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0EE8106566B; Tue, 17 Jan 2012 21:47:22 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 82AC18FC1E; Tue, 17 Jan 2012 21:47:22 +0000 (UTC) Received: by ggki1 with SMTP id i1so4440328ggk.13 for ; Tue, 17 Jan 2012 13:47:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.195.129 with SMTP id ie1mr19179190igc.29.1326836841660; Tue, 17 Jan 2012 13:47:21 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 13:47:21 -0800 (PST) In-Reply-To: <86mx9msog3.fsf@ds4.des.no> References: <4F14E291.5090803@FreeBSD.org> <86mx9msog3.fsf@ds4.des.no> Date: Tue, 17 Jan 2012 13:47:21 -0800 Message-ID: From: Jos Backus To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:47:22 -0000 2012/1/17 Dag-Erling Sm=F8rgrav > Jos Backus writes: > > If FreeBSD had a solid solution out of the box, all this pidfile hacker= y > in > > the base system wouldn't be necessary. I always thought FreeBSD was abo= ut > > good engineering. Perpetuating the pidfile mess in the base is not a si= gn > > of good engineering. > > Software written by DJB hardly qualifies as "good engineering". PID > files are well-known and well-tested, we have a solid implementation > with a simple API (pidfile(3)), and a lot of our infrastructure depends > on them (/etc/rc, newsyslog etc.) > Just because lots of people have been doing something for a long time that is widely supported, doesn't mean it's the right thing to do. As I said before, pidfiles export partial information that is already available in the process table, without requiring extra cached file system copies that need to be created/removed, have their permissions managed carefully and can get stale. daemontools is one implementation that solves the same problem without using pidfiles. It also gives you the option of a well-defined startup environment for each service (not tied to the environment of the caller) and the ability to add fine-grained control over a service (by manipulating the permissions on the control socket, so select non-root users can start root services if desired). It also comes with built-in logging (multilog). Additionally, using the finish script functionality, policies around crashes can be instituted (e.g. down the service and send an alert if it crashes more than N times within M minutes). These are just some of the features that I have used in the past to run services on hundreds of machines in multiple data centers. daemontools is surprisingly flexible, and it doesn't require complex configuration commands or configuration files - a boon when used in combination with tools like Puppet. That said, I don't care what we pick as long as we pick something that can do all the above. Jos > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > --=20 Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 21:50:03 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF15C106566C; Tue, 17 Jan 2012 21:50:02 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 984598FC13; Tue, 17 Jan 2012 21:50:02 +0000 (UTC) Received: by ggki1 with SMTP id i1so4442277ggk.13 for ; Tue, 17 Jan 2012 13:50:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.10.199 with SMTP id k7mr13009200igb.25.1326837001876; Tue, 17 Jan 2012 13:50:01 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 13:50:01 -0800 (PST) In-Reply-To: <86ipkasnyt.fsf@ds4.des.no> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <86ipkasnyt.fsf@ds4.des.no> Date: Tue, 17 Jan 2012 13:50:01 -0800 Message-ID: From: Jos Backus To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:50:03 -0000 2012/1/17 Dag-Erling Sm=F8rgrav > Warner Losh writes: > > I'm not convinced it is a non-starter. I'd fully support Jos if he > > wanted to commit the code and had done the leg work to do it. I > > wouldn't support just importing the daemontools and leaving it at > > that. If that's the plan, then leaving it in ports is the best bet. > > If we ever want to move in that direction, we should look at launchd, > not daemontools. > That's fine. I merely proposed daemontools because I have lots of experience with it, it is in the public domain and it seems less intrusive than launchd - it would just be a handful extra binaries people like me could use if they wanted to= . Jos > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > --=20 Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 21:54:07 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DB201065673; Tue, 17 Jan 2012 21:54:07 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 465878FC17; Tue, 17 Jan 2012 21:54:06 +0000 (UTC) Received: by iagz16 with SMTP id z16so8833881iag.13 for ; Tue, 17 Jan 2012 13:54:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.77.234 with SMTP id v10mr7388716igw.29.1326837246518; Tue, 17 Jan 2012 13:54:06 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 13:54:06 -0800 (PST) In-Reply-To: <86boq2smsv.fsf@ds4.des.no> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <86boq2smsv.fsf@ds4.des.no> Date: Tue, 17 Jan 2012 13:54:06 -0800 Message-ID: From: Jos Backus To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:54:07 -0000 2012/1/17 Dag-Erling Sm=F8rgrav > Jos Backus writes: > > I want/need a solution that works in (nearly) all cases and is devoid o= f > > complex code trying to track state that is already represented elsewher= e > in > > the system (the process table and the parent/child process > > relationship). > > Please show me the complex code required to handle pidfiles. > In my solution, no such code exists, so whatever code is there now (the pidfile library/API) is more complex by definition :) > > > I want a solution that can reliably handle a crashing server that > > doesn't clean up its pidfile > > That's a strawman. Whatever tool you use needs to be able to handle > stale pidfiles anyway. > Um, why? The solution I propose doesn't use pidfiles at all. > > > I want a unified control interface for the services running on a box, > > a la launchd or what have you. > > So extend service(8) to support enabling / disabling services through > /etc/rc.conf.d/. Probably no more than an afternoon's > work. > > > This isn't about religion but about missing base system functionality > > - the ability to reliably control services running on a box. > > The onus is on you to show that we don't already have that. > As I said before, the only thing we have today that will automatically restart services is init, and it is not flexible enough. That's where launchd would come in, but that would be a much more invasive change than just adding the daemontools bits, which would be optional and could be integrated gradually. Jos > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > --=20 Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 21:57:55 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA4BF1065674; Tue, 17 Jan 2012 21:57:55 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79E348FC1B; Tue, 17 Jan 2012 21:57:55 +0000 (UTC) Received: by iagz16 with SMTP id z16so8839174iag.13 for ; Tue, 17 Jan 2012 13:57:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.77.234 with SMTP id v10mr7403189igw.29.1326837474882; Tue, 17 Jan 2012 13:57:54 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 13:57:54 -0800 (PST) In-Reply-To: <20120117092422.5f8b0018.trhodes@FreeBSD.org> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F15284D.7010806@FreeBSD.org> <20120117092422.5f8b0018.trhodes@FreeBSD.org> Date: Tue, 17 Jan 2012 13:57:54 -0800 Message-ID: From: Jos Backus To: Tom Rhodes Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:57:55 -0000 On Tue, Jan 17, 2012 at 6:24 AM, Tom Rhodes wrote: > On Mon, 16 Jan 2012 23:50:37 -0800 > Doug Barton wrote: > > > On 01/16/2012 22:32, Jos Backus wrote: > > > > > I want/need a solution that works in (nearly) all cases and is devoid > of > > > complex code trying to track state that is already represented > elsewhere > > > in the system (the process table and the parent/child process > > > relationship). I want a solution that can reliably handle a crashing > > > server that doesn't clean up its pidfile (the finish script > > > functionality in daemontools-encore provides this), > > > > We get it, you want daemontools. It's in the ports, you can have it. > > > > > and I want a unified > > > control interface for the services running on a box, > > > > rc.d provides that, and service(8) makes that easier. > > > > > a la launchd or what have you. > > > > We've looked at importing launchd, or something like it. It's not a bad > > idea, it's just way more complex than it sounds. And a lot more work > > than "hey, let's import daemontools." > > > > If we were going to do something like this I think we should properly > > spec out what the goals should be, what the available solutions are, and > > what we want our ultimate solution to look like when we're done. > > > > > This isn't about religion but about missing base system > > > functionality - the ability to reliably control services running on a > box. > > > > And my argument is that we already have that in the base, it's just not > > the one you want; and since it's not the one you want you're redefining > > "reliably" to suit your needs. > > Just use/improve my fscd. I meant to import it but have > just ended up getting too busy. Now, I'm way too busy and > would be more than happy to help anyone bring it in. > I looked at fsc briefly but it seems to use pidfiles as well. I also don't like the BUGS section of fscd.8. The daemontools approach doesn't have this issue; if a service under daemontools' control dies for whatever reason, the OS will notify supervise and the finish script (in daemontools-encore) can perform any user-directed action as necessary. Jos > That said, happy new year. :P > > -- > Tom Rhodes > -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 22:04:57 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B65AA106566C; Tue, 17 Jan 2012 22:04:57 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 623518FC13; Tue, 17 Jan 2012 22:04:57 +0000 (UTC) Received: by ggki1 with SMTP id i1so4454088ggk.13 for ; Tue, 17 Jan 2012 14:04:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.195.129 with SMTP id ie1mr19248624igc.29.1326837896480; Tue, 17 Jan 2012 14:04:56 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 14:04:56 -0800 (PST) In-Reply-To: <20120117180044.GB43278@night.db.net> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> <20120117180044.GB43278@night.db.net> Date: Tue, 17 Jan 2012 14:04:56 -0800 Message-ID: From: Jos Backus To: Diane Bruce Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 22:04:57 -0000 On Tue, Jan 17, 2012 at 10:00 AM, Diane Bruce wrote: > On Tue, Jan 17, 2012 at 10:29:53AM -0700, Warner Losh wrote: > > > ... > > > > I have spent time with djb-ites in other areas. I tend to ignore their > rancor and focus on the technical issues. I've had issues with pidfiles > and such in the past. There are a lot of hacks to get around those issues, > and things mostly work. If there's a good alternative that can be > demonstrated to work and gain us additional functionality, I'm all for it. > I've fought with init() to make it keep important daemons around should > they die. I've worked with other systems that make it easy to do and miss > that on FreeBSD. It is possible, but not easy. If daemontools makes it > easy, we should evaluate it. > > It would be more useful to see what is offered with other systems and see > if we can provide the same or similar functionality with some sort of > 'standard' (I know impossible). How much work would it be to simply > add a few scripts as Doug suggests? etc. etc. Instead of just saying > "lets import everything in daemontools", what really is proposed? > How would it impact an embedded system? Is it yet more bloat that should > be delegated to the same pile of important ports as sendmail, bind etc. > that > some of us have been trying to get out of base? > I'm proposing that we add some sort of service management framework (big words, I know) to FreeBSD, as it seems to be the missing part between the OS and the services running on the OS such as Apache. The only solution that can handle automatic service restarts without some form of polling is init, but it is not flexible enough. I am proposing to add daemontools (specifically, daemontools-encore) because it could be added without affecting anything else in the base so it would be an easy import: don't use it if you don't want to. daemontools has not undergone many changes in recent years so if we were to import it it would likely not change much thereafter, requiring little maintenance. That said, if we feel that importing launchd is the better way to go, I'm all for it. I just want us to add something to fill the gap. Jos > > - Diane > -- > - db@FreeBSD.org db@db.net http://www.db.net/~db > Why leave money to our children if we don't leave them the Earth? > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 22:07:22 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E70EA106567D for ; Tue, 17 Jan 2012 22:07:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7F27B202DB8; Tue, 17 Jan 2012 22:07:07 +0000 (UTC) Message-ID: <4F15F10A.20600@FreeBSD.org> Date: Tue, 17 Jan 2012 14:07:06 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Jos Backus References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> <20120117180044.GB43278@night.db.net> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 22:07:23 -0000 On 01/17/2012 14:04, Jos Backus wrote: > I just want us to add something to fill the gap. I think that you have made your perspective quite clear at this point. -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 22:07:32 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EA8D106566C; Tue, 17 Jan 2012 22:07:32 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id CFC638FC12; Tue, 17 Jan 2012 22:07:31 +0000 (UTC) Received: by mail-iy0-f182.google.com with SMTP id z16so8852567iag.13 for ; Tue, 17 Jan 2012 14:07:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.152.65 with SMTP id h1mr7848075icw.50.1326838051595; Tue, 17 Jan 2012 14:07:31 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 14:07:31 -0800 (PST) In-Reply-To: References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> Date: Tue, 17 Jan 2012 14:07:31 -0800 Message-ID: From: Jos Backus To: Ivo Vachkov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 22:07:32 -0000 On Tue, Jan 17, 2012 at 1:56 PM, Ivo Vachkov wrote: > > > On Tue, Jan 17, 2012 at 11:33 PM, Jos Backus wrote: > >> On Mon, Jan 16, 2012 at 11:10 PM, Warner Losh wrote: >> >> > >> > On Jan 16, 2012, at 10:10 PM, Doug Barton wrote: >> > >> > > On 01/16/2012 19:41, Jos Backus wrote: >> > >> On Jan 16, 2012 6:53 PM, "Doug Barton" wrote: >> > >>> >> > >>> On 01/16/2012 12:53, Jos Backus wrote: >> > >>>> >> > >>>> Thoughts? >> > >>> >> > >>> This is already available in ports. >> > >> >> > >> I realize that. >> > > >> > > Good, then we're done. :) >> > >> > Not necessarily... >> > >> > >> If FreeBSD had a solid solution out of the box, all this pidfile >> > hackery in >> > >> the base system wouldn't be necessary. >> > > >> > > We don't do religious wars here. We especially don't do trollbait from >> > > djb acolytes. The "pidfile hackery" that we currently have works just >> > > fine in the vast majority of cases. The fact that it doesn't meet some >> > > people's ideas of architectural purity is totally beside the point. >> > >> > This isn't a religious war. This is someone coming to us and saying >> that >> > it might be a good idea to clean up the mess by importing a tiny bit of >> > extra code into the base. Seems like how we've always done things :) >> > >> > >> I always thought FreeBSD was about >> > >> good engineering. Perpetuating the pidfile mess in the base is not a >> > sign >> > >> of good engineering. >> > > >> > > FreeBSD is about giving people choices. Those who want to use >> > > daemontools can do that. >> > > >> > > And lest people think that I'm just hating on daemontools, I'm not. I >> > > use it for some things. But converting everything in the base to use >> it >> > > is a non-starter, even if we wanted to import it, which I don't see >> any >> > > need to do. >> > >> > I'm not convinced it is a non-starter. I'd fully support Jos if he >> wanted >> > to commit the code and had done the leg work to do it. I wouldn't >> support >> > just importing the daemontools and leaving it at that. If that's the >> plan, >> > then leaving it in ports is the best bet. >> > >> > Let's not dismiss this out of hand. >> > >> >> Thanks, Warner. >> >> I'm perfectly willing to make an effort moving FreeBSD forward in this >> area once we can achieve consensus on what moving forward means. I don't >> care about the implementation so much as having the functionality >> available >> out of the box. Porting launchd sounds like a good plan. >> >> Jos >> >> >> > Wouldn't it be more logical to first: > 1) Define what a modern start/boot/service control system should do? > 2) Define technological and architectural constraints? > ... and only then jump to "port *this*" kind of discussions ... > > I know of at least one successful commercial project to port launchd on > FreeBSD (6.x and 7.x), but still there are also others: initNG, eINIT, > Upstart, Service Management Facility, etc. > > I don't want to start another flamewar here, i'm aware of license issues, > dead code, commercial issues and so on, I just want to point out that there > are other options and IMHO the focus should not be on what to port, but > what to develop that suits our needs. > If people feel that's the right thing to talk about first, by all means, sure. Jos > > > >> > Warner >> >> >> >> >> -- >> Jos Backus >> jos at catnook.com >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> > > > > -- > Ivo Vachkov > -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 22:08:51 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28421106566C; Tue, 17 Jan 2012 22:08:51 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA35F8FC16; Tue, 17 Jan 2012 22:08:50 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so4070216obc.13 for ; Tue, 17 Jan 2012 14:08:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.168.70 with SMTP id zu6mr17005213igb.1.1326838130309; Tue, 17 Jan 2012 14:08:50 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 14:08:50 -0800 (PST) In-Reply-To: <4F15F10A.20600@FreeBSD.org> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> <20120117180044.GB43278@night.db.net> <4F15F10A.20600@FreeBSD.org> Date: Tue, 17 Jan 2012 14:08:50 -0800 Message-ID: From: Jos Backus To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 22:08:51 -0000 On Tue, Jan 17, 2012 at 2:07 PM, Doug Barton wrote: > On 01/17/2012 14:04, Jos Backus wrote: > > I just want us to add something to fill the gap. > > I think that you have made your perspective quite clear at this point. > Excellent! I'd like to think that good communication is half the struggle :) Jos -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 22:17:14 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19DD6106566B; Tue, 17 Jan 2012 22:17:14 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id B1C588FC17; Tue, 17 Jan 2012 22:17:13 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q0HM9C1d006676 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 17 Jan 2012 15:09:14 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) From: Warner Losh In-Reply-To: Date: Tue, 17 Jan 2012 15:09:06 -0700 Message-Id: <254DCE9D-5E28-4B21-99C5-F36283BB5AE6@bsdimp.com> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> To: Jos Backus X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 17 Jan 2012 15:09:14 -0700 (MST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 22:17:14 -0000 On Jan 17, 2012, at 2:33 PM, Jos Backus wrote: > Let's not dismiss this out of hand. >=20 > Thanks, Warner. >=20 > I'm perfectly willing to make an effort moving FreeBSD forward in = this area once we can achieve consensus on what moving forward means. I = don't care about the implementation so much as having the functionality = available out of the box. Porting launchd sounds like a good plan. Sounds like a good idea. I know the current init stuff is weak and has = to be worked around. /etc/rc.d has no interaction with init at this = level, which is what the problem is. init has the ability to keep = things alive, but little flexibility. /etc/rc.d has the ability to = launch a bunch of stuff, but little ability to keep things alive. Any = improvement in this area is needed. launchd is a better solution still, = and I look forward to seeing it in the tree if you get it working. But to reiterate my point: the judgement will be on the result of the = work. If it is done poorly, it may not make it into the tree. If it = turns out that launchd has some fundamental incompatibility with = FreeBSD, you may have to do a lot of work for no gain in the tree. On = the other hand, it should work well and likely is less work than = integrating daemontools completely into the system (key point here is = completely). Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 22:26:22 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BC291065680; Tue, 17 Jan 2012 22:26:22 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B17198FC1F; Tue, 17 Jan 2012 22:26:21 +0000 (UTC) Received: by qcse1 with SMTP id e1so2056638qcs.13 for ; Tue, 17 Jan 2012 14:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HHfYsAgPOVQts6gW77f/hTqUM8A3jMzcBedboFJqs6k=; b=DrJOkw5vTGxdCpR7ihspcSQemsjjFAu/BKCPb3nxuNpt9P4YkaFp6A2RFqPoR4DHlB llhfmKlUisSGG8F66cazwu5Tkpm26bu6AbuGsQly5hPmSrRabLtiga4UB7Q1K608ElR4 YIo96wJP5Ct1vJ8aeWmI/R6eFwaplvZAQylHg= Received: by 10.229.78.145 with SMTP id l17mr7119600qck.141.1326837426186; Tue, 17 Jan 2012 13:57:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.47.85 with HTTP; Tue, 17 Jan 2012 13:56:45 -0800 (PST) In-Reply-To: References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> From: Ivo Vachkov Date: Tue, 17 Jan 2012 23:56:45 +0200 Message-ID: To: Jos Backus Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 22:26:22 -0000 On Tue, Jan 17, 2012 at 11:33 PM, Jos Backus wrote: > On Mon, Jan 16, 2012 at 11:10 PM, Warner Losh wrote: > > > > > On Jan 16, 2012, at 10:10 PM, Doug Barton wrote: > > > > > On 01/16/2012 19:41, Jos Backus wrote: > > >> On Jan 16, 2012 6:53 PM, "Doug Barton" wrote: > > >>> > > >>> On 01/16/2012 12:53, Jos Backus wrote: > > >>>> > > >>>> Thoughts? > > >>> > > >>> This is already available in ports. > > >> > > >> I realize that. > > > > > > Good, then we're done. :) > > > > Not necessarily... > > > > >> If FreeBSD had a solid solution out of the box, all this pidfile > > hackery in > > >> the base system wouldn't be necessary. > > > > > > We don't do religious wars here. We especially don't do trollbait from > > > djb acolytes. The "pidfile hackery" that we currently have works just > > > fine in the vast majority of cases. The fact that it doesn't meet some > > > people's ideas of architectural purity is totally beside the point. > > > > This isn't a religious war. This is someone coming to us and saying that > > it might be a good idea to clean up the mess by importing a tiny bit of > > extra code into the base. Seems like how we've always done things :) > > > > >> I always thought FreeBSD was about > > >> good engineering. Perpetuating the pidfile mess in the base is not a > > sign > > >> of good engineering. > > > > > > FreeBSD is about giving people choices. Those who want to use > > > daemontools can do that. > > > > > > And lest people think that I'm just hating on daemontools, I'm not. I > > > use it for some things. But converting everything in the base to use it > > > is a non-starter, even if we wanted to import it, which I don't see any > > > need to do. > > > > I'm not convinced it is a non-starter. I'd fully support Jos if he > wanted > > to commit the code and had done the leg work to do it. I wouldn't > support > > just importing the daemontools and leaving it at that. If that's the > plan, > > then leaving it in ports is the best bet. > > > > Let's not dismiss this out of hand. > > > > Thanks, Warner. > > I'm perfectly willing to make an effort moving FreeBSD forward in this > area once we can achieve consensus on what moving forward means. I don't > care about the implementation so much as having the functionality available > out of the box. Porting launchd sounds like a good plan. > > Jos > > > Wouldn't it be more logical to first: 1) Define what a modern start/boot/service control system should do? 2) Define technological and architectural constraints? ... and only then jump to "port *this*" kind of discussions ... I know of at least one successful commercial project to port launchd on FreeBSD (6.x and 7.x), but still there are also others: initNG, eINIT, Upstart, Service Management Facility, etc. I don't want to start another flamewar here, i'm aware of license issues, dead code, commercial issues and so on, I just want to point out that there are other options and IMHO the focus should not be on what to port, but what to develop that suits our needs. > > Warner > > > > > -- > Jos Backus > jos at catnook.com > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Ivo Vachkov From owner-freebsd-arch@FreeBSD.ORG Tue Jan 17 23:52:57 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42FA21065672; Tue, 17 Jan 2012 23:52:57 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by mx1.freebsd.org (Postfix) with ESMTP id 2003E8FC14; Tue, 17 Jan 2012 23:52:56 +0000 (UTC) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id AADC336006B; Tue, 17 Jan 2012 15:52:56 -0800 (PST) Received: from lab (ip72-219-240-45.dc.dc.cox.net [72.219.240.45]) (Authenticated sender: trhodes@fbsdsecure.org) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 18980360014; Tue, 17 Jan 2012 15:52:56 -0800 (PST) Date: Tue, 17 Jan 2012 18:52:47 -0500 From: Tom Rhodes To: Jos Backus Message-Id: <20120117185247.4fef62a8.trhodes@FreeBSD.org> In-Reply-To: References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F15284D.7010806@FreeBSD.org> <20120117092422.5f8b0018.trhodes@FreeBSD.org> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: trhodes@freebsd.org, dougb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 23:52:57 -0000 On Tue, 17 Jan 2012 13:57:54 -0800 Jos Backus wrote: > On Tue, Jan 17, 2012 at 6:24 AM, Tom Rhodes wrote: > > > On Mon, 16 Jan 2012 23:50:37 -0800 > > Doug Barton wrote: > > > > > On 01/16/2012 22:32, Jos Backus wrote: > > > > > > > I want/need a solution that works in (nearly) all cases and is devoid > > of > > > > complex code trying to track state that is already represented > > elsewhere > > > > in the system (the process table and the parent/child process > > > > relationship). I want a solution that can reliably handle a crashing > > > > server that doesn't clean up its pidfile (the finish script > > > > functionality in daemontools-encore provides this), > > > > > > We get it, you want daemontools. It's in the ports, you can have it. > > > > > > > and I want a unified > > > > control interface for the services running on a box, > > > > > > rc.d provides that, and service(8) makes that easier. > > > > > > > a la launchd or what have you. > > > > > > We've looked at importing launchd, or something like it. It's not a bad > > > idea, it's just way more complex than it sounds. And a lot more work > > > than "hey, let's import daemontools." > > > > > > If we were going to do something like this I think we should properly > > > spec out what the goals should be, what the available solutions are, and > > > what we want our ultimate solution to look like when we're done. > > > > > > > This isn't about religion but about missing base system > > > > functionality - the ability to reliably control services running on a > > box. > > > > > > And my argument is that we already have that in the base, it's just not > > > the one you want; and since it's not the one you want you're redefining > > > "reliably" to suit your needs. > > > > Just use/improve my fscd. I meant to import it but have > > just ended up getting too busy. Now, I'm way too busy and > > would be more than happy to help anyone bring it in. > > > > I looked at fsc briefly but it seems to use pidfiles as well. I also don't > like the BUGS section of fscd.8. The daemontools approach doesn't have this > issue; if a service under daemontools' control dies for whatever reason, > the OS will notify supervise and the finish script (in daemontools-encore) > can perform any user-directed action as necessary. > That bug could be fixed (IIRC what it was) - and it does most of the legwork you're talking about, removing pidfile requirements would probably be trivial for someone with a free evening. Regardless, I tried to find a common ground with launchd and nothing, the community is more than welcome to make changes. Maybe I'll just test build and bring it in, then people can make it work the way they'd like. ;) -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Wed Jan 18 01:39:05 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9FF51065672; Wed, 18 Jan 2012 01:39:05 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A18F8FC15; Wed, 18 Jan 2012 01:39:05 +0000 (UTC) Received: by iagz16 with SMTP id z16so9199809iag.13 for ; Tue, 17 Jan 2012 17:39:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.195.129 with SMTP id ie1mr19860735igc.29.1326850744927; Tue, 17 Jan 2012 17:39:04 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 17:39:04 -0800 (PST) In-Reply-To: <20120117185247.4fef62a8.trhodes@FreeBSD.org> References: <4F14E291.5090803@FreeBSD.org> <4F1502CD.90409@FreeBSD.org> <4F15284D.7010806@FreeBSD.org> <20120117092422.5f8b0018.trhodes@FreeBSD.org> <20120117185247.4fef62a8.trhodes@FreeBSD.org> Date: Tue, 17 Jan 2012 17:39:04 -0800 Message-ID: From: Jos Backus To: Tom Rhodes Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: dougb@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 01:39:05 -0000 On Tue, Jan 17, 2012 at 3:52 PM, Tom Rhodes wrote: > [snip] > That bug could be fixed (IIRC what it was) - and it does most of the > legwork you're talking about, removing pidfile requirements would > probably be trivial for someone with a free evening. Regardless, I > tried to find a common ground with launchd and nothing, the > community is more than welcome to make changes. Maybe I'll > just test build and bring it in, then people can make it work the > way they'd like. ;) > I'm not opposed to this if the consensus is that we want to try this. Here are some of the things I like about daemontools that I would want any accepted solution to support, as I have actively used all these features in the past: - Decouple running of the service from the user controlling the service. With daemontools, this is handled by the service run script being run by supervise in response to a command sent across a UNIX domain socket. No environment variables or other user state can leak into the service process by default. - The ability for arbitrary sets of (non-root) users to control a service. With daemontools this can be achieved by manipulating the UNIX domain socket permissions for a service. - The ability to reliably deal with crashing processes and be able to take action upon signals/non-zero exits. With daemontools-encore, the finish script lets one fine-tune these cases, and standard daemontools can automatically restart a service. - Simple command interface to bring a service up or down, up once (one-shot) or send signals. With daemontools, the svc command is used for this. - Simple command interface to see the status of a service, including its uptime and pending status. E.g. with daemontools, svstat will display service status and uptime, including if a service wants to go down. - Simple service configuration. In daemontools, the file system is used. This makes it possible to use tools such as `echo', `rm' and `ln -s' to manipulate and configure services independently from each other. I don't like a single shared configuration file such as /etc/inittab because it makes it difficult to edit services safely as the wrong edit can affect all services (think Puppet). E.g. with daemontools, enabling a service can be as simple as an `ln -s' command. Editing the state of one service should not be able to affect any other service. - Handle logging of stdout/stderr. daemontools uses the associated log service for this, usually with multilog. - No reliance on pidfiles. In daemontools, supervise is the parent of a service so it already knows its child's pid. If fsc can be made to do all these things too and we feel more comfortable with it than importing daemontools, that's great. Jos -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Wed Jan 18 02:08:15 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D1B5106564A for ; Wed, 18 Jan 2012 02:08:15 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id B64FF8FC18 for ; Wed, 18 Jan 2012 02:08:14 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.1.339.1; Tue, 17 Jan 2012 20:57:22 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 6B48F33C02; Tue, 17 Jan 2012 20:57:22 -0500 (EST) Date: Tue, 17 Jan 2012 20:57:21 -0500 From: Ed Maste To: Jos Backus Message-ID: <20120118015720.GA17409@sandvine.com> References: <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> <4F15BB21.50905@freebsd.org> <20120117201807.GJ4729@azathoth.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 02:08:15 -0000 On Tue, Jan 17, 2012 at 01:29:52PM -0800, Jos Backus wrote: > How much work would this be, you think? Doesn't launchd rely on some kernel > functionality that FreeBSD doesn't have? Maybe I misremember. Are you perhaps thinking of systemd, which does use a whole bunch of Linux-specific features? There was a GSoC project to port launchd in the past; I have no idea how much it has changed since then. http://wiki.freebsd.org/launchd -Ed From owner-freebsd-arch@FreeBSD.ORG Wed Jan 18 02:17:42 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F7A6106566B for ; Wed, 18 Jan 2012 02:17:42 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 059B28FC08 for ; Wed, 18 Jan 2012 02:17:41 +0000 (UTC) Received: by iagz16 with SMTP id z16so9271358iag.13 for ; Tue, 17 Jan 2012 18:17:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.168.4 with SMTP id zs4mr11742488igb.25.1326853060937; Tue, 17 Jan 2012 18:17:40 -0800 (PST) Received: by 10.42.140.196 with HTTP; Tue, 17 Jan 2012 18:17:40 -0800 (PST) In-Reply-To: <20120118015720.GA17409@sandvine.com> References: <4F1502CD.90409@FreeBSD.org> <4F152475.50503@FreeBSD.org> <33752E6C-E016-4C7E-92DD-97B531D185E7@bsdimp.com> <4F15BB21.50905@freebsd.org> <20120117201807.GJ4729@azathoth.lan> <20120118015720.GA17409@sandvine.com> Date: Tue, 17 Jan 2012 18:17:40 -0800 Message-ID: From: Jos Backus To: Ed Maste Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 02:17:42 -0000 On Tue, Jan 17, 2012 at 5:57 PM, Ed Maste wrote: > On Tue, Jan 17, 2012 at 01:29:52PM -0800, Jos Backus wrote: > > > How much work would this be, you think? Doesn't launchd rely on some > kernel > > functionality that FreeBSD doesn't have? Maybe I misremember. > > Are you perhaps thinking of systemd, which does use a whole bunch of > Linux-specific features? > Probably :) I guess part of the launchd porting effort was removing stuff that FreeBSD doesn't support out of the box, such as zeroconf/Bonjour. > There was a GSoC project to port launchd in the past; I have no idea > how much it has changed since then. > > http://wiki.freebsd.org/launchd I found the wiki and the Perforce soc2005 branch on perforce.freebsd.org, as well as the official launchd Subversion repo at http://launchd.macosforge.org. There's also https://github.com/rtyler/launchd-for-freebsd which seems to based on the Subversion repo but at an older revision. Only the Perforce branch seems to have any FreeBSD build glue. I guess a plan would be to port the changes made to Subversion trunk since the Perforce snapshot was taken to the Perforce branch. It looks like launchd hasn't changed in several years. After looking at the launchd code for a little bit, it looks much more complicated than daemontools, which in turn worries me in terms of its expected robustness. One of the nice properties of daemontools is that the individual pieces are fairly small and have been proven in the field to work well. Specifically, I'm worried that it will be harder to create a quality port of launchd compared to daemontools, and as Warner has hinted at, the port needs to work well for it to be accepted. It seems to me that a working port of daemontools is easier to achieve because the code is (much) simpler. Hence the chances of a solution to be accepted seem higher when using daemontools as a base. But maybe I'm overestimating the amount of work needed to get launchd into good enough shape to be committed. Jos > > -Ed > -- Jos Backus jos at catnook.com From owner-freebsd-arch@FreeBSD.ORG Thu Jan 19 13:50:54 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D6DF106564A; Thu, 19 Jan 2012 13:50:54 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CC3638FC13; Thu, 19 Jan 2012 13:50:53 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0JDopOB034080; Thu, 19 Jan 2012 13:50:51 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4F181FBB.4060104@gmail.com> Date: Thu, 19 Jan 2012 21:50:51 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Jos Backus References: <4F14E291.5090803@FreeBSD.org> <86mx9msog3.fsf@ds4.des.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Doug Barton , freebsd-arch@freebsd.org Subject: Re: Importing djb's public domain daemontools? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 13:50:54 -0000 On 2012/1/18 5:47, Jos Backus wrote: > 2012/1/17 Dag-Erling Smørgrav > >> Jos Backus writes: >>> If FreeBSD had a solid solution out of the box, all this pidfile hackery >> in >>> the base system wouldn't be necessary. I always thought FreeBSD was about >>> good engineering. Perpetuating the pidfile mess in the base is not a sign >>> of good engineering. >> Software written by DJB hardly qualifies as "good engineering". PID >> files are well-known and well-tested, we have a solid implementation >> with a simple API (pidfile(3)), and a lot of our infrastructure depends >> on them (/etc/rc, newsyslog etc.) >> > Just because lots of people have been doing something for a long time that > is widely supported, doesn't mean it's the right thing to do. > > As I said before, pidfiles export partial information that is already > available in the process table, without requiring extra cached file system > copies that need to be created/removed, have their permissions managed > carefully and can get stale. daemontools is one implementation that solves > the same problem without using pidfiles. It also gives you the option of a > well-defined startup environment for each service (not tied to the > environment of the caller) and the ability to add fine-grained control over > a service (by manipulating the permissions on the control socket, so select > non-root users can start root services if desired). It also comes with > built-in logging (multilog). Additionally, using the finish script > functionality, policies around crashes can be instituted (e.g. down the > service and send an alert if it crashes more than N times within M > minutes). These are just some of the features that I have used in the past > to run services on hundreds of machines in multiple data centers. > > daemontools is surprisingly flexible, and it doesn't require complex > configuration commands or configuration files - a boon when used in > combination with tools like Puppet. That said, I don't care what we pick as > long as we pick something that can do all the above. > > Jos > This sounds like a very cool tool, looks like these ideas are widely adopted, I found some of the concepts are also in erlang OTP. ;-) Regards, David Xu From owner-freebsd-arch@FreeBSD.ORG Fri Jan 20 20:30:29 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61DFE1065672; Fri, 20 Jan 2012 20:30:29 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id B7ADF8FC1E; Fri, 20 Jan 2012 20:30:28 +0000 (UTC) Received: from rnote.ddteam.net (55-40-133-95.pool.ukrtel.net [95.133.40.55]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 4CA9AC493A; Fri, 20 Jan 2012 22:13:29 +0200 (EET) Date: Fri, 20 Jan 2012 22:13:19 +0200 From: Aleksandr Rybalko To: freebsd-arch@FreeBSD.org, freebsd-net@FreeBSD.org Message-Id: <20120120221319.ca8b631f.ray@freebsd.org> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Ethernet Switch Framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 20:30:29 -0000 Hi, Sorry for cross posting. I just thought this might interesting to review for subscribers on both MLs. I glad to introduce working version of Ethernet Switch Framework. of course, here is so many things to do, but it already work and can help us in some situations for embedded devices. here is the patch: http://my.ddteam.net/files/2012-01-20_switch_framework.patch It include sys/mips/conf/AR7240, that together with hints file is good example for typical AR7240 setup. Since it still don't have any documentation, I will try to explain it here. The framework contain 3 basic parts: 1. core module, which handle ioctl calls and interact with driver. 2. Various bus glue (now it is obio(mem), mii(MDIO) and IIC in near future) 3. drivers. Atheros AR8x16, Broadcom BCM53xx, Ralink RT305xF, Realtek RTL8305/09 4. FloatPHY, pseudo driver which find master switchX device and ask his PHY reg's. 5. switchctl utility. Utility. Currently can do switchctl /dev/switch0 (get|set) (reg|port|vlan) [flags] get/set port: get or set port flags: "IngressCheck" - put port into VLAN mode, drop packets which have 802.1q tag with value != PVID "Q-in-Q" - enable double tag, add second tag to already tagged packets. "LAN" and "WAN" - flags, for switches which have special function for LAN-WAN processing. "Tagged" and "Untagged" - mark port Tagged/Untagged, used if switch using Global Tag flag (one flag for all VLANs) "pvid" - set Port VLAN ID Example: switchctl /dev/switch0 set port 2 pvid 2 flags IngressCheck LAN Tagged get/set vlan V: add N (tag|untag|forbid) - add port N to VLAN member ports as (tag| untag| forbid) del N - delete port N from VLAN member ports vid N - assign VLAN ID to internal index V Example: switchctl /dev/switch0 set vlan 2 vid 12 switchctl /dev/switch0 set vlan 2 add 2 u switchctl /dev/switch0 set vlan 2 del 1 get/set reg: Generic access to registers. Have 2 address modifiers: 0x00000000(no modifiers) - access to parent space (parent MDIO bus, if switchX attaches to miibusX) 0x40000000 - access to switch MDIO bus 0x80000000 - access to switch registers. Example: # switchctl /dev/switch0 get reg 0x80000008 Reg 0x80000008 Value = 0x012603e2 # switchctl /dev/switch0 get reg 0x00000008 Reg 0x00000008 Value = 0x0000ffff # switchctl /dev/switch0 get reg 0x40000001 Reg 0x40000001 Value = 0x00007949 # switchctl /dev/switch0 set reg 0x80000008 0x012603e2 Reg 0x80000008 Value = 0x012603e2 (Old value = 0x012603e2) FloatPHY pseudo driver which attach to miibus like normal PHY, but do find master switchX device and ask his PHY reg's. Main problem with that driver - is usage of newbus calls between independent device (not a parent <-> child), since floatphyX query set/get methods of switchX. Use hints: "master" - to set master name. "master_unit" - master unit. "master_phys" - bitmap of PHY numbers on which get link status/speed. "flags" - see driver (dev/switch/floatphy.c). "speed" - initial link speed value, used when no access to master. I will describe as example 4 situation that current framework is cover: 1. Ralink RT305X SoC, internal switch, one NIC with two paths. 2. Atheros AR7240 SoC, two NIC, but MDIO routed only from second 3. Cavium Octeon CN5010, one NIC with three paths + BCM53115 switch + some Broadcom PHY 1. Ralink RT305X - is simple one Attached by obio0 if driver present in kernel. VLAN features: it have so called global untagged flag, so port can be member of any VLAN but may be tagged or untagged in all VLAN in same time. How to enable: just add following into kernel config file. ------------------------------------------------ device switch device switch_rt305x ------------------------------------------------ 2. Atheros AR7240 - very interesting. have AR8216 internal switch and two arge NICs. arge0 MII bus connected to PHY4 which configured as separate PHY(not attached to switch core). But PHY4 reg's can be accessible only via switch MDIO bus access. arge1 MII bus connected to switch MII. But MDIO bus wired only on arge0, so if arge0 want to know speed and link status, it must ask switch connected to miibus attached to arge1. [1] Page 3 VLAN features: Like RT395x use global untagged like flag. How to enable (example config for AR7240 in patch) Config: ------------------------------------------------ device mii device switch device switch_ar8x16 ------------------------------------------------ hints: ------------------------------------------------ # No probe at all # First MDIO connected to switch which not have real PHY regs hint.miibus.0.phymask="0x00000000" # Second MDIO not wired at all hint.miibus.1.phymask="0x00000000" # Connect pseudo PHY driver to miibus0 hint.floatphy.0.at="miibus0" hint.floatphy.0.phyno=0 # floatphy0 will ask switch0 hint.floatphy.0.master="switch" hint.floatphy.0.master_unit=0 # and get link status from PHYs masked by 0x00000010 hint.floatphy.0.master_phys=0x00000010 # Sense PHY4 hint.floatphy.0.flags=0x00000000 # Default link speed 100 (if no access to master) hint.floatphy.0.speed=100 # Switch attached to MDIO bus on arge0 hint.switch.0.at="miibus0" hint.switch.0.phyno=1 # AR8x16 Magic register which can configure PHY4 as a standalone PHY hint.ar8x16_switch.0.mii_mode=0x012603e2 hint.floatphy.1.at="miibus1" hint.floatphy.1.phyno=0 hint.floatphy.1.master="switch" hint.floatphy.1.master_unit=0 # check link on PHY0-PHY3 (link on any rise link on arge1) hint.floatphy.1.master_phys=0x0000000f # Link Sensing PHY0-PHY3 hint.floatphy.1.flags=0x00000004 # "Link on any PHYs" | "Static link speed" hint.floatphy.1.speed=1000 ------------------------------------------------ 3. Cavium Octeon CN5010, one NIC with three paths + BCM53115 switch + some Broadcom PHY. Since here is required a lot of magic to attach anything that Cavium was not expect as "can be attached" (i.e. Cavium SDK limitation), I made patch which allow to attach one PHY driver per NIC path (per octe0 iface). VLAN features: it seems have most clear VLAN implementation, except some things like remapped some regs which have port bit maps. (seems forget to think about bigger port count when design small switches) How to enable: Config: ------------------------------------------------ device brgphy device switch device switch_bcm5325 ------------------------------------------------ Hints: ------------------------------------------------ hint.miibus.0.phymask="0x00000000" hint.miibus.1.phymask="0x00000000" hint.miibus.3.phymask="0x00000100" # brgphy will attach here hint.floatphy.0.at="miibus0" hint.floatphy.0.phyno=0 hint.floatphy.0.master="switch" hint.floatphy.0.master_unit=0 # Check link on any ports hint.floatphy.0.master_phys=0x0000001f # Sense PHY0 hint.floatphy.0.flags=0x00000000 hint.floatphy.0.speed=1000 hint.switch.0.at="miibus1" hint.switch.0.phyno=30 ------------------------------------------------ Huh, hope that is enough for first release of manual :) Will wait for any comments and suggestions! We're committing this in 5 days unless anyone objects in any meaningful way. 1. http://my.ddteam.net/files/Switch_Framework.pdf WBW -- Aleksandr Rybalko From owner-freebsd-arch@FreeBSD.ORG Fri Jan 20 23:08:38 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35DA0106564A for ; Fri, 20 Jan 2012 23:08:38 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 986E08FC18 for ; Fri, 20 Jan 2012 23:08:36 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 464C311D3F3 for ; Fri, 20 Jan 2012 23:08:35 +0000 (UTC) From: Stefan Bethke Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/mixed; boundary="Apple-Mail=_213E4B8A-6009-4FF8-A23A-C6A4E1D4CE37" Date: Sat, 21 Jan 2012 00:08:34 +0100 In-Reply-To: <20120111193738.GB44286@alchemy.franken.de> To: FreeBSD-arch References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> Message-Id: <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> X-Mailer: Apple Mail (2.1251.1) Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 23:08:38 -0000 --Apple-Mail=_213E4B8A-6009-4FF8-A23A-C6A4E1D4CE37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 11.01.2012 um 20:37 schrieb Marius Strobl: > Okay, I suggest to postpone this discussion until then. For the > scenario when mdiobus is the parent of miibus I see no technical > need to change miibus to support what you want to do, just implement > the miibus_if in mdiobus and redirect it to the device_t of the > MAC there. Moreover, that way the hack to sidestep newbus is contained > in the layer that actually needs it and not scattered over multiple > frameworks. I've posted to -net a patch that implements a workaround along those = lines. It solves two issues: talking to two upstream devices, and = providing a proper attachment for miibus. There's a number of things that made this harder than I would have = liked: - miibus has a funny way of attaching to it's parent. Making the parent = a bus that automatically attaches matching children does not lead to = good results. - miibus uses it's parents ivars. To clarify: device_get_ivars get's a = devices ivars, but those are owned by the parent; the bus uses = device_[gs]et_ivars(9) to manipulate it's own private per-child data = storage. The device must not manipulate them. I believe those = variables can be moved to mii_data. - miibus makes assumptions about it's children, namely that they have = specific softc's and that they provide callbacks outside of the newbus = method mechanism - miibus assumes that all devices attached to that mdio have certain = registers that have certain bits set or cleared - miibus calls it's parent methods and two explicit callbacks, plus = various calls into the interface management code. The second problem is that there's currently no way to express a = dependency between two devices other than a parent-child relationship. = I would be interested to learn why this appears to be so uncommon that I = could not find any discussion of such a feature. Has it really never = before come up? Leaving aside the miibus issue, the newbus problem is that the ethernet = driver (which is attached to some bus) needs to associate with some = other driver that might not be in it's vincinity, in particular neither = it's parent nor one of it's children. Compounding the problem is that = there is no way to express an attachment ordering constraint so that the = ethernet driver is only attached once the required mdio driver has = attached. Stefan --=20 Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_213E4B8A-6009-4FF8-A23A-C6A4E1D4CE37 Content-Disposition: attachment; filename=miiproxy.patch Content-Type: application/octet-stream; name="miiproxy.patch" Content-Transfer-Encoding: 7bit diff --git a/sys/dev/etherswitch/mdio.c b/sys/dev/etherswitch/mdio.c new file mode 100644 index 0000000..9302075 --- /dev/null +++ b/sys/dev/etherswitch/mdio.c @@ -0,0 +1,156 @@ +/*- + * Copyright (c) 2011-2012 Stefan Bethke. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include +#include + +#include + +#include "mdio_if.h" + +static void +mdio_identify(driver_t *driver, device_t parent) +{ + if (device_find_child(parent, mdio_driver.name, -1) == NULL) + BUS_ADD_CHILD(parent, 0, mdio_driver.name, -1); +} + +static int +mdio_probe(device_t dev) +{ + device_set_desc(dev, "MDIO"); + + return (BUS_PROBE_SPECIFIC); +} + +static int +mdio_attach(device_t dev) +{ + bus_generic_probe(dev); + bus_enumerate_hinted_children(dev); + return (bus_generic_attach(dev)); +} + +static int +mdio_detach(device_t dev) +{ + bus_generic_detach(dev); + return (0); +} + +static int +mdio_readreg(device_t dev, int phy, int reg) +{ + return MDIO_READREG(device_get_parent(dev), phy, reg); +} + +static int +mdio_writereg(device_t dev, int phy, int reg, int val) +{ + return MDIO_WRITEREG(device_get_parent(dev), phy, reg, val); +} + +static int +mdio_print_child(device_t dev, device_t child) +{ + int retval; + + retval = bus_print_child_header(dev, child); + retval += bus_print_child_footer(dev, child); + + return (retval); +} + +static int +mdio_read_ivar(device_t dev, device_t child __unused, int which, + uintptr_t *result) +{ + struct miibus_ivars *ivars; + + ivars = device_get_ivars(dev); + switch (which) { + default: + return (ENOENT); + } + return (0); +} + +static int +mdio_child_pnpinfo_str(device_t dev __unused, device_t child, char *buf, + size_t buflen) +{ + buf[0] = '\0'; + return (0); +} + +static int +mdio_child_location_str(device_t dev __unused, device_t child, char *buf, + size_t buflen) +{ + buf[0] = '\0'; + return (0); +} + +static void +mdio_hinted_child(device_t dev, const char *name, int unit) +{ + device_add_child(dev, name, unit); +} + +static device_method_t mdio_methods[] = { + /* device interface */ + DEVMETHOD(device_identify, mdio_identify), + DEVMETHOD(device_probe, mdio_probe), + DEVMETHOD(device_attach, mdio_attach), + DEVMETHOD(device_detach, mdio_detach), + DEVMETHOD(device_shutdown, bus_generic_shutdown), + + /* bus interface */ + DEVMETHOD(bus_print_child, mdio_print_child), + DEVMETHOD(bus_read_ivar, mdio_read_ivar), + DEVMETHOD(bus_child_pnpinfo_str, mdio_child_pnpinfo_str), + DEVMETHOD(bus_child_location_str, mdio_child_location_str), + DEVMETHOD(bus_add_child, device_add_child_ordered), + DEVMETHOD(bus_hinted_child, mdio_hinted_child), + + /* MDIO access */ + DEVMETHOD(mdio_readreg, mdio_readreg), + DEVMETHOD(mdio_writereg, mdio_writereg), + + DEVMETHOD_END +}; + +driver_t mdio_driver = { + "mdio", + mdio_methods, + 0 +}; + +devclass_t mdio_devclass; + diff --git a/sys/dev/etherswitch/mdio.h b/sys/dev/etherswitch/mdio.h new file mode 100644 index 0000000..52eddbd --- /dev/null +++ b/sys/dev/etherswitch/mdio.h @@ -0,0 +1,35 @@ +/*- + * Copyright (c) 2011-2012 Stefan Bethke. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _DEV_MII_MDIO_H_ +#define _DEV_MII_MDIO_H_ + +extern driver_t mdio_driver; +extern devclass_t mdio_devclass; + +#endif diff --git a/sys/dev/etherswitch/mdio_if.m b/sys/dev/etherswitch/mdio_if.m new file mode 100644 index 0000000..9aedd92 --- /dev/null +++ b/sys/dev/etherswitch/mdio_if.m @@ -0,0 +1,24 @@ +# $FreeBSD$ + +#include + +INTERFACE mdio; + +# +# Read register from device on MDIO bus +# +METHOD int readreg { + device_t dev; + int phy; + int reg; +}; + +# +# Write register to device on MDIO bus +# +METHOD int writereg { + device_t dev; + int phy; + int reg; + int val; +}; diff --git a/sys/dev/etherswitch/miiproxy.c b/sys/dev/etherswitch/miiproxy.c new file mode 100644 index 0000000..2791082 --- /dev/null +++ b/sys/dev/etherswitch/miiproxy.c @@ -0,0 +1,437 @@ +/*- + * Copyright (c) 2011-2012 Stefan Bethke. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "mdio_if.h" +#include "miibus_if.h" + + +MALLOC_DECLARE(M_MIIPROXY); +MALLOC_DEFINE(M_MIIPROXY, "miiproxy", "miiproxy data structures"); + +driver_t miiproxy_driver; +driver_t mdioproxy_driver; + +struct miiproxy_softc { + device_t parent; + device_t proxy; + device_t mdio; + miiproxy_attach_callback_t attach_callback; + void *attach_arg; +}; + +struct mdioproxy_softc { +}; + +/* + * The rendevous data structures and functions allow two device endpoints to + * match up, so that the proxy endpoint can be associated with a target + * endpoint. The proxy has to know the device name of the target that it + * wants to associate with, for example through a hint. The rendevous code + * makes no assumptions about the devices that want to meet. + */ +struct rendevous_entry; + +enum rendevous_op { + RENDEVOUS_ATTACH, + RENDEVOUS_DETACH +}; + +typedef int (*rendevous_callback_t)(enum rendevous_op, + struct rendevous_entry *); + +static SLIST_HEAD(rendevoushead, rendevous_entry) rendevoushead = + SLIST_HEAD_INITIALIZER(rendevoushead); + +struct rendevous_endpoint { + device_t device; + const char *name; + rendevous_callback_t callback; +}; + +struct rendevous_entry { + SLIST_ENTRY(rendevous_entry) entries; + struct rendevous_endpoint proxy; + struct rendevous_endpoint target; +}; + +/* + * Call the callback routines for both the proxy and the target. If either + * returns an error, undo the attachment. + */ +static int +rendevous_attach(struct rendevous_entry *e, struct rendevous_endpoint *ep) +{ + int error; + + error = e->proxy.callback(RENDEVOUS_ATTACH, e); + if (error == 0) + error = e->target.callback(RENDEVOUS_ATTACH, e); + if (error != 0) { + e->proxy.callback(RENDEVOUS_DETACH, e); + ep->device = NULL; + ep->callback = NULL; + } + return (error); +} + +/* + * Create an entry for the proxy in the rendevous list. The name parameter + * indicates the name of the device that is the target endpoint for this + * rendevous. The callback will be invoked as soon as the target is + * registered: either immediately if the target registered itself earlier, + * or once the target registers. + */ +static int +rendevous_register_proxy(device_t dev, const char *name, + rendevous_callback_t callback) +{ + struct rendevous_entry *e; + + KASSERT(callback != NULL, ("callback must not be NULL")); + SLIST_FOREACH(e, &rendevoushead, entries) { + if (strcmp(name, e->target.name) == 0) { + /* the target is already attached */ + e->proxy.name = device_get_nameunit(dev); + e->proxy.device = dev; + e->proxy.callback = callback; + return (rendevous_attach(e, &e->proxy)); + } + } + e = malloc(sizeof(*e), M_MIIPROXY, M_WAITOK | M_ZERO); + e->proxy.name = device_get_nameunit(dev); + e->proxy.device = dev; + e->proxy.callback = callback; + e->target.name = name; + SLIST_INSERT_HEAD(&rendevoushead, e, entries); + return (0); +} + +/* + * Create an entry in the rendevous list for the target. The callback will + * be called once the proxy has registered. + */ +static int +rendevous_register_target(device_t dev, rendevous_callback_t callback) +{ + struct rendevous_entry *e; + const char *name; + + KASSERT(callback != NULL, ("callback must not be NULL")); + name = device_get_nameunit(dev); + SLIST_FOREACH(e, &rendevoushead, entries) { + if (strcmp(name, e->target.name) == 0) { + e->target.device = dev; + e->target.callback = callback; + return (rendevous_attach(e, &e->target)); + } + } + e = malloc(sizeof(*e), M_MIIPROXY, M_WAITOK | M_ZERO); + e->target.name = name; + e->target.device = dev; + e->target.callback = callback; + SLIST_INSERT_HEAD(&rendevoushead, e, entries); + return (0); +} + +/* + * Remove the registration for the proxy. + */ +static int +rendevous_unregister_proxy(device_t dev) +{ + struct rendevous_entry *e; + int error = 0; + + SLIST_FOREACH(e, &rendevoushead, entries) { + if (e->proxy.device == dev) { + if (e->target.device == NULL) { + SLIST_REMOVE(&rendevoushead, e, rendevous_entry, entries); + free(e, M_MIIPROXY); + return (0); + } else { + e->proxy.callback(RENDEVOUS_DETACH, e); + e->target.callback(RENDEVOUS_DETACH, e); + } + e->proxy.device = NULL; + e->proxy.callback = NULL; + return (error); + } + } + return (ENOENT); +} + +/* + * Remove the registration for the target. + */ +static int +rendevous_unregister_target(device_t dev) +{ + struct rendevous_entry *e; + int error = 0; + + SLIST_FOREACH(e, &rendevoushead, entries) { + if (e->target.device == dev) { + if (e->proxy.device == NULL) { + SLIST_REMOVE(&rendevoushead, e, rendevous_entry, entries); + free(e, M_MIIPROXY); + return (0); + } else { + e->proxy.callback(RENDEVOUS_DETACH, e); + e->target.callback(RENDEVOUS_DETACH, e); + } + e->target.device = NULL; + e->target.callback = NULL; + return (error); + } + } + return (ENOENT); +} + +/* + * Functions of the proxy that is interposed between the ethernet interface + * driver and the miibus device. + */ + +static int +miiproxy_rendevous_callback(enum rendevous_op op, struct rendevous_entry *rendevous) +{ + struct miiproxy_softc *sc = device_get_softc(rendevous->proxy.device); + + switch (op) { + case RENDEVOUS_ATTACH: + sc->mdio = device_get_parent(rendevous->target.device); + (sc->attach_callback)(sc->attach_arg); + break; + case RENDEVOUS_DETACH: + sc->mdio = NULL; + /* detach miibus */ + } + return (0); +} + +static int +miiproxy_probe(device_t dev) +{ + device_set_desc(dev, "MII/MDIO proxy, MII side"); + + return (BUS_PROBE_SPECIFIC); +} + +static int +miiproxy_attach(device_t dev) +{ + /* + * The ethernet interface needs to call mii_attach_proxy() to pass + * the relevant parameters for rendevous with the MDIO target. + */ + return (bus_generic_attach(dev)); +} + +static int +miiproxy_detach(device_t dev) +{ + rendevous_unregister_proxy(dev); + bus_generic_detach(dev); + return (0); +} + +static int +miiproxy_readreg(device_t dev, int phy, int reg) +{ + struct miiproxy_softc *sc = device_get_softc(dev); + + if (sc->mdio != NULL) + return (MDIO_READREG(sc->mdio, phy, reg)); + return (-1); +} + +static int +miiproxy_writereg(device_t dev, int phy, int reg, int val) +{ + struct miiproxy_softc *sc = device_get_softc(dev); + + if (sc->mdio != NULL) + return (MDIO_WRITEREG(sc->mdio, phy, reg, val)); + return (-1); +} + +static void +miiproxy_statchg(device_t dev) +{ + MIIBUS_STATCHG(device_get_parent(dev)); +} + +static void +miiproxy_linkchg(device_t dev) +{ + MIIBUS_LINKCHG(device_get_parent(dev)); +} + +static void +miiproxy_mediainit(device_t dev) +{ + MIIBUS_MEDIAINIT(device_get_parent(dev)); +} + +/* + * Functions for the MDIO target device driver. + */ +static int +mdioproxy_rendevous_callback(enum rendevous_op op, struct rendevous_entry *rendevous) +{ + return (0); +} + +static void +mdioproxy_identify(driver_t *driver, device_t parent) +{ + device_t child; + + if (device_find_child(parent, driver->name, -1) == NULL) { + child = BUS_ADD_CHILD(parent, 0, driver->name, -1); + } +} + +static int +mdioproxy_probe(device_t dev) +{ + device_set_desc(dev, "MII/MDIO proxy, MDIO side"); + + return (BUS_PROBE_SPECIFIC); +} + +static int +mdioproxy_attach(device_t dev) +{ + rendevous_register_target(dev, mdioproxy_rendevous_callback); + return (bus_generic_attach(dev)); +} + +static int +mdioproxy_detach(device_t dev) +{ + rendevous_unregister_target(dev); + bus_generic_detach(dev); + return (0); +} + +/* + * Attach this proxy in place of miibus. The callback is called once all + * parts are in place, so that it can attach the miibus to the proxy device, + * and finish interface initialization. + */ +device_t +mii_attach_proxy(device_t dev, miiproxy_attach_callback_t cb, void *aa) +{ + struct miiproxy_softc *sc; + int error; + const char *name; + device_t miiproxy; + + if (resource_string_value(device_get_name(dev), + device_get_unit(dev), "mdio", &name) != 0) { + if (bootverbose) + printf("mii_attach_proxy: not attaching, no mdio" + " device hint for %s\n", device_get_nameunit(dev)); + return (NULL); + } + + miiproxy = device_add_child(dev, miiproxy_driver.name, -1); + error = bus_generic_attach(dev); + if (error != 0) { + device_printf(dev, "can't attach miiproxy\n"); + return (NULL); + } + sc = device_get_softc(miiproxy); + sc->parent = dev; + sc->proxy = miiproxy; + sc->attach_callback = cb; + sc->attach_arg = aa; + rendevous_register_proxy(miiproxy, name, miiproxy_rendevous_callback); + return (miiproxy); +} + +static device_method_t miiproxy_methods[] = { + /* device interface */ + DEVMETHOD(device_probe, miiproxy_probe), + DEVMETHOD(device_attach, miiproxy_attach), + DEVMETHOD(device_detach, miiproxy_detach), + DEVMETHOD(device_shutdown, bus_generic_shutdown), + + /* MII interface */ + DEVMETHOD(miibus_readreg, miiproxy_readreg), + DEVMETHOD(miibus_writereg, miiproxy_writereg), + DEVMETHOD(miibus_statchg, miiproxy_statchg), + DEVMETHOD(miibus_linkchg, miiproxy_linkchg), + DEVMETHOD(miibus_mediainit, miiproxy_mediainit), + + DEVMETHOD_END +}; + +static device_method_t mdioproxy_methods[] = { + /* device interface */ + DEVMETHOD(device_identify, mdioproxy_identify), + DEVMETHOD(device_probe, mdioproxy_probe), + DEVMETHOD(device_attach, mdioproxy_attach), + DEVMETHOD(device_detach, mdioproxy_detach), + DEVMETHOD(device_shutdown, bus_generic_shutdown), + + DEVMETHOD_END +}; + +DEFINE_CLASS_0(miiproxy, miiproxy_driver, miiproxy_methods, + sizeof(struct miiproxy_softc)); +DEFINE_CLASS_0(mdioproxy, mdioproxy_driver, mdioproxy_methods, + sizeof(struct mdioproxy_softc)); + +devclass_t miiproxy_devclass; +static devclass_t mdioproxy_devclass; + +DRIVER_MODULE(mdioproxy, mdio, mdioproxy_driver, mdioproxy_devclass, 0, 0); +DRIVER_MODULE(miibus, miiproxy, miibus_driver, miibus_devclass, 0, 0); +MODULE_VERSION(miiproxy, 1); +MODULE_DEPEND(miiproxy, miibus, 1, 1, 1); diff --git a/sys/dev/etherswitch/miiproxy.h b/sys/dev/etherswitch/miiproxy.h new file mode 100644 index 0000000..5b8ee7c --- /dev/null +++ b/sys/dev/etherswitch/miiproxy.h @@ -0,0 +1,39 @@ +/*- + * Copyright (c) 2011-2012 Stefan Bethke. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _DEV_ETHERSWITCH_MIIPROXY_H_ +#define _DEV_ETHERSWITCH_MIIPROXY_H_ + +typedef void (*miiproxy_attach_callback_t)(void *); + +extern devclass_t miiproxy_devclass; +extern driver_t miiproxy_driver; + +device_t mii_attach_proxy(device_t dev, miiproxy_attach_callback_t cb, void *aa); + +#endif diff --git a/sys/mips/atheros/if_arge.c b/sys/mips/atheros/if_arge.c index 0154ae2..3dd2e15 100644 --- a/sys/mips/atheros/if_arge.c +++ b/sys/mips/atheros/if_arge.c @@ -72,8 +72,18 @@ __FBSDID("$FreeBSD$"); #include #include +#include + +#if defined(ARGE_MDIO) +#include +#include +#include "mdio_if.h" +#endif + + MODULE_DEPEND(arge, ether, 1, 1, 1); MODULE_DEPEND(arge, miibus, 1, 1, 1); +MODULE_VERSION(arge, 1); #include "miibus_if.h" @@ -102,6 +112,7 @@ typedef enum { #endif static int arge_attach(device_t); +static int arge_attach_finish(struct arge_softc *sc); static int arge_detach(device_t); static void arge_flush_ddr(struct arge_softc *); static int arge_ifmedia_upd(struct ifnet *); @@ -134,6 +145,8 @@ static void arge_intr(void *); static int arge_intr_filter(void *); static void arge_tick(void *); +static void arge_hinted_child(device_t bus, const char *dname, int dunit); + /* * ifmedia callbacks for multiPHY MAC */ @@ -160,6 +173,10 @@ static device_method_t arge_methods[] = { DEVMETHOD(miibus_writereg, arge_miibus_writereg), DEVMETHOD(miibus_statchg, arge_miibus_statchg), + /* bus interface */ + DEVMETHOD(bus_add_child, device_add_child_ordered), + DEVMETHOD(bus_hinted_child, arge_hinted_child), + DEVMETHOD_END }; @@ -174,6 +191,37 @@ static devclass_t arge_devclass; DRIVER_MODULE(arge, nexus, arge_driver, arge_devclass, 0, 0); DRIVER_MODULE(miibus, arge, miibus_driver, miibus_devclass, 0, 0); +#if defined(ARGE_MDIO) +static int argemdio_probe(device_t); +static int argemdio_attach(device_t); +static int argemdio_detach(device_t); + +/* + * Declare an additional, separate driver for accessing the MDIO bus. + */ +static device_method_t argemdio_methods[] = { + /* Device interface */ + DEVMETHOD(device_probe, argemdio_probe), + DEVMETHOD(device_attach, argemdio_attach), + DEVMETHOD(device_detach, argemdio_detach), + + /* bus interface */ + DEVMETHOD(bus_add_child, device_add_child_ordered), + + /* MDIO access */ + DEVMETHOD(mdio_readreg, arge_miibus_readreg), + DEVMETHOD(mdio_writereg, arge_miibus_writereg), +}; + +DEFINE_CLASS_0(argemdio, argemdio_driver, argemdio_methods, + sizeof(struct arge_softc)); +static devclass_t argemdio_devclass; + +DRIVER_MODULE(miiproxy, arge, miiproxy_driver, miiproxy_devclass, 0, 0); +DRIVER_MODULE(argemdio, nexus, argemdio_driver, argemdio_devclass, 0, 0); +DRIVER_MODULE(mdio, argemdio, mdio_driver, mdio_devclass, 0, 0); +#endif + /* * RedBoot passes MAC address to entry point as environment * variable. platfrom_start parses it and stores in this variable @@ -234,15 +282,22 @@ arge_attach_sysctl(device_t dev) #endif } +#if defined(ARGE_MDIO) +static void +arge_attach_proxy(void *aa) +{ + arge_attach_finish(aa); +} +#endif + static int arge_attach(device_t dev) { - uint8_t eaddr[ETHER_ADDR_LEN]; struct ifnet *ifp; struct arge_softc *sc; - int error = 0, rid, phymask; + int error = 0, rid; uint32_t reg, rnd; - int is_base_mac_empty, i, phys_total; + int is_base_mac_empty, i; uint32_t hint; long eeprom_mac_addr = 0; @@ -277,18 +332,18 @@ arge_attach(device_t dev) * Get which PHY of 5 available we should use for this unit */ if (resource_int_value(device_get_name(dev), device_get_unit(dev), - "phymask", &phymask) != 0) { + "phymask", &sc->arge_phymask) != 0) { /* * Use port 4 (WAN) for GE0. For any other port use * its PHY the same as its unit number */ if (sc->arge_mac_unit == 0) - phymask = (1 << 4); + sc->arge_phymask = (1 << 4); else /* Use all phys up to 4 */ - phymask = (1 << 4) - 1; + sc->arge_phymask = (1 << 4) - 1; - device_printf(dev, "No PHY specified, using mask %d\n", phymask); + device_printf(dev, "No PHY specified, using mask %d\n", sc->arge_phymask); } /* @@ -313,8 +368,6 @@ arge_attach(device_t dev) else sc->arge_duplex_mode = 0; - sc->arge_phymask = phymask; - mtx_init(&sc->arge_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK, MTX_DEF); callout_init_mtx(&sc->arge_stat_callout, &sc->arge_mtx, 0); @@ -323,7 +376,7 @@ arge_attach(device_t dev) /* Map control/status registers. */ sc->arge_rid = 0; sc->arge_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, - &sc->arge_rid, RF_ACTIVE); + &sc->arge_rid, RF_ACTIVE | RF_SHAREABLE); if (sc->arge_res == NULL) { device_printf(dev, "couldn't map memory\n"); @@ -371,8 +424,8 @@ arge_attach(device_t dev) is_base_mac_empty = 1; for (i = 0; i < ETHER_ADDR_LEN; i++) { - eaddr[i] = ar711_base_mac[i] & 0xff; - if (eaddr[i] != 0) + sc->arge_eaddr[i] = ar711_base_mac[i] & 0xff; + if (sc->arge_eaddr[i] != 0) is_base_mac_empty = 0; } @@ -385,16 +438,15 @@ arge_attach(device_t dev) "Generating random ethernet address.\n"); rnd = arc4random(); - eaddr[0] = 'b'; - eaddr[1] = 's'; - eaddr[2] = 'd'; - eaddr[3] = (rnd >> 24) & 0xff; - eaddr[4] = (rnd >> 16) & 0xff; - eaddr[5] = (rnd >> 8) & 0xff; + sc->arge_eaddr[0] = 'b'; + sc->arge_eaddr[1] = 's'; + sc->arge_eaddr[2] = 'd'; + sc->arge_eaddr[3] = (rnd >> 24) & 0xff; + sc->arge_eaddr[4] = (rnd >> 16) & 0xff; + sc->arge_eaddr[5] = (rnd >> 8) & 0xff; } - if (sc->arge_mac_unit != 0) - eaddr[5] += sc->arge_mac_unit; + sc->arge_eaddr[5] += sc->arge_mac_unit; if (arge_dma_alloc(sc) != 0) { error = ENXIO; @@ -423,19 +475,23 @@ arge_attach(device_t dev) ARGE_WRITE(sc, AR71XX_MAC_MAX_FRAME_LEN, 1536); +#if !defined(ARGE_MDIO) /* Reset MII bus */ ARGE_WRITE(sc, AR71XX_MAC_MII_CFG, MAC_MII_CFG_RESET); DELAY(100); ARGE_WRITE(sc, AR71XX_MAC_MII_CFG, MAC_MII_CFG_CLOCK_DIV_28); DELAY(100); +#endif /* * Set all Ethernet address registers to the same initial values * set all four addresses to 66-88-aa-cc-dd-ee */ - ARGE_WRITE(sc, AR71XX_MAC_STA_ADDR1, - (eaddr[2] << 24) | (eaddr[3] << 16) | (eaddr[4] << 8) | eaddr[5]); - ARGE_WRITE(sc, AR71XX_MAC_STA_ADDR2, (eaddr[0] << 8) | eaddr[1]); + ARGE_WRITE(sc, AR71XX_MAC_STA_ADDR1, (sc->arge_eaddr[2] << 24) + | (sc->arge_eaddr[3] << 16) | (sc->arge_eaddr[4] << 8) + | sc->arge_eaddr[5]); + ARGE_WRITE(sc, AR71XX_MAC_STA_ADDR2, (sc->arge_eaddr[0] << 8) + | sc->arge_eaddr[1]); ARGE_WRITE(sc, AR71XX_MAC_FIFO_CFG0, FIFO_CFG0_ALL << FIFO_CFG0_ENABLE_SHIFT); @@ -458,30 +514,44 @@ arge_attach(device_t dev) ARGE_WRITE(sc, AR71XX_MAC_FIFO_RX_FILTMASK, FIFO_RX_FILTMASK_DEFAULT); - /* - * Check if we have single-PHY MAC or multi-PHY - */ - phys_total = 0; - for (i = 0; i < ARGE_NPHY; i++) - if (phymask & (1 << i)) - phys_total ++; +#if defined(ARGE_MDIO) + sc->arge_miiproxy = mii_attach_proxy(sc->arge_dev, arge_attach_proxy, sc); + if (sc->arge_miiproxy == NULL) + return (arge_attach_finish(sc)); +#else + return (arge_attach_finish(sc)); +#endif +fail: + if (error) + arge_detach(dev); - if (phys_total == 0) { - error = EINVAL; - goto fail; - } + return (error); +} - if (phys_total == 1) { - /* Do MII setup. */ - error = mii_attach(dev, &sc->arge_miibus, ifp, - arge_ifmedia_upd, arge_ifmedia_sts, BMSR_DEFCAPMASK, - MII_PHY_ANY, MII_OFFSET_ANY, 0); - if (error != 0) { - device_printf(dev, "attaching PHYs failed\n"); - goto fail; +static int +arge_attach_finish(struct arge_softc *sc) +{ + int error, phy; + + device_printf(sc->arge_dev, "finishing attachment, phymask %04x" + ", proxy %s \n", sc->arge_phymask, sc->arge_miiproxy == NULL ? + "null" : "set"); + for (phy = 0; phy < ARGE_NPHY; phy++) { + if (((1 << phy) & sc->arge_phymask) != 0) { + error = mii_attach(sc->arge_miiproxy != NULL ? + sc->arge_miiproxy : sc->arge_dev, + &sc->arge_miibus, sc->arge_ifp, + arge_ifmedia_upd, arge_ifmedia_sts, + BMSR_DEFCAPMASK, phy, MII_OFFSET_ANY, 0); + if (error != 0) { + device_printf(sc->arge_dev, "unable to attach" + " PHY %d: %d\n", phy, error); + goto fail; + } } } - else { + if (sc->arge_miibus == NULL) { + /* no PHY, so use hard-coded values */ ifmedia_init(&sc->arge_ifmedia, 0, arge_multiphy_mediachange, arge_multiphy_mediastatus); @@ -494,24 +564,23 @@ arge_attach(device_t dev) } /* Call MI attach routine. */ - ether_ifattach(ifp, eaddr); + ether_ifattach(sc->arge_ifp, sc->arge_eaddr); /* Hook interrupt last to avoid having to lock softc */ - error = bus_setup_intr(dev, sc->arge_irq, INTR_TYPE_NET | INTR_MPSAFE, + error = bus_setup_intr(sc->arge_dev, sc->arge_irq, INTR_TYPE_NET | INTR_MPSAFE, arge_intr_filter, arge_intr, sc, &sc->arge_intrhand); if (error) { - device_printf(dev, "couldn't set up irq\n"); - ether_ifdetach(ifp); + device_printf(sc->arge_dev, "couldn't set up irq\n"); + ether_ifdetach(sc->arge_ifp); goto fail; } /* setup sysctl variables */ - arge_attach_sysctl(dev); - + arge_attach_sysctl(sc->arge_dev); fail: if (error) - arge_detach(dev); + arge_detach(sc->arge_dev); return (error); } @@ -542,6 +611,9 @@ arge_detach(device_t dev) if (sc->arge_miibus) device_delete_child(dev, sc->arge_miibus); + if (sc->arge_miiproxy) + device_delete_child(dev, sc->arge_miiproxy); + bus_generic_detach(dev); if (sc->arge_intrhand) @@ -592,6 +664,13 @@ arge_shutdown(device_t dev) return (0); } +static void +arge_hinted_child(device_t bus, const char *dname, int dunit) +{ + BUS_ADD_CHILD(bus, 0, dname, dunit); + device_printf(bus, "hinted child %s%d\n", dname, dunit); +} + static int arge_miibus_readreg(device_t dev, int phy, int reg) { @@ -600,16 +679,13 @@ arge_miibus_readreg(device_t dev, int phy, int reg) uint32_t addr = (phy << MAC_MII_PHY_ADDR_SHIFT) | (reg & MAC_MII_REG_MASK); - if ((sc->arge_phymask & (1 << phy)) == 0) - return (0); - mtx_lock(&miibus_mtx); - ARGE_MII_WRITE(AR71XX_MAC_MII_CMD, MAC_MII_CMD_WRITE); - ARGE_MII_WRITE(AR71XX_MAC_MII_ADDR, addr); - ARGE_MII_WRITE(AR71XX_MAC_MII_CMD, MAC_MII_CMD_READ); + ARGE_MDIO_WRITE(sc, AR71XX_MAC_MII_CMD, MAC_MII_CMD_WRITE); + ARGE_MDIO_WRITE(sc, AR71XX_MAC_MII_ADDR, addr); + ARGE_MDIO_WRITE(sc, AR71XX_MAC_MII_CMD, MAC_MII_CMD_READ); i = ARGE_MII_TIMEOUT; - while ((ARGE_MII_READ(AR71XX_MAC_MII_INDICATOR) & + while ((ARGE_MDIO_READ(sc, AR71XX_MAC_MII_INDICATOR) & MAC_MII_INDICATOR_BUSY) && (i--)) DELAY(5); @@ -620,8 +696,8 @@ arge_miibus_readreg(device_t dev, int phy, int reg) return (-1); } - result = ARGE_MII_READ(AR71XX_MAC_MII_STATUS) & MAC_MII_STATUS_MASK; - ARGE_MII_WRITE(AR71XX_MAC_MII_CMD, MAC_MII_CMD_WRITE); + result = ARGE_MDIO_READ(sc, AR71XX_MAC_MII_STATUS) & MAC_MII_STATUS_MASK; + ARGE_MDIO_WRITE(sc, AR71XX_MAC_MII_CMD, MAC_MII_CMD_WRITE); mtx_unlock(&miibus_mtx); ARGEDEBUG(sc, ARGE_DBG_MII, "%s: phy=%d, reg=%02x, value[%08x]=%04x\n", __func__, @@ -638,19 +714,15 @@ arge_miibus_writereg(device_t dev, int phy, int reg, int data) uint32_t addr = (phy << MAC_MII_PHY_ADDR_SHIFT) | (reg & MAC_MII_REG_MASK); - - if ((sc->arge_phymask & (1 << phy)) == 0) - return (-1); - ARGEDEBUG(sc, ARGE_DBG_MII, "%s: phy=%d, reg=%02x, value=%04x\n", __func__, phy, reg, data); mtx_lock(&miibus_mtx); - ARGE_MII_WRITE(AR71XX_MAC_MII_ADDR, addr); - ARGE_MII_WRITE(AR71XX_MAC_MII_CONTROL, data); + ARGE_MDIO_WRITE(sc, AR71XX_MAC_MII_ADDR, addr); + ARGE_MDIO_WRITE(sc, AR71XX_MAC_MII_CONTROL, data); i = ARGE_MII_TIMEOUT; - while ((ARGE_MII_READ(AR71XX_MAC_MII_INDICATOR) & + while ((ARGE_MDIO_READ(sc, AR71XX_MAC_MII_INDICATOR) & MAC_MII_INDICATOR_BUSY) && (i--)) DELAY(5); @@ -715,6 +787,8 @@ arge_set_pll(struct arge_softc *sc, int media, int duplex) uint32_t fifo_tx; int if_speed; + ARGEDEBUG(sc, ARGE_DBG_MII, "set_pll(%04x, %s)\n", media, + duplex == IFM_FDX ? "full" : "half"); cfg = ARGE_READ(sc, AR71XX_MAC_CFG2); cfg &= ~(MAC_CFG2_IFACE_MODE_1000 | MAC_CFG2_IFACE_MODE_10_100 @@ -1923,3 +1997,47 @@ arge_multiphy_mediastatus(struct ifnet *ifp, struct ifmediareq *ifmr) sc->arge_duplex_mode; } +#if defined(ARGE_MDIO) +static int +argemdio_probe(device_t dev) +{ + device_set_desc(dev, "Atheros AR71xx built-in ethernet interface, MDIO controller"); + return (0); +} + +static int +argemdio_attach(device_t dev) +{ + struct arge_softc *sc; + int error = 0; + + sc = device_get_softc(dev); + sc->arge_dev = dev; + sc->arge_mac_unit = device_get_unit(dev); + sc->arge_rid = 0; + sc->arge_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, + &sc->arge_rid, RF_ACTIVE | RF_SHAREABLE); + if (sc->arge_res == NULL) { + device_printf(dev, "couldn't map memory\n"); + error = ENXIO; + goto fail; + } + /* Reset MII bus */ + ARGE_WRITE(sc, AR71XX_MAC_MII_CFG, MAC_MII_CFG_RESET); + DELAY(100); + ARGE_WRITE(sc, AR71XX_MAC_MII_CFG, MAC_MII_CFG_CLOCK_DIV_28); + DELAY(100); + bus_generic_probe(dev); + bus_enumerate_hinted_children(dev); + error = bus_generic_attach(dev); +fail: + return (error); +} + +static int +argemdio_detach(device_t dev) +{ + return (0); +} + +#endif diff --git a/sys/mips/atheros/if_argevar.h b/sys/mips/atheros/if_argevar.h index c1df678..dc3d931 100644 --- a/sys/mips/atheros/if_argevar.h +++ b/sys/mips/atheros/if_argevar.h @@ -67,15 +67,10 @@ #define ARGE_CLEAR_BITS(sc, reg, bits) \ ARGE_WRITE(sc, reg, ARGE_READ(sc, (reg)) & ~(bits)) -/* - * MII registers access macros - */ -#define ARGE_MII_READ(reg) \ - *((volatile uint32_t *)MIPS_PHYS_TO_KSEG1((AR71XX_MII_BASE + reg))) - -#define ARGE_MII_WRITE(reg, val) \ - *((volatile uint32_t *)MIPS_PHYS_TO_KSEG1((AR71XX_MII_BASE + reg))) = (val) - +#define ARGE_MDIO_WRITE(_sc, _reg, _val) \ + ARGE_WRITE((_sc), (_reg), (_val)) +#define ARGE_MDIO_READ(_sc, _reg) \ + ARGE_READ((_sc), (_reg)) #define ARGE_DESC_EMPTY (1 << 31) #define ARGE_DESC_MORE (1 << 24) @@ -132,11 +127,14 @@ struct arge_softc { */ uint32_t arge_media_type; uint32_t arge_duplex_mode; + uint32_t arge_phymask; + uint8_t arge_eaddr[ETHER_ADDR_LEN]; struct resource *arge_res; int arge_rid; struct resource *arge_irq; void *arge_intrhand; device_t arge_miibus; + device_t arge_miiproxy; bus_dma_tag_t arge_parent_tag; bus_dma_tag_t arge_tag; struct mtx arge_mtx; @@ -148,7 +146,6 @@ struct arge_softc { int arge_detach; uint32_t arge_intr_status; int arge_mac_unit; - int arge_phymask; int arge_if_flags; uint32_t arge_debug; struct { --Apple-Mail=_213E4B8A-6009-4FF8-A23A-C6A4E1D4CE37-- From owner-freebsd-arch@FreeBSD.ORG Fri Jan 20 23:35:19 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09EEA106564A; Fri, 20 Jan 2012 23:35:19 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id C069C8FC0A; Fri, 20 Jan 2012 23:35:18 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id C780211D5BB; Fri, 20 Jan 2012 23:35:17 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20120120221319.ca8b631f.ray@freebsd.org> Date: Sat, 21 Jan 2012 00:35:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120120221319.ca8b631f.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Ethernet Switch Framework X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 23:35:19 -0000 Thank you for the update, that clears up a number of questions I had. Here's a couple of questions and comments. Which devices can this code be run on? For example, can the AR7240 = config run on an TL-WR3420? Would you mind giving an overview of how the various parts fit together, = how they are probed and attached? I think I understand from you = explanations on IRC, but not everbody had that chance. Am 20.01.2012 um 21:13 schrieb Aleksandr Rybalko: > get/set reg: > Generic access to registers. Have 2 address modifiers: > 0x00000000(no modifiers) - access to parent space (parent MDIO bus, if > switchX attaches to miibusX) > 0x40000000 - access to switch MDIO bus > 0x80000000 - access to switch registers. Wouldn't it be better to have a proper API to select the various busses = and device register files? > FloatPHY > pseudo driver which attach to miibus like normal PHY, but do find > master switchX device and ask his PHY reg's. Main problem with that > driver - is usage of newbus calls between independent device (not a > parent <-> child), since floatphyX query set/get methods of switchX. The general approach has a number of problems, as far as I understand = the miibus code. miibus assumes that only one of the PHYs on the MII is = active concurrently (since that's a requirement of the MII/GMII/... = bus). If I read your code correctly, you have one miibus that has all = the PHYs for all switch ports on them. Won't miibus just isolate all = but one PHY? In your current implementation, you've reimplented ukphy (in a limited = fashion). One of the advantages of reusing the mii framework is being = able to use all the PHYs, in case a switch chip would include a quirky = PHY. Extending floatphy to work as a full proxy for any phy driver = looks non-trivial to me due to the API constraints the mii framework = imposes. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arch@FreeBSD.ORG Sat Jan 21 01:45:18 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B888D106566C for ; Sat, 21 Jan 2012 01:45:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6AAA98FC12 for ; Sat, 21 Jan 2012 01:45:18 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q0L1hRjb047153; Fri, 20 Jan 2012 18:43:36 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> Date: Fri, 20 Jan 2012 19:43:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> To: Stefan Bethke X-Mailer: Apple Mail (2.1084) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [127.0.0.1]); Fri, 20 Jan 2012 18:43:37 -0700 (MST) Cc: FreeBSD-arch Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 01:45:18 -0000 On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote: > The second problem is that there's currently no way to express a = dependency between two devices other than a parent-child relationship. = I would be interested to learn why this appears to be so uncommon that I = could not find any discussion of such a feature. Has it really never = before come up? Sure there is: you can do it by name. I wrote a driver that attached to = the ISA bus, but also needed to talk to the ppbus that was attached to = the printer. My solution was to have a post-attach name-lookup so that = it could then call methods on the other driver's device_t. I wonder why = we can't do that here? Warner From owner-freebsd-arch@FreeBSD.ORG Sat Jan 21 04:34:40 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F39D1065670 for ; Sat, 21 Jan 2012 04:34:40 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9998FC17 for ; Sat, 21 Jan 2012 04:34:39 +0000 (UTC) Received: from localhost ([127.0.0.1]) by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1RoSKD-0005Sm-D6; Fri, 20 Jan 2012 20:13:11 -0800 Message-ID: <4F1A3B58.7040001@freebsd.org> Date: Fri, 20 Jan 2012 20:13:12 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-arch@freebsd.org, Ben Gray References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com> In-Reply-To: <8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 20/01/2012 5:43 PM, Warner Losh wrote: > > On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote: >> The second problem is that there's currently no way to express a dependency between two devices other than a parent-child relationship. I would be interested to learn why this appears to be so uncommon that I could not find any discussion of such a feature. Has it really never before come up? > > Sure there is: you can do it by name. I wrote a driver that attached to the ISA bus, but also needed to talk to the ppbus that was attached to the printer. My solution was to have a post-attach name-lookup so that it could then call methods on the other driver's device_t. I wonder why we can't do that here? [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list Cc: Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 04:34:40 -0000 On 20/01/2012 5:43 PM, Warner Losh wrote: > > On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote: >> The second problem is that there's currently no way to express a dependency between two devices other than a parent-child relationship. I would be interested to learn why this appears to be so uncommon that I could not find any discussion of such a feature. Has it really never before come up? > > Sure there is: you can do it by name. I wrote a driver that attached to the ISA bus, but also needed to talk to the ppbus that was attached to the printer. My solution was to have a post-attach name-lookup so that it could then call methods on the other driver's device_t. I wonder why we can't do that here? I've been thinking about it recently in regard to GPIO subsystem. And the same issue appeared during OMAP code import: there are at least two subsystems that are used by the rest of the drivers. Ben's suggested following solution: define kobj interface if_SUBSYTEM.m and then provide API call in form: int omap_prcm_clk_enable(clk_ident_t clk) { device_t prcm_dev; prcm_dev = devclass_get_device(devclass_find("omap_prcm"), 0); if (prcm_dev == NULL) { printf("Error: failed to get the PRCM device\n"); return (EINVAL); } return OMAP_PRCM_CLK_ENABLE(prcm_dev, clk); } So it might make sense to create some kind of upper-level API for defining this kind of subsystems' APIs since every implementation would duplicate a lot of code: look for instance of specific devclass, check if it exists. Not sure how to do it at the moment though. From owner-freebsd-arch@FreeBSD.ORG Sat Jan 21 12:03:01 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6118106566C for ; Sat, 21 Jan 2012 12:03:01 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 9004E8FC1A for ; Sat, 21 Jan 2012 12:03:01 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 4AF0811DE2C; Sat, 21 Jan 2012 12:03:00 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com> Date: Sat, 21 Jan 2012 13:02:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0759FAC9-D4CD-444D-A7A4-545383709631@lassitu.de> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD-arch Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 12:03:01 -0000 Am 21.01.2012 um 02:43 schrieb Warner Losh: >=20 > On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote: >> The second problem is that there's currently no way to express a = dependency between two devices other than a parent-child relationship. = I would be interested to learn why this appears to be so uncommon that I = could not find any discussion of such a feature. Has it really never = before come up? >=20 > Sure there is: you can do it by name. I wrote a driver that attached = to the ISA bus, but also needed to talk to the ppbus that was attached = to the printer. My solution was to have a post-attach name-lookup so = that it could then call methods on the other driver's device_t. I = wonder why we can't do that here? That was my first approach, but the attachment sequence foiled it: arge0 = is probed and attached before the device that provides the MDIO bus = arge0 needs to attach the miibus and phy. As far as I can tell, there = is no way to express (via code or hints or otherwise) that a device = should be attached only after some other device has been attached. The solution for me was to write miiproxy which contains code that waits = for both devices to attach, and then calls a callback on arge0 to = complete the interface attachment (attaches miibus, makes the interface = available). =46rom a driver writers point of view, it would be desirable to be able = to say "attach this only after 'foo0' has been attached", so the attach = method can still be a single, linear piece of code. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-arch@FreeBSD.ORG Sat Jan 21 13:13:32 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA3DB106564A for ; Sat, 21 Jan 2012 13:13:32 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 457FD8FC16 for ; Sat, 21 Jan 2012 13:13:31 +0000 (UTC) Received: by bkbc12 with SMTP id c12so1665326bkb.13 for ; Sat, 21 Jan 2012 05:13:30 -0800 (PST) Received: by 10.204.10.82 with SMTP id o18mr622184bko.20.1327151610644; Sat, 21 Jan 2012 05:13:30 -0800 (PST) Received: from rnote.ddteam.net (58-37-133-95.pool.ukrtel.net. [95.133.37.58]) by mx.google.com with ESMTPS id d2sm13448405bky.11.2012.01.21.05.13.28 (version=SSLv3 cipher=OTHER); Sat, 21 Jan 2012 05:13:29 -0800 (PST) Date: Sat, 21 Jan 2012 15:13:17 +0200 From: Aleksandr Rybalko To: Oleksandr Tymoshenko Message-Id: <20120121151317.d0532390.ray@ddteam.net> In-Reply-To: <4F1A3B58.7040001@freebsd.org> References: <8D025847-4BE4-4B2C-87D7-97E72CC9D325@lassitu.de> <20120104215930.GM90831@alchemy.franken.de> <47ABA638-7E08-4350-A03C-3D4A23BF2D7E@lassitu.de> <1763C3FF-1EA0-4DC0-891D-63816EBF4A04@lassitu.de> <20120106182756.GA88161@alchemy.franken.de> <95372FB3-406F-46C2-8684-4FDB672D9FCF@lassitu.de> <20120106214741.GB88161@alchemy.franken.de> <20120108130039.GG88161@alchemy.franken.de> <23477898-8D85-498C-8E30-192810BD68A8@lassitu.de> <20120111193738.GB44286@alchemy.franken.de> <66DDA0A2-F878-43FF-8824-54868F493B18@lassitu.de> <8EF24110-C985-400F-ADDF-B1D63C4E304B@bsdimp.com> <4F1A3B58.7040001@freebsd.org> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 X-Gm-Message-State: ALoCoQnPCw0jOIvtywDRW8jBMdz5IUTEjcGIwwM09r4TXsC+O84UK3t8QfEm9c6piFmrrpHrD+Mu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Ben Gray , freebsd-arch@freebsd.org Subject: Re: Extending sys/dev/mii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 13:13:32 -0000 On Fri, 20 Jan 2012 20:13:12 -0800 Oleksandr Tymoshenko wrote: > On 20/01/2012 5:43 PM, Warner Losh wrote: > > > > On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote: > >> The second problem is that there's currently no way to express a > >> dependency between two devices other than a parent-child > >> relationship. I would be interested to learn why this appears to > >> be so uncommon that I could not find any discussion of such a > >> feature. Has it really never before come up? > > > > Sure there is: you can do it by name. I wrote a driver that > > attached to the ISA bus, but also needed to talk to the ppbus that > > was attached to the printer. My solution was to have a post-attach > > name-lookup so that it could then call methods on the other > > driver's device_t. I wonder why we can't do that here? > > I've been thinking about it recently in regard to GPIO subsystem. > And the same issue appeared during OMAP code import: there are at > least two subsystems that are used by the rest of the drivers. Ben's > suggested following solution: define kobj interface if_SUBSYTEM.m and > then provide API call in form: > > int omap_prcm_clk_enable(clk_ident_t clk) > { > device_t prcm_dev; > > prcm_dev = devclass_get_device(devclass_find("omap_prcm"), > 0); if (prcm_dev == NULL) { > printf("Error: failed to get the PRCM device\n"); > return (EINVAL); > } > > return OMAP_PRCM_CLK_ENABLE(prcm_dev, clk); > } > > So it might make sense to create some kind of upper-level API for > defining this kind of subsystems' APIs since every implementation > would duplicate a lot of code: look for instance of specific > devclass, check if it exists. Not sure how to do it at the moment > though. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" I use the same: devclass_get_device(devclass_find(driver_name), 0); in my floatphy0. But i save device_t of device driver i found. And make it on first call to my device. Since it is pseudo PHY driver, i try to find master device driver on first PHY status or poll request. And driver is happy with that. Only one problem here, if master will be detached (because unload or some problem) then address for master device_t became wrong. I think it easy to solve it with use of event handler for device attache/detach. Then we be able to find master device on _attach stage or when event handler will be invoked. And clear saved master device_t when device detach event handler will be invoked. We need only add EVENTHANDLER_INVOKE to devadded/devremoved in the sys/kern/subr_bus.c. WBW -- Aleksandr Rybalko