On Sat, Feb 16, 2019 at 9:16 AM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> >
> > > On Feb 15, 2019, at 11:47, Robert Huff wrote:
> > >
> > > Lev Serebryakov writes:
> > >
> > >>> My question would be: why? If some drivers have a new
> > >>> dependency on iflib, why isn't that expressed in sys/conf/files
> > >>> and handled automatically?
> As expressed elsewhere that gets a bit messy when it is more than
> just a few things that depend on this module, and historically
> has been done by adding comments to GENERIC that describe the
> dependency in the form of "requires iflib".
>
> Though there are some ideas floating around that might better
> address this, for the time being that is how it is being handled.
>
> > >> My question exactly.
> > >
> > >I am so glad people who know what they're talking about have the
> > > same response I did. :-)
> >
> > I totally missed the part where Robert said he was compiling it
> > into the kernel. Also, I remember the days when drivers didn?t
> > automatically compile in dependent options (example: ?device re?
> > requires ?device miibus?). I guess things have changed a bit in
> > the past year [while I was away] with some drivers?
> > Thanks,
> > -Enji
> > >Respectcfully,
> > >Robert Huff
>
> Nothing has changed, other than we now have another miibus
> type thing called iflib and there are a half dozen drivers
> that need to have iflib compiled in if you use them. What
> is new is that these drivers already existed in the past,
> but have been re-written to use iflib, so if your carrying
> an old kernel config file around and update accross the
> iflib'ification of that driver you have to pick up the
> change that went into GENERIC that pulls in iflib.
>
That's always been true. We've never really had good support for invariant
kernel config files on the branch that weren't derived from GENERIC in some
way. Some recent branches have been better about this, but there's plenty
of precedent in the past where changes like this have become required for
this driver or that.
> These are probably the types of changes that we should
> consider not merging to something called stable/.
>
Generally, I tend to agree. However, apart from making the iflib standard,
and impossible to remove, there's little that can be done in this case.
We've made minor changes like this to kernel config files in the past, and
merging this work would fall under that precedent. Not something to be done
willy-nilly, but also not something to not do if the consequences of not
doing it are worse than doing it. For our low end, already starting to feel
the squeeze, being able to compile this out is a needful thing.
config(8) sucks. Plain and simple. It's difficult to work on, doesn't
express what it needs to, and is hard to transition away from. We are stuck
with it for the life of the 12 branch (and like 13 and 14 too). It's easy
to solve 80% of the problems with it, but hard to do so without introducing
more problems that are much harder to paper-over. It needs to be taken out
behind the woodshed and shot, but it does it job adequately enough that any
replacement will have hard shoes to fill, especially since the number of
weird, idiosyncratic edge cases config leans one way or the other have
become expected and are actually the right thing to do. We also have enough
velocity in the files, options and other files that trying to write a
replacement and keep up is hard.
tl;dr: config(8)'s unique quirks may force us to do things we'd rather not.
Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
