--=-=-=
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-----
--=-=-=--