Subject: Re: ugen change for review (try 2)
To: Quentin Garnier <cube@cubidou.net>
From: Greg Troxel <gdt@ir.bbn.com>
List: tech-kern
Date: 07/24/2006 13:56:08
--=-=-=
Content-Transfer-Encoding: quoted-printable
Quentin Garnier <cube@cubidou.net> 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
> attribute.
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
uhub?'.
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
file differences
1) MD
2) hardware that's usually missing on platform X
3) bloat/functionality tradeoff, which is different for large vs small memo=
ry
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
> included.
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.
=2D-=20
Greg Troxel <gdt@ir.bbn.com>
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (NetBSD)
iD8DBQFExQm8+vesoDJhHiURAhbQAJ4xO6g+2SlF5X8VZJdtJSog/FXScQCfcDzv
EXQuBgXEzpzYga0kV1HCitE=
=cCy/
-----END PGP SIGNATURE-----
--=-=-=--