On Thu, Jan 10, 2013 at 8:18 PM, Darren Hart <[email protected]> wrote:
> > > On 01/10/2013 05:06 PM, Liang Li wrote: > > On 2013-01-11 05:24, Bruce Ashfield <[email protected]> > wrote: > >> On 13-01-08 02:18 AM, Liang Li wrote: > >>> On 2013-01-08 09:14, Darren Hart <[email protected]> wrote: > >>>> > >>>> > >>>> On 01/07/2013 05:11 PM, Liang Li wrote: > >>>>> On 2013-01-08 08:59, Liang Li <[email protected]> wrote: > >>>>>> On 2013-01-08 01:00, Darren Hart <[email protected]> wrote: > >>>>>>> Hrm, is this right with respect to the KMS driver? If we specify a > >>>>>>> console resolution requiring KMS, does this work with DRM_I915 as > a module? > >>>>>>> > >>>>>> > >>>>>> Yes, I think so. :) > >>>>> > >>>>> Er, I mean, boot progress would be fine .. just delayed KMS > >>>>> initialization then console resolution would be changed after the > >>>>> module loaded. > >>>> > >>>> Personally I'd prefer this stayed as a =y. I see very little need for > >>> > >>> Actually, I see 'm' will be more flexible. Eg, when its be 'y', > >>> intel-agp also *have to be* 'y'. But with a 'm', it would offer > >>> convenience. > >>> > >>>> modules in kernels tailored for specific systems. i915 config is > already > >>>> separated out... why make KMS a module? > >>>> > >>> > >>> Not for the kernel configure option, its still be 'y', but as soon as > >>> drm-i915 be 'm', its actually be 'm'. :) > >>> > >>> Besides, I see distroes make drm drivers be modules as much as > >>> possible, seems it would works good, reduced kernel footprint, gain > >>> flexible etc. So I wonder if you know some explicit benefits that I > >>> did not aware of .. to support it stay as 'y' ? :) > >> > >> bump. I'm sitting on all these patches until the Intel folks do an > >> ack / nack or otherwise on the queue .. since they are the creators > >> of the configs! > >> > > > > Yes, I am waiting to hear response as well, since I think Darren or > > other folks might a bit busy. But wait one or two more days seems ok > > to me. :) Hopefully I'll get ack. > > Sorry guys, avalanche of new work piling up over the stale pre-vacation > work. > > No problem at all. I was just trying to get a few email out of my inbox at the end of the day and figured I'd ping. I should have pointed out in my ping that don't assume I'm for or against the series as is stands, I'm the one that asked Liang to send it along, since I wanted to gather more thoughts before weighing in. > 1) I don't think what the distros do is particularly relevant as they > have very different goals. They use modules because it allows them to > make more generic images. You don't want to bloat your kernel with > features only some systems will use. In our case we build > system-specific > kernels where very little of what is configured in will not be used. > Agreed. Tight configs should always be a top goal, and I agree, built in is my preference to a pile of modules floating around a disk, since we know our configs, create a baseline and encourage anyone inheriting them to tweak to their taste. > > 2) I remain strongly opposed to modules. If we are going to make such a > change, I would want to see real numbers demonstrating WHY it is a good > idea. How much space do we actually save? What does that space buy us in > boot time? > Also agreed. > > 3) The impact on users of the existing fragments needs to be well > understood, "Yes, I think so. :-)" really isn't enough. > > This was also my concern as well, there are existing users and use cases, we need to be careful changing the configs once they've been in tree for a while. I'm good with 2/3 and 3/3 of the series, they are legitimate bug fixes. As for changing I915 to a module, I'd suggest we leave it as-is in the base yocto configuration and it can be tweaked to 'y' in the Wind River kernel .. using a feature fragment of a different name (since we want to consume the yocto baseline as-is). Cheers, Bruce > So that's my position on making platform specific support options into > modules. > > -- > Darren Hart > Intel Open Source Technology Center > Yocto Project - Technical Lead - Linux Kernel > _______________________________________________ > linux-yocto mailing list > [email protected] > https://lists.yoctoproject.org/listinfo/linux-yocto > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
_______________________________________________ linux-yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/linux-yocto
