On Fri, Dec 26, 2003 at 05:33:06AM +0900, OGAWA Hirofumi wrote:

> > +# Yes, this looks a bit odd. Yes, it ends up being turned on in lots
> > +# of cases. Please don't touch it. It is here to handle the case where
> > +# a sound driver can be either a module or compiled in if GAMEPORT is
> > +# not selected, but must be a module if the joystick is selected as a 
> > +# module. The sound driver calls GAMEPORT functions. If GAMEPORT is
> > +# not selected, stubs are provided. If GAMEPORT is built in,
> > +# everything is fine. If GAMEPORT is a module, however, it would need
> > +# to be loaded for the sound driver to be able to link
> > +# properly. Therefore, the sound driver must be a module as well in
> > +# that case (and the GAMEPORT module must be loaded first). 
> >  config SOUND_GAMEPORT
> >  	tristate
> >  	default y if GAMEPORT!=m
> 
> I see. So why did we need the SOUND_GAMEPORT?

I thought I explained this above, quite verbosely :-) 
Rather than make the sound drivers depend directly on GAMEPORT, which
is troublesome because Kconfig has no provisions for this type of
dependancy, we create an artificial dependency, SOUND_GAMEPORT, which
the sound driver depends on. SOUND_GAMEPORT depends on GAMEPORT, and
Kconfig ends up doing the right thing. I hope that was clearer. 

Cheers, 
Muli 
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/

"the nucleus of linux oscillates my world" - gccbot@#offtopic