Re: finalizing 2.6.28 config options

2009-02-13 Thread maximilian attems
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

2009-02-13 Thread Ian Campbell
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

2009-02-09 Thread maximilian attems
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

2009-02-08 Thread Ben Hutchings
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

2009-02-06 Thread Ian Campbell
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

2009-02-06 Thread Moritz Muehlenhoff
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