RE: [PATCH 1/7] 34XX: PM: Workaround to build omap hsmmc as a module

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > My main bone of contention was the statement that there was no reason for
> > not building something as a module. There is a case for building drivers
> > into the kernel. Whether it is the best choice is something that depends
> > on what one is trying to achieve.
>
> As Felipe wrote, it is easy to reconfigure a module to be build in than
> it is to get a build in and have it to be compilable and usable as
> module. Developing a module gives you for free the builtin case.
> The other way is not always true.

Agreed. That is correct.


> Your case of "let's veryfy all the modules at once by converting them to
> built-ins" is more the exception than the rule.

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.


> > > And on top of that, having modules allows to makes it simpler to address
> > > in one go different boards and subarchitectures.
> >
> > I'm afraid I don't understand. How would having a driver as a module or
> > built-in make a difference when targetting different boards?
>
> I can do just one build and use the same binary to do the deployment to
> different boards.

This can still be done if you have everything built-in. Is there any reason for
such a all-built-in kernel not to work across boards?

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.


> That's the direction the kernel is currently going to, with code that
> probes for OMAP version and uses the appropriate register addresses.
>
> The bootloader can pass the board type as option.

This can be done with a modular kernel as well as with an all-built-in kernel.

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.


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.

- Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux