Ok, the merge window has closed, and 2.6.22-rc1 is out there.
The diffstat and shortlogs are way too big to fit under the kernel mailing
list limits, and the changes are all over the place. Almost seven thousand
files changed, and that's not double-counting the files that got moved
around.
Architecture updates, drivers, filesystems, networking, security, build
scripts, reorganizations, cleanups.. You name it, it's there.
You want a new firewire stack? We've got it. New wireless networking
infrastructure? Check. New infiniband drivers? Digital video drivers? A
totally new CPU architecture (blackfin)? Check, check, check.
That said, I think (and certainly hope) that this will not be nearly as
painful as the big fundamental timer changes for 2.6.21, and while there
are some pretty core changes there (like the new SLUB allocator, which
hopefully will end up replacing both SLAB and SLOB), it feels pretty
solid, and not as scary as ripping the carpet from under the timer
infrastructure.
So give it a good testing. We'll see how the regression tracking ends up
working, but in order to actually track that, we want people actively
testing -rc1 and making good reports!
Linus
Linus,
> So give it a good testing. We'll see how the regression tracking ends up
> working, but in order to actually track that, we want people actively
> testing -rc1 and making good reports!
Here's a little patch to fix filemap.c compilation problem ...
Thanks,
Jeff
--- linux/mm/filemap.c.org 2007-05-13 13:54:16 +0800
+++ linux/mm/filemap.c 2007-05-13 13:54:25 +0800
@@ -782,6 +782,7 @@
read_unlock_irq(&mapping->tree_lock);
return ret;
}
+EXPORT_SYMBOL(find_get_pages);
EXPORT_SYMBOL(find_get_pages_tag);
/**
@@ -840,8 +841,6 @@
ra->ra_pages /= 4;
}
-EXPORT_SYMBOL(find_get_pages);
-EXPORT_SYMBOL(find_get_pages_tag);
/**
* do_generic_mapping_read - generic file read routine
Take that back. It's after patching reiser4-for-2.6.21.patch.gz that
causes duplicated export symbols.
Sorry,
Jeff.
On 5/13/07, Jeff Chua <[email protected]> wrote:
>
> Linus,
>
> > So give it a good testing. We'll see how the regression tracking ends up
> > working, but in order to actually track that, we want people actively
> > testing -rc1 and making good reports!
>
> Here's a little patch to fix filemap.c compilation problem ...
>
>
> Thanks,
> Jeff
>
>
> --- linux/mm/filemap.c.org 2007-05-13 13:54:16 +0800
> +++ linux/mm/filemap.c 2007-05-13 13:54:25 +0800
> @@ -782,6 +782,7 @@
> read_unlock_irq(&mapping->tree_lock);
> return ret;
> }
> +EXPORT_SYMBOL(find_get_pages);
> EXPORT_SYMBOL(find_get_pages_tag);
>
> /**
> @@ -840,8 +841,6 @@
>
> ra->ra_pages /= 4;
> }
> -EXPORT_SYMBOL(find_get_pages);
> -EXPORT_SYMBOL(find_get_pages_tag);
>
> /**
> * do_generic_mapping_read - generic file read routine
>
>
On May 13 2007 14:00, Jeff Chua wrote:
>> So give it a good testing. We'll see how the regression tracking ends up
>> working, but in order to actually track that, we want people actively
>> testing -rc1 and making good reports!
>
> Here's a little patch to fix filemap.c compilation problem ...
gmail greets with broken spacing :-/
> --- linux/mm/filemap.c.org 2007-05-13 13:54:16 +0800
> +++ linux/mm/filemap.c 2007-05-13 13:54:25 +0800
> @@ -782,6 +782,7 @@
> read_unlock_irq(&mapping->tree_lock);
> return ret;
> }
> +EXPORT_SYMBOL(find_get_pages);
> EXPORT_SYMBOL(find_get_pages_tag);
>
> /**
> @@ -840,8 +841,6 @@
>
> ra->ra_pages /= 4;
> }
> -EXPORT_SYMBOL(find_get_pages);
> -EXPORT_SYMBOL(find_get_pages_tag);
>
> /**
> * do_generic_mapping_read - generic file read routine
Jan
--
On May 12 2007 20:20, Linus Torvalds wrote:
>
>Ok, the merge window has closed, and 2.6.22-rc1 is out there.
I have hit a randconfig compile failure. .config attached.
LD .tmp_vmlinux1
drivers/built-in.o: In function `acpi_bus_generate_event':
(.text+0x233f7): undefined reference to `event_is_open'
drivers/built-in.o: In function `acpi_bus_get_power':
(.text+0x236ad): undefined reference to `acpi_power_get_inferred_state'
drivers/built-in.o: In function `acpi_bus_set_power':
(.text+0x237c3): undefined reference to `acpi_power_transition'
drivers/built-in.o: In function `acpi_bus_set_power':
(.text+0x23835): undefined reference to `acpi_power_transition'
drivers/built-in.o: In function `sony_pic_fanspeed_store':
sony-laptop.c:(.text+0x91930): undefined reference to `ec_write'
drivers/built-in.o: In function `sony_pic_fanspeed_show':
sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read'
make: *** [.tmp_vmlinux1] Error 1
Jan
--
On May 12 2007 20:20, Linus Torvalds wrote:
>
>Ok, the merge window has closed, and 2.6.22-rc1 is out there.
<Am I collecting randconfig miles?>
net/built-in.o: In function `rxrpc_destroy_all_calls':
(.exit.text+0x71d): undefined reference to `rxrpc_call_states'
make: *** [.tmp_vmlinux1] Error 1
.config atx.
Jan
--
Hi,
if I'm not mistaken, despite the PCI_MULTITHREAD_PROBE removal,
Cornelia Huck wanted to keep driver-core-per-subsystem-multithreaded-probing.patch:
<quote>
> Wouldn't per-subsystem multithreaded probing just expose bugs that
> could also be exposed on SMP systems?
Yes, it would be the same.
</quote>
However, device_probe_drivers() remains temporarily unused, so we either
suppress the compiler warning or remove the whole function altogether. The
following patch does the first.
-----
From: Borislav Petkov <[email protected]>
This patch shuts the following warning:
drivers/base/dd.c:211: warning: 'device_probe_drivers' defined but not used
Signed-off-by: Borislav Petkov <[email protected]>
--
Index: 22-rc1/drivers/base/dd.c
===================================================================
--- 22-rc1/drivers/base/dd.c.orig
+++ 22-rc1/drivers/base/dd.c
@@ -207,7 +207,7 @@ static int __device_attach(struct device
return driver_probe_device(drv, dev);
}
-static int device_probe_drivers(void *data)
+static int __used device_probe_drivers(void *data)
{
struct device *dev = data;
int ret = 0;
--
Regards/Gru?,
Boris.
On 5/13/07, Linus Torvalds <[email protected]> wrote:
>
> Ok, the merge window has closed, and 2.6.22-rc1 is out there.
[snip]
I took a more careful look than with recent -gitXX, and
for reporting's sake here's a few MODPOST warnings:
MODPOST vmlinux
WARNING: init/built-in.o - Section mismatch: reference to .init.text:
from .text between 'rest_init' (at offset 0xfd) and 'try_name'
WARNING: mm/built-in.o - Section mismatch: reference to .init.text:
from .text between 'kmem_cache_create' (at offset 0x196e4) and
'cache_reap'
WARNING: mm/built-in.o - Section mismatch: reference to .init.text:
from .text between 'kmem_cache_create' (at offset 0x19716) and
'cache_reap
Grepping in my recent kernel build logs, the rest_init one
seems to be present since -git7 but wasn't in -git6.
Googling around seems that this has already been looked
into in the 2.6.20-rc series, with patches that may or may
not have made it into mainline.
I still have old .config files, so if there's anything useful I
can do to provide more info, just holler.
ciao,
--alessandro
"Did you get married but forgot to get divorced ?"
(Danny and Dusty, 'The Good Old Days')
Hello,
When compiling 2.6.22-rc1 I get the following (new and interesting) warnings:
GEN /home/indan/src/git/obj/Makefile
scripts/kconfig/conf -s arch/i386/Kconfig
drivers/macintosh/Kconfig:116:warning:
'select' used by config symbol 'PMAC_APM_EMU'
refers to undefined symbol 'SYS_SUPPORTS_APM_EMULATION'
drivers/net/Kconfig:2283:warning:
'select' used by config symbol 'UCC_GETH'
refers to undefined symbol 'UCC_FAST'
drivers/input/keyboard/Kconfig:170:warning:
'select' used by config symbol 'KEYBOARD_ATARI'
refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:181:warning:
'select' used by config symbol 'MOUSE_ATARI'
refers to undefined symbol 'ATARI_KBD_CORE'
And:
/home/indan/src/git/linux-2.6/drivers/base/dd.c:211:
warning: 'device_probe_drivers' defined but not used
No idea how the first warnings can show up at all when I've selected nothing
related to them, nor who to CC for it.
Added Greg to the CC list for the second warning. device_probe_drivers() is
a static function, so it seems safe to remove.
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 92428e5..b0088b0 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -207,19 +207,6 @@ static int __device_attach(struct device_driver * drv, void * data)
return driver_probe_device(drv, dev);
}
-static int device_probe_drivers(void *data)
-{
- struct device *dev = data;
- int ret = 0;
-
- if (dev->bus) {
- down(&dev->sem);
- ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
- up(&dev->sem);
- }
- return ret;
-}
-
/**
* device_attach - try to attach device to a driver.
* @dev: device.
2007/5/13, Linus Torvalds <[email protected]>:
>
> Ok, the merge window has closed, and 2.6.22-rc1 is out there.
>
[cut]
>
> So give it a good testing. We'll see how the regression tracking ends up
> working, but in order to actually track that, we want people actively
> testing -rc1 and making good reports!
>
On my desktop pc with Debian Etch and 2.6.22-rc1 the gnome panel
applet "Sensors Applet" give an error message "No chip detected".
Works fine on 2.6.21.1 (it show cpu temperature) with the same config
(I've only only done make oldconfig).
$ lspci
Is this considered a regression or can be due to userland incompatibilities?
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P]
System Controller (rev 13)
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P] AGP Bridge
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 1a)
00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 1a)
00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
00:0f.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
00:0f.1 Input device controller: Creative Labs SB Audigy Game Port (rev 03)
00:0f.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon RV100
QY [Radeon 7000/VE]
Config attached.
More info on request (sorry if this is not just a *good* report).
> Linus
~ Antonio
On Sun, 13 May 2007, Antonino Ingargiola wrote:
>
> On my desktop pc with Debian Etch and 2.6.22-rc1 the gnome panel
> applet "Sensors Applet" give an error message "No chip detected".
> Works fine on 2.6.21.1 (it show cpu temperature) with the same config
> (I've only only done make oldconfig).
One thing to check is that "make oldconfig" can actually change the
configuration if things were moved behind a new top-level configuration
parameter or such. I'm not saying that's the case here, but it's possible
that things like the i2c changes might have made you inadvertedly changed
some config option.
> Is this considered a regression or can be due to userland incompatibilities?
It's a regression, although I'd like to know more about your cases. It's
just hard to tell what happened: was it a i2c/hwmon driver that got
broken, or is it some sysfs file that got buggered, or what..
For example, "dmesg" output before and after (preferably as a diff between
the two), and what modules you had loaded in the working/nonworking case.
Linus
Am 13.05.2007 05:20 schrieb Linus Torvalds:
> Ok, the merge window has closed, and 2.6.22-rc1 is out there.
[...]
> So give it a good testing.
Would it be asking too much to have help texts on the following
new (wrt 2.6.21) configuration options?
ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
Macintosh device drivers (MACINTOSH_DRIVERS) [Y/n] (NEW)
Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
Ethernet (10000 Mbit) (NETDEV_10000) [Y/n] (NEW)
Those for the latter three could/should say something like the
one for the WLAN_80211 option.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
Hi,
2007/5/13, Linus Torvalds <[email protected]>:
>
>
> On Sun, 13 May 2007, Antonino Ingargiola wrote:
> >
> > On my desktop pc with Debian Etch and 2.6.22-rc1 the gnome panel
> > applet "Sensors Applet" give an error message "No chip detected".
> > Works fine on 2.6.21.1 (it show cpu temperature) with the same config
> > (I've only only done make oldconfig).
>
> One thing to check is that "make oldconfig" can actually change the
> configuration if things were moved behind a new top-level configuration
> parameter or such. I'm not saying that's the case here, but it's possible
> that things like the i2c changes might have made you inadvertedly changed
> some config option.
I suspected so. However the acpi and i2c section of the two config are
identical. I report the only selected options:
Power management options (ACPI, APM) --->
[*] Power Management support
[*] Software Suspend (Hibernation)
ACPI (Advanced Configuration and Power Interface) Support --->
[*] ACPI Support
[*] Sleep States
<M> Button
<M> Video
<M> Fan
<M> Processor
<M> Thermal Zone
(0) Disable ACPI for systems before Jan 1st this year
Device Drivers --->
I2C support --->
<M> I2C device interface
I2C Hardware Bus support --->
<M> VIA VT82C596/82C686/82xx and CX700
> > Is this considered a regression or can be due to userland incompatibilities?
>
> It's a regression, although I'd like to know more about your cases. It's
> just hard to tell what happened: was it a i2c/hwmon driver that got
> broken, or is it some sysfs file that got buggered, or what..
>
> For example, "dmesg" output before and after (preferably as a diff between
> the two), and what modules you had loaded in the working/nonworking case.
>
The first column of lsmod list the same modules in both kernels. The
diff-ed dmesg is attached.
> Linus
~ Antonio
On Sat, May 12, 2007 at 08:20:35PM -0700, Linus Torvalds wrote:
> Ok, the merge window has closed, and 2.6.22-rc1 is out there.
1. Should loop.c create max_loop or 8 devices for compatability?
I'm asking because quite a few people after upgrade will try
to find out where the hell is right place to create device
nodes like loop0 in distro of choice.
Offending line in my setup is
/portage /usr/portage auto loop,noatime 0 0
2. After (so far) manual invocations of mknod and mount -a, lockdep spit
the following:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.22-rc1 #1
-------------------------------------------------------
mount/6168 is trying to acquire lock:
(block_subsys_lock){--..}, at: [<c0290b1d>] kobj_map+0x94/0xf3
but task is already holding lock:
(loop_devices_mutex){--..}, at: [<c0292364>] loop_lock+0xd/0x13
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (loop_devices_mutex){--..}:
[<c012566f>] add_lock_to_list+0x68/0x8d
[<c0126cbb>] debug_check_no_locks_freed+0x10a/0x127
[<c0127963>] __lock_acquire+0x993/0xafa
[<c0292364>] loop_lock+0xd/0x13
[<c0127e74>] lock_acquire+0x54/0x6b
[<c0292364>] loop_lock+0xd/0x13
[<c034c7fc>] __mutex_lock_slowpath+0xd9/0x254
[<c0292364>] loop_lock+0xd/0x13
[<c034c96f>] __mutex_lock_slowpath+0x24c/0x254
[<c02909ff>] kobj_lookup+0x34/0xbe
[<c0292364>] loop_lock+0xd/0x13
[<c0290a49>] kobj_lookup+0x7e/0xbe
[<c0293355>] loop_probe+0x0/0x12e
[<c0167ba0>] blkdev_open+0x0/0x4f
[<c0232a1e>] get_gendisk+0x11/0x1c
[<c01677d8>] do_open+0x2e/0x261
[<c0167ba0>] blkdev_open+0x0/0x4f
[<c034de80>] _spin_unlock+0x28/0x42
[<c0167ba0>] blkdev_open+0x0/0x4f
[<c0167bc7>] blkdev_open+0x27/0x4f
[<c0147c0e>] __dentry_open+0x9a/0x142
[<c0147d2c>] nameidata_to_filp+0x24/0x33
[<c0147d72>] do_filp_open+0x37/0x3e
[<c0147ae3>] get_unused_fd+0x1e/0xaf
[<c034de80>] _spin_unlock+0x28/0x42
[<c0147b6a>] get_unused_fd+0xa5/0xaf
[<c0147db5>] do_sys_open+0x3c/0x6f
[<c0147e23>] sys_open+0x1c/0x20
[<c01025c6>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
-> #0 (block_subsys_lock){--..}:
[<c012784f>] __lock_acquire+0x87f/0xafa
[<c034df55>] _spin_unlock_irqrestore+0x37/0x5d
[<c0127e74>] lock_acquire+0x54/0x6b
[<c0290b1d>] kobj_map+0x94/0xf3
[<c034c7fc>] __mutex_lock_slowpath+0xd9/0x254
[<c0290b1d>] kobj_map+0x94/0xf3
[<c0126b8e>] trace_hardirqs_on+0x118/0x13b
[<c0126cbb>] debug_check_no_locks_freed+0x10a/0x127
[<c0290b1d>] kobj_map+0x94/0xf3
[<c0232a84>] blk_register_region+0x2f/0x34
[<c0232224>] exact_match+0x0/0x4
[<c0232954>] exact_lock+0x0/0x13
[<c0232ab8>] add_disk+0x2f/0x41
[<c0232224>] exact_match+0x0/0x4
[<c0232954>] exact_lock+0x0/0x13
[<c029342c>] loop_probe+0xd7/0x12e
[<c0290a64>] kobj_lookup+0x99/0xbe
[<c0293355>] loop_probe+0x0/0x12e
[<c0167ba0>] blkdev_open+0x0/0x4f
[<c0232a1e>] get_gendisk+0x11/0x1c
[<c01677d8>] do_open+0x2e/0x261
[<c0167ba0>] blkdev_open+0x0/0x4f
[<c034de80>] _spin_unlock+0x28/0x42
[<c0167ba0>] blkdev_open+0x0/0x4f
[<c0167bc7>] blkdev_open+0x27/0x4f
[<c0147c0e>] __dentry_open+0x9a/0x142
[<c0147d2c>] nameidata_to_filp+0x24/0x33
[<c0147d72>] do_filp_open+0x37/0x3e
[<c0147ae3>] get_unused_fd+0x1e/0xaf
[<c034de80>] _spin_unlock+0x28/0x42
[<c0147b6a>] get_unused_fd+0xa5/0xaf
[<c0147db5>] do_sys_open+0x3c/0x6f
[<c0147e23>] sys_open+0x1c/0x20
[<c01025c6>] sysenter_past_esp+0x5f/0x99
[<ffffffff>] 0xffffffff
other info that might help us debug this:
1 lock held by mount/6168:
#0: (loop_devices_mutex){--..}, at: [<c0292364>] loop_lock+0xd/0x13
stack backtrace:
[<c0126134>] print_circular_bug_tail+0x5e/0x66
[<c012784f>] __lock_acquire+0x87f/0xafa
[<c034df55>] _spin_unlock_irqrestore+0x37/0x5d
[<c0127e74>] lock_acquire+0x54/0x6b
[<c0290b1d>] kobj_map+0x94/0xf3
[<c034c7fc>] __mutex_lock_slowpath+0xd9/0x254
[<c0290b1d>] kobj_map+0x94/0xf3
[<c0126b8e>] trace_hardirqs_on+0x118/0x13b
[<c0126cbb>] debug_check_no_locks_freed+0x10a/0x127
[<c0290b1d>] kobj_map+0x94/0xf3
[<c0232a84>] blk_register_region+0x2f/0x34
[<c0232224>] exact_match+0x0/0x4
[<c0232954>] exact_lock+0x0/0x13
[<c0232ab8>] add_disk+0x2f/0x41
[<c0232224>] exact_match+0x0/0x4
[<c0232954>] exact_lock+0x0/0x13
[<c029342c>] loop_probe+0xd7/0x12e
[<c0290a64>] kobj_lookup+0x99/0xbe
[<c0293355>] loop_probe+0x0/0x12e
[<c0167ba0>] blkdev_open+0x0/0x4f
[<c0232a1e>] get_gendisk+0x11/0x1c
[<c01677d8>] do_open+0x2e/0x261
[<c0167ba0>] blkdev_open+0x0/0x4f
[<c034de80>] _spin_unlock+0x28/0x42
[<c0167ba0>] blkdev_open+0x0/0x4f
[<c0167bc7>] blkdev_open+0x27/0x4f
[<c0147c0e>] __dentry_open+0x9a/0x142
[<c0147d2c>] nameidata_to_filp+0x24/0x33
[<c0147d72>] do_filp_open+0x37/0x3e
[<c0147ae3>] get_unused_fd+0x1e/0xaf
[<c034de80>] _spin_unlock+0x28/0x42
[<c0147b6a>] get_unused_fd+0xa5/0xaf
[<c0147db5>] do_sys_open+0x3c/0x6f
[<c0147e23>] sys_open+0x1c/0x20
[<c01025c6>] sysenter_past_esp+0x5f/0x99
=======================
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
On 5/13/07, Linus Torvalds <[email protected]> wrote:
>
> Ok, the merge window has closed, and 2.6.22-rc1 is out there.
Got this ...
Thanks,
Jeff.
# make config
scripts/kconfig/conf arch/i386/Kconfig
drivers/macintosh/Kconfig:116:warning: 'select' used by config symbol
'PMAC_APM_EMU' refers to undefined symbol 'SYS_SUPPORTS_APM_EMULATION'
drivers/net/Kconfig:2283:warning: 'select' used by config symbol
'UCC_GETH' refers to undefined symbol 'UCC_FAST'
drivers/input/keyboard/Kconfig:170:warning: 'select' used by config
symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:181:warning: 'select' used by config
symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
From: Tilman Schmidt <[email protected]>
Date: Sun, 13 May 2007 20:19:09 +0200
> Would it be asking too much to have help texts on the following
> new (wrt 2.6.21) configuration options?
>
> ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
This one is a case where the option makes no sense by itself,
it provides the core common code for other front-end drivers.
The documentation exists in those front end drivers, which
in turn auto-matically select and enable this config option.
It would be nice if there was a Kconfig way to not provide
this thing at all unless one of the front-ends got selected
but on the otherhand I like how anyone can select it and thus
test the build of it :-)
> > Would it be asking too much to have help texts on the following
> > new (wrt 2.6.21) configuration options?
> >
> > ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
>
> This one is a case where the option makes no sense by itself,
> it provides the core common code for other front-end drivers.
>
> The documentation exists in those front end drivers, which
> in turn auto-matically select and enable this config option.
>
> It would be nice if there was a Kconfig way to not provide
> this thing at all unless one of the front-ends got selected
> but on the otherhand I like how anyone can select it and thus
> test the build of it :-)
If this is just an internal option that people shouldn't have to deal
with, why have a prompt at all? AFAIK the following (untested) patch
should do exactly what you want.
FWIW:
Signed-off-by: Roland Dreier <[email protected]>
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index e62d23f..5366913 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1754,7 +1754,7 @@ config SUN3X_ESP
machines. Say Y here to compile in support for it.
config SCSI_ESP_CORE
- tristate "ESP Scsi Driver Core"
+ tristate
depends on SCSI
select SCSI_SPI_ATTRS
Am 14.05.2007 01:20 schrieb David Miller:
>>
>> ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
>
> This one is a case where the option makes no sense by itself,
> it provides the core common code for other front-end drivers.
>
> The documentation exists in those front end drivers, which
> in turn auto-matically select and enable this config option.
Thanks for the explanation. I never saw those other front-end
drivers, perhaps because for lack of information I just chose
the default of "N" on this one.
> It would be nice if there was a Kconfig way to not provide
> this thing at all unless one of the front-ends got selected
> but on the otherhand I like how anyone can select it and thus
> test the build of it :-)
Well, as it stands, I am presented with that option but I don't
have the faintest idea what "ESP" is and whether it would even
be worth attempting to compile it. I would have preferred to
see at least a short explanation of the term in order to decide
whether it would be worth trying.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
sorry, forgot to CC mailing list last time.
build errors from make randconfig
# CONFIG_SMP is not set
CONFIG_X86_VOYAGER=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
arch/i386/kernel/built-in.o: In function `vic_sys_interrupt':
(.text+0x2770): undefined reference to `smp_vic_sys_interrupt'
arch/i386/kernel/built-in.o: In function `vic_cmn_interrupt':
(.text+0x27a8): undefined reference to `smp_vic_cmn_interrupt'
arch/i386/kernel/built-in.o: In function `vic_cpi_interrupt':
(.text+0x27e0): undefined reference to `smp_vic_cpi_interrupt'
arch/i386/kernel/built-in.o: In function `qic_timer_interrupt':
(.text+0x2818): undefined reference to `smp_qic_timer_interrupt'
arch/i386/kernel/built-in.o: In function `qic_invalidate_interrupt':
(.text+0x2850): undefined reference to `smp_qic_invalidate_interrupt'
arch/i386/kernel/built-in.o: In function `qic_reschedule_interrupt':
(.text+0x2888): undefined reference to `smp_qic_reschedule_interrupt'
arch/i386/kernel/built-in.o: In function `qic_enable_irq_interrupt':
(.text+0x28c0): undefined reference to `smp_qic_enable_irq_interrupt'
arch/i386/kernel/built-in.o: In function `qic_call_function_interrupt':
(.text+0x28f8): undefined reference to `smp_qic_call_function_interrupt'
arch/i386/kernel/built-in.o: In function `setup_bootmem_allocator':
(.init.text+0x58a): undefined reference to `find_smp_config'
arch/i386/mach-voyager/built-in.o: In function `voyager_power_off':
(.text+0x18f): undefined reference to `voyager_cat_power_off'
arch/i386/mach-voyager/built-in.o: In function `thread':
voyager_thread.c:(.text+0x3b8): undefined reference to `voyager_status'
voyager_thread.c:(.text+0x405): undefined reference to `voyager_status'
voyager_thread.c:(.text+0x418): undefined reference to `voyager_cat_psi'
voyager_thread.c:(.text+0x452): undefined reference to `voyager_status'
voyager_thread.c:(.text+0x46c): undefined reference to `voyager_status'
CONFIG_SMP=y
CONFIG_X86_VOYAGER=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
arch/i386/kernel/built-in.o: In function `msr_read':
msr.c:(.text+0xa614): undefined reference to `smp_call_function_single'
arch/i386/kernel/built-in.o: In function `msr_write':
msr.c:(.text+0xa710): undefined reference to `smp_call_function_single'
arch/i386/kernel/built-in.o: In function `cpuid_read':
cpuid.c:(.text+0xa8d0): undefined reference to `smp_call_function_single'
arch/i386/lib/built-in.o: In function `wrmsr_on_cpu':
(.text+0x63): undefined reference to `smp_call_function_single'
arch/i386/lib/built-in.o: In function `rdmsr_on_cpu':
(.text+0xb6): undefined reference to `smp_call_function_single'
make: *** [.tmp_vmlinux1] Error 1
CONFIG_SMP=y
CONFIG_X86_VOYAGER=y
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
arch/i386/lib/built-in.o: In function `wrmsr_on_cpu':
(.text+0x63): undefined reference to `smp_call_function_single'
arch/i386/lib/built-in.o: In function `rdmsr_on_cpu':
(.text+0xb6): undefined reference to `smp_call_function_single'
On 5/13/07, Linus Torvalds <[email protected]> wrote:
>
> Ok, the merge window has closed, and 2.6.22-rc1 is out there.
>
> The diffstat and shortlogs are way too big to fit under the kernel mailing
> list limits, and the changes are all over the place. Almost seven thousand
> files changed, and that's not double-counting the files that got moved
> around.
>
> Architecture updates, drivers, filesystems, networking, security, build
> scripts, reorganizations, cleanups.. You name it, it's there.
>
> You want a new firewire stack? We've got it. New wireless networking
> infrastructure? Check. New infiniband drivers? Digital video drivers? A
> totally new CPU architecture (blackfin)? Check, check, check.
>
> That said, I think (and certainly hope) that this will not be nearly as
> painful as the big fundamental timer changes for 2.6.21, and while there
> are some pretty core changes there (like the new SLUB allocator, which
> hopefully will end up replacing both SLAB and SLOB), it feels pretty
> solid, and not as scary as ripping the carpet from under the timer
> infrastructure.
>
> So give it a good testing. We'll see how the regression tracking ends up
> working, but in order to actually track that, we want people actively
> testing -rc1 and making good reports!
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Alexey Dobriyan wrote:
> 2. After (so far) manual invocations of mknod and mount -a, lockdep spit
> the following:
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
>
Al has a patch to fix this (haven't tested it myself yet though).
J
On Sun, May 13, 2007 at 04:20:59PM -0700, David Miller wrote:
> From: Tilman Schmidt <[email protected]>
> Date: Sun, 13 May 2007 20:19:09 +0200
>
> > Would it be asking too much to have help texts on the following
> > new (wrt 2.6.21) configuration options?
> >
> > ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
>
> This one is a case where the option makes no sense by itself,
> it provides the core common code for other front-end drivers.
>
> The documentation exists in those front end drivers, which
> in turn auto-matically select and enable this config option.
>
> It would be nice if there was a Kconfig way to not provide
> this thing at all unless one of the front-ends got selected
> but on the otherhand I like how anyone can select it and thus
> test the build of it :-)
The above is almost the help entry seeked for this option.
For some this is maybe given from the option name,
but for other the above info is a help.
So either provide help or do not have the option visible.
I would prefer the first.
Sam
From: Sam Ravnborg <[email protected]>
Date: Mon, 14 May 2007 06:37:14 +0200
> The above is almost the help entry seeked for this option.
> For some this is maybe given from the option name,
> but for other the above info is a help.
>
> So either provide help or do not have the option visible.
> I would prefer the first.
Agreed, I'll cook something up.
Hi Antonino, hi Linus,
On Sun, 13 May 2007 20:50:54 +0200, Antonino Ingargiola wrote:
> 2007/5/13, Linus Torvalds <[email protected]>:
> > On Sun, 13 May 2007, Antonino Ingargiola wrote:
> > >
> > > On my desktop pc with Debian Etch and 2.6.22-rc1 the gnome panel
> > > applet "Sensors Applet" give an error message "No chip detected".
> > > Works fine on 2.6.21.1 (it show cpu temperature) with the same config
> > > (I've only only done make oldconfig).
I am not familiar with the gnome sensors applet. Does it say where it
is getting the data (driver name, device name...)?
> > One thing to check is that "make oldconfig" can actually change the
> > configuration if things were moved behind a new top-level configuration
> > parameter or such. I'm not saying that's the case here, but it's possible
> > that things like the i2c changes might have made you inadvertedly changed
> > some config option.
>
> I suspected so. However the acpi and i2c section of the two config are
> identical. I report the only selected options:
>
> Power management options (ACPI, APM) --->
> [*] Power Management support
> [*] Software Suspend (Hibernation)
> ACPI (Advanced Configuration and Power Interface) Support --->
> [*] ACPI Support
> [*] Sleep States
> <M> Button
> <M> Video
> <M> Fan
> <M> Processor
> <M> Thermal Zone
> (0) Disable ACPI for systems before Jan 1st this year
>
> Device Drivers --->
> I2C support --->
> <M> I2C device interface
> I2C Hardware Bus support --->
> <M> VIA VT82C596/82C686/82xx and CX700
You forgot to list the Hardware Monitoring support options.
> > > Is this considered a regression or can be due to userland incompatibilities?
> >
> > It's a regression, although I'd like to know more about your cases. It's
> > just hard to tell what happened: was it a i2c/hwmon driver that got
> > broken, or is it some sysfs file that got buggered, or what..
> >
> > For example, "dmesg" output before and after (preferably as a diff between
> > the two), and what modules you had loaded in the working/nonworking case.
>
> The first column of lsmod list the same modules in both kernels. The
> diff-ed dmesg is attached.
Please provide the output of lsmod.
If you are using one of the following drivers: lm78, smsc47b397,
smsc47m1, w83627hf or w83781d, you need lm_sensors >= 2.10.1
(libsensors.so.3.1.1 or later).
--
Jean Delvare
Hi David,
On 5/14/07, David Miller <[email protected]> wrote:
> From: Tilman Schmidt <[email protected]>
> Date: Sun, 13 May 2007 20:19:09 +0200
>
> > Would it be asking too much to have help texts on the following
> > new (wrt 2.6.21) configuration options?
> >
> > ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
>
> This one is a case where the option makes no sense by itself,
> it provides the core common code for other front-end drivers.
>
> The documentation exists in those front end drivers, which
> in turn auto-matically select and enable this config option.
>
> It would be nice if there was a Kconfig way to not provide
> this thing at all unless one of the front-ends got selected
Yeah, so the Kconfig-blessed way that you're looking for is:
config SCSI_ESP_CORE
tristate
depends on SCSI && SCSI_SPI_ATTRS
default y if SCSI_SUNESP=y
default m if SCSI_SUNESP=m
Add other front-ends (other than SCSI_SUNESP) to the last
two lines, as applicable.
Important: And then *remove* the "select SCSI_ESP_CORE"
from the Kconfig options of the front-ends themselves.
[ You could do something similar with SCSI_SPI_ATTRS
also, it looks like to be something that probably never makes
sense alone either, and needs only to be automatically pulled
in by other options (?) ]
[ Note that "select"ing stuff that is not library-like and itself
depends on other stuff is a Bad Thing. ]
> but on the otherhand I like how anyone can select it and thus
> test the build of it :-)
Satyam
On Sun, 13 May 2007 11:47:53 +0200,
Borislav Petkov <[email protected]> wrote:
> if I'm not mistaken, despite the PCI_MULTITHREAD_PROBE removal,
> Cornelia Huck wanted to keep driver-core-per-subsystem-multithreaded-probing.patch:
>
> <quote>
> > Wouldn't per-subsystem multithreaded probing just expose bugs that
> > could also be exposed on SMP systems?
>
> Yes, it would be the same.
> </quote>
Hm, I don't think I'll follow up with this - we need a different
approach, I guess.
> However, device_probe_drivers() remains temporarily unused, so we either
> suppress the compiler warning or remove the whole function altogether. The
> following patch does the first.
I'd prefer to kill device_probe_drivers(). If we really need something
like this sometime in the future, we can easily resurrect it.
Signed-off-by: Cornelia Huck <[email protected]>
---
drivers/base/dd.c | 13 -------------
1 file changed, 13 deletions(-)
--- linux-2.6.orig/drivers/base/dd.c
+++ linux-2.6/drivers/base/dd.c
@@ -207,19 +207,6 @@ static int __device_attach(struct device
return driver_probe_device(drv, dev);
}
-static int device_probe_drivers(void *data)
-{
- struct device *dev = data;
- int ret = 0;
-
- if (dev->bus) {
- down(&dev->sem);
- ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
- up(&dev->sem);
- }
- return ret;
-}
-
/**
* device_attach - try to attach device to a driver.
* @dev: device.
Existing v4l applications are failing with the latest release
candidate.
This is xawtv-3.95.dfsg.1, running on Linux/i686 (2.6.22-rc1)
xinerama 0: 1280x1024+0+0
/dev/video0 [v4l2]: ioctl VIDIOC_G_FBUF: Invalid argument
v4l-conf had some trouble, trying to continue anyway
ioctl: VIDIOC_G_FBUF(capability=0x0 [];flags=0x0 [];base=(nil);fmt.width=0;fmt.h
eight=0;fmt.pixelformat=0x00000000 [....];fmt.field=ANY;fmt.bytesperline=0;fmt.s
izeimage=0;fmt.colorspace=unknown;fmt.priv=0): Invalid argument
ioctl: VIDIOC_TRY_FMT(type=VIDEO_OVERLAY;fmt.win.w.left=3;fmt.win.w.top=701;fmt.
win.w.width=384;fmt.win.w.height=288;fmt.win.field=ANY;fmt.win.chromakey=0;fmt.w
in.clips=(nil);fmt.win.clipcount=0;fmt.win.bitmap=(nil)): Invalid argument
ioctl: VIDIOC_S_FMT(type=VIDEO_OVERLAY;fmt.win.w.left=3;fmt.win.w.top=701;fmt.wi
n.w.width=384;fmt.win.w.height=288;fmt.win.field=ANY;fmt.win.chromakey=0;fmt.win
.clips=(nil);fmt.win.clipcount=0;fmt.win.bitmap=(nil)): Invalid argument
After bisecting I tracked the problem down to this commit:
206ebaf32795cf1582b1e2ff2ec6a560c9e986b8
V4L/DVB (5272): Add V4L2_CAP_VIDEO_OUTPUT_POS capability
Add V4L2_CAP_VIDEO_OUTPUT_POS capability and x, y position coordinates
to struct v4l2_pix_format.
This is needed to support positioning the MPEG/YUV output of the cx23415.
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
This commit changes the ABI by adding two new fields to the existing
struct v4l2_pix_format which is used by the existing VIDIOC_G_FBUF
ioctl. v4l applications compiled against a previous version of the
kernel will fail in the generic ioctl code due to the size mismatch of
the arguments.
Commenting out the two new fields and recompiling allows the exists
application to work correctly.
Possibly the commit should be reverted or reworked to not change the
ABI?
Robert
2007/5/14, Jean Delvare <[email protected]>:
[cut]
> I am not familiar with the gnome sensors applet. Does it say where it
> is getting the data (driver name, device name...)?
The applet settings show a list of sensors under the libsensors name.
Those are the sensors that work on 2.6.21.1.
However the acpi and i2c section of the two config are
> > identical. I report the only selected options:
> >
> > Power management options (ACPI, APM) --->
> > [*] Power Management support
> > [*] Software Suspend (Hibernation)
> > ACPI (Advanced Configuration and Power Interface) Support --->
> > [*] ACPI Support
> > [*] Sleep States
> > <M> Button
> > <M> Video
> > <M> Fan
> > <M> Processor
> > <M> Thermal Zone
> > (0) Disable ACPI for systems before Jan 1st this year
> >
> > Device Drivers --->
> > I2C support --->
> > <M> I2C device interface
> > I2C Hardware Bus support --->
> > <M> VIA VT82C596/82C686/82xx and CX700
>
> You forgot to list the Hardware Monitoring support options.
Sorry. Here it is (they are identical in the two config):
Hardware Monitoring support --->
<*> Hardware Monitoring support
<*> Abit uGuru
<M> VIA686A
<*> IBM Hard Drive Active Protection System (hdaps)
But I'm quite sure that the only module used is VIA686A (I'm
rebuilding to confirm).
> > The first column of lsmod list the same modules in both kernels. The
> > diff-ed dmesg is attached.
>
> Please provide the output of lsmod.
>
> If you are using one of the following drivers: lm78, smsc47b397,
> smsc47m1, w83627hf or w83781d, you need lm_sensors >= 2.10.1
> (libsensors.so.3.1.1 or later).
>
I've attached the lsmod for 2.6.22-rc. I'm not using any of the listed
drivers. However the lm-sensors package is version 2.10.1-3 and
libsensors.so.3.1.1 is on my system too (package libsensors3).
Thanks.
> --
> Jean Delvare
~ Antonio
Jan Engelhardt <[email protected]> wrote:
> net/built-in.o: In function `rxrpc_destroy_all_calls':
> (.exit.text+0x71d): undefined reference to `rxrpc_call_states'
> make: *** [.tmp_vmlinux1] Error 1
This is the problem:
# CONFIG_PROC_FS is not set
CONFIG_AF_RXRPC=y
David
Hi Antonino,
On Mon, 14 May 2007 10:34:08 +0200, Antonino Ingargiola wrote:
> 2007/5/14, Jean Delvare <[email protected]>:
> [cut]
> > I am not familiar with the gnome sensors applet. Does it say where it
> > is getting the data (driver name, device name...)?
>
> The applet settings show a list of sensors under the libsensors name.
> Those are the sensors that work on 2.6.21.1.
>
> However the acpi and i2c section of the two config are
> > > identical. I report the only selected options:
> > >
> > > Power management options (ACPI, APM) --->
> > > [*] Power Management support
> > > [*] Software Suspend (Hibernation)
> > > ACPI (Advanced Configuration and Power Interface) Support --->
> > > [*] ACPI Support
> > > [*] Sleep States
> > > <M> Button
> > > <M> Video
> > > <M> Fan
> > > <M> Processor
> > > <M> Thermal Zone
> > > (0) Disable ACPI for systems before Jan 1st this year
> > >
> > > Device Drivers --->
> > > I2C support --->
> > > <M> I2C device interface
> > > I2C Hardware Bus support --->
> > > <M> VIA VT82C596/82C686/82xx and CX700
> >
> > You forgot to list the Hardware Monitoring support options.
>
> Sorry. Here it is (they are identical in the two config):
>
> Hardware Monitoring support --->
> <*> Hardware Monitoring support
> <*> Abit uGuru
> <M> VIA686A
> <*> IBM Hard Drive Active Protection System (hdaps)
>
> But I'm quite sure that the only module used is VIA686A (I'm
> rebuilding to confirm).
This is a rather bad idea to build the abituguru and hdaps drivers into
your kernel if you don't have these devices. Especially abituguru, as
it does arbitrary port probing.
> > > The first column of lsmod list the same modules in both kernels. The
> > > diff-ed dmesg is attached.
> >
> > Please provide the output of lsmod.
> >
> > If you are using one of the following drivers: lm78, smsc47b397,
> > smsc47m1, w83627hf or w83781d, you need lm_sensors >= 2.10.1
> > (libsensors.so.3.1.1 or later).
>
> I've attached the lsmod for 2.6.22-rc.
You didn't.
> I'm not using any of the listed drivers.
How strange, why are they loaded then?
> However the lm-sensors package is version 2.10.1-3 and
> libsensors.so.3.1.1 is on my system too (package libsensors3).
Can you please share the output of "sensors" under both kernels 2.6.21.1
and 2.6.22-rc1.
I would also be interested in a diff of /proc/ioports between 2.6.21.1
and 2.6.22-rc1.
--
Jean Delvare
Hi Jean,
2007/5/14, Jean Delvare <[email protected]>:
[cut]
> This is a rather bad idea to build the abituguru and hdaps drivers into
> your kernel if you don't have these devices. Especially abituguru, as
> it does arbitrary port probing.
My bad. I have an abit motherboard and in doubt I selected the driver
(and then leaved selected since all worked on previous kernels). I've
disabled them and the problem persist.
> > > > The first column of lsmod list the same modules in both kernels. The
> > > > diff-ed dmesg is attached.
> > >
> > > Please provide the output of lsmod.
> > >
> > > If you are using one of the following drivers: lm78, smsc47b397,
> > > smsc47m1, w83627hf or w83781d, you need lm_sensors >= 2.10.1
> > > (libsensors.so.3.1.1 or later).
> >
> > I've attached the lsmod for 2.6.22-rc.
>
> You didn't.
>
:) Right, sorry. Now it is.
> > I'm not using any of the listed drivers.
>
> How strange, why are they loaded then?
My reply refers to your list of drivers that require a certain version
of lm-sensors.
> > However the lm-sensors package is version 2.10.1-3 and
> > libsensors.so.3.1.1 is on my system too (package libsensors3).
>
> Can you please share the output of "sensors" under both kernels 2.6.21.1
> and 2.6.22-rc1.
Sure. On 2.6.21.1:
via686a-isa-6000
Adapter: ISA adapter
CPU core: +1.63 V (min = +0.06 V, max = +3.10 V)
+2.5V: +2.45 V (min = +0.06 V, max = +3.10 V)
I/O: +3.52 V (min = +3.12 V, max = +3.45 V) ALARM
+5V: +5.05 V (min = +4.73 V, max = +5.20 V)
+12V: +12.30 V (min = +11.35 V, max = +12.48 V)
CPU Fan: 0 RPM (min = 42187 RPM, div = 2)
P/S Fan: 2657 RPM (min = 42187 RPM, div = 2) ALARM
SYS Temp: +40.9?C (high = +146?C, hyst = -71?C)
CPU Temp: +43.3?C (high = +146?C, hyst = -71?C)
SBr Temp: +24.9?C (high = -63?C, hyst = -71?C) ALARM
while on 2.6.22-rc1:
via686a-i2c-9191-6000
ERROR: Can't get adapter or algorithm?!?
CPU core: +1.65 V (min = +0.06 V, max = +3.10 V)
+2.5V: +2.45 V (min = +0.06 V, max = +3.10 V)
I/O: +3.52 V (min = +3.12 V, max = +3.45 V) ALARM
+5V: +5.08 V (min = +4.73 V, max = +5.20 V)
+12V: +12.24 V (min = +11.35 V, max = +12.48 V)
CPU Fan: 0 RPM (min = 42187 RPM, div = 2)
P/S Fan: 0 RPM (min = 42187 RPM, div = 2) ALARM
SYS Temp: +41.3?C (high = +146?C, hyst = -71?C)
CPU Temp: +41.8?C (high = +146?C, hyst = -71?C)
SBr Temp: +24.9?C (high = -63?C, hyst = -71?C) ALARM
In both kernels I have set:
I2C Algorithms --->
<M> I2C PCF 8584 interfaces
<M> I2C PCA 9564 interfaces
> I would also be interested in a diff of /proc/ioports between 2.6.21.1
> and 2.6.22-rc1.
>
The diff is empty.
> --
> Jean Delvare
~ Antonio
On Mon, 14 May 2007 15:28:00 +0200, Antonino Ingargiola wrote:
> Hi Jean,
>
> 2007/5/14, Jean Delvare <[email protected]>:
> [cut]
> > This is a rather bad idea to build the abituguru and hdaps drivers into
> > your kernel if you don't have these devices. Especially abituguru, as
> > it does arbitrary port probing.
>
> My bad. I have an abit motherboard and in doubt I selected the driver
> (and then leaved selected since all worked on previous kernels). I've
> disabled them and the problem persist.
Sure, I didn't expect it to solve the problem. But as a general advice,
hardware monitoring drivers are better selected as modules than
built-in.
> > > I'm not using any of the listed drivers.
> >
> > How strange, why are they loaded then?
>
> My reply refers to your list of drivers that require a certain version
> of lm-sensors.
Ah, OK. Sorry, I got confused.
> > > However the lm-sensors package is version 2.10.1-3 and
> > > libsensors.so.3.1.1 is on my system too (package libsensors3).
> >
> > Can you please share the output of "sensors" under both kernels 2.6.21.1
> > and 2.6.22-rc1.
>
> Sure. On 2.6.21.1:
>
> via686a-isa-6000
> Adapter: ISA adapter
> CPU core: +1.63 V (min = +0.06 V, max = +3.10 V)
> +2.5V: +2.45 V (min = +0.06 V, max = +3.10 V)
> I/O: +3.52 V (min = +3.12 V, max = +3.45 V) ALARM
> +5V: +5.05 V (min = +4.73 V, max = +5.20 V)
> +12V: +12.30 V (min = +11.35 V, max = +12.48 V)
> CPU Fan: 0 RPM (min = 42187 RPM, div = 2)
> P/S Fan: 2657 RPM (min = 42187 RPM, div = 2) ALARM
Hint: increase the fan clock dividers to 4.
> SYS Temp: +40.9?C (high = +146?C, hyst = -71?C)
> CPU Temp: +43.3?C (high = +146?C, hyst = -71?C)
> SBr Temp: +24.9?C (high = -63?C, hyst = -71?C) ALARM
>
> while on 2.6.22-rc1:
>
> via686a-i2c-9191-6000
> ERROR: Can't get adapter or algorithm?!?
Ah, interesting. Could it be that the gnome applet quits because it
fails to get the adapter name? That wouldn't be very smart, but that's
possible.
This is a side effect of an i2c-core cleanup. This is already fixed in
lm_sensors 2.10.3 (libsensors.so.3.1.3). Care to give it a try and
confirm it fixes the problem? Note that it might be a bit tricky to get
the gnome applet to use your own libsensors rather than the system one.
You might need to set the LD_LIBRARY_PATH environment variable before
the applet starts, or something similar.
> CPU core: +1.65 V (min = +0.06 V, max = +3.10 V)
> +2.5V: +2.45 V (min = +0.06 V, max = +3.10 V)
> I/O: +3.52 V (min = +3.12 V, max = +3.45 V) ALARM
> +5V: +5.08 V (min = +4.73 V, max = +5.20 V)
> +12V: +12.24 V (min = +11.35 V, max = +12.48 V)
> CPU Fan: 0 RPM (min = 42187 RPM, div = 2)
> P/S Fan: 0 RPM (min = 42187 RPM, div = 2) ALARM
> SYS Temp: +41.3?C (high = +146?C, hyst = -71?C)
> CPU Temp: +41.8?C (high = +146?C, hyst = -71?C)
> SBr Temp: +24.9?C (high = -63?C, hyst = -71?C) ALARM
>
> In both kernels I have set:
>
> I2C Algorithms --->
> <M> I2C PCF 8584 interfaces
> <M> I2C PCA 9564 interfaces
Irrelevant to your problem, but you most certainly need neither - else
they would have been selected automatically.
--
Jean Delvare
Hi Jean!
2007/5/14, Jean Delvare <[email protected]>:
> > Sure. On 2.6.21.1:
> >
> > via686a-isa-6000
> > Adapter: ISA adapter
> > CPU core: +1.63 V (min = +0.06 V, max = +3.10 V)
> > +2.5V: +2.45 V (min = +0.06 V, max = +3.10 V)
> > I/O: +3.52 V (min = +3.12 V, max = +3.45 V) ALARM
> > +5V: +5.05 V (min = +4.73 V, max = +5.20 V)
> > +12V: +12.30 V (min = +11.35 V, max = +12.48 V)
> > CPU Fan: 0 RPM (min = 42187 RPM, div = 2)
> > P/S Fan: 2657 RPM (min = 42187 RPM, div = 2) ALARM
>
> Hint: increase the fan clock dividers to 4.
>
I've not found an obvious way to set it in sensors.conf. Could you
point me to some doumentation, thanks.
> > while on 2.6.22-rc1:
> >
> > via686a-i2c-9191-6000
> > ERROR: Can't get adapter or algorithm?!?
>
> Ah, interesting. Could it be that the gnome applet quits because it
> fails to get the adapter name? That wouldn't be very smart, but that's
> possible.
Just for the record. Does not quit. It displays on the panel "Chip not found.".
> This is a side effect of an i2c-core cleanup. This is already fixed in
> lm_sensors 2.10.3 (libsensors.so.3.1.3). Care to give it a try and
> confirm it fixes the problem? Note that it might be a bit tricky to get
> the gnome applet to use your own libsensors rather than the system one.
> You might need to set the LD_LIBRARY_PATH environment variable before
> the applet starts, or something similar.
Luckily the 2.10.3 lm-sensors version is on unstable. The backport to
Debian Etch was straightforward. Now the applet works again! And the
P/S fan indicator (you may have noted that showed 0 in the 2.6.22-rc1
case) works too. Many thanks ;-).
Is this new version required only for the via686 chip or should be a
general advise for Debian Etch users to upgrade to lm-sensors >=
2.10.3 for kernels >= 2.6.22?
~ Antonio
Hi,
On 14/05/07, Antonino Ingargiola <[email protected]> wrote:
> Hi Jean!
>
> 2007/5/14, Jean Delvare <[email protected]>:
>
> > > Sure. On 2.6.21.1:
> > >
> > > via686a-isa-6000
> > > Adapter: ISA adapter
> > > CPU core: +1.63 V (min = +0.06 V, max = +3.10 V)
> > > +2.5V: +2.45 V (min = +0.06 V, max = +3.10 V)
> > > I/O: +3.52 V (min = +3.12 V, max = +3.45 V) ALARM
> > > +5V: +5.05 V (min = +4.73 V, max = +5.20 V)
> > > +12V: +12.30 V (min = +11.35 V, max = +12.48 V)
> > > CPU Fan: 0 RPM (min = 42187 RPM, div = 2)
> > > P/S Fan: 2657 RPM (min = 42187 RPM, div = 2) ALARM
> >
> > Hint: increase the fan clock dividers to 4.
> >
>
> I've not found an obvious way to set it in sensors.conf. Could you
> point me to some doumentation, thanks.
>
> > > while on 2.6.22-rc1:
> > >
> > > via686a-i2c-9191-6000
> > > ERROR: Can't get adapter or algorithm?!?
> >
> > Ah, interesting. Could it be that the gnome applet quits because it
> > fails to get the adapter name? That wouldn't be very smart, but that's
> > possible.
>
> Just for the record. Does not quit. It displays on the panel "Chip not found.".
>
> > This is a side effect of an i2c-core cleanup.
I call it "breaking userspace".
> > This is already fixed in
> > lm_sensors 2.10.3 (libsensors.so.3.1.3). Care to give it a try and
> > confirm it fixes the problem? Note that it might be a bit tricky to get
> > the gnome applet to use your own libsensors rather than the system one.
> > You might need to set the LD_LIBRARY_PATH environment variable before
> > the applet starts, or something similar.
>
> Luckily the 2.10.3 lm-sensors version is on unstable. The backport to
> Debian Etch was straightforward. Now the applet works again! And the
> P/S fan indicator (you may have noted that showed 0 in the 2.6.22-rc1
> case) works too. Many thanks ;-).
>
> Is this new version required only for the via686 chip or should be a
> general advise for Debian Etch users to upgrade to lm-sensors >=
> 2.10.3 for kernels >= 2.6.22?
Ok, I removed this issue from the list of known regressions.
>
>
> ~ Antonio
> -
Regards,
Michal
--
Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)
On Mon, 14 May 2007, Jean Delvare wrote:
>
> This is a side effect of an i2c-core cleanup. This is already fixed in
> lm_sensors 2.10.3 (libsensors.so.3.1.3).
So apparently that fixed it, but in general we do not allow these kinds of
"need to have new xyz with new kernel".
Kernels are supposed to be backwards compatible. Jean, what was it that
changed, and why can't we just make them appear the same?
It may be that something like a sensors package isn't important enough to
worry about (the machine still *works*, and everything else won't notice),
but if it's a simple matter of adding some random file to /sysfs, we
should just do it.
Linus
On May 13 2007 20:19, Tilman Schmidt wrote:
>Am 13.05.2007 05:20 schrieb Linus Torvalds:
>> Ok, the merge window has closed, and 2.6.22-rc1 is out there.
>[...]
>> So give it a good testing.
>
>Would it be asking too much to have help texts on the following
>new (wrt 2.6.21) configuration options?
>
>ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
>Macintosh device drivers (MACINTOSH_DRIVERS) [Y/n] (NEW)
>Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
>Ethernet (10000 Mbit) (NETDEV_10000) [Y/n] (NEW)
>
>Those for the latter three could/should say something like the
>one for the WLAN_80211 option.
"Patches welcome" ;-)
As for NETDEV_1000 and _10000, I really wonder if we need anymore
help text than the option. I do not know what the minimum level
of user knowledge is that kconfig help texts need to support,
but maybe you can tell?
Jan
--
On May 14 2007 12:44, David Howells wrote:
>Jan Engelhardt <[email protected]> wrote:
>
>> net/built-in.o: In function `rxrpc_destroy_all_calls':
>> (.exit.text+0x71d): undefined reference to `rxrpc_call_states'
>> make: *** [.tmp_vmlinux1] Error 1
>
>This is the problem:
>
> # CONFIG_PROC_FS is not set
> CONFIG_AF_RXRPC=y
Are you going to fix it?
Jan
--
Jan Engelhardt wrote:
> On May 13 2007 20:19, Tilman Schmidt wrote:
...
>> Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
>> Ethernet (10000 Mbit) (NETDEV_10000) [Y/n] (NEW)
>>
>> Those for the latter three could/should say something like the
>> one for the WLAN_80211 option.
>
> "Patches welcome" ;-)
>
> As for NETDEV_1000 and _10000, I really wonder if we need anymore
> help text than the option. I do not know what the minimum level
> of user knowledge is that kconfig help texts need to support,
> but maybe you can tell?
The text "Ethernet (10000 Mbit)" _doesn't_ tell me that this option
"does not affect the kernel build, it only lets [me] choose drivers".
The "patches welcome" is quite appropriate. On the other hand, visible
Kconfig options without help text should almost never be allowed to go
in in the first place, IMO.
--
Stefan Richter
-=====-=-=== -=-= -===-
http://arcgraph.de/sr/
Jan Engelhardt schrieb:
> On May 13 2007 20:19, Tilman Schmidt wrote:
>>
>>Would it be asking too much to have help texts on the following
>>new (wrt 2.6.21) configuration options?
>>
>>ESP Scsi Driver Core (SCSI_ESP_CORE) [N/m] (NEW)
>>Macintosh device drivers (MACINTOSH_DRIVERS) [Y/n] (NEW)
>>Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
>>Ethernet (10000 Mbit) (NETDEV_10000) [Y/n] (NEW)
>>
>>Those for the latter three could/should say something like the
>>one for the WLAN_80211 option.
>
> "Patches welcome" ;-)
Sure. Just tell me exactly what those options are intended to do
and I'll happily write up a patch adding help texts trying to
express that in bad English. :-)
Seriously, it might be a tad more efficient if the help texts were
written by those who invented the options in the first place.
> As for NETDEV_1000 and _10000, I really wonder if we need anymore
> help text than the option. I do not know what the minimum level
> of user knowledge is that kconfig help texts need to support,
> but maybe you can tell?
For a start, it shouldn't require users to grep through Kconfigs
and Makefiles in order to find out what effects an option has.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
Hi Antonino,
On Mon, 14 May 2007 18:04:00 +0200, Antonino Ingargiola wrote:
> Hi Jean!
>
> 2007/5/14, Jean Delvare <[email protected]>:
>
> > > Sure. On 2.6.21.1:
> > >
> > > via686a-isa-6000
> > > Adapter: ISA adapter
> > > CPU core: +1.63 V (min = +0.06 V, max = +3.10 V)
> > > +2.5V: +2.45 V (min = +0.06 V, max = +3.10 V)
> > > I/O: +3.52 V (min = +3.12 V, max = +3.45 V) ALARM
> > > +5V: +5.05 V (min = +4.73 V, max = +5.20 V)
> > > +12V: +12.30 V (min = +11.35 V, max = +12.48 V)
> > > CPU Fan: 0 RPM (min = 42187 RPM, div = 2)
> > > P/S Fan: 2657 RPM (min = 42187 RPM, div = 2) ALARM
> >
> > Hint: increase the fan clock dividers to 4.
>
> I've not found an obvious way to set it in sensors.conf. Could you
> point me to some doumentation, thanks.
sensors.conf supposedly _is_ the the documentation ;)
Search for the following line in /etc/sensors.conf:
chip "via686a-*"
After this line, add:
set fan1_div 4
set fan2_div 4
Save, quit, run "sensors -s" (as root), that should do it.
> > > while on 2.6.22-rc1:
> > >
> > > via686a-i2c-9191-6000
> > > ERROR: Can't get adapter or algorithm?!?
> >
> > Ah, interesting. Could it be that the gnome applet quits because it
> > fails to get the adapter name? That wouldn't be very smart, but that's
> > possible.
>
> Just for the record. Does not quit. It displays on the panel "Chip not found.".
>
> > This is a side effect of an i2c-core cleanup. This is already fixed in
> > lm_sensors 2.10.3 (libsensors.so.3.1.3). Care to give it a try and
> > confirm it fixes the problem? Note that it might be a bit tricky to get
> > the gnome applet to use your own libsensors rather than the system one.
> > You might need to set the LD_LIBRARY_PATH environment variable before
> > the applet starts, or something similar.
>
> Luckily the 2.10.3 lm-sensors version is on unstable. The backport to
> Debian Etch was straightforward. Now the applet works again! And the
> P/S fan indicator (you may have noted that showed 0 in the 2.6.22-rc1
> case) works too. Many thanks ;-).
Great, this is good news.
The 0 RPM reading isn't related to the problem you had, this is a
coincidence. 2657 RPM (which your other example shows) is the lowest fan
speed this chip can measure with a fan clock divider of 2, anything
slower is reported as 0 RPM. That's the reason why I suggested
switching the divider to 4.
> Is this new version required only for the via686 chip or should be a
> general advise for Debian Etch users to upgrade to lm-sensors >=
> 2.10.3 for kernels >= 2.6.22?
The problem affects almost all hardware monitoring chips, so this is a
general advice. I've added a note about it on the lm-sensors website.
Alternatively though, you could have recompiled your kernel with
CONFIG_SYSFS_DEPRECATED=y, then lm_sensors 2.10.1 would have worked
fine again. Sorry for not mentioning this before, this might have been
easier than upgrading lm_sensors.
--
Jean Delvare
Hello Linus,
On Mon, 14 May 2007 09:30:19 -0700 (PDT), Linus Torvalds wrote:
> On Mon, 14 May 2007, Jean Delvare wrote:
> >
> > This is a side effect of an i2c-core cleanup. This is already fixed in
> > lm_sensors 2.10.3 (libsensors.so.3.1.3).
>
> So apparently that fixed it, but in general we do not allow these kinds of
> "need to have new xyz with new kernel".
Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.
> Kernels are supposed to be backwards compatible. Jean, what was it that
> changed, and why can't we just make them appear the same?
>
> It may be that something like a sensors package isn't important enough to
> worry about (the machine still *works*, and everything else won't notice),
> but if it's a simple matter of adding some random file to /sysfs, we
> should just do it.
We already have CONFIG_SYSFS_DEPRECATED for that.
--
Jean Delvare
Hi Jean,
2007/5/14, Jean Delvare <[email protected]>:
[cut]
> > I've not found an obvious way to set it in sensors.conf. Could you
> > point me to some doumentation, thanks.
>
> sensors.conf supposedly _is_ the the documentation ;)
>
> Search for the following line in /etc/sensors.conf:
>
> chip "via686a-*"
>
> After this line, add:
>
> set fan1_div 4
> set fan2_div 4
>
> Save, quit, run "sensors -s" (as root), that should do it.
Thanks for the explanation (it's not too evident form sensors.conf ;)).
> > Is this new version required only for the via686 chip or should be a
> > general advise for Debian Etch users to upgrade to lm-sensors >=
> > 2.10.3 for kernels >= 2.6.22?
>
> The problem affects almost all hardware monitoring chips, so this is a
> general advice. I've added a note about it on the lm-sensors website.
>
> Alternatively though, you could have recompiled your kernel with
> CONFIG_SYSFS_DEPRECATED=y, then lm_sensors 2.10.1 would have worked
> fine again. Sorry for not mentioning this before, this might have been
> easier than upgrading lm_sensors.
No problem. I took no more than 5 min to do the backport instead of
~25 min of a full kernel built ;-). BTW it's always good to know the
various solutions.
Thanks,
~ Antonio
On Mon, 14 May 2007, Jean Delvare wrote:
>
> Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
> 2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.
And we really complained about it! The oprofile thing should be fixed,
btw, and yeah,if udev breaks any more, I'll have to stop taking patches
from Greg. That thing has been a disaster, and everybody involved should
be ashamed and now hopefully *very* aware of the fact that we don't break
user-level interfaces.
(Right now, I suspect we may have a loop setup regression. Not sure)
> We already have CONFIG_SYSFS_DEPRECATED for that.
..and that should have been made more clear. I certainly didn't react to
it immediately.
Linus
On Mon, 14 May 2007 11:43:45 -0700 (PDT), Linus Torvalds wrote:
>
> On Mon, 14 May 2007, Jean Delvare wrote:
> >
> > Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
> > 2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.
>
> And we really complained about it! The oprofile thing should be fixed,
> btw, and yeah,if udev breaks any more, I'll have to stop taking patches
> from Greg. That thing has been a disaster, and everybody involved should
> be ashamed and now hopefully *very* aware of the fact that we don't break
> user-level interfaces.
>
> (Right now, I suspect we may have a loop setup regression. Not sure)
While I'm all for keeping things relatively stable and not asking the
user to constantly upgrade user-space, I believe that we just can't
promise to never break user-level interfaces while keeping the
development pace we have right now. We can promise to grant people
significant delay before we drop compatibility options, but "forever"
doesn't scale.
If you really want to enforce the "never" rule, be prepared to either
see development slow down and finally come to a stop, or see the code
become unmaintainable and insecure and nobody is longer willing to work
on it.
> > We already have CONFIG_SYSFS_DEPRECATED for that.
>
> ..and that should have been made more clear. I certainly didn't react to
> it immediately.
You seem to assume that I remembered myself about this option when I
first replied. I wish it were true :(
--
Jean Delvare
Jean Delvare wrote:
> On Mon, 14 May 2007 11:43:45 -0700 (PDT), Linus Torvalds wrote:
>> On Mon, 14 May 2007, Jean Delvare wrote:
>>> Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
>>> 2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.
>> And we really complained about it! The oprofile thing should be fixed,
>> btw, and yeah,if udev breaks any more, I'll have to stop taking patches
>> from Greg. That thing has been a disaster, and everybody involved should
>> be ashamed and now hopefully *very* aware of the fact that we don't break
>> user-level interfaces.
>>
>> (Right now, I suspect we may have a loop setup regression. Not sure)
>
> While I'm all for keeping things relatively stable and not asking the
> user to constantly upgrade user-space, I believe that we just can't
> promise to never break user-level interfaces while keeping the
> development pace we have right now. We can promise to grant people
> significant delay before we drop compatibility options, but "forever"
> doesn't scale.
>
> If you really want to enforce the "never" rule, be prepared to either
> see development slow down and finally come to a stop, or see the code
> become unmaintainable and insecure and nobody is longer willing to work
> on it.
Why do you think we -stopped- enforcing such a rule? :)
It's been the rule throughout Linux's history. syscalls from early
Linux binaries should still work, for example.
Jeff
On Mon, May 14, 2007 at 11:43:45AM -0700, Linus Torvalds wrote:
>
>
> On Mon, 14 May 2007, Jean Delvare wrote:
> >
> > Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
> > 2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.
>
> And we really complained about it! The oprofile thing should be fixed,
> btw, and yeah,if udev breaks any more, I'll have to stop taking patches
> from Greg. That thing has been a disaster, and everybody involved should
> be ashamed and now hopefully *very* aware of the fact that we don't break
> user-level interfaces.
sysfs is an even bigger desaster. Even if people know they can't break
userspace apis sysfs can force it on them. As long as we tightly couple
kernel data structures and a userspace ABI that's unavoidable. Unfortunately
sorting that mess out properly would be such a massive amount of work
that it'd alsmost require a 2.7 series.
On Mon, May 14, 2007 at 09:28:07PM +0200, Jean Delvare wrote:
> > And we really complained about it! The oprofile thing should be fixed,
> > btw, and yeah,if udev breaks any more, I'll have to stop taking patches
> > from Greg. That thing has been a disaster, and everybody involved should
> > be ashamed and now hopefully *very* aware of the fact that we don't break
> > user-level interfaces.
> >
> > (Right now, I suspect we may have a loop setup regression. Not sure)
>
> While I'm all for keeping things relatively stable and not asking the
> user to constantly upgrade user-space, I believe that we just can't
> promise to never break user-level interfaces while keeping the
> development pace we have right now. We can promise to grant people
> significant delay before we drop compatibility options, but "forever"
> doesn't scale.
never with a loong deprecations period. At least for APIs that are not
private to a single obscure driver. But this would require people actually
beeing aware of creating ABIs, and maybe someone with half a clue reviewing
them. Which of course is not the case today, thanks to ioctls, procfs, sysfs,
debugfs and co people can create userspace ABIs without a single though
easily, and they happily do it.
On Mon, May 14, 2007 at 03:53:21PM -0400, Jeff Garzik wrote:
> Jean Delvare wrote:
> >On Mon, 14 May 2007 11:43:45 -0700 (PDT), Linus Torvalds wrote:
> >>On Mon, 14 May 2007, Jean Delvare wrote:
> >>>Sure, we don't allow that. Except for xfsprogs in 2.6.1, procps in
> >>>2.6.4, oprofile in 2.6.13 and udev in 2.6.19, of course.
> >>And we really complained about it! The oprofile thing should be fixed,
> >>btw, and yeah,if udev breaks any more, I'll have to stop taking patches
> >>from Greg. That thing has been a disaster, and everybody involved should
> >>be ashamed and now hopefully *very* aware of the fact that we don't break
> >>user-level interfaces.
> >>
> >>(Right now, I suspect we may have a loop setup regression. Not sure)
> >
> >While I'm all for keeping things relatively stable and not asking the
> >user to constantly upgrade user-space, I believe that we just can't
> >promise to never break user-level interfaces while keeping the
> >development pace we have right now. We can promise to grant people
> >significant delay before we drop compatibility options, but "forever"
> >doesn't scale.
> >
> >If you really want to enforce the "never" rule, be prepared to either
> >see development slow down and finally come to a stop, or see the code
> >become unmaintainable and insecure and nobody is longer willing to work
> >on it.
>
> Why do you think we -stopped- enforcing such a rule? :)
>
> It's been the rule throughout Linux's history. syscalls from early
> Linux binaries should still work, for example.
Except for very rare case (modules support comes to mine) syscall
compatiblity works perfectly. But that's because syscalls are a very
visible ABI and people don't break them by accident. They also don't
decide they have a cool new scheme all syscalls need to follow now.
Now compare that to sysfs..
On May 14 2007 19:32, Stefan Richter wrote:
>>
>> As for NETDEV_1000 and _10000, I really wonder if we need anymore
>> help text than the option. I do not know what the minimum level
>> of user knowledge is that kconfig help texts need to support,
>> but maybe you can tell?
>
>The text "Ethernet (10000 Mbit)" _doesn't_ tell me that this option
>"does not affect the kernel build, it only lets [me] choose drivers".
>
>The "patches welcome" is quite appropriate. On the other hand, visible
>Kconfig options without help text should almost never be allowed to go
>in in the first place, IMO.
Well, it was a conversion from "menu" to "menuconfig". Since
menus cannot(?) have a kconfig text, I did not transform one.
For the "config" to "menuconfig" conversions, the help text
was preserved, since there was something to preserve.
Jan
--
On May 14 2007 20:01, Tilman Schmidt wrote:
>>
>> "Patches welcome" ;-)
>
>Sure. Just tell me exactly what those options are intended to do
>and I'll happily write up a patch adding help texts trying to
>express that in bad English. :-)
They are just a menu that can be switched on or off.
It is for those people that start with an arbitrary .config and
work their way through menuconfig to disable all the parts they
do not want. So, point no. 1:
* Disabling this menu disables all the fluff inside it,
without needing to enter the menu and disable each
option one by one (as was the case previously)
Then of course, one can also turn these menuconfig on (apparently!)
to be able to descend into them and select some drivers they like.
Point no. 2:
* Since Jens Axboe's stance ["default y idiocy"] is to have
these menus disabled by default, people should most likely
enable them first before they will be able to enter them.
(I would have wanted them to be always 'y' - it does not affect
the build, just opens all menus by default)
>Seriously, it might be a tad more efficient if the help texts were
>written by those who invented the options in the first place.
menuconfig NETDEV_10000
bool "Ethernet (10GbE)"
---help--
Say Y here to actually be able to go into this menu
and select some drivers that we think belong to the
"10 Gigabit Ethernet" family.
If unsure, it is unwise to say N!
See, this looks so fundamentally basic to me that I find it
almost funny. YMMV, hence I asked for suggestions from
other people.
>> As for NETDEV_1000 and _10000, I really wonder if we need anymore
>> help text than the option. I do not know what the minimum level
>> of user knowledge is that kconfig help texts need to support,
>> but maybe you can tell?
>
>For a start, it shouldn't require users to grep through Kconfigs
>and Makefiles in order to find out what effects an option has.
menuconfigs are some special kind in that they combine an option
with a menu. Perhaps now that some ->menuconfig patches have gone
in, more people will get to know these constructs.
Jan
--
Am 14.05.2007 22:33 schrieb Jan Engelhardt:
> On May 14 2007 20:01, Tilman Schmidt wrote:
>>> "Patches welcome" ;-)
>> Sure. Just tell me exactly what those options are intended to do
>> and I'll happily write up a patch adding help texts trying to
>> express that in bad English. :-)
>
> They are just a menu that can be switched on or off.
Ok, that's the first essential piece of information which is *not*
evident from the prompt "make oldconfig" presents me with:
Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
contains *no* indication that this is the start of a menu.
> * Disabling this menu disables all the fluff inside it,
Another essential piece of information. I seem to remember other
menus which, when disabled, kept the selection status of the
options inside and just hid them from view.
> menuconfig NETDEV_10000
> bool "Ethernet (10GbE)"
> ---help--
> Say Y here to actually be able to go into this menu
> and select some drivers that we think belong to the
> "10 Gigabit Ethernet" family.
>
> If unsure, it is unwise to say N!
>
> See, this looks so fundamentally basic to me that I find it
> almost funny. YMMV, hence I asked for suggestions from
> other people.
That's because it's so incomplete and mentions only the facts
which where obvious in the first place. (Except for the "this
menu" part which might appear rather cryptic to users of the
curses based interface who don't see any menu.)
Have a look at the entry "config NET_ETHERNET" for an impression
of what others felt worth mentioning in similar circumstances.
And no, that is not funny, even though much of it is of course
fundamentally basic for most of us. It does actually help people
confronted with the question.
>> For a start, it shouldn't require users to grep through Kconfigs
>> and Makefiles in order to find out what effects an option has.
>
> menuconfigs are some special kind in that they combine an option
> with a menu. Perhaps now that some ->menuconfig patches have gone
> in, more people will get to know these constructs.
Point is, without grepping through the Kconfig the user has no
way of knowing that the question comes from a menuconfig in the
first place, at least with "make menuconfig" and friends, and
without grepping through the Makefile (and, ? la limite, source
files) s/he cannot be sure the option doesn't directly affect
code generation.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
Jan Engelhardt wrote:
> menuconfig NETDEV_10000
> bool "Ethernet (10GbE)"
> ---help--
> Say Y here to actually be able to go into this menu
> and select some drivers that we think belong to the
> "10 Gigabit Ethernet" family.
>
> If unsure, it is unwise to say N!
>
> See, this looks so fundamentally basic to me that I find it
> almost funny. YMMV, hence I asked for suggestions from
> other people.
One problem is, nobody can see easily whether saying Y is merely the
ticket to get into the menu, or whether it on its own will cause
something to be built.
PS: I still believe that Kconfigs shouldn't by overly burdened with
presentation. Presentation should mostly be left to the UIs. And the
UIs shouldn't be created by kernel hackers... ;-)
--
Stefan Richter
-=====-=-=== -=-= -===-
http://arcgraph.de/sr/
Tilman Schmidt wrote:
> Am 14.05.2007 22:33 schrieb Jan Engelhardt:
>> * Disabling this menu disables all the fluff inside it,
except when it doesn't.
> Another essential piece of information. I seem to remember other
> menus which, when disabled, kept the selection status of the
> options inside and just hid them from view.
It's a matter of /dependence/ on a menuconfig option whether options
inside the menu will be disabled. Not a matter of being located in the
menu.
If menuconfig isn't used with strict discipline, we end up with
inconsistent and misleading presentation of the kernel configuration.
--
Stefan Richter
-=====-=-=== -=-= -===-
http://arcgraph.de/sr/
Hello,
On 5/15/07, Jan Engelhardt <[email protected]> wrote:
> [...]
> They are just a menu
Ok, so they don't really affect Makefiles / sources (and thus builds).
In that case I'd suggest that let's please change the names of such
menuconfig options from CONFIG_ to CONFIG_MENU_, otherwise
we really screw the text-based "make oldconfig" folks who think
that they're taking a build-related (and not presentation-related)
decision when confronted with a:
Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
kind of option. OTOH:
Ethernet (1000 Mbit) (MENU_NETDEV_1000) [Y/n] (NEW)
taxes a make-oldconfig-using-person's intuition a little less, IMHO.
So this'll hopefully take care of Tilman's and Stefan's gripes:
On 5/15/07, Tilman Schmidt <[email protected]> wrote:
> (Except for the "this
> menu" part which might appear rather cryptic to users of the
> curses based interface who don't see any menu.)
> [...]
> Point is, without grepping through the Kconfig the user has no
> way of knowing that the question comes from a menuconfig in the
> first place ...
> ... s/he cannot be sure the option doesn't directly affect
> code generation.
and
On 5/15/07, Stefan Richter <[email protected]> wrote:
> One problem is, nobody can see easily whether saying Y is merely the
> ticket to get into the menu, or whether it on its own will cause
> something to be built.
?
On 5/15/07, Jan Engelhardt <[email protected]> wrote:
> that can be switched on or off.
> It is for those people that start with an arbitrary .config and
> work their way through menuconfig to disable all the parts they
> do not want. So, point no. 1:
>
> * Disabling this menu disables all the fluff inside it,
> without needing to enter the menu and disable each
> option one by one (as was the case previously)
This kind of promise was really nice, and why I liked Jan's
menuconfig patches a lot.
But if:
On 5/15/07, Tilman Schmidt <[email protected]> wrote:
> Another essential piece of information. I seem to remember other
> menus which, when disabled, kept the selection status of the
> options inside and just hid them from view.
is true, then are we really gaining much from these configmenu's?
[unrelated]
I wish these new constructs were called "configmenu" and
_not_ "menuconfig". It causes confusion with the "menuconfig"
master Makefile rule which has nothing to do with these new
"configmenu"s.
[/unrelated]
> Then of course, one can also turn these menuconfig on (apparently!)
> to be able to descend into them and select some drivers they like.
> Point no. 2:
>
> * Since Jens Axboe's stance ["default y idiocy"] is to have
> these menus disabled by default, people should most likely
> enable them first before they will be able to enter them.
I do agree that anything non-essential (even if it's just a presentation
menu that doesn't affect builds) must be default n.
> (I would have wanted them to be always 'y' - it does not affect
> the build, just opens all menus by default)
IMHO, the real problem with "default y" menuconfig's, is that they
cause unpleasant surprises to those folks that use the text-based
"make oldconfig". They get confronted with choices that they never
bothered about (or even knew existed) previously, and have no
idea how to answer them -- same problem faced by Tilman, when
he used oldconfig.
> >Seriously, it might be a tad more efficient if the help texts were
> >written by those who invented the options in the first place.
>
> menuconfig NETDEV_10000
> bool "Ethernet (10GbE)"
> ---help--
> Say Y here to actually be able to go into this menu
> and select some drivers that we think belong to the
> "10 Gigabit Ethernet" family.
>
> If unsure, it is unwise to say N!
>
> See, this looks so fundamentally basic to me that I find it
> almost funny. YMMV, hence I asked for suggestions from
> other people.
IMHO, those using "oldconfig" are often looking towards doing
things quickly ... doesn't help them if they have default y menu's
that they need to "?" upon then to see what they're really about.
> >For a start, it shouldn't require users to grep through Kconfigs
> >and Makefiles in order to find out what effects an option has.
>
> menuconfigs are some special kind in that they combine an option
> with a menu. Perhaps now that some ->menuconfig patches have gone
> in, more people will get to know these constructs.
I think what happened here is that Jan really only considered the
"make menuconfig" users with these new constructs (which makes life
really simple for them), but "oldconfig" users were unfortunately in for
unpleasant surprises ...
On 5/15/07, Stefan Richter <[email protected]> wrote:
> PS: I still believe that Kconfigs shouldn't by overly burdened with
> presentation. Presentation should mostly be left to the UIs. And the
> UIs shouldn't be created by kernel hackers... ;-)
Kernel dev's can still try, can't they ;-) I do agree that Kconfig is
primarily a build dependency language, but also, note that linking
Kconfig dependency rules with presentation isn't an idea that seems
to be fundamentally broken or anything.
Just my 2 paise,
Satyam
> On 5/15/07, Jan Engelhardt <[email protected]> wrote:
> > [...]
> > They are just a menu
>
> Ok, so they don't really affect Makefiles / sources (and thus builds).
> In that case I'd suggest that let's please change the names of such
> menuconfig options from CONFIG_ to CONFIG_MENU_, otherwise
Or perhaps we could change the text associated with these
"menu-only" dummy constructs instead ...
> we really screw the text-based "make oldconfig" folks who think
> that they're taking a build-related (and not presentation-related)
> decision when confronted with a:
So:
> Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
becomes:
[MENU] Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
?
Thanks,
Satyam
On 5/15/07, Stefan Richter <[email protected]> wrote:
> Tilman Schmidt wrote:
> > Am 14.05.2007 22:33 schrieb Jan Engelhardt:
> >> * Disabling this menu disables all the fluff inside it,
>
> except when it doesn't.
>
> > Another essential piece of information. I seem to remember other
> > menus which, when disabled, kept the selection status of the
> > options inside and just hid them from view.
>
> It's a matter of /dependence/ on a menuconfig option whether options
> inside the menu will be disabled. Not a matter of being located in the
> menu.
Yeah, this is a good solution -- making options inside a menuconfig
also dependent on it makes sense.
> If menuconfig isn't used with strict discipline, we end up with
> inconsistent and misleading presentation of the kernel configuration.
Yes, this really requires discipline on the part of those who add new
config options, to also "depends on" the menuconfig they're inside,
otherwise we end up with inconsistencies. We can't really make this
automatic, or can we?
from a randconfig, attached.
arch/i386/mm/discontig.c:107: error: expected identifier or '(' before
numeric constant
arch/i386/mm/discontig.c: In function 'zone_sizes_init':
arch/i386/mm/discontig.c:363: error: 'ZONE_HIGHMEM' undeclared (first
use in this function)
arch/i386/mm/discontig.c:363: error: (Each undeclared identifier is
reported only once
arch/i386/mm/discontig.c:363: error: for each function it appears in.)
make[1]: *** [arch/i386/mm/discontig.o] Error 1
make: *** [arch/i386/mm] Error 2
On Tue, 15 May 2007, andrew hendry wrote:
>
> from a randconfig, attached.
>
> arch/i386/mm/discontig.c:107: error: expected identifier or '(' before numeric constant
Gaah. That file is horrible. It redeclares a lot of stuff that it has no
business declaring.
Does this patch help?
Linus
---
arch/i386/mm/discontig.c | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/i386/mm/discontig.c b/arch/i386/mm/discontig.c
index aa58720..baac2a4 100644
--- a/arch/i386/mm/discontig.c
+++ b/arch/i386/mm/discontig.c
@@ -31,6 +31,7 @@
#include <linux/module.h>
#include <linux/kexec.h>
#include <linux/pfn.h>
+#include <linux/swap.h>
#include <asm/e820.h>
#include <asm/setup.h>
@@ -97,15 +98,8 @@ unsigned long node_memmap_size_bytes(int nid, unsigned long start_pfn,
#endif
extern unsigned long find_max_low_pfn(void);
-extern void find_max_pfn(void);
extern void add_one_highpage_init(struct page *, int, int);
-extern struct e820map e820;
-extern unsigned long highend_pfn, highstart_pfn;
-extern unsigned long max_low_pfn;
-extern unsigned long totalram_pages;
-extern unsigned long totalhigh_pages;
-
#define LARGE_PAGE_BYTES (PTRS_PER_PTE * PAGE_SIZE)
unsigned long node_remap_start_pfn[MAX_NUMNODES];
@@ -360,7 +354,9 @@ void __init zone_sizes_init(void)
max_zone_pfns[ZONE_DMA] =
virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
+#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;
+#endif
/* If SRAT has not registered memory, register it now */
if (find_max_pfn_with_active_regions() == 0) {
almost, highstart_pfn is used in a few printks
arch/i386/mm/discontig.c: In function 'setup_memory':
arch/i386/mm/discontig.c:314: error: 'highstart_pfn' undeclared (first
use in this function)
arch/i386/mm/discontig.c:314: error: (Each undeclared identifier is
reported only once
arch/i386/mm/discontig.c:314: error: for each function it appears in.)
On 5/15/07, Linus Torvalds <[email protected]> wrote:
>
>
> On Tue, 15 May 2007, andrew hendry wrote:
> >
> > from a randconfig, attached.
> >
> > arch/i386/mm/discontig.c:107: error: expected identifier or '(' before numeric constant
>
> Gaah. That file is horrible. It redeclares a lot of stuff that it has no
> business declaring.
>
> Does this patch help?
>
> Linus
> ---
> arch/i386/mm/discontig.c | 10 +++-------
> 1 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/arch/i386/mm/discontig.c b/arch/i386/mm/discontig.c
> index aa58720..baac2a4 100644
> --- a/arch/i386/mm/discontig.c
> +++ b/arch/i386/mm/discontig.c
> @@ -31,6 +31,7 @@
> #include <linux/module.h>
> #include <linux/kexec.h>
> #include <linux/pfn.h>
> +#include <linux/swap.h>
>
> #include <asm/e820.h>
> #include <asm/setup.h>
> @@ -97,15 +98,8 @@ unsigned long node_memmap_size_bytes(int nid, unsigned long start_pfn,
> #endif
>
> extern unsigned long find_max_low_pfn(void);
> -extern void find_max_pfn(void);
> extern void add_one_highpage_init(struct page *, int, int);
>
> -extern struct e820map e820;
> -extern unsigned long highend_pfn, highstart_pfn;
> -extern unsigned long max_low_pfn;
> -extern unsigned long totalram_pages;
> -extern unsigned long totalhigh_pages;
> -
> #define LARGE_PAGE_BYTES (PTRS_PER_PTE * PAGE_SIZE)
>
> unsigned long node_remap_start_pfn[MAX_NUMNODES];
> @@ -360,7 +354,9 @@ void __init zone_sizes_init(void)
> max_zone_pfns[ZONE_DMA] =
> virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
> max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
> +#ifdef CONFIG_HIGHMEM
> max_zone_pfns[ZONE_HIGHMEM] = highend_pfn;
> +#endif
>
> /* If SRAT has not registered memory, register it now */
> if (find_max_pfn_with_active_regions() == 0) {
>
> >Seriously, it might be a tad more efficient if the help texts were
> >written by those who invented the options in the first place.
>
> menuconfig NETDEV_10000
> bool "Ethernet (10GbE)"
> ---help--
> Say Y here to actually be able to go into this menu
> and select some drivers that we think belong to the
> "10 Gigabit Ethernet" family.
>
> If unsure, it is unwise to say N!
>
> See, this looks so fundamentally basic to me that I find it
> almost funny. YMMV, hence I asked for suggestions from
> other people.
I remember very well the time when I first issued make menuconfig.
Ever since then I've been grateful for all those "fundamentally basic"
explanations. And I've learned quite alot about kernelconfig just
by reading them.
Best,
Michael
--
Technosis GmbH, Gesch?ftsf?hrer: Michael Gerdau, Tobias Dittmar
Sitz Hamburg; HRB 89145 Amtsgericht Hamburg
Vote against SPAM - see http://www.politik-digital.de/spam/
Michael Gerdau email: [email protected]
GPG-keys available on request or at public keyserver
Satyam Sharma wrote:
> I think what happened here is that Jan really only considered the
> "make menuconfig" users with these new constructs (which makes life
> really simple for them), but "oldconfig" users were unfortunately in for
> unpleasant surprises ...
That's one of the things I thought of...
> On 5/15/07, Stefan Richter <[email protected]> wrote:
>> PS: I still believe that Kconfigs shouldn't by overly burdened with
>> presentation.
...when I wrote this.
--
Stefan Richter
-=====-=-=== -=-= -====
http://arcgraph.de/sr/
Satyam Sharma wrote:
> Or perhaps we could change the text associated with these
> "menu-only" dummy constructs instead ...
>
>> we really screw the text-based "make oldconfig" folks who think
>> that they're taking a build-related (and not presentation-related)
>> decision when confronted with a:
>
> So:
>
>> Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
>
> becomes:
>
> [MENU] Ethernet (1000 Mbit) (NETDEV_1000) [Y/n] (NEW)
Make menuconfig and xconfig already have hints that these are menus.
Make oldconfig and gconfig and maybe others lack such hints.
--
Stefan Richter
-=====-=-=== -=-= -====
http://arcgraph.de/sr/
On May 15 2007 08:32, Satyam Sharma wrote:
> On 5/15/07, Stefan Richter <[email protected]> wrote:
>> Tilman Schmidt wrote:
>> > Am 14.05.2007 22:33 schrieb Jan Engelhardt:
>> > > * Disabling this menu disables all the fluff inside it,
>>
>> except when it doesn't.
Blame CONFIG_EMBEDDED!
>> If menuconfig isn't used with strict discipline, we end up with
>> inconsistent and misleading presentation of the kernel configuration.
>
> Yes, this really requires discipline on the part of those who add new
> config options, to also "depends on" the menuconfig they're inside,
> otherwise we end up with inconsistencies. We can't really make this
> automatic, or can we?
Well more or less yes. Instead of adding 'depends on' on every subconfig
object, just wrap the whole thing into an if block:
menuconfig FOOBAR
if FOOBAR
config FOO
config BAR
endif # FOOBAR
Since this is still edgy, an implicit if-endif block could be added as
part of the menuconfig. Sort of like the old menu:
menuconfig FOOBAR
config FOO
config BAR
endmenu
Robert P.J. Day had some solid ideas about this.
Jan
--
On May 15 2007 08:04, Satyam Sharma wrote:
> On 5/15/07, Jan Engelhardt <[email protected]> wrote:
>> that can be switched on or off.
>> It is for those people that start with an arbitrary .config and
>> work their way through menuconfig to disable all the parts they
>> do not want. So, point no. 1:
>>
>> * Disabling this menu disables all the fluff inside it,
>> without needing to enter the menu and disable each
>> option one by one (as was the case previously)
>
> This kind of promise was really nice, and why I liked Jan's
> menuconfig patches a lot.
>
> But if:
>
> On 5/15/07, Tilman Schmidt <[email protected]> wrote:
>> Another essential piece of information. I seem to remember other
>> menus which, when disabled, kept the selection status of the
>> options inside and just hid them from view.
>
> is true, then are we really gaining much from these configmenu's?
If you transform a menu with hidden options (which do NOT "depend on"
the menu - they can't even) into a menuconfig (continuing not to
depend on the menuconfig), the presentation fucks up (especially in
ncurses-menuconfig). That is a good hint something should be taken
more seriously.
So, for menus with hidden options I had a number of options how to
go about them:
- move the hidden options before the menuconfig or after, so
the presentation does not bork;
- leave the menu as-is because there's just so many hidden
options and a menuconfig entry is detrimental
> [unrelated]
> I wish these new constructs were called "configmenu" and
> _not_ "menuconfig". It causes confusion with the "menuconfig"
> master Makefile rule which has nothing to do with these new
> "configmenu"s.
> [/unrelated]
Indeed.
>> Then of course, one can also turn these menuconfig on (apparently!)
>> to be able to descend into them and select some drivers they like.
>> Point no. 2:
>>
>> * Since Jens Axboe's stance ["default y idiocy"] is to have
>> these menus disabled by default, people should most likely
>> enable them first before they will be able to enter them.
>
> I do agree that anything non-essential (even if it's just a presentation
> menu that doesn't affect builds) must be default n.
>
>> (I would have wanted them to be always 'y' - it does not affect
>> the build, just opens all menus by default)
>
> IMHO, the real problem with "default y" menuconfig's, is that they
> cause unpleasant surprises to those folks that use the text-based
> "make oldconfig". They get confronted with choices that they never
> bothered about (or even knew existed) previously, and have no
> idea how to answer them -- same problem faced by Tilman, when
> he used oldconfig.
>
> I think what happened here is that Jan really only considered the
> "make menuconfig" users with these new constructs (which makes life
> really simple for them), but "oldconfig" users were unfortunately in for
> unpleasant surprises ...
I can't tell, since I'd just say yes if it asks "Ethernet (10 GbE)?" -
either I have such an adapter or I don't.
So what do we need?
* 'configmenu' option (with 'endconfigmenu') that works the same as
'menu' and 'endmenu' (so we can have hidden options), but at the
same time make the ---> and options inside it disappear when it is
not selected. Currently, no other type seems to satisfy this.
Jan
--
Jan Engelhardt <[email protected]> wrote:
> Are you going to fix it?
You should've got a copy of the patch.
David
On May 15 2007 10:26, David Howells wrote:
>Jan Engelhardt <[email protected]> wrote:
>
>> Are you going to fix it?
>
>You should've got a copy of the patch.
Yes, right. So much for asynchronous mail transferral :)
Jan
--
Hi,
Satyam Sharma schrieb:
>> * Since Jens Axboe's stance ["default y idiocy"] is to have
>> these menus disabled by default, people should most likely
>> enable them first before they will be able to enter them.
>
> I do agree that anything non-essential (even if it's just a presentation
> menu that doesn't affect builds) must be default n.
It's tricky for "make oldconfig" when introducing a new "menuconfig"
around some previously existing "config"s, because just accepting
the default for the new option then causes previously selected
ones to be silently dropped. But I don't know a perfect solution
for that. Perhaps we'll just have to live with it. Or perhaps a
warning message along the line of "deselecting option xxx" would
be in order.
> IMHO, the real problem with "default y" menuconfig's, is that they
> cause unpleasant surprises to those folks that use the text-based
> "make oldconfig". They get confronted with choices that they never
> bothered about (or even knew existed) previously, and have no
> idea how to answer them -- same problem faced by Tilman, when
> he used oldconfig.
It's actually the other way around, all those options now tucked
underneath the menuconfig were previously directly visible, so
selecting "y" (either explicitly or by default) makes everything
work as before while "n" very conveniently skips them all.
It's really quite nice if you know how it works. The only thing
that's missing is instructions for those seeing it for the first
time.
> IMHO, those using "oldconfig" are often looking towards doing
> things quickly ... doesn't help them if they have default y menu's
> that they need to "?" upon then to see what they're really about.
Well, yes and no. I am of course trying to get through the new
options as quickly as possible. But if I hit an option I don't
understand then typing "?" is the quickest way to sort it out,
so it's doubly annoying if that yields nothing.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
On Tue, 15 May 2007, andrew hendry wrote:
>
> almost, highstart_pfn is used in a few printks
>
> arch/i386/mm/discontig.c: In function 'setup_memory':
> arch/i386/mm/discontig.c:314: error: 'highstart_pfn' undeclared (first
> use in this function)
> arch/i386/mm/discontig.c:314: error: (Each undeclared identifier is
> reported only once
> arch/i386/mm/discontig.c:314: error: for each function it appears in.)
Gaah. highstart_pfn is declared in <asm/highmem.h>, but that one is
protected by a
#ifdef CONFIG_HIGHMEM
#include <asm/highmem.h>
in <linux/highmem.h>, so even though we include highmem.h, we never see
the declaration.
Your config is insane, but anyway, does it compile if you just add back
the extra "unnecessary" declaration of highstart_pfn?
Linus
Yes, putting the extern highstart_pfn back compiles clean for that rand config.
Sorry for the attachment, no access to a patch friendly mailer at work.
Andrew.
On 5/16/07, Linus Torvalds <[email protected]> wrote:
>
>
> On Tue, 15 May 2007, andrew hendry wrote:
> >
> > almost, highstart_pfn is used in a few printks
> >
> > arch/i386/mm/discontig.c: In function 'setup_memory':
> > arch/i386/mm/discontig.c:314: error: 'highstart_pfn' undeclared (first
> > use in this function)
> > arch/i386/mm/discontig.c:314: error: (Each undeclared identifier is
> > reported only once
> > arch/i386/mm/discontig.c:314: error: for each function it appears in.)
>
> Gaah. highstart_pfn is declared in <asm/highmem.h>, but that one is
> protected by a
>
> #ifdef CONFIG_HIGHMEM
> #include <asm/highmem.h>
>
> in <linux/highmem.h>, so even though we include highmem.h, we never see
> the declaration.
>
> Your config is insane, but anyway, does it compile if you just add back
> the extra "unnecessary" declaration of highstart_pfn?
>
> Linus
>
On 5/15/07, Tilman Schmidt <[email protected]> wrote:
> [...]
> > I do agree that anything non-essential (even if it's just a presentation
> > menu that doesn't affect builds) must be default n.
>
> It's tricky for "make oldconfig" when introducing a new "menuconfig"
> around some previously existing "config"s, because just accepting
> the default for the new option then causes previously selected
> ones to be silently dropped. But I don't know a perfect solution
> for that. Perhaps we'll just have to live with it. Or perhaps a
> warning message along the line of "deselecting option xxx" would
> be in order.
> [...]
> It's actually the other way around, all those options now tucked
> underneath the menuconfig were previously directly visible, so
> selecting "y" (either explicitly or by default) makes everything
> work as before while "n" very conveniently skips them all.
Jan did mention this in the previous thread, but as Jens said,
these problems would occur only the _first_ time someone
transitions from the old .config's to the new scheme. But those
"default y"s for all the various "configmenu"s (let's please call
them that) that got introduced in the Kconfig files would cause
unnecessary annoyance to users of make oldconfig _for ever_.
On 5/15/07, Jan Engelhardt <[email protected]> wrote:
> [...]
> If you transform a menu with hidden options (which do NOT "depend on"
> the menu - they can't even) into a menuconfig (continuing not to
> depend on the menuconfig), the presentation fucks up (especially in
> ncurses-menuconfig). That is a good hint something should be taken
> more seriously.
Sorry, I didn't follow this "hidden options" thing at all ...
> So, for menus with hidden options I had a number of options how to
> go about them:
>
> - move the hidden options before the menuconfig or after, so
> the presentation does not bork;
>
> - leave the menu as-is because there's just so many hidden
> options and a menuconfig entry is detrimental
... but the second method seems sane and safe, still :-)
> So what do we need?
>
> * 'configmenu' option (with 'endconfigmenu') that works the same as
> 'menu' and 'endmenu' (so we can have hidden options), but at the
> same time make the ---> and options inside it disappear when it is
> not selected. Currently, no other type seems to satisfy this.
(Yes, and with that implicit if-endif block to make "depends on" the
configmenu for those config options that are inside it automatic)
* Also, some "[MENU]" kind of prefix/tag in the text of configmenu
options would also be nice.
Satyam
Satyam Sharma wrote:
> * Also, some "[MENU]" kind of prefix/tag in the text of configmenu
> options would also be nice.
This belongs into the UIs, not into Kconfigs.
And it'd not just be nice, it's a requirement.
--
Stefan Richter
-=====-=-=== -=-= =----
http://arcgraph.de/sr/
Am 16.05.2007 03:39 schrieb Satyam Sharma:
["default n" for menuconfig]
> these problems would occur only the _first_ time someone
> transitions from the old .config's to the new scheme. But those
> "default y"s for all the various "configmenu"s (let's please call
> them that) that got introduced in the Kconfig files would cause
> unnecessary annoyance to users of make oldconfig _for ever_.
I'm not sure I'm following you. Where would that annoyance occur?
On subsequent uses of "make oldconfig" the default shouldn't even
matter, as the previous choice would just silently be kept.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
On 5/16/07, Tilman Schmidt <[email protected]> wrote:
> Am 16.05.2007 03:39 schrieb Satyam Sharma:
> ["default n" for menuconfig]
> > these problems would occur only the _first_ time someone
> > transitions from the old .config's to the new scheme. But those
> > "default y"s for all the various "configmenu"s (let's please call
> > them that) that got introduced in the Kconfig files would cause
> > unnecessary annoyance to users of make oldconfig _for ever_.
>
> I'm not sure I'm following you. Where would that annoyance occur?
> On subsequent uses of "make oldconfig" the default shouldn't even
> matter, as the previous choice would just silently be kept.
Aargh, you're right. The prompt'll come only if it's a "(NEW)"
configmenu addition and hence not come after the first time either.
On 5/16/07, Stefan Richter <[email protected]> wrote:
> Satyam Sharma wrote:
> > * Also, some "[MENU]" kind of prefix/tag in the text of configmenu
> > options would also be nice.
>
> This belongs into the UIs, not into Kconfigs.
> And it'd not just be nice, it's a requirement.
Indeed. "make menuconfig" interprets them specially (suffixes "--->")
and so does "xconfig". Just that the non-curses/graphics-based
scripts/kconfig/conf.c also needs to be taught to treat them specially
and tag something to them. Gaah. What was I smoking ...
Hi!
> > Hardware Monitoring support --->
> > <*> Hardware Monitoring support
> > <*> Abit uGuru
> > <M> VIA686A
> > <*> IBM Hard Drive Active Protection System (hdaps)
> >
> > But I'm quite sure that the only module used is VIA686A (I'm
> > rebuilding to confirm).
>
> This is a rather bad idea to build the abituguru and hdaps drivers into
> your kernel if you don't have these devices. Especially abituguru, as
> it does arbitrary port probing.
hdaps should be safe (DMI based whitelist, no?)
If abitguru breaks random machines, we probably should DMI whitelist,
too.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 15 May 2007 20:31:00 +0000, Pavel Machek wrote:
> Hi!
>
> > > Hardware Monitoring support --->
> > > <*> Hardware Monitoring support
> > > <*> Abit uGuru
> > > <M> VIA686A
> > > <*> IBM Hard Drive Active Protection System (hdaps)
> > >
> > > But I'm quite sure that the only module used is VIA686A (I'm
> > > rebuilding to confirm).
> >
> > This is a rather bad idea to build the abituguru and hdaps drivers into
> > your kernel if you don't have these devices. Especially abituguru, as
> > it does arbitrary port probing.
>
> hdaps should be safe (DMI based whitelist, no?)
Correct.
> If abitguru breaks random machines, we probably should DMI whitelist,
> too.
I never said it was breaking machines, just that it was accessing
arbitrary I/O ports.
This was already discussed with the driver's author (Hans de Goede,
Cc'd) and I think we agreed on the principle, but it didn't happen yet.
This device only exists on Abit motherboards so it would be easy enough
to check the DMI vendor. A more detailed white list is also possible,
but I'm not insisting on it.
The driver could also be made to depend on X86, as this is the only
architecture where it is useful.
Hans, can you please submit a patch doing this?
Thanks,
--
Jean Delvare
On Sunday 13 May 2007 05:20, Jan Engelhardt wrote:
> On May 12 2007 20:20, Linus Torvalds wrote:
> >
> >Ok, the merge window has closed, and 2.6.22-rc1 is out there.
>
> I have hit a randconfig compile failure. .config attached.
>
> LD .tmp_vmlinux1
> drivers/built-in.o: In function `acpi_bus_generate_event':
> (.text+0x233f7): undefined reference to `event_is_open'
> drivers/built-in.o: In function `acpi_bus_get_power':
> (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state'
> drivers/built-in.o: In function `acpi_bus_set_power':
> (.text+0x237c3): undefined reference to `acpi_power_transition'
> drivers/built-in.o: In function `acpi_bus_set_power':
> (.text+0x23835): undefined reference to `acpi_power_transition'
> drivers/built-in.o: In function `sony_pic_fanspeed_store':
> sony-laptop.c:(.text+0x91930): undefined reference to `ec_write'
> drivers/built-in.o: In function `sony_pic_fanspeed_show':
> sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read'
> make: *** [.tmp_vmlinux1] Error 1
CONFIG_PM=n
CONFIG_ACPI=y
not possible.
"select" in Kconfig is broken.
http://lkml.org/lkml/2007/4/28/28
-Len
Jean Delvare wrote:
> On Tue, 15 May 2007 20:31:00 +0000, Pavel Machek wrote:
>> Hi!
>>
>>>> Hardware Monitoring support --->
>>>> <*> Hardware Monitoring support
>>>> <*> Abit uGuru
>>>> <M> VIA686A
>>>> <*> IBM Hard Drive Active Protection System (hdaps)
>>>>
>>>> But I'm quite sure that the only module used is VIA686A (I'm
>>>> rebuilding to confirm).
>>> This is a rather bad idea to build the abituguru and hdaps drivers into
>>> your kernel if you don't have these devices. Especially abituguru, as
>>> it does arbitrary port probing.
>> hdaps should be safe (DMI based whitelist, no?)
>
> Correct.
>
>> If abitguru breaks random machines, we probably should DMI whitelist,
>> too.
>
> I never said it was breaking machines, just that it was accessing
> arbitrary I/O ports.
>
> This was already discussed with the driver's author (Hans de Goede,
> Cc'd) and I think we agreed on the principle, but it didn't happen yet.
> This device only exists on Abit motherboards so it would be easy enough
> to check the DMI vendor. A more detailed white list is also possible,
> but I'm not insisting on it.
>
> The driver could also be made to depend on X86, as this is the only
> architecture where it is useful.
>
> Hans, can you please submit a patch doing this?
>
As you can see from the CC I've send you, I've just mailed my private army of
testers / known uguru users, requesting them to send me the output of dmidecode
on their uguru mobo's. Once I have this info, I'll see if there is some
consistency in the manufacturer DMI field.
I've mailed them, since the DMI info is needed anyways to put uguru detection
in sensors-detect, but I'm not sure I want to add this to the driver too. Many
other ISA drivers do io probe's too, if a users decides to start loading random
drivers, he is asking for problems, should we really even try to protect
against this?
Regards,
Hans
Hi!
> >>If abitguru breaks random machines, we probably should
> >>DMI whitelist,
> >>too.
> >
> >I never said it was breaking machines, just that it was
> >accessing
> >arbitrary I/O ports.
> >
> >This was already discussed with the driver's author
> >(Hans de Goede,
> >Cc'd) and I think we agreed on the principle, but it
> >didn't happen yet.
> >This device only exists on Abit motherboards so it
> >would be easy enough
> >to check the DMI vendor. A more detailed white list is
> >also possible,
> >but I'm not insisting on it.
> >
> >The driver could also be made to depend on X86, as this
> >is the only
> >architecture where it is useful.
> >
> >Hans, can you please submit a patch doing this?
> >
>
> As you can see from the CC I've send you, I've just
> mailed my private army of testers / known uguru users,
> requesting them to send me the output of dmidecode on
> their uguru mobo's. Once I have this info, I'll see if
> there is some consistency in the manufacturer DMI field.
>
> I've mailed them, since the DMI info is needed anyways
> to put uguru detection in sensors-detect, but I'm not
> sure I want to add this to the driver too. Many other
> ISA drivers do io probe's too, if a users decides to
> start loading random drivers, he is asking for problems,
> should we really even try to protect against this?
Yes. config-all-yes kernel should boot. And it should be ok to share
kernel between different machines.
ISA drivers should be disappearing these days, if something does
dangerous port-probe, we want to fix it somehow.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html