Re: finalizing 2.6.28 config options
On Fri, 2009-02-13 at 18:17 +0100, maximilian attems wrote: > On Fri, 06 Feb 2009, Ian Campbell wrote: > > > On Fri, 2009-02-06 at 14:42 +0100, maximilian attems wrote: > > > > > > have gone through the open 2.6.28 Kconfig variables for x86_64 and set the > > > evident ones, those below are still open. once we have settled those. i'll > > > see to have also a clean x86_32 config. > > got asked for 686-bigmem: > Xen virtual frame buffer support (XEN_FBDEV_FRONTEND) [Y/n/m/?] (NEW) It should certainly be Y or M, whatever you would normally do for framebuffer drivers should be fine. I've never tried it as M, I assume it works fine. FWIW Fedora goes with Y. The .o is a little bit under 4000 bytes. Ian. -- Ian Campbell Finality is death. Perfection is finality. Nothing is perfect. There are lumps in it. signature.asc Description: This is a digitally signed message part
Re: finalizing 2.6.28 config options
On Fri, 06 Feb 2009, Ian Campbell wrote: > On Fri, 2009-02-06 at 14:42 +0100, maximilian attems wrote: > > > > have gone through the open 2.6.28 Kconfig variables for x86_64 and set the > > evident ones, those below are still open. once we have settled those. i'll > > see to have also a clean x86_32 config. got asked for 686-bigmem: Xen virtual frame buffer support (XEN_FBDEV_FRONTEND) [Y/n/m/?] (NEW) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: finalizing 2.6.28 config options
On Mon, Feb 09, 2009 at 12:59:41AM +, Ben Hutchings wrote: > On Fri, 2009-02-06 at 14:42 +0100, maximilian attems wrote: > [...] > > * FIRMWARE_IN_KERNEL > > default enabled > > we probably don't ship right yet relevant firmware separetly? > > FIRMWARE_IN_KERNEL enables inclusion of firmware along with drivers in > the main kernel image, and has no effect on driver modules. Driver > modules that use request_firmware() will always need separate firmware. right so do we disable support by not setting it? or do we get crucified for setting :) > [...] > > * USB_SERIAL_KEYSPAN_MPR > > USB_SERIAL_KEYSPAN_USA28 > > USB_SERIAL_KEYSPAN_USA28X > > USB_SERIAL_KEYSPAN_USA28XA > > USB_SERIAL_KEYSPAN_USA28XB > > USB_SERIAL_KEYSPAN_USA19 > > USB_SERIAL_KEYSPAN_USA18X > > USB_SERIAL_KEYSPAN_USA19W > > USB_SERIAL_KEYSPAN_USA19QW > > USB_SERIAL_KEYSPAN_USA19QI > > USB_SERIAL_KEYSPAN_USA49W > > USB_SERIAL_KEYSPAN_USA49WLC > > bunch of new firmware for some option style serial dev > > not looked at their licences yet nor request_firmware() usage > > This driver uses request_firmware(). so aboves configs can be disabled, i'd guess? thanks for the input -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: finalizing 2.6.28 config options
On Fri, 2009-02-06 at 14:42 +0100, maximilian attems wrote: [...] > * FIRMWARE_IN_KERNEL > default enabled > we probably don't ship right yet relevant firmware separetly? FIRMWARE_IN_KERNEL enables inclusion of firmware along with drivers in the main kernel image, and has no effect on driver modules. Driver modules that use request_firmware() will always need separate firmware. [...] > * USB_SERIAL_KEYSPAN_MPR > USB_SERIAL_KEYSPAN_USA28 > USB_SERIAL_KEYSPAN_USA28X > USB_SERIAL_KEYSPAN_USA28XA > USB_SERIAL_KEYSPAN_USA28XB > USB_SERIAL_KEYSPAN_USA19 > USB_SERIAL_KEYSPAN_USA18X > USB_SERIAL_KEYSPAN_USA19W > USB_SERIAL_KEYSPAN_USA19QW > USB_SERIAL_KEYSPAN_USA19QI > USB_SERIAL_KEYSPAN_USA49W > USB_SERIAL_KEYSPAN_USA49WLC > bunch of new firmware for some option style serial dev > not looked at their licences yet nor request_firmware() usage This driver uses request_firmware(). > * STAGING > pile of crap drivers > disabled in fedora, users might request it, but currently seems > not really supportable. so i'd be for unsetting, but want opinons? We already distribute some of these, e.g. rt2860. I would favour enabling at least the ones that we currently distribute separately. [...] > * STRICT_DEVMEM > is userspace ready for that!? > probably should da a testboot and see if lenny xorg comes up with it > enabled. This has no effect on the X server, or at least that's the theory. > * X86_VERBOSE_BOOTUP > default yes and guess debian users like it!? [...] This can easily be overridden with "quiet", in any case. Ben. signature.asc Description: This is a digitally signed message part
Re: finalizing 2.6.28 config options
On 2009-02-06, maximilian attems wrote: > hello :) > > have gone through the open 2.6.28 Kconfig variables for x86_64 and set the > evident ones, those below are still open. once we have settled those. i'll > see to have also a clean x86_32 config. > > * STAGING > pile of crap drivers > disabled in fedora, users might request it, but currently seems > not really supportable. so i'd be for unsetting, but want opinons? The following drivers from staging are already present in the archive as OOT modules: - comedi - rt2860 - et131x - wlan-ng So, while staging drivers certainly shouldn't be built by default it makes sense to build these from the official kernel tree in the future. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: finalizing 2.6.28 config options
On Fri, 2009-02-06 at 14:42 +0100, maximilian attems wrote: > hello :) > > have gone through the open 2.6.28 Kconfig variables for x86_64 and set the > evident ones, those below are still open. once we have settled those. i'll > see to have also a clean x86_32 config. > > * XEN_DEBUG_FS > ian can you please decide on that one for x86? > have seen it enabled in fedora but Kconfig speaks of performance hit. I think leave it off, it's probably only really useful for developers anyway and anybody who is having a problem this would help diagnose is probably going to have to rebuild at some point anyway. Ian. -- Ian Campbell I was in a beauty contest one. I not only came in last, I was hit in the mouth by Miss Congeniality. -- Phyllis Diller -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
finalizing 2.6.28 config options
hello :) have gone through the open 2.6.28 Kconfig variables for x86_64 and set the evident ones, those below are still open. once we have settled those. i'll see to have also a clean x86_32 config. * XEN_DEBUG_FS ian can you please decide on that one for x86? have seen it enabled in fedora but Kconfig speaks of performance hit. * MEMTEST do we want it? it is disabled by default if needs bootparam to be enabled. although defaults to N and i see it disabled in fedora!? * X86_CHECK_BIOS_CORRUPTION default disabled, diagnostic tool guess not, but.. * FIRMWARE_IN_KERNEL default enabled we probably don't ship right yet relevant firmware separetly? * MTD_DATAFLASH_WRITE_VERIFY data integrity, but default disabled? not seen in any fedora config * MTD_DATAFLASH_OTP OTP data support, default disabled? * VIDEO_FIXED_MINOR_RANGES usefull for !udev setups defaults unset and so seen in fedora * HID_COMPAT default set useful for !udev setups seen unset in fedora * USB_SERIAL_KEYSPAN_MPR USB_SERIAL_KEYSPAN_USA28 USB_SERIAL_KEYSPAN_USA28X USB_SERIAL_KEYSPAN_USA28XA USB_SERIAL_KEYSPAN_USA28XB USB_SERIAL_KEYSPAN_USA19 USB_SERIAL_KEYSPAN_USA18X USB_SERIAL_KEYSPAN_USA19W USB_SERIAL_KEYSPAN_USA19QW USB_SERIAL_KEYSPAN_USA19QI USB_SERIAL_KEYSPAN_USA49W USB_SERIAL_KEYSPAN_USA49WLC bunch of new firmware for some option style serial dev not looked at their licences yet nor request_firmware() usage * STAGING pile of crap drivers disabled in fedora, users might request it, but currently seems not really supportable. so i'd be for unsetting, but want opinons? * SUNRPC_REGISTER_V4 experimental default disabled but seen enabled in fedora requires portmapper that supports protocol version 4!? * SYSCTL_SYSCALL_CHECK might uncover things, maybe for some time in squeeze?? * IRQSOFF_TRACER SCHED_TRACER CONTEXT_SWITCH_TRACER BOOT_TRACER default disabled, but enabled on fedora * STRICT_DEVMEM is userspace ready for that!? probably should da a testboot and see if lenny xorg comes up with it enabled. * X86_VERBOSE_BOOTUP default yes and guess debian users like it!? * EARLY_PRINTK_DBGP defaults no, seen enabled on fedora * OPTIMIZE_INLINING shall we trust gcc? default disabled can reduce kernel size and requires gcc 4.x :) thanks for your input. would like to have those set by this week, so that we can soon jump on the .29 resume and butter goodness :D -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
