Hi, On Thu, Dec 25, 2014 at 12:13:07PM +0200, Igor Grinberg wrote: > Hi Tony, > > On 12/24/14 21:04, Tony Lindgren wrote: > > * Felipe Balbi <balbi@xxxxxx> [141224 07:52]: > >> Hi, > >> > >> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA1 > >>> > >>> On 12/23/14 18:19, Felipe Balbi wrote: > >>>> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote: > >>>>> Hi Felipe, > >>>>> > >>>>> On 12/22/14 20:05, Felipe Balbi wrote: > >>>>> > >>>>> [...] > >>>>> > >>>>>> CONFIG_SCSI_SCAN_ASYNC=y > >>>>>> -CONFIG_ATA=y > >>>>>> -CONFIG_SATA_AHCI_PLATFORM=y > >>>>>> -CONFIG_MD=y > >>>>>> +CONFIG_ATA=m > >>>>>> +CONFIG_SATA_AHCI_PLATFORM=m > >>>>> > >>>>> Isn't this needed for the rootfs on SATA devices? > >>>> > >>>> there's no known boards with rootfs on SATA. Until then, we can reduce > >>>> the size. > >>> > >>> What makes you say so? > >>> The decision for rootfs on SATA is taken dynamically. > >>> OMAP5 boards (specifically cm-t54) can have rootfs on SATA... > >> > >> I'll leave the decision to Tony. Even though they _can_, they really > >> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be > >> annoying to find that special device which works (e.g it can't negotiate > >> lower speeds with SATA III devices and it won't support SATA I). > > Yet, it is not that buggy and at least until now, I di not get any > reports about badly working SATA from customers... > > >> > >> As of today, we don't know of anybody really shipping anything with > >> rootfs on SATA and distros would rather ship initiramfs than a giant > >> zImage anyway. > > So, you just continue to ignore what I'm saying... even after I point > to a device... you pointed a device which *can* have rootfs on SATA, not one which *has* rootfs on SATA, there's a very big difference there. > Is it SATA that makes it so giant? > Because I find it worth having in SATA than spare some more k's... that's your point of view. As Tony mentioned, we have a very standard way of dealing with this which is initramfs and x86 has been using that for the past 15+ years. > >> 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. > > 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. > 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. > (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. > 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. You should at a minimum provide your customers with a more minimal rootfs. Why would you have your customers 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. -- balbi
Attachment:
signature.asc
Description: Digital signature
