Subject: Re: ugen change for review (try 2)
To: Quentin Garnier <firstname.lastname@example.org>
From: Greg Troxel <email@example.com>
Date: 07/24/2006 13:56:08
Quentin Garnier <firstname.lastname@example.org> writes:
> On Mon, Jul 24, 2006 at 11:17:28AM -0400, Greg Troxel wrote:
>> I could add the option to amd64/GENERIC if there are no objections
> Please do; most if not all new x86 platforms, including laptops, now
> are AMD64 or EM64T.
I just committed it, and am running a build to make sure I didn't typo
it - please try it out.
>> Perhaps we need a standard config file for things that attach to
>> "uhub?" that can be included from kernels that have USB interfaces.
>> This should probably be done as part of a larger effort to perform
>> common subexpression elimination in config files, but might be a good
>> concrete example to drive the discussion.
> That should be done with utter care. It's an interesting idea though,
> having small feature-centered files the user could include. It makes
> the main configuration file more opaque, though, and we would soon need
> some sort of conditional for platforms which doesn't provide a given
I think a simple ".include std-usb" is fairly clear, and aids
understanding by reducing the amount of things that have to be
followed at once. In this case, it would be put in config files that
have a usb? of some sort, and replace 'uhub at usb?' and 'foo at
The question of "Why is there this difference? Is it intentional, or
just an error?" will arise less often.
I can see three large reasons (surely I'm missing some) for config
2) hardware that's usually missing on platform X
3) bloat/functionality tradeoff, which is different for large vs small memo=
Some of 2 and 3 could be dealt with by having usb-tier1 and usb-tier2
configs that could be used to include only tier1 on small machines.
> One thing that could be done, though, is having files automatically
> included when a feature is selected by the user. E.g., in that
> case, when the user has a ugen instance declared in the main
> configuration file, a file enabling the said option would be
That seems likely to confuse people.
> That way we don't pollute other configurations, though it has some
> side-effects: any "no options FEATURE" would have to be placed after
> the first ugen instance, or would produce an error. It's one thing
> that bugs me a lot in config(5): "no" statements affect the current
> state of the options selection, although other statements only have
> effect when the whole file is finished processing. I see "no"
> statements as barriers.
More consistent semantics sounds like a good thing, but I don't grasp
config well enough to comment.
Greg Troxel <email@example.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (NetBSD)
-----END PGP SIGNATURE-----