Date: Thu, 20 Dec 2018 00:01:21 +0800 From: Marcelo Araujo <araujobsdport@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Marcelo Araujo <araujo@freebsd.org>, Martin Wilke <miwi@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Joe Maloney <jmaloney@ixsystems.com>, ken@ixsystems.com, Kris Moore <kmoore@freebsd.org>, Warren Block <wblock@freebsd.org> Subject: Re: OpenRC on FreeBSD Message-ID: <CAOfEmZjfrBycHjE6eyztEE1oTOKktuh%2BWUkA66f6QBLJue8rMA@mail.gmail.com> In-Reply-To: <CANCZdfrSERSPm3eG6xni8LJ63TJ7mrWK=ek9y7qAQWFbz9i99A@mail.gmail.com> References: <397FBAFF-2575-4AE4-B2BC-2DFDA769040A@FreeBSD.org> <CANCZdfp%2BQXngCRqevXT%2BDKgQj1S276PdpvqyZpiuOC%2BvMAP24A@mail.gmail.com> <7BBA9943-7CA1-4349-9B48-1641BA11FCA3@FreeBSD.org> <CANCZdfoFXjx_dEW-8CkAB5Wq1=H806jJeoLAStVWcJ=ErcHm0A@mail.gmail.com> <CAOfEmZh4RHCkfSsxNGjtg%2BSa6CowgGSTntkicd0Ny4g=m5n0Og@mail.gmail.com> <CANCZdfrSERSPm3eG6xni8LJ63TJ7mrWK=ek9y7qAQWFbz9i99A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Em qua, 19 de dez de 2018 =C3=A0s 23:58, Warner Losh <imp@bsdimp.com> escre= veu: > > > On Wed, Dec 19, 2018 at 8:48 AM Marcelo Araujo <araujobsdport@gmail.com> > wrote: > >> >> >> Em qua, 19 de dez de 2018 =C3=A0s 23:02, Warner Losh <imp@bsdimp.com> >> escreveu: >> >>> >>> >>> On Wed, Dec 19, 2018 at 7:57 AM Martin Wilke <miwi@freebsd.org> wrote: >>> >>>> Hi, >>>> >>>> The missing bit was actually the flag for switching the rc=E2=80=99s w= hich have >>>> been resolved. >>>> >>> >>> No. The missing bit is an articulated plan. While that minor sub-issue >>> may be resolved, I see no plan for integration into the tree. Unless th= e >>> plan is 'commit the review in one big push' which really isn't a viable >>> plan. There are problems with the review (it's too large to be successf= ul, >>> and has issues that need to be discussed in a less massively huge >>> environment). This isn't what the working group's conclusion would be t= he >>> next steps. The FCP I provided feedback on died. It was a good start on= a >>> plan, but was just dropped with my feedback completely ignored. >>> >> >> Hi Warner, >> >> I have asked miwi@ to keep that huge patch on the review because of the >> lack of coordination and discussion between different groups and also >> because there is not a clear plan how to bring OpenRC into FreeBSD. So i= n >> that way people could try the patch easily without chasing different ope= n >> reviews, and to be honest, without further discussion regarding to how t= he >> transition would happens between rcd and OpenRC, there is nothing much t= o >> review there. >> >> IMHO, if we want to move forward with OpenRC on FreeBSD we would need a >> broad discussion, because it will impacts not only the base system but a= lso >> ports, and also docs needs to get involved because we eventually would n= eed >> to update our documentation. We have people that wants OpenRC also in ot= her >> hands we have people that wants to keep things as it is. >> >> NOTE: I have updated the review with the same content of this email just >> to make it registered there. >> >> I agree for review purpose small chunks are better, however I don't see >> yet a plan for all this migration between rcd and OpenRC. >> > > Reviews aren't patch delivery devices. They are to review the code > present. You can't do that with the super-monster review that's there. If > you want to have one patch file, that's great! You can always link each > review to that patch file or have a dummy master review to do that. Revie= ws > this large in the past have failed to reach consensus and frustrated the > authors. I'd kinda like to avoid that outcome here because I really want = to > see forward progress here. Maybe once we've hashed out the plan on > integration, we can move to breaking up the patch into manageable pieces. > Agree with that, as soon as there is a plan on integration, breaking up the patch will be easier for review! But without a plan, as I said, there is nothing to review to be honest. :( > > So what's my next step for saying that the verbatim copy of devd.conf int= o > devd-openrc.conf is not going to work, that problem needs to be solved > properly without such copying. Eg, moving the openrc dependency out of > devd.conf and into pccard-ether or its replacement to hide this detail. = I > don't know if this is emblematic of a poor design, or just a sloppy > short-cut. > > Warner > > >> Best, >> >> >>> >>> Warner >>> >>> >>>> - Martin >>>> >>>> On 19 Dec 2018, at 10:51 PM, Warner Losh <imp@bsdimp.com> wrote: >>>> >>>> >>>> >>>> On Wed, Dec 19, 2018 at 7:39 AM Martin Wilke <miwi@freebsd.org> wrote: >>>> >>>>> Hi >>>>> >>>>> I'd like to reopen the discussion for OpenRC on FreeBSD. Basically >>>>> this is the second attempt to get it into FreeBSD. >>>>> >>>>> I've opened a review here with a working patch for CURRENT, >>>>> https://reviews.freebsd.org/D18578 >>>>> >>>>> >>>>> To recap the discussion >>>>> * First attempt of RFC in March of 2018: >>>>> https://lists.freebsd.org/pipermail/freebsd-hackers/2018-March/052358= .html >>>>> * Working group at BSDCan: >>>>> https://wiki.freebsd.org/DevSummit/201806/OpenRC >>>>> >>>>> Here some key points: >>>>> >>>>> OpenRC provides additional features for service management without >>>>> requiring kernel changes or replacing pid 1, unlike launchd and other >>>>> solutions. All rc.d scripts have been converted with a few changes, >>>>> typically changing the shebang and making sure the start function is = named >>>>> start(). Most service scripts are simplified, usually needing only na= me, >>>>> command, and, if required, depends statements. >>>>> >>>>> History: >>>>> OpenRC started out as an init system by Roy Marples, developed for th= e >>>>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into G= entoo >>>>> as baselayout v2, and was then split off as a separate BSD-licensed >>>>> project. It is under active development, portable, and remains BSD li= censed >>>>> today. >>>>> >>>>> OpenRC and RC: >>>>> Both can coexist and be chosen with a setting in /boot/loader.conf. >>>>> >>>>> OpenRC Features: >>>>> >>>>> Service supervision and service monitoring: any service can be >>>>> supervised. Supervised services that crash are automatically restarte= d. The >>>>> rc-status command shows how many times a service has restarted. >>>>> >>>>> Device hotplug support and event-driven service management: the >>>>> hotplug feature allows devd to take actions when devices are connecte= d. For >>>>> example, a USB wifi adapter can create additional network services wh= en >>>>> attached. The net-online service can, for example, detect when a netw= ork >>>>> connection is restored, and restart ntp. >>>>> >>>>> Network profiles: using stacked runlevels, different profiles can be >>>>> established for different networking settings. For instance, differen= t >>>>> profiles can be used for wired or wireless networking, or for differi= ng >>>>> wireless networks, as well as dependency caching and parallel startup= speed >>>>> up booting. >>>>> >>>>> Interactive mode: >>>>> The boot process can be run interactively for more effective debuggin= g. >>>>> >>>>> OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the cont= ext in which a >>>>> script is running. There are only three at present: >>>>> sysinit (the OpenRC system is starting), boot (start base services >>>>> when the computer is booting), and default (normal execution). >>>>> >>>>> OpenRC, by default, provides a =E2=80=9Ccolorized=E2=80=9D text boot,= using ANSI color >>>>> sequences. This can be disabled. >>>>> >>>>> Ports: >>>>> As of July 2017, iXsystems has created OpenRC versions of port servic= e >>>>> scripts for the entire ports tree. These scripts coexist with the rc.= d >>>>> versions. >>>>> >>>>> License: >>>>> OpenRC is a BSD licensed RC init system written in C. From a user >>>>> perspective, it is very similar to the FreeBSD rc.d init system, maki= ng it >>>>> easy to use and learn. >>>>> >>>>> Tested: OpenRC has been used as the init system for TrueOS since >>>>> October 2016. >>>>> >>>>> Ken Moore has an OpenRC vs RC.d comparison which can be found here: >>>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf < >>>>> http://www.wonkity.com/~wblock/openrc/OpenRC_rc.d.pdf>; >>>>> I look forward to discuss the features and capabilities of OpenRC. >>>>> >>>> >>>> This is cool technology. >>>> >>>> However, what was missing last time was a written plan that could be >>>> critiqued for fit with the project's needs. The result of the working = group >>>> was that this was to be produced, and we'd iterate through it to ease = the >>>> landing of openrc in the tree. I think there's wide agreement this is = cool, >>>> and that we'd like tot have both it and rc.d in the tree for a transit= ion >>>> period. Absent a plan, though, it's not really possible to say 'go do = it' >>>> or 'that's insane'. >>>> >>>> So maybe start there? >>>> >>>> Warner >>>> >>>> >>>> >> >> -- >> >> -- >> Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.F= reeBSD.org <http://www.freebsd.org/>; \/ \ ^ >> Power To Server. .\. /_) >> >> --=20 --=20 Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>; \/ \ ^ Power To Server. .\. /_)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfEmZjfrBycHjE6eyztEE1oTOKktuh%2BWUkA66f6QBLJue8rMA>