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 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 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
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
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
Re: finalizing 2.6.28 config options
On 2009-02-06, maximilian attems m...@stro.at 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
