> > That wasn't what I said or meant. What I did want to bring out was that having
> > something built-in might give it more exposure to test by someone who wasn't
> > actively working on that area. And most bugs are caught by people other than
> > the active developers.
>
> Not really, another usecase for modular kernel is that we don't wanna
> add e.g. tea (radio) driver for n810 cuz it doesn't have that chip.
> With modular kernel with proper MODULE_ALIAS() and udev, you just
> flash the same kernel and modules in both n800 and n810 and tea driver
> would only be probed in n800.
>
> I think this is what Igor meant when we said about validation across
> boards.
Ok. Fair enough. Point taken.
> > At first glance to your email, I thought you had a valid point here. Thinking a
> > little more, I think your point is valid only if you had a module that should not
> > be loaded on a particular board. In such a case, you would anyway want to fix that
> > module.
>
> Or you rely on udev rules and keep the main kernel code smaller.
>
> > Yes, having a modular kernel is useful. And it is probably the way to go. But please
> > don't tell me that you can't do the same things with almost everything built-in.
>
> some stuff you really can't. If your mmc driver get stuck somewhere, you
> can't modprobe -r -f omap_hsmmc and restart your work with a built-in
> mmc driver. With modular kernel, we really can do it: forcefully remove
> the driver and reset the controller, this would give us oportunity to
> analyze logs and try again by reloading the module.
>
> With a built-in kernel, the only way out is reboot.
Agreed.
> > The 2430 defconfig has almost everything modular, while the 3430 defconfig doesn't.
> > I propose we start a separate defconfig for the modular case or use allmodconfig.
> > Maybe even have this as the defconfig for the multi-omap kernel. If we keep the
> > individual defconfigs as a nearly all-built-in case, we can still get the best of
> > both worlds.
>
> The thins is that normaly you'd have udev running anyways, and it would
> automatically load modules based on /sys and correct MODULE_ALIAS()
> and that's already another thing to test that can't be tested with built-in
> modules.
>
> We know that several omap drivers are missing MODULE_ALIAS() and recently I've
> added it to all twl4030 drivers for that purpose.
>
> We can now rely that udev will correctly load the necessary module when we
> need it. And when I stated that there's no reason for not building
> everything as dynamic module for omaps, I was considering that we have
> enough memory in our boards and generaly developers will use NFS
> root file system anyways.
>
> I think this discussion is now way too long for something really
> simple: For development purposes on SDPs, dynamic linked modules
> can increase the development cycle by decreasing the amount of
> build/flash/reboot cycles.
Okay. End of discussion. :)
- Anand
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
