Date: Wed, 19 Dec 2018 08:58:04 -0700 From: Warner Losh <imp@bsdimp.com> To: Marcelo Araujo <araujo@freebsd.org> Cc: 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: <CANCZdfrSERSPm3eG6xni8LJ63TJ7mrWK=ek9y7qAQWFbz9i99A@mail.gmail.com> In-Reply-To: <CAOfEmZh4RHCkfSsxNGjtg%2BSa6CowgGSTntkicd0Ny4g=m5n0Og@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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> esc= reveu: > >> >> >> 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 wh= ich 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 the >> 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 successfu= l, >> 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 th= e >> 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 in > that way people could try the patch easily without chasing different open > reviews, and to be honest, without further discussion regarding to how th= e > transition would happens between rcd and OpenRC, there is nothing much to > 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 al= so > ports, and also docs needs to get involved because we eventually would ne= ed > to update our documentation. We have people that wants OpenRC also in oth= er > 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. Reviews 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. So what's my next step for saying that the verbatim copy of devd.conf into 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 thi= s >>>> 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 n= amed >>>> start(). Most service scripts are simplified, usually needing only nam= e, >>>> command, and, if required, depends statements. >>>> >>>> History: >>>> OpenRC started out as an init system by Roy Marples, developed for the >>>> Gentoo Alt (FreeBSD) kernel branch. It was more widely adopted into Ge= ntoo >>>> as baselayout v2, and was then split off as a separate BSD-licensed >>>> project. It is under active development, portable, and remains BSD lic= ensed >>>> 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 restarted= . The >>>> rc-status command shows how many times a service has restarted. >>>> >>>> Device hotplug support and event-driven service management: the hotplu= g >>>> feature allows devd to take actions when devices are connected. For >>>> example, a USB wifi adapter can create additional network services whe= n >>>> attached. The net-online service can, for example, detect when a netwo= rk >>>> connection is restored, and restart ntp. >>>> >>>> Network profiles: using stacked runlevels, different profiles can be >>>> established for different networking settings. For instance, different >>>> profiles can be used for wired or wireless networking, or for differin= g >>>> 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 debugging= . >>>> >>>> OpenRC uses the term =E2=80=9Crunlevels=E2=80=9D to refer to the conte= xt in which a >>>> script is running. There are only three at present: >>>> sysinit (the OpenRC system is starting), boot (start base services whe= n >>>> 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 service >>>> 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, makin= g 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 g= roup >>> was that this was to be produced, and we'd iterate through it to ease t= he >>> landing of openrc in the tree. I think there's wide agreement this is c= ool, >>> and that we'd like tot have both it and rc.d in the tree for a transiti= on >>> period. Absent a plan, though, it's not really possible to say 'go do i= t' >>> or 'that's insane'. >>> >>> So maybe start there? >>> >>> Warner >>> >>> >>> > > -- > > -- > Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.Fr= eeBSD.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?CANCZdfrSERSPm3eG6xni8LJ63TJ7mrWK=ek9y7qAQWFbz9i99A>