Subject: Re: ugen change for review (try 2)
To: Greg Troxel <email@example.com>
From: Quentin Garnier <firstname.lastname@example.org>
Date: 07/24/2006 19:24:23
Content-Type: text/plain; charset=us-ascii
On Mon, Jul 24, 2006 at 11:17:28AM -0400, Greg Troxel wrote:
> Quentin Garnier <email@example.com> writes:
> > On Mon, Jul 24, 2006 at 10:26:48AM -0400, Greg Troxel wrote:
> >> firstname.lastname@example.org (Christos Zoulas) writes:
> >> > Is there a reason why we wouldn't
> >> > want to enable them by default all the time?
> >> I mentioned two earlier, and apparently no one is concerned about
> >> breakage from this (if one doesn't call the ioctl). The other is code
> >> size, but we're talking about GENERIC, and this is critical for anyone
> >> trying to use a USRP. So, I enabled it in GENERIC and GENERIC_LAPTOP.
> > The world is an i386? Rnow people should consider at least amd64 as a
> > really mainstream platform. I'd actually consider enabling it in
> > conf/std and disable it in size-constrained kernel configurations.
> Good point; I'm used to other platforms, but haven't had an amd64 yet
> so I'm not mentally used to USB2 being normal elsewhere.
> From src/sys/conf/std:
> # this file is for options which can't be off-by-default for some reaso=
> # "it's commonly used" is NOT a good reason to enable options here.
> My memory of the negative option debate is fuzzy.
Well, I do remember not entirely agreeing with Yamamoto-san on some
specific points. I think the issue here for conf/std is that it's
uncertain if files.usb has been included. How many platforms don't
have PCI? The point stands, though. It's not a core-enough feature.
> I recall that we don't like "options NO_FOO", so inverting the sense
> of the option is not ok.
Clearly we don't deny not wanting to have negative options.
> A number of config files have ugen - list at end. (I don't know why
> i386/INSTALL_LAPTOP has ugen - I don't know of any ugen-attaching
> device that one could install via.)
At some point we might offer the possiblity to load drivers for special
devices at installation time, so while now it seems bogus, it's not
> 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.
> 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
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 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.
Quentin Garnier - email@example.com - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----