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-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-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 Moritz Muehlenhoff
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

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



finalizing 2.6.28 config options

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