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. 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. 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? 3) The impact on users of the existing fragments needs to be well understood, "Yes, I think so. :-)" really isn't enough. 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
