Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Jun 2005 08:53:10 +0200
From:      Jose M Rodriguez <josemi@freebsd.jazztel.es>
To:        Brooks Davis <brooks@one-eyed-alien.net>
Cc:        ports@freebsd.org, Doug Barton <dougb@freebsd.org>, Jose M Rodriguez <josemi@freebsd.jazztel.es>
Subject:   Re: Including PREFIX/etc/rc.d/* scripts in the system's rcorder for startup in 6.0-Release
Message-ID:  <200506100853.10883.josemi@redesjm.local>
In-Reply-To: <20050610035646.GA19116@odin.ac.hmc.edu>
References:  <42A8B4E6.9090401@FreeBSD.org> <200506100232.34832.josemi@redesjm.local> <20050610035646.GA19116@odin.ac.hmc.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
El Viernes, 10 de Junio de 2005 05:56, Brooks Davis escribi=F3:
> On Fri, Jun 10, 2005 at 02:32:34AM +0200, Jose M Rodriguez wrote:
> > El Jueves, 9 de Junio de 2005 23:30, escribi=F3:
> > > Howdy,
> > >
> > > I realize that this is pretty short notice before the release,
> > > but the rc.d team just got a spiffy new volunteer to do the
> > > legwork on this, and so we're going to try to beat the code
> > > freeze/slushie deadline for 6.0. What we've been discussing for
> > > the last few days on the freebsd-rc list is a two-fold approach
> > > in order to avoid needing a flag day to cover this issue.
> > > <snip/>
> >
> > I'm not sure that this is the correct approach.  And even maybe too
> > late in the RELENG_6 timeline.
> >
> > Firts, most ports in real need of rcorder can't wait to localpkg,
> > and use direct rc support breaking $prefix.
>
> This is easy to fix.  We just modify RC_ORDER to take appropriate
> action based on the version of FreeBSD.  There's plenty of time prior
> to 6.0-RELEASE for that.
>

Well,  but I think this must begin after RELENG_6 creation.  The actual=20
rc is more or less valid.

> > Second, I can easy work scenarios where I can break any logic
> > trying to mix localpkg lex order and rcorder key order.
>
> The fact that you can break the schem does not imply it would
> actually be broken.  More importantly, a little breaking isn't all
> that serious.
>

I only point that you may aply the new logic only to ports that 'really=20
want it'.

> > If we go to maintain short release cycles, please, delay this to
> > HEAD after RELENG_6.  And only merge it if we go to a safe status
> > before real release.
>
> The problem is that we have to start some day and we won't be able to
> make a full switch for at least two relases after the initial commit.
> At the very least, I think we should make some attempt at supporting
> rcorder orders scripts within PREFIX/etc/rc.d in 6.0.
>

I can see the problem, but not the priority.  We're switching from a=20
long major release cycle to a short one.  And making a really good '0=20
rev' release must be the target.

This is why I point that this must be take only after we are sure.  We=20
can test this changes in HEAD after RELENG_6 is tagged and merge from=20
current after test before the real release.

> > I still remember latest approach to solve this.
> >
> > I think that the only safe way to take this is make some sort of
> > 'stage' concept into rc (use the SystemV runlevels as a very loose
> > reference).
> >
> > We can use 'stage keys' for implement this.
> >
> > If we have safe localfs access at the end of stage 'n-1', we can do
> > and rcorder for stage 'n' mixing scripts with key 'stage n'
> > in /etc/rc.d/*, /usr/local/etc/rc.d/*, /usr/X11R6/etc/rc.d/* ...
>
> This requires too much modification of scripts.  There is a quite
> nice proposal on rc@ that simply requires the addition of one script
> to mark the point at which scripts are rescanned.
>

As I can remember, SystemV runlevels are few, and we implement as last=20
part of the concept with the shutdown key.

localpkg is only one case where the problem of rcorder 'linearity'=20
shines.  We 'order' the boot at the very begin only.

Allthough 'tagging' only those special scripts maybe easy of implement,=20
tagging all the rc system will be a better long term approach.

=46or clarity, I'm talking about every stript having a key pointing the=20
stage (sysinit, ...,multiuser) and do several rcorder keyed scans,=20
using predefined macros filled by previuos stage.

rc will to the task for the first stage (sysinit).

The script doing the new keyed scan and invoke of selected scripts must=20
be a special end target of the previous stage.

We can implement this adding process of and special %%STAGE%% sed macro=20
to RC_ORDER.

And we have allready special 'stage' targets like NETWORKING, SERVERS,=20
DAEMON, LOGIN.

So we can talk, at last of:
		...	NETWORKING	sysinit
NETWORKING	...	SERVERS		network
SERVERS		...	DAEMON		servers
DAEMON		...	LOGIN		daemon
LOGIN		...			login

> -- Brooks

=2D-
  josemi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506100853.10883.josemi>