Hi, On Fri, Dec 26, 2014 at 01:56:26PM +0200, Igor Grinberg wrote: > >>>> Tony, your call. > >>> > >>> I think we should move omap2plus_defconfig to be mostly modular and > >>> usable for distros as a base. Most distros prefer to build almost > >>> everything as loadable modules. And my preference is that we should > >>> only keep the minimum rootfs for devices and serial support as > >>> built-in and rely on initramfs for most drivers. And slowly move > >>> also the remaining built-in drivers to be loadable modules. > >>> > >>> The reasons for having drivers as loadable modules are many. It > >>> allows distros to use the same kernel for all the devices without > >>> bloating the kernel. It makes developing drivers easier as just the > >>> module needs to be reloaded. And loadable modules protect us from > >>> cross-framework spaghetti calls in the kernel as the interfaces are > >>> clearly defined. > >>> > >>> Are there people really using SATA as rootfs right now on omaps? > >> > >> Yes. That is exactly my point. > > > > read your email, you said it *CAN* have rootfs on SATA. > > yep, it also *CAN* have rootfs on MMC and NFS and ... those we *know* people are using as rootfs. We know of several users who are actually using it :-) > >>> If it's only something that will be more widely used in the future, > >>> then I suggest we make it into a loadable module, and presume > >>> initramfs and loadable module also for any new devices. The same > >>> way x86 has been doing with distros for years. > >> > >> The difference from x86 is that we're in embedded here and > > > > bullshit, you would never ship a product with omap2plus_defconfig. You'd > > build your own at which point you would switch SATA to built-in. > > Yep, that is one of the options indeed, but I'm not asking you to > deal with my problems, right? > I'm feeling like you are trying to insult me. > Are you angry with me? Why? > Is it because I have a different opinion? heh, cute :-) > >> although initramfs is a kind of option, but it means, you need to > >> load even more data during the boot process... it is annoying and > >> I would not want to use it on embedded. > > > > make your own defconfig. > > This sounds like: mind your own business... > Is that what you want to say? nope, not really. Just saying that if you're really concerned about being embedded and that initramfs takes that much more time to load, you'd just make your own defconfig and maintain it out-of-tree. RMK does that for quite a few boards, I do it for my boards and also for my x86 desktops/laptops. It's not really rocket science. > >> (BTW, x86_64_defconfig has it compiled in...) > >> > >> We can also, split the defconfig as it was some time ago... but I > >> would not want to go that direction... > >> > >> If we go the initramfs way, then why not also load MMC from it? > >> That will also reduce kernel size... (but add initramfs size) > > > > I'm fine with that. The difference is that people have been relying on > > MMC built-in for the past 10+ years, since the old OMAP1 MMC driver, > > changing that now is likely to cause some "my board won't boot anymore" > > bug reports. > > Yep. So there are exceptions, right? never claimed the contrary. > >> I'm sure you will find making the MMC a loadable module inconvenient. > >> That how I find making the SATA a loadable module... > >> > >> Right now, we tell our customers that they can use mainline with > >> omap2plus_defconfig. > > > > that's the worst thing you can do. > > Hmmm... Interesting, so people should not use mainline. now you're reading what you want to read ;-) Using my statements out of context. It's clear (actually s/rootfs/defconfig below) that I meant defconfig. > > You should at a minimum provide your > > customers with a more minimal rootfs. Why would you have your customers oh wait, not rootfs, defconfig. > > build MUSB on an OMAP5 board ? Why would they build 5 different > > network device drivers ? Why would they build almost every single PMIC > > we ever used ? The list goes on and on. > > That is their decision to make. I'm just saying that they can use it. right, and they can switch SATA to built-in if they want to ship an initramfs-less product, don't you think ? Or they can append initramfs to the kernel image and not even have a root filesystem anywhere (been there, done that), but that's not relevant to this discussion. Anyway, I'll leave it to Tony. -- balbi
Attachment:
signature.asc
Description: Digital signature
