On Mon, 12 Mar 2001, Keith Owens wrote:
> In 2.4.2-ac18 there are 130 CONFIG options that are always derived from
> other options, the user has no control over them. It is useful for the
> kernel build process to know which variables are derived and which
> variables the user can control.
If it's useful for the (future?) kernel build process to know this,
shouldn't that config/build process derive this info itself, rather
than going by _DERIVED on the end of a CONFIG_ name?
And aren't there many CONFIG_ options (I think your "always" implies
so) which are derived in some cases (e.g. on some architectures),
specified by the user in others? Those don't get to be called
_DERIVED though often they are derived.
And easy to imagine an option always derived in one release, sometimes
specified in the next, always derived in the next... Yes, we can
keep on editing the CONFIG_ name in all sources affected, but I
just don't think the name should be trying to carry that info.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 15 2001 - 21:00:13 EST