[tip: irq/core] softirq: s/BUG/WARN_ONCE/ on tasklet SCHED state not set
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 6b2c339df90788ce6aeecee78d6494f262929206
Gitweb:
https://git.kernel.org/tip/6b2c339df90788ce6aeecee78d6494f262929206
Author:Dirk Behme
AuthorDate:Wed, 17 Mar 2021 11:20:12 +01:00
Committer: Ingo Molnar
CommitterDate: Wed, 17 Mar 2021 12:59:35 +01:00
softirq: s/BUG/WARN_ONCE/ on tasklet SCHED state not set
Replace BUG() with WARN_ONCE() on wrong tasklet state, in order to:
- increase the verbosity / aid in debugging
- avoid fatal/unrecoverable state
Suggested-by: Thomas Gleixner
Signed-off-by: Dirk Behme
Signed-off-by: Eugeniu Rosca
Signed-off-by: Ingo Molnar
Link: https://lore.kernel.org/r/20210317102012.32399-1-ero...@de.adit-jv.com
---
kernel/softirq.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 8b44ab9..8d56bbf 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -531,6 +531,18 @@ void __tasklet_hi_schedule(struct tasklet_struct *t)
}
EXPORT_SYMBOL(__tasklet_hi_schedule);
+static bool tasklet_should_run(struct tasklet_struct *t)
+{
+ if (test_and_clear_bit(TASKLET_STATE_SCHED, >state))
+ return true;
+
+ WARN_ONCE(1, "tasklet SCHED state not set: %s %pS\n",
+ t->use_callback ? "callback" : "func",
+ t->use_callback ? (void *)t->callback : (void *)t->func);
+
+ return false;
+}
+
static void tasklet_action_common(struct softirq_action *a,
struct tasklet_head *tl_head,
unsigned int softirq_nr)
@@ -550,13 +562,12 @@ static void tasklet_action_common(struct softirq_action
*a,
if (tasklet_trylock(t)) {
if (!atomic_read(>count)) {
- if (!test_and_clear_bit(TASKLET_STATE_SCHED,
- >state))
- BUG();
- if (t->use_callback)
- t->callback(t);
- else
- t->func(t->data);
+ if (tasklet_should_run(t)) {
+ if (t->use_callback)
+ t->callback(t);
+ else
+ t->func(t->data);
+ }
tasklet_unlock(t);
continue;
}
[PATCH 0/1] tpm_tis: handle -EPROBE_DEFER in tpm_tis_plat_probe()
Hello, I noticed that the tpm_tis driver behaves different depending on wether it was compiled builtin or as a module. At least on my hardware, if builtin it always falls back to polling mode without notification which I do not understand considering the current efforts to fix interrupt probing[1]. The builtin case could be fixed by handling -EPROBE_DEFER. With a temporary dev_dbg() call added and James Bottomley's "[PATCH v2 4/5] tpm_tis: fix IRQ probing [1]" applied my kernel log looks like this: [2.671629] tpm_tis STM0125:00: Waiting for interrupt... [2.851920] tpm_tis STM0125:00: Waiting for interrupt... [2.852627] tpm_tis STM0125:00: Waiting for interrupt... [2.908286] tpm_tis STM0125:00: Waiting for interrupt... [3.340223] tpm_tis STM0125:00: Waiting for interrupt... [3.407238] tpm_tis STM0125:00: Waiting for interrupt... [3.408178] tpm_tis STM0125:00: Waiting for interrupt... [3.408994] tpm_tis STM0125:00: Waiting for interrupt... [3.487694] tpm_tis STM0125:00: Waiting for interrupt... [3.773769] tpm_tis STM0125:00: Waiting for interrupt... [3.868590] tpm_tis STM0125:00: Waiting for interrupt... [3.923855] tpm_tis STM0125:00: Waiting for interrupt... [4.235670] tpm_tis STM0125:00: Waiting for interrupt... [4.852556] tpm_tis STM0125:00: Waiting for interrupt... [6.767544] tpm_tis STM0125:00: 2.0 TPM (device-id 0x0, rev-id 78) [6.767567] tpm_tis STM0125:00: TPM interface capabilities (0x3415): [6.767569] tpm_tis STM0125:00: Interrupt Level Low [6.767570] tpm_tis STM0125:00: Locality Change Int Support [6.767570] tpm_tis STM0125:00: Data Avail Int Support Of course, this patch should not be added before Jarkko's fix [2], because builtin drivers would then hit the WARN_ONCE(), as well. Dirk [1] https://lore.kernel.org/linux-integrity/20201001180925.13808-5-james.bottom...@hansenpartnership.com/ [2] https://lore.kernel.org/linux-integrity/3936843b-c0da-dd8c-8aa9-90aa3b49d...@linux.ibm.com/T/#t Dirk Gouders (1): tpm_tis: handle -EPROBE_DEFER in tpm_tis_plat_probe() drivers/char/tpm/tpm_tis.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.26.2
[PATCH 1/1] tpm_tis: handle -EPROBE_DEFER in tpm_tis_plat_probe()
tpm_tis does not consider -EPROBE_DEFER in tpm_tis_plat_probe().
Instead, without notification it falls back to polling mode if
platform_get_irq_optional() returns a negative value.
This could lead to different behavior depending on wether tpm_tis was
compiled builtin or as a module; in the latter case
platform_get_irq_optional() often if not always returns a valid IRQ
number on the first attempt.
Harmonize builtin and module behavior by returning -EPROBE_DEFER,
effectively putting the device on the deferred probe list for later
probe attempts.
Signed-off-by: Dirk Gouders
---
drivers/char/tpm/tpm_tis.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 4ed6e660273a..4cf863704aa1 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -320,6 +320,9 @@ static int tpm_tis_plat_probe(struct platform_device *pdev)
tpm_info.irq = platform_get_irq_optional(pdev, 0);
if (tpm_info.irq <= 0) {
+if (tpm_info.irq == -EPROBE_DEFER)
+/* Enter deferred probe list and try again, later. */
+return -EPROBE_DEFER;
if (pdev != force_pdev)
tpm_info.irq = -1;
else
--
2.26.2
Re: [PATCH v3] tpm_tis: Add missing tpm_request/relinquish_locality calls
Dirk Gouders writes: > Lukasz Majczak writes: > >> There are missing calls to tpm_request_locality before the calls to >> the tpm_get_timeouts() and tpm_tis_probe_irq_single() - both functions >> internally send commands to the tpm. As the current >> approach might work for tpm2, it fails for tpm1.x - in that case >> call to tpm_get_timeouts() or tpm_tis_probe_irq_single() >> without acquired locality fails and in turn causes tpm_tis_core_init() >> to fail, it can be observed in the log with the following warning >> trace: >> >> [4.324298] TPM returned invalid status >> [4.324806] WARNING: CPU: 2 PID: 1 at drivers/char/tpm/tpm_tis_core.c:275 >> tpm_tis_status+0x86/0x8f >> [4.325888] Modules linked in: >> [4.326287] CPU: 2 PID: 1 Comm: swapper/0 Tainted: GW >> 5.11.0-rc6-next-20210201-3-g214461adb2e8 #43 >> [4.327406] Hardware name: Google Caroline/Caroline, BIOS >> Google_Caroline.7820.430.0 07/20/2018 >> [4.327918] RIP: 0010:tpm_tis_status+0x86/0x8f >> [4.328323] Code: 28 00 00 00 48 3b 45 f0 75 24 89 d8 48 83 c4 10 5b 5d >> c3 c6 05 58 d9 28 01 01 31 db 48 c7 c7 73 52 98 9c 31 c0 e8 c2 17 b0 ff <0f> >> 0b eb cd e8 cf 4f 55 00 0f 1f 44 00 00 55 48 89 e56 >> [4.330592] RSP: :88810092f7a0 EFLAGS: 00010246 >> [4.331223] RAX: 691ee151166db100 RBX: RCX: >> 0001 >> [4.331860] RDX: 0006 RSI: 9c96d302 RDI: >> >> [4.332272] RBP: 88810092f7b8 R08: dc00 R09: >> fbfff39c96ce >> [4.332683] R10: fbfff39c96ce R11: 0001 R12: >> 8881053e2000 >> [4.333109] R13: 6500 R14: 888105d71000 R15: >> 888105cd2628 >> [4.333738] FS: () GS:88842f20() >> knlGS: >> [4.334432] CS: 0010 DS: ES: CR0: 80050033 >> [4.334783] CR2: CR3: 37828001 CR4: >> 003706e0 >> [4.335196] DR0: DR1: DR2: >> >> [4.335886] DR3: DR6: fffe0ff0 DR7: >> 0400 >> [4.336793] Call Trace: >> [4.337107] tpm_tis_send_data+0x3d/0x22f >> [4.337506] tpm_tis_send_main+0x30/0xf5 >> [4.337746] tpm_transmit+0xbf/0x327 >> [4.338042] ? __alloc_pages_nodemask+0x261/0x36d >> [4.338615] tpm_transmit_cmd+0x2c/0x93 >> [4.339109] tpm1_getcap+0x232/0x285 >> [4.339578] tpm1_get_timeouts+0x48/0x47d >> [4.339964] ? lockdep_init_map_type+0x71/0x257 >> [4.340256] ? lockdep_init_map_type+0x71/0x257 >> [4.340719] ? __raw_spin_lock_init+0x40/0x69 >> [4.341208] tpm_tis_core_init+0x402/0x5ee >> [4.341629] tpm_tis_init+0x11d/0x1a2 >> [4.341867] tpm_tis_pnp_init+0x91/0xb5 >> [4.342101] ? tis_int_handler+0x15f/0x15f >> [4.342466] pnp_device_probe+0x79/0x9f >> [4.342941] really_probe+0x149/0x4a8 >> [4.343412] driver_probe_device+0xd6/0x144 >> [4.343968] device_driver_attach+0x42/0x5b >> [4.344382] __driver_attach+0xca/0x139 >> [4.344617] ? driver_attach+0x1f/0x1f >> [4.344860] bus_for_each_dev+0x85/0xb7 >> [4.345096] bus_add_driver+0x12b/0x228 >> [4.345330] driver_register+0x64/0xed >> [4.345560] init_tis+0xa5/0xeb >> [4.345784] ? lock_is_held_type+0x100/0x141 >> [4.346044] ? tpm_init+0x106/0x106 >> [4.346259] ? rcu_read_lock_sched_held+0x41/0x7e >> [4.346542] ? tpm_init+0x106/0x106 >> [4.346678] battery: ACPI: Battery Slot [BAT0] (battery present) >> [4.346754] do_one_initcall+0x1b9/0x43d >> [4.346776] ? asm_sysvec_apic_timer_interrupt+0x12/0x20 >> [4.347659] ? lockdep_hardirqs_on+0x8e/0x12e >> [4.347937] ? lock_is_held_type+0x100/0x141 >> [4.348196] ? rcu_read_lock_sched_held+0x41/0x7e >> [4.348477] do_initcall_level+0x99/0xa9 >> [4.348717] ? kernel_init+0xe/0x10a >> [4.348954] do_initcalls+0x4e/0x79 >> [4.349170] kernel_init_freeable+0x15a/0x1ae >> [4.349434] ? rest_init+0x1d6/0x1d6 >> [4.349655] kernel_init+0xe/0x10a >> [4.349882] ret_from_fork+0x22/0x30 >> [4.350103] irq event stamp: 700039 >> [4.350318] hardirqs last enabled at (700047): [] >> console_unlock+0x4be/0x538 >> [4.350836] hardirqs last disabled at (700056): [] >> console_unlock+0xdd/0x538 >> [4.351331] softirqs last enabled at (699522):
Re: [PATCH v3] tpm_tis: Add missing tpm_request/relinquish_locality calls
* acquired. Usually because tpm_try_get_ops() hasn't
>* been called before doing a TPM operation.
>*/
> In this case we don't have to call tpm_try_get_ops()
> as both calls (tpm_get_timeouts() and tpm_tis_probe_irq_single()) are
> in the tpm_tis_core_init function and don't require any locking or clock
> enablement. Similar usage is in the probe_itpm() function also called
> inside tpm_tis_core_init().
> Tested on Samsung Chromebook Pro (Caroline).
>
> Signed-off-by: Lukasz Majczak
> ---
> Hi Jarkko
>
> I have checked the linux-next with James patches, also followed Dirk
> suggestion applying remaining ones, although without any luck -
> a warning trace was still present. As Guneter mentioned earlier, this
> patch[1] doesn't address a lack of acquired locality in the
> tpm_get_timeouts() and does it only for tpm_tis_probe_irq_single() but
> also without a call to tpm_relinquish_locality().
>
> Here are my logs from the clean linux-next master branch [2]
> (with two James' patches present) and with my
> patch applied[3]
>
> Best regards,
> Lukasz
>
> [1]
> https://lore.kernel.org/linux-integrity/20201001180925.13808-5-james.bottom...@hansenpartnership.com/
> [2]
> https://gist.github.com/semihalf-majczak-lukasz/f588c0684a6cc7d983bb9c4eb4bda586
> [3]
> https://gist.github.com/semihalf-majczak-lukasz/88ede933bc7d28d806e3532850a04054
>
> v2 -> v3:
> - Added braces around if part of if/else statements
> - Rebased to linux-next
> - Updated commit message
>
> drivers/char/tpm/tpm-chip.c | 4 ++--
> drivers/char/tpm/tpm-interface.c | 13 ++---
> drivers/char/tpm/tpm.h | 2 ++
> drivers/char/tpm/tpm_tis_core.c | 14 +++---
> 4 files changed, 25 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index ddaeceb7e109..5351963a4b19 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -32,7 +32,7 @@ struct class *tpm_class;
> struct class *tpmrm_class;
> dev_t tpm_devt;
>
> -static int tpm_request_locality(struct tpm_chip *chip)
> +int tpm_request_locality(struct tpm_chip *chip)
> {
> int rc;
> @@ -47,7 +47,7 @@ static int tpm_request_locality(struct tpm_chip *chip)
> return 0;
> }
>
> -static void tpm_relinquish_locality(struct tpm_chip *chip)
> +void tpm_relinquish_locality(struct tpm_chip *chip)
> {
> int rc;
>
Here, it seems
+EXPORT_SYMBOL_GPL(tpm_request_locality);
and
+EXPORT_SYMBOL_GPL(tpm_relinquish_locality);
are needed. Otherwise building tpm* modules fails:
ERROR: modpost: "tpm_request_locality" [drivers/char/tpm/tpm_tis_core.ko]
undefined!
ERROR: modpost: "tpm_relinquish_locality" [drivers/char/tpm/tpm_tis_core.ko]
undefined!
make[1]: *** [scripts/Makefile.modpost:132: Module.symvers] Error 1
make[1]: *** Deleting file 'Module.symvers'
make: *** [Makefile:1405: modules] Error 2
Otherwise, testing this patch results in no more warning
TPM returned invalid status: 0xff
and also no more warnings:
tpm tpm0: tpm_try_transmit: send(): error -5
tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead
Dirk
> diff --git a/drivers/char/tpm/tpm-interface.c
> b/drivers/char/tpm/tpm-interface.c
> index 1621ce818705..2a9001d329f2 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -241,10 +241,17 @@ int tpm_get_timeouts(struct tpm_chip *chip)
> if (chip->flags & TPM_CHIP_FLAG_HAVE_TIMEOUTS)
> return 0;
>
> - if (chip->flags & TPM_CHIP_FLAG_TPM2)
> + if (chip->flags & TPM_CHIP_FLAG_TPM2) {
> return tpm2_get_timeouts(chip);
> - else
> - return tpm1_get_timeouts(chip);
> + } else {
> + ssize_t ret = tpm_request_locality(chip);
> +
> + if (ret)
> + return ret;
> + ret = tpm1_get_timeouts(chip);
> + tpm_relinquish_locality(chip);
> + return ret;
> + }
> }
> EXPORT_SYMBOL_GPL(tpm_get_timeouts);
>
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 947d1db0a5cc..8c13008437dd 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -193,6 +193,8 @@ static inline void tpm_msleep(unsigned int delay_msec)
>
> int tpm_chip_start(struct tpm_chip *chip);
> void tpm_chip_stop(struct tpm_chip *chip);
> +int tpm_request_locality(struct tpm_chip *chip);
> +void tpm_relinquish_locality(struct tpm_chip *chip);
> struct tpm_chip *tpm_find_get_ops(struct tpm_chip *chip);
> __must_check int tpm_try_get_ops(struct tpm_chip *chip);
> void tpm_put_
Re: [PATCH V2] rtc: mc146818: Dont test for bit 0-5 in Register D
Thomas Gleixner writes:
> The recent change to validate the RTC turned out to be overly tight.
>
> While it cures the problem on the reporters machine it breaks machines
> with Intel chipsets which use bit 0-5 of the D register. So check only
> for bit 6 being 0 which is the case on these Intel machines as well.
>
> Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
> Reported-by: Serge Belyshev
> Reported-by: Dirk Gouders
> Signed-off-by: Thomas Gleixner
> ---
> V2: Provide the actual delta patch. Should have stayed away from
> computers today
I tested V2 and it eliminates the warning, here.
Thank you,
Dirk
> ---
> drivers/rtc/rtc-cmos.c |4 ++--
> drivers/rtc/rtc-mc146818-lib.c |4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -805,8 +805,8 @@ cmos_do_probe(struct device *dev, struct
>
> spin_lock_irq(_lock);
>
> - /* Ensure that the RTC is accessible. Bit 0-6 must be 0! */
> - if ((CMOS_READ(RTC_VALID) & 0x7f) != 0) {
> + /* Ensure that the RTC is accessible. Bit 6 must be 0! */
> + if ((CMOS_READ(RTC_VALID) & 0x40) != 0) {
> spin_unlock_irq(_lock);
> dev_warn(dev, "not accessible\n");
> retval = -ENXIO;
> --- a/drivers/rtc/rtc-mc146818-lib.c
> +++ b/drivers/rtc/rtc-mc146818-lib.c
> @@ -21,8 +21,8 @@ unsigned int mc146818_get_time(struct rt
>
> again:
> spin_lock_irqsave(_lock, flags);
> - /* Ensure that the RTC is accessible. Bit 0-6 must be 0! */
> - if (WARN_ON_ONCE((CMOS_READ(RTC_VALID) & 0x7f) != 0)) {
> + /* Ensure that the RTC is accessible. Bit 6 must be 0! */
> + if (WARN_ON_ONCE((CMOS_READ(RTC_VALID) & 0x40) != 0)) {
> spin_unlock_irqrestore(_lock, flags);
> memset(time, 0xff, sizeof(*time));
> return 0;
Re: [PATCH V2] rtc: mc146818: Detect and handle broken RTCs
Thomas Gleixner writes:
> The recent fix for handling the UIP bit unearthed another issue in the RTC
> code. If the RTC is advertised but the readout is straight 0xFF because
> it's not available, the old code just proceeded with crappy values, but the
> new code hangs because it waits for the UIP bit to become low.
>
> Add a sanity check in the RTC CMOS probe function which reads the RTC_VALID
> register (Register D) which should have bit 0-6 cleared. If that's not the
> case then fail to register the CMOS.
>
> Add the same check to mc146818_get_time(), warn once when the condition
> is true and invalidate the rtc_time data.
In case it is helpful: on my hardware this patch triggers a warning
(attached below).
Without it the rtc messages look like this:
[2.783386] rtc_cmos 00:01: RTC can wake from S4
[2.784302] rtc_cmos 00:01: registered as rtc0
[2.785036] rtc_cmos 00:01: setting system clock to 2021-01-31T10:13:40 UTC
(1612088020)
[2.785713] rtc_cmos 00:01: alarms up to one month, y3k, 114 bytes nvram,
hpet irqs
Dirk
[7.258410] [ cut here ]
[7.258414] WARNING: CPU: 2 PID: 0 at drivers/rtc/rtc-mc146818-lib.c:25
mc146818_get_time+0x2b/0x1e5
[7.258420] Modules linked in: iwlmvm(+) mac80211 iwlwifi sdhci_pci
amdgpu(+) drm_ttm_helper cfg80211 ttm cqhci gpu_sched sdhci ccp
thinkpad_acpi(+) rng_core nvram tpm_tis(+) tpm_tis_core wmi tpm pinctrl_amd
[7.258432] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
5.11.0-rc5-next-20210129-x86_64 #180
[7.258434] Hardware name: LENOVO 20U50008GE/20U50008GE, BIOS R19ET26W (1.10
) 06/22/2020
[7.258435] RIP: 0010:mc146818_get_time+0x2b/0x1e5
[7.258437] Code: 56 41 55 45 31 ed 41 54 55 53 48 89 fb 48 c7 c7 bc d9 eb
82 e8 26 d8 36 00 bf 0d 00 00 00 48 89 c5 e8 6d d1 8f ff a8 7f 74 24 <0f> 0b 48
c7 c7 bc d9 eb 82 48 89 ee e8 bc d6 36 00 b0 ff b9 24 00
[7.258438] RSP: 0018:c922cef0 EFLAGS: 00010002
[7.258440] RAX: 0031 RBX: c922cf24 RCX:
[7.258441] RDX: 0001 RSI: 888105607000 RDI: 000d
[7.258441] RBP: 0046 R08: c922cf24 R09:
[7.258442] R10: R11: R12: 888105607000
[7.258443] R13: R14: c922cfa4 R15:
[7.258444] FS: () GS:88840ec8()
knlGS:
[7.258445] CS: 0010 DS: ES: CR0: 80050033
[7.258446] CR2: 7f2ed26c4160 CR3: 0480a000 CR4: 00350ee0
[7.258447] Call Trace:
[7.258449]
[7.258450] hpet_rtc_interrupt+0xd3/0x1a3
[7.258454] __handle_irq_event_percpu+0x6b/0x12e
[7.258457] handle_irq_event_percpu+0x2c/0x6f
[7.258459] handle_irq_event+0x23/0x43
[7.258461] handle_edge_irq+0x9e/0xbb
[7.258463] asm_call_irq_on_stack+0x12/0x20
[7.258467]
[7.258467] common_interrupt+0x9a/0x123
[7.258470] asm_common_interrupt+0x1e/0x40
[7.258472] RIP: 0010:cpuidle_enter_state+0x13e/0x1fe
[7.258475] Code: 49 89 c4 e8 bd fd ff ff 31 ff e8 3e 80 92 ff 45 84 ff 74
12 9c 58 0f ba e0 09 73 03 0f 0b fa 31 ff e8 13 16 96 ff fb 45 85 f6 <0f> 88 97
00 00 00 49 63 d6 4c 2b 24 24 48 6b ca 68 48 6b c2 30 4c
[7.258476] RSP: 0018:c9167eb0 EFLAGS: 0206
[7.258477] RAX: 88840eca8240 RBX: 888101e0d400 RCX: 0001b0a24b16
[7.258478] RDX: 0002 RSI: 0002 RDI:
[7.258478] RBP: 0003 R08: R09:
[7.258479] R10: 88810083c4a8 R11: R12: 0001b0a24b48
[7.258480] R13: 8299cc60 R14: 0003 R15:
[7.258482] cpuidle_enter+0x2b/0x37
[7.258483] do_idle+0x126/0x184
[7.258485] cpu_startup_entry+0x18/0x1a
[7.258486] secondary_startup_64_no_verify+0xb0/0xbb
[7.258489] ---[ end trace 9da59c3696ed99d8 ]---
> Reported-by: Mickaël Salaün
> Signed-off-by: Thomas Gleixner
> Tested-by: Mickaël Salaün
> ---
> V2: Fixed the sizeof() as spotted by Mickaël
> ---
> drivers/rtc/rtc-cmos.c |8
> drivers/rtc/rtc-mc146818-lib.c |7 +++
> 2 files changed, 15 insertions(+)
>
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -805,6 +805,14 @@ cmos_do_probe(struct device *dev, struct
>
> spin_lock_irq(_lock);
>
> + /* Ensure that the RTC is accessible. Bit 0-6 must be 0! */
> + if ((CMOS_READ(RTC_VALID) & 0x7f) != 0) {
> + spin_unlock_irq(_lock);
> + dev_warn(dev, "not accessible\n");
> + retval = -ENXIO;
> + goto cleanup1;
> + }
> +
> if (!(flags & CMOS_RTC_FLAGS_NOFREQ)) {
> /* force periodic irq to CMOS reset defa
Re: [PATCH 1/1] iommu/vt-d: Add qi_submit trace event
Lu Baolu writes:
> This adds a new trace event to track the submissions of requests to the
> invalidation queue. This event will provide the information like:
> - IOMMU name
> - Invalidation type
> - Descriptor raw data
>
> A sample output like:
> | qi_submit: iotlb_inv dmar1: 0x100e2 0x0 0x0 0x0
> | qi_submit: dev_tlb_inv dmar1: 0x13 0x7001 0x0 0x0
> | qi_submit: iotlb_inv dmar2: 0x800f2 0xf9a5 0x0 0x0
>
> This will be helpful for queued invalidation related debugging.
>
> Signed-off-by: Lu Baolu
While compiling current linux-next for some other test I noticed a
compiler error because of this patch:
drivers/iommu/intel/dmar.c: In function ‘qi_submit_sync’:
drivers/iommu/intel/dmar.c:1311:3: error: implicit declaration of function
‘trace_qi_submit’ [-Werror=implicit-function-declaration]
1311 | trace_qi_submit(iommu, desc[i].qw0, desc[i].qw1,
| ^~~
cc1: some warnings being treated as errors
On my machine CONFIG_INTEL_IOMMU is not set so
#include cannot provide the prototype for
that function.
Dirk
> ---
> drivers/iommu/intel/dmar.c | 3 +++
> include/trace/events/intel_iommu.h | 37 ++
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
> index 004feaed3c72..bd51f33642e0 100644
> --- a/drivers/iommu/intel/dmar.c
> +++ b/drivers/iommu/intel/dmar.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include "../irq_remapping.h"
>
> @@ -1307,6 +1308,8 @@ int qi_submit_sync(struct intel_iommu *iommu, struct
> qi_desc *desc,
> offset = ((index + i) % QI_LENGTH) << shift;
> memcpy(qi->desc + offset, [i], 1 << shift);
> qi->desc_status[(index + i) % QI_LENGTH] = QI_IN_USE;
> + trace_qi_submit(iommu, desc[i].qw0, desc[i].qw1,
> + desc[i].qw2, desc[i].qw3);
> }
> qi->desc_status[wait_index] = QI_IN_USE;
>
> diff --git a/include/trace/events/intel_iommu.h
> b/include/trace/events/intel_iommu.h
> index 112bd06487bf..aad2ff0c1e2e 100644
> --- a/include/trace/events/intel_iommu.h
> +++ b/include/trace/events/intel_iommu.h
> @@ -135,6 +135,43 @@ DEFINE_EVENT(dma_map_sg, bounce_map_sg,
>struct scatterlist *sg),
> TP_ARGS(dev, index, total, sg)
> );
> +
> +TRACE_EVENT(qi_submit,
> + TP_PROTO(struct intel_iommu *iommu, u64 qw0, u64 qw1, u64 qw2, u64 qw3),
> +
> + TP_ARGS(iommu, qw0, qw1, qw2, qw3),
> +
> + TP_STRUCT__entry(
> + __field(u64, qw0)
> + __field(u64, qw1)
> + __field(u64, qw2)
> + __field(u64, qw3)
> + __string(iommu, iommu->name)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(iommu, iommu->name);
> + __entry->qw0 = qw0;
> + __entry->qw1 = qw1;
> + __entry->qw2 = qw2;
> + __entry->qw3 = qw3;
> + ),
> +
> + TP_printk("%s %s: 0x%llx 0x%llx 0x%llx 0x%llx",
> + __print_symbolic(__entry->qw0 & 0xf,
> +{ QI_CC_TYPE,"cc_inv" },
> +{ QI_IOTLB_TYPE, "iotlb_inv" },
> +{ QI_DIOTLB_TYPE,"dev_tlb_inv" },
> +{ QI_IEC_TYPE, "iec_inv" },
> +{ QI_IWD_TYPE, "inv_wait" },
> +{ QI_EIOTLB_TYPE,"p_iotlb_inv" },
> +{ QI_PC_TYPE,"pc_inv" },
> +{ QI_DEIOTLB_TYPE, "p_dev_tlb_inv" },
> +{ QI_PGRP_RESP_TYPE, "page_grp_resp" }),
> + __get_str(iommu),
> + __entry->qw0, __entry->qw1, __entry->qw2, __entry->qw3
> + )
> +);
> #endif /* _TRACE_INTEL_IOMMU_H */
>
> /* This part must be outside protection */
Re: [PATCH v2] tpm_tis: Add missing tpm_request/relinquish_locality calls
Jarkko Sakkinen writes:
> On Thu, 2021-01-28 at 14:07 +0100, Lukasz Majczak wrote:
>> There is a missing call to tpm_request_locality before the call to
>> the tpm_get_timeouts() and tpm_tis_probe_irq_single(). As the current
>> approach might work for tpm2, it fails for tpm1.x - in that case
>> call to tpm_get_timeouts() or tpm_tis_probe_irq_single()
>> without locality fails and in turn causes tpm_tis_core_init() to fail.
>> Tested on Samsung Chromebook Pro (Caroline).
>>
>> Signed-off-by: Lukasz Majczak
>
> Is it possible that you test against linux-next and see if any
> problems still arise? I've applied the locality fixes from James.
I tested current linux-next and the warning still appears,
unfortunately.
I then incrementally applied further patches from James' series [1] and
after "[PATCH v2 4/5] tpm_tis: fix IRQ probing" the warning has gone:
# dmesg | grep tpm
[7.220410] tpm_tis STM0125:00: 2.0 TPM (device-id 0x0, rev-id 78)
[7.322564] Modules linked in: iwlmvm(+) btusb btrtl btbcm btintel mac80211
amdgpu(+) iwlwifi drm_ttm_helper tpm_crb sdhci_pci ttm cqhci gpu_sched sdhci
ccp cfg80211 rng_core tpm_tis tpm_tis_core tpm thinkpad_acpi(+) wmi nvram
pinctrl_amd
You might notice there is another warning but that is rtc related and I
still have to find out if that is something I should report.
Dirk
[1]
https://lore.kernel.org/linux-integrity/20201001180925.13808-1-james.bottom...@hansenpartnership.com/
>> ---
>> Jarkko, James, Guenter
>>
>> I’m aware about the other thread, but it seems to be dead for a few months.
>> Here is the small patch as fixing this specific issue
>> would allow us to unblock the ChromeOs development.
>> We want to upstream all of our patches,
>> so the ChromeOs will not diverge even more,
>> so I'm hoping this could be applied, if you see it neat enough.
>
> The usual approach is that you construct a series picking the pre-existing
> fixes and on top of that create your own, if any required.
>
>> Best regards,
>> Lukasz
>
> /Jarkko
>
>>
>> v1 -> v2:
>> - fixed typos
>> - as there is no need to enable clock, switched to
>> use only tpm_request/relinquish_locality calls
>> - narrowed down boundaries of tpm_request/relinquish_locality calls
>>
>> drivers/char/tpm/tpm-chip.c | 4 ++--
>> drivers/char/tpm/tpm-interface.c | 11 +--
>> drivers/char/tpm/tpm.h | 2 ++
>> drivers/char/tpm/tpm_tis_core.c | 12 ++--
>> 4 files changed, 23 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
>> index ddaeceb7e109..5351963a4b19 100644
>> --- a/drivers/char/tpm/tpm-chip.c
>> +++ b/drivers/char/tpm/tpm-chip.c
>> @@ -32,7 +32,7 @@ struct class *tpm_class;
>> struct class *tpmrm_class;
>> dev_t tpm_devt;
>>
>> -static int tpm_request_locality(struct tpm_chip *chip)
>> +int tpm_request_locality(struct tpm_chip *chip)
>> {
>> int rc;
>>
>> @@ -47,7 +47,7 @@ static int tpm_request_locality(struct tpm_chip *chip)
>> return 0;
>> }
>>
>> -static void tpm_relinquish_locality(struct tpm_chip *chip)
>> +void tpm_relinquish_locality(struct tpm_chip *chip)
>> {
>> int rc;
>>
>> diff --git a/drivers/char/tpm/tpm-interface.c
>> b/drivers/char/tpm/tpm-interface.c
>> index 1621ce818705..69309b2bea6a 100644
>> --- a/drivers/char/tpm/tpm-interface.c
>> +++ b/drivers/char/tpm/tpm-interface.c
>> @@ -243,8 +243,15 @@ int tpm_get_timeouts(struct tpm_chip *chip)
>>
>> if (chip->flags & TPM_CHIP_FLAG_TPM2)
>> return tpm2_get_timeouts(chip);
>> - else
>> - return tpm1_get_timeouts(chip);
>> + else {
>> + ssize_t ret = tpm_request_locality(chip);
>> +
>> + if (ret)
>> + return ret;
>> + ret = tpm1_get_timeouts(chip);
>> + tpm_relinquish_locality(chip);
>> + return ret;
>> + }
>> }
>> EXPORT_SYMBOL_GPL(tpm_get_timeouts);
>>
>> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
>> index 947d1db0a5cc..8c13008437dd 100644
>> --- a/drivers/char/tpm/tpm.h
>> +++ b/drivers/char/tpm/tpm.h
>> @@ -193,6 +193,8 @@ static inline void tpm_msleep(unsigned int delay_msec)
>>
>> int tpm_chip_start(struct tpm_chip *chip);
>> void tpm_chip_stop(struct tpm_chip *chip);
>> +int tpm_request_locality(struct tpm_chip *chip);
>> +void tpm_relinqu
Re: WARN_ONCE triggered: tpm_tis: Add a check for invalid status
James Bottomley writes: > On Wed, 2020-10-14 at 19:57 +0200, Dirk Gouders wrote: >> On my laptop the check introduced with 55707d531af62b (tpm_tis: Add a >> check for invalid status) triggered the warning (output below). >> >> So, my laptop seems to be a candidate for testing. > > I'm afraid this is a known problem on a wide range of TIS TPMs ... it's > fixed by the patch set I'm trying to get upstream: > > https://lore.kernel.org/linux-integrity/20201001180925.13808-1-james.bottom...@hansenpartnership.com/ > > But in the meantime, it's harmless. The TIS code at the point in the > trace is trying to send a TPM2_GetCapability() command which fails > because the locality isn't listening, but the design of that command is > only to trigger an interrupt to probe the interrupt handling nothing > else depends on it succeeding. Thank you for the explanation and sorry for the noise. It seems I misunderstood the commit message. I will watch the ongoing discussion you pointed me to. Dirk
WARN_ONCE triggered: tpm_tis: Add a check for invalid status
On my laptop the check introduced with 55707d531af62b (tpm_tis: Add a check for invalid status) triggered the warning (output below). So, my laptop seems to be a candidate for testing. Dirk [7.255467] [ cut here ] [7.255468] TPM returned invalid status [7.255481] WARNING: CPU: 4 PID: 816 at drivers/char/tpm/tpm_tis_core.c:249 tpm_tis_status+0x5e/0x7f [tpm_tis_core] [7.255481] Modules linked in: nvram tpm_tis(+) tpm_tis_core tpm wmi pinctrl_amd [7.255485] CPU: 4 PID: 816 Comm: udevd Not tainted 5.9.0-x86_64+ #148 [7.255486] Hardware name: LENOVO 20U50008GE/20U50008GE, BIOS R19ET26W (1.10 ) 06/22/2020 [7.255488] RIP: 0010:tpm_tis_status+0x5e/0x7f [tpm_tis_core] [7.255489] Code: 44 8a 64 24 07 41 f6 c4 23 74 21 45 31 e4 80 3d 86 26 00 00 00 75 15 48 c7 c7 2a 71 01 a0 c6 05 76 26 00 00 01 e8 e1 17 0e e1 <0f> 0b 48 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 cd cd a2 [7.255489] RSP: 0018:c9f7f8b8 EFLAGS: 00010286 [7.255490] RAX: RBX: 8883f9117198 RCX: 038a [7.255490] RDX: 0001 RSI: 0002 RDI: 82dbd34c [7.255491] RBP: 8883f8aae000 R08: 0001 R09: 00012d00 [7.255491] R10: R11: 003c R12: [7.255492] R13: R14: 8883f7c8a000 R15: 0016 [7.255493] FS: 7f350c98d780() GS:88840ed0() knlGS: [7.255493] CS: 0010 DS: ES: CR0: 80050033 [7.255494] CR2: 7f350c572ca8 CR3: 0003f700 CR4: 00350ee0 [7.255494] Call Trace: [7.255497] tpm_tis_send_data+0x28/0x187 [tpm_tis_core] [7.255498] tpm_tis_send_main+0x14/0x84 [tpm_tis_core] [7.255500] tpm_transmit+0xc5/0x2d7 [tpm] [7.255503] tpm_transmit_cmd+0x23/0x8b [tpm] [7.255504] tpm2_get_tpm_pt+0x71/0xb2 [tpm] [7.255505] tpm_tis_probe_irq_single+0x134/0xbe2 [tpm_tis_core] [7.255506] tpm_tis_core_init+0x3b3/0x47b [tpm_tis_core] [7.255508] tpm_tis_plat_probe+0xa7/0xc5 [tpm_tis] [7.255512] platform_drv_probe+0x2a/0x6b [7.255514] really_probe+0x157/0x32a [7.255516] driver_probe_device+0x63/0x97 [7.255517] device_driver_attach+0x37/0x50 [7.255518] __driver_attach+0x92/0x9a [7.255519] ? device_driver_attach+0x50/0x50 [7.255520] bus_for_each_dev+0x70/0xa6 [7.255521] bus_add_driver+0x103/0x1b4 [7.255522] driver_register+0x99/0xd2 [7.255523] ? 0xa0023000 [7.255524] init_tis+0x88/0x1000 [tpm_tis] [7.255526] ? consume_skb+0x9/0x20 [7.255529] ? ___cache_free+0x5c/0x153 [7.255531] ? _cond_resched+0x1b/0x1e [7.255532] do_one_initcall+0x8a/0x195 [7.255534] ? kmem_cache_alloc_trace+0x80/0x8f [7.255536] do_init_module+0x56/0x1e8 [7.255537] load_module+0x1c2c/0x2139 [7.255538] ? __do_sys_finit_module+0x8f/0xb6 [7.255539] __do_sys_finit_module+0x8f/0xb6 [7.255541] do_syscall_64+0x5d/0x6a [7.255543] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [7.255544] RIP: 0033:0x7f350cae8919 [7.255545] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 47 05 0c 00 f7 d8 64 89 01 48 [7.255545] RSP: 002b:7ffe0e5ed928 EFLAGS: 0246 ORIG_RAX: 0139 [7.255546] RAX: ffda RBX: 55a400c373e0 RCX: 7f350cae8919 [7.255546] RDX: RSI: 7f350cbc1a7d RDI: 000b [7.255547] RBP: 0002 R08: R09: 7ffe0e5edaa0 [7.255547] R10: 000b R11: 0246 R12: 7f350cbc1a7d [7.255548] R13: R14: 55a400c30e10 R15: 55a400c373e0 [7.255548] ---[ end trace 883dd41f557db5d3 ]---
Re: [PATCH 1/1] drm/amdgpu: fix NULL pointer dereference for Renoir
Dirk Gouders writes:
> Commit c1cf79ca5ced46 (drm/amdgpu: use IP discovery table for renoir)
> introduced a NULL pointer dereference when booting with
> amdgpu.discovery=0, because it removed the call of vega10_reg_base_init()
> for that case.
>
> Fix this by calling that funcion if amdgpu_discovery == 0 in addition to
> the case that amdgpu_discovery_reg_base_init() failed.
>
> Fixes: c1cf79ca5ced46 (drm/amdgpu: use IP discovery table for renoir)
> Signed-off-by: Dirk Gouders
> Cc: Hawking Zhang
> Cc: Evan Quan
> ---
> drivers/gpu/drm/amd/amdgpu/soc15.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
> b/drivers/gpu/drm/amd/amdgpu/soc15.c
> index 84d811b6e48b..f8cb62b326d6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/soc15.c
> +++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
> @@ -694,12 +694,12 @@ static void soc15_reg_base_init(struct amdgpu_device
> *adev)
>* it doesn't support SRIOV. */
> if (amdgpu_discovery) {
> r = amdgpu_discovery_reg_base_init(adev);
> - if (r) {
> - DRM_WARN("failed to init reg base from ip
> discovery table, "
> - "fallback to legacy init method\n");
> - vega10_reg_base_init(adev);
> - }
> + if (r == 0)
> + break;
Grrr, wrong indentation here.
But I will wait for your review before v1.
Dirk
> + DRM_WARN("failed to init reg base from ip discovery
> table, "
> + "fallback to legacy init method\n");
> }
> + vega10_reg_base_init(adev);
> break;
> case CHIP_VEGA20:
> vega20_reg_base_init(adev);
[PATCH 1/1] drm/amdgpu: fix NULL pointer dereference for Renoir
Commit c1cf79ca5ced46 (drm/amdgpu: use IP discovery table for renoir)
introduced a NULL pointer dereference when booting with
amdgpu.discovery=0, because it removed the call of vega10_reg_base_init()
for that case.
Fix this by calling that funcion if amdgpu_discovery == 0 in addition to
the case that amdgpu_discovery_reg_base_init() failed.
Fixes: c1cf79ca5ced46 (drm/amdgpu: use IP discovery table for renoir)
Signed-off-by: Dirk Gouders
Cc: Hawking Zhang
Cc: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index 84d811b6e48b..f8cb62b326d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -694,12 +694,12 @@ static void soc15_reg_base_init(struct amdgpu_device
*adev)
* it doesn't support SRIOV. */
if (amdgpu_discovery) {
r = amdgpu_discovery_reg_base_init(adev);
- if (r) {
- DRM_WARN("failed to init reg base from ip
discovery table, "
-"fallback to legacy init method\n");
- vega10_reg_base_init(adev);
- }
+ if (r == 0)
+ break;
+ DRM_WARN("failed to init reg base from ip discovery
table, "
+"fallback to legacy init method\n");
}
+ vega10_reg_base_init(adev);
break;
case CHIP_VEGA20:
vega20_reg_base_init(adev);
--
2.26.2
[PATCH 0/1] drm/amdgpu: fix NULL pointer dereference for Renoir
Alex Deucher writes:
> On Wed, Sep 30, 2020 at 4:46 PM Dirk Gouders wrote:
>>
>> Commit c1cf79ca5ced46 (drm/amdgpu: use IP discovery table for renoir)
>> introduced a NULL pointer dereference when booting with
>> amdgpu.discovery=0.
>>
>> For amdgpu.discovery=0 that commit effectively removed the call of
>> vega10_reg_base_init(adev), so I tested the correctness of the bisect
>> session by restoring that function call for amdgpu_discovery == 0 and with
>> that change, the NULL pointer dereference does not occur:
>>
>
> Can I add your Signed-off-by?
I did not expect the diff to be seen as a proposed patch, not even that it
shows the correct fix.
Anyway, I did my best to create a hopefully acceptable patch with
some modification of the code that avoids "else" and an identical function call
at two places in the code.
I testet that patch with amdgpu.discovery={0,1} and together with the patch for
the
first issue you helped me with. The result is no more call traces.
Thank you for your patient assistance with the two issues.
Dirk
> Thanks,
>
> Alex
>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
>> b/drivers/gpu/drm/amd/amdgpu/soc15.c
>> index 84d811b6e48b..2e93c5e1e7e6 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/soc15.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
>> @@ -699,7 +699,8 @@ static void soc15_reg_base_init(struct amdgpu_device
>> *adev)
>> "fallback to legacy init method\n");
>> vega10_reg_base_init(adev);
>> }
>> - }
>> + } else
>> + vega10_reg_base_init(adev);
>> break;
>> case CHIP_VEGA20:
>> vega20_reg_base_init(adev);
>>
>> Dirk
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Dirk Gouders (1):
drm/amdgpu: fix NULL pointer dereference for Renoir
drivers/gpu/drm/amd/amdgpu/soc15.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--
2.26.2
BUG: amdgpu: NULL pointer dereference introduced in 5.9-rc1
Commit c1cf79ca5ced46 (drm/amdgpu: use IP discovery table for renoir) introduced a NULL pointer dereference when booting with amdgpu.discovery=0. For amdgpu.discovery=0 that commit effectively removed the call of vega10_reg_base_init(adev), so I tested the correctness of the bisect session by restoring that function call for amdgpu_discovery == 0 and with that change, the NULL pointer dereference does not occur: diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c b/drivers/gpu/drm/amd/amdgpu/soc15.c index 84d811b6e48b..2e93c5e1e7e6 100644 --- a/drivers/gpu/drm/amd/amdgpu/soc15.c +++ b/drivers/gpu/drm/amd/amdgpu/soc15.c @@ -699,7 +699,8 @@ static void soc15_reg_base_init(struct amdgpu_device *adev) "fallback to legacy init method\n"); vega10_reg_base_init(adev); } - } + } else + vega10_reg_base_init(adev); break; case CHIP_VEGA20: vega20_reg_base_init(adev); Dirk
[PATCH] ./Makefile: consider PAGER for `make help'
`make help' outputs more than a screenfull of lines. In case a user has PAGER defined in his environment, she most likely wants it to be used in such situations. Signed-off-by: Dirk Gouders --- Makefile | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Makefile b/Makefile index 992d24467ca0..ce1b7e83a4c8 100644 --- a/Makefile +++ b/Makefile @@ -1531,7 +1531,14 @@ board-dirs := $(dir $(wildcard $(srctree)/arch/$(SRCARCH)/configs/*/*_defconfig) board-dirs := $(sort $(notdir $(board-dirs:/=))) PHONY += help +ifdef PAGER +PHONY += _help help: + $(Q)$(MAKE) _help | $(PAGER) +_help: +else +help: +endif @echo 'Cleaning targets:' @echo ' clean - Remove most generated files but keep the config and' @echo 'enough build support to build external modules'
Re: amdgpu: call trace introduced in 5.9-rc1 for Lenovo L14 Renoir
Alex Deucher writes:
> On Wed, Sep 23, 2020 at 3:45 PM Dirk Gouders wrote:
>>
>> Dirk Gouders writes:
>>
>> > Alex Deucher writes:
>> >
>> >> On Wed, Sep 23, 2020 at 8:54 AM Dirk Gouders wrote:
>> >>>
>> >>> Dirk Gouders writes:
>> >>>
>> >>> > Hi,
>> >>> >
>> >>> > I noticed a call trace (attached) when starting my machine (ThinkPad
>> >>> > L14). This machine is new and I am still working on it's
>> >>> > configuration but visually noticeable is that scrolling in xterms with
>> >>> > SHIFT-PgUp/PgDn is broken. Using the mouse wheel works.
>> >>> >
>> >>> > It seems the call trace has been introduced between 5.8 and 5.9-rc1 and
>> >>> > I tried to bisect this but always end in situations where I dont't find
>> >>> > a bootable commit around the current bisect position. Mainly the
>> >>> > machine then hangs when udevd is started.
>> >>>
>> >>> I fixed my netconsole setup (had to use a switch instead of the
>> >>> ports of a FritzBox) and tried a bisect, again (log below). With the
>> >>> commits between the earliest bad and latest good commits I marked, my
>> >>> machine does not boot and hangs very early with the message:
>> >>>
>> >>> fb0: switching to amdgpudrmfb from EFI VGA
>> >>>
>> >>> That was introduced with
>> >>>
>> >>> c1cf79ca5ced drm/amdgpu: use IP discovery table for renoir
>> >>>
>> >>> and ended with a commit that instead produces the call trace
>> >>>
>> >>> b6df946ef4b5 drm/amdgpu: fix the nullptr issue as for PWR IP not
>> >>> existing in discovery table
>> >>>
>> >>> I was hoping to get further with the bisect but have no idea how to
>> >>> avoid the early hangs.
>> >>
>> >> You can disable use of the IP discovery table by setting
>> >> amdgpu.discovery=0 on the kernel command line in grub.
>> >
>> > I tried that with b770f04ba2ee (next step in bisect), but no success
>> > with this option, unfortunately.
>> >
>> > I'm not using grub but directly booting from UEFI using CONFIG_CMDLINE.
>> > Any other option I am using (root, loglevel and netconsole) works as
>> > expected and I veryfied that "amdgpu.discovery=0" is included in
>> > vmlinux.
>>
>> Apologies if I'm causing too much noise.
>>
>> While thinking about this I recalled that I changed amdgpu from modular to
>> static when I had problems with netconsole. I changed it back to
>> modular to see if that helps and I get the earlier mentioned hangs later
>> in the boot process when udevd starts and netconsole is up working.
>> This enables me to inspect boot messages and I tested with
>> amdgpu.discovery=0:
>>
>> 5,175,49060,-;Kernel command line: root=PARTLABEL=system1 amdgpu.discovery=0
>> loglevel=15 netconsole=...
>>
>> I'm afraid I now get traces that commit b6df946ef4b5 (drm/amdgpu: fix
>> the nullptr issue as for PWR IP not existing in discovery table) is
>> fixing (output attached below) and I cannot decide how to continue with
>> bisecting...
>
> You get the issue with discovery=0? You can try skipping that commit
> (mark as skip) to finish the bisection.
I get issues with both, amdgpu.discovery={0,1}. With "0" I hit the NULL
pointer dereference in soc15_set_ip_blocks() and with "1" I hit the
assert in rn_clk_mgr_helper_populate_bw_params().
I only noticed the issue with "0" after you told me about
amdgpu.discovery, so I continued to find the commit that introduced the
issue with "1".
Using bisect skip alone did not help but keeping b6df946ef4b5
(drm/amdgpu: fix the nullptr issue as for PWR IP not existing in
discovery table) in the working tree made the bisect session much more
straight forward.
It resulted in 02cf91c113ea (drm/amd/powerplay: postpone operations not
required for hw setup to late_init) as the first bad commit.
Not that I understand anything about the driver but I wanted to know if
that commit really is causing the issue. So, I tried to move back some
initialization code from smu_late_init() to smu_smc_hw_setup() (diff
below) and with that the issue is gone. I'm not sure if you prefer a
full dmesg output, for now I'll append the [drm] part.
Dirk
= diff
Re: amdgpu: call trace introduced in 5.9-rc1 for Lenovo L14 Renoir
Dirk Gouders writes: > Alex Deucher writes: > >> On Wed, Sep 23, 2020 at 8:54 AM Dirk Gouders wrote: >>> >>> Dirk Gouders writes: >>> >>> > Hi, >>> > >>> > I noticed a call trace (attached) when starting my machine (ThinkPad >>> > L14). This machine is new and I am still working on it's >>> > configuration but visually noticeable is that scrolling in xterms with >>> > SHIFT-PgUp/PgDn is broken. Using the mouse wheel works. >>> > >>> > It seems the call trace has been introduced between 5.8 and 5.9-rc1 and >>> > I tried to bisect this but always end in situations where I dont't find >>> > a bootable commit around the current bisect position. Mainly the >>> > machine then hangs when udevd is started. >>> >>> I fixed my netconsole setup (had to use a switch instead of the >>> ports of a FritzBox) and tried a bisect, again (log below). With the >>> commits between the earliest bad and latest good commits I marked, my >>> machine does not boot and hangs very early with the message: >>> >>> fb0: switching to amdgpudrmfb from EFI VGA >>> >>> That was introduced with >>> >>> c1cf79ca5ced drm/amdgpu: use IP discovery table for renoir >>> >>> and ended with a commit that instead produces the call trace >>> >>> b6df946ef4b5 drm/amdgpu: fix the nullptr issue as for PWR IP not >>> existing in discovery table >>> >>> I was hoping to get further with the bisect but have no idea how to >>> avoid the early hangs. >> >> You can disable use of the IP discovery table by setting >> amdgpu.discovery=0 on the kernel command line in grub. > > I tried that with b770f04ba2ee (next step in bisect), but no success > with this option, unfortunately. > > I'm not using grub but directly booting from UEFI using CONFIG_CMDLINE. > Any other option I am using (root, loglevel and netconsole) works as > expected and I veryfied that "amdgpu.discovery=0" is included in > vmlinux. Apologies if I'm causing too much noise. While thinking about this I recalled that I changed amdgpu from modular to static when I had problems with netconsole. I changed it back to modular to see if that helps and I get the earlier mentioned hangs later in the boot process when udevd starts and netconsole is up working. This enables me to inspect boot messages and I tested with amdgpu.discovery=0: 5,175,49060,-;Kernel command line: root=PARTLABEL=system1 amdgpu.discovery=0 loglevel=15 netconsole=... I'm afraid I now get traces that commit b6df946ef4b5 (drm/amdgpu: fix the nullptr issue as for PWR IP not existing in discovery table) is fixing (output attached below) and I cannot decide how to continue with bisecting... Dirk 1,840,5418458,-;BUG: kernel NULL pointer dereference, address: 0008 1,841,5418472,-;#PF: supervisor read access in kernel mode 1,842,5418474,-;#PF: error_code(0x) - not-present page 6,843,5418476,-;PGD 0 P4D 0 4,844,5418480,-;Oops: [#1] SMP NOPTI 4,845,5418483,-;CPU: 3 PID: 744 Comm: udevd Not tainted 5.7.0-rc2-x86_64-01641-gb770f04ba2ee #216 4,846,5418486,-;Hardware name: LENOVO 20U50008GE/20U50008GE, BIOS R19ET26W (1.10 ) 06/22/2020 4,847,5418559,-;RIP: 0010:nbio_v7_0_get_rev_id+0x9/0x1b [amdgpu] 4,848,5418562,-;Code: 5d 41 5d 41 5e e9 9a f0 f9 ff 48 8b 87 e8 5f 01 00 31 d2 8b 70 08 81 c6 c3 00 00 00 e9 9d ef f9 ff 48 8b 87 e8 5f 01 00 31 d2 <8b> 70 08 83 c6 0f e8 89 ef f9 ff c1 e8 18 83 e0 0f c3 49 89 f8 48 4,849,5418566,-;RSP: 0018:c900011dba90 EFLAGS: 00010246 4,850,5418568,-;RAX: RBX: 000fffe0 RCX: 0018 4,851,5418571,-;RDX: RSI: a0970e20 RDI: 8883f554 4,852,5418573,-;RBP: 8883f554 R08: 0001 R09: 4,853,5418575,-;R10: R11: 0048 R12: ffea 4,854,5418577,-;R13: 7fff R14: 8883f9486800 R15: c900011dbe98 4,855,5418580,-;FS: 7f750db3dd80() GS:88840ecc() knlGS: 4,856,5418583,-;CS: 0010 DS: ES: CR0: 80050033 4,857,5418586,-;CR2: 0008 CR3: 0003f9728000 CR4: 00340ee0 4,858,5418588,-;Call Trace: 4,859,5418660,-; soc15_set_ip_blocks+0x105/0x4fd [amdgpu] 4,860,5418714,-; amdgpu_device_init+0xcab/0x1862 [amdgpu] 4,861,5418720,-; ? __kmalloc+0xb2/0xc4 4,862,5418766,-; amdgpu_driver_load_kms+0x41/0x178 [amdgpu] 4,863,5418813,-; amdgpu_pci_probe+0x147/0x1c7 [amdgpu] 4,864,5418818,-; pci_device_probe+0xc6/0x135 4,865,5418822,-; really_probe+0x157/0x2d1 4,866,5418825,-; driver_probe_device+0x97/0xcc 4,867,5418828,-; de
Re: amdgpu: call trace introduced in 5.9-rc1 for Lenovo L14 Renoir
Alex Deucher writes: > On Wed, Sep 23, 2020 at 8:54 AM Dirk Gouders wrote: >> >> Dirk Gouders writes: >> >> > Hi, >> > >> > I noticed a call trace (attached) when starting my machine (ThinkPad >> > L14). This machine is new and I am still working on it's >> > configuration but visually noticeable is that scrolling in xterms with >> > SHIFT-PgUp/PgDn is broken. Using the mouse wheel works. >> > >> > It seems the call trace has been introduced between 5.8 and 5.9-rc1 and >> > I tried to bisect this but always end in situations where I dont't find >> > a bootable commit around the current bisect position. Mainly the >> > machine then hangs when udevd is started. >> >> I fixed my netconsole setup (had to use a switch instead of the >> ports of a FritzBox) and tried a bisect, again (log below). With the >> commits between the earliest bad and latest good commits I marked, my >> machine does not boot and hangs very early with the message: >> >> fb0: switching to amdgpudrmfb from EFI VGA >> >> That was introduced with >> >> c1cf79ca5ced drm/amdgpu: use IP discovery table for renoir >> >> and ended with a commit that instead produces the call trace >> >> b6df946ef4b5 drm/amdgpu: fix the nullptr issue as for PWR IP not >> existing in discovery table >> >> I was hoping to get further with the bisect but have no idea how to >> avoid the early hangs. > > You can disable use of the IP discovery table by setting > amdgpu.discovery=0 on the kernel command line in grub. I tried that with b770f04ba2ee (next step in bisect), but no success with this option, unfortunately. I'm not using grub but directly booting from UEFI using CONFIG_CMDLINE. Any other option I am using (root, loglevel and netconsole) works as expected and I veryfied that "amdgpu.discovery=0" is included in vmlinux. Dirk > > Alex > > >> >> Dirk >> >> = bisect log === >> git bisect start >> # bad: [9123e3a74ec7b934a4a099e98af6a61c2f80bbf5] Linux 5.9-rc1 >> git bisect bad 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5 >> # good: [bcf876870b95592b52519ed4aafcf9d95999bc9c] Linux 5.8 >> git bisect good bcf876870b95592b52519ed4aafcf9d95999bc9c >> # bad: [8186749621ed6b8fc42644c399e8c755a2b6f630] Merge tag >> 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm >> git bisect bad 8186749621ed6b8fc42644c399e8c755a2b6f630 >> # good: [2324d50d051ec0f14a548e78554fb02513d6dcef] Merge tag 'docs-5.9' of >> git://git.lwn.net/linux >> git bisect good 2324d50d051ec0f14a548e78554fb02513d6dcef >> # bad: [54d44bfc56308d105b0da37392d8398bdc9d4745] drm/nouveau/nvif: >> give every disp object a human-readable identifier >> git bisect bad 54d44bfc56308d105b0da37392d8398bdc9d4745 >> # bad: [9555152beb1143c85c03f9b9de59863cbbe89f4b] Merge tag >> 'amd-drm-next-5.9-2020-07-01' of >> git://people.freedesktop.org/~agd5f/linux into drm-next >> git bisect bad 9555152beb1143c85c03f9b9de59863cbbe89f4b >> # bad: [dfd991794685b1228387214f28630b6e94e56944] drm/amd/display: Not doing >> bios data pack. >> git bisect bad dfd991794685b1228387214f28630b6e94e56944 >> # good: [ba806f98f868ce107aa9c453fef751de9980e4af] drm/radeon: disable AGP >> by default >> git bisect good ba806f98f868ce107aa9c453fef751de9980e4af >> # good: [97d798b276e94a366dfb03d62bc90d4742ab3a31] drm/amdgpu: simplify ATIF >> backlight handling >> git bisect good 97d798b276e94a366dfb03d62bc90d4742ab3a31 >> # good: [ac4e189a5623579c023c9cf8006422aef2a487b4] drm/amdgpu/gfx10: add >> navi12 to gfxoff case >> git bisect good ac4e189a5623579c023c9cf8006422aef2a487b4 >> # good: [70534d1ee89ceadd03292d0c2da4dd4020189678] drm/amdgpu: simplify >> raven and renoir checks >> git bisect good 70534d1ee89ceadd03292d0c2da4dd4020189678 >> # good: [4541ea81edde6ce9a1d9be082489aca7e8e7e1dc] >> drm/[radeon|amdgpu]: Replace one-element array and use struct_size() >> helper >> git bisect good 4541ea81edde6ce9a1d9be082489aca7e8e7e1dc >> # good: [84034ad4c0c0813c1350b43087eed036066edd5a] drm/amd/display: combine >> public interfaces into single header >> git bisect good 84034ad4c0c0813c1350b43087eed036066edd5a >> # good: [4f1fad0e9dbd762497df7c79309697ed8b2b6cfc] drm/amd/powerplay: stop >> thermal IRQs on suspend >> git bisect good 4f1fad0e9dbd762497df7c79309697ed8b2b6cfc >> # good: [4292b0b2026bc10bced32636ea02dd8eed00cea9] drm/amdgpu: clean up >> discovery testing >> g
Re: amdgpu: call trace introduced in 5.9-rc1 for Lenovo L14 Renoir
Dirk Gouders writes: > Hi, > > I noticed a call trace (attached) when starting my machine (ThinkPad > L14). This machine is new and I am still working on it's > configuration but visually noticeable is that scrolling in xterms with > SHIFT-PgUp/PgDn is broken. Using the mouse wheel works. > > It seems the call trace has been introduced between 5.8 and 5.9-rc1 and > I tried to bisect this but always end in situations where I dont't find > a bootable commit around the current bisect position. Mainly the > machine then hangs when udevd is started. I fixed my netconsole setup (had to use a switch instead of the ports of a FritzBox) and tried a bisect, again (log below). With the commits between the earliest bad and latest good commits I marked, my machine does not boot and hangs very early with the message: fb0: switching to amdgpudrmfb from EFI VGA That was introduced with c1cf79ca5ced drm/amdgpu: use IP discovery table for renoir and ended with a commit that instead produces the call trace b6df946ef4b5 drm/amdgpu: fix the nullptr issue as for PWR IP not existing in discovery table I was hoping to get further with the bisect but have no idea how to avoid the early hangs. Dirk = bisect log === git bisect start # bad: [9123e3a74ec7b934a4a099e98af6a61c2f80bbf5] Linux 5.9-rc1 git bisect bad 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5 # good: [bcf876870b95592b52519ed4aafcf9d95999bc9c] Linux 5.8 git bisect good bcf876870b95592b52519ed4aafcf9d95999bc9c # bad: [8186749621ed6b8fc42644c399e8c755a2b6f630] Merge tag 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm git bisect bad 8186749621ed6b8fc42644c399e8c755a2b6f630 # good: [2324d50d051ec0f14a548e78554fb02513d6dcef] Merge tag 'docs-5.9' of git://git.lwn.net/linux git bisect good 2324d50d051ec0f14a548e78554fb02513d6dcef # bad: [54d44bfc56308d105b0da37392d8398bdc9d4745] drm/nouveau/nvif: give every disp object a human-readable identifier git bisect bad 54d44bfc56308d105b0da37392d8398bdc9d4745 # bad: [9555152beb1143c85c03f9b9de59863cbbe89f4b] Merge tag 'amd-drm-next-5.9-2020-07-01' of git://people.freedesktop.org/~agd5f/linux into drm-next git bisect bad 9555152beb1143c85c03f9b9de59863cbbe89f4b # bad: [dfd991794685b1228387214f28630b6e94e56944] drm/amd/display: Not doing bios data pack. git bisect bad dfd991794685b1228387214f28630b6e94e56944 # good: [ba806f98f868ce107aa9c453fef751de9980e4af] drm/radeon: disable AGP by default git bisect good ba806f98f868ce107aa9c453fef751de9980e4af # good: [97d798b276e94a366dfb03d62bc90d4742ab3a31] drm/amdgpu: simplify ATIF backlight handling git bisect good 97d798b276e94a366dfb03d62bc90d4742ab3a31 # good: [ac4e189a5623579c023c9cf8006422aef2a487b4] drm/amdgpu/gfx10: add navi12 to gfxoff case git bisect good ac4e189a5623579c023c9cf8006422aef2a487b4 # good: [70534d1ee89ceadd03292d0c2da4dd4020189678] drm/amdgpu: simplify raven and renoir checks git bisect good 70534d1ee89ceadd03292d0c2da4dd4020189678 # good: [4541ea81edde6ce9a1d9be082489aca7e8e7e1dc] drm/[radeon|amdgpu]: Replace one-element array and use struct_size() helper git bisect good 4541ea81edde6ce9a1d9be082489aca7e8e7e1dc # good: [84034ad4c0c0813c1350b43087eed036066edd5a] drm/amd/display: combine public interfaces into single header git bisect good 84034ad4c0c0813c1350b43087eed036066edd5a # good: [4f1fad0e9dbd762497df7c79309697ed8b2b6cfc] drm/amd/powerplay: stop thermal IRQs on suspend git bisect good 4f1fad0e9dbd762497df7c79309697ed8b2b6cfc # good: [4292b0b2026bc10bced32636ea02dd8eed00cea9] drm/amdgpu: clean up discovery testing git bisect good 4292b0b2026bc10bced32636ea02dd8eed00cea9 # bad: [c0838cbee2d05c3eb8a2b5a3d1ce706a73008044] drm/amd/display: Revert "enable plane if plane_status changed" git bisect bad c0838cbee2d05c3eb8a2b5a3d1ce706a73008044 # bad: [651a146526a04993c5bebf0e19cd9256f5e6511d] drm/amdgpu/jpeg: fix race condition issue for jpeg start git bisect bad 651a146526a04993c5bebf0e19cd9256f5e6511d # bad: [3bda8acd974e362069e291a78c59a10624debc6e] drm/amdgpu/sriov: Add clear vf fw support git bisect bad 3bda8acd974e362069e291a78c59a10624debc6e # bad: [b6df946ef4b5ae29183b2fdb2d12c381c757b3fb] drm/amdgpu: fix the nullptr issue as for PWR IP not existing in discovery table git bisect bad b6df946ef4b5ae29183b2fdb2d12c381c757b3fb > Please let me know if I can help with further information. > > Dirk > > = lspci -vk > > 06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Renoir (rev c3) (prog-if 00 [VGA controller]) > Subsystem: Lenovo Renoir > Flags: bus master, fast devsel, latency 0, IRQ 64 > Memory at 46000 (64-bit, prefetchable) [size=256M] > Memory at 4
amdgpu: call trace introduced in 5.9-rc1 for Lenovo L14 Renoir
Hi, I noticed a call trace (attached) when starting my machine (ThinkPad L14). This machine is new and I am still working on it's configuration but visually noticeable is that scrolling in xterms with SHIFT-PgUp/PgDn is broken. Using the mouse wheel works. It seems the call trace has been introduced between 5.8 and 5.9-rc1 and I tried to bisect this but always end in situations where I dont't find a bootable commit around the current bisect position. Mainly the machine then hangs when udevd is started. Please let me know if I can help with further information. Dirk = lspci -vk 06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Renoir (rev c3) (prog-if 00 [VGA controller]) Subsystem: Lenovo Renoir Flags: bus master, fast devsel, latency 0, IRQ 64 Memory at 46000 (64-bit, prefetchable) [size=256M] Memory at 47000 (64-bit, prefetchable) [size=2M] I/O ports at 1000 [size=256] Memory at fd30 (32-bit, non-prefetchable) [size=512K] Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [64] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable- Count=1/4 Maskable- 64bit+ Capabilities: [c0] MSI-X: Enable+ Count=4 Masked- Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [270] Secondary PCI Express Capabilities: [2b0] Address Translation Service (ATS) Capabilities: [2c0] Page Request Interface (PRI) Capabilities: [2d0] Process Address Space ID (PASID) Capabilities: [400] Data Link Feature Capabilities: [410] Physical Layer 16.0 GT/s Capabilities: [440] Lane Margining at the Receiver Kernel driver in use: amdgpu Kernel modules: amdgpu = call trace === [5.181468] amdgpu :06:00.0: amdgpu: SMU is initialized successfully! [5.182857] [drm] kiq ring mec 2 pipe 1 q 0 [5.183374] [ cut here ] [5.183448] WARNING: CPU: 1 PID: 684 at drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.c:716 rn_clk_mgr_construct+0x242/0x389 [amdgpu] [5.183449] Modules linked in: btusb btrtl btbcm btintel bluetooth ecdh_generic ecc iwlmvm mac80211 libarc4 wmi_bmof crct10dif_pclmul snd_hda_codec_realtek crc32c_intel iwlwifi snd_hda_codec_generic amdgpu(+) tpm_crb snd_hda_codec_hdmi gpu_sched i2c_algo_bit ttm sdhci_pci aesni_intel drm_kms_helper cqhci sdhci ccp syscopyarea snd_hda_intel sysfillrect tpm_tis snd_intel_dspcfg sysimgblt xhci_pci tpm_tis_core fb_sys_fops r8169 snd_hda_codec mmc_core snd_hda_core xhci_hcd thinkpad_acpi cfg80211 realtek drm snd_pcm rng_core mdio_devres sha1_generic snd_timer nvram libphy i2c_piix4 snd k10temp soundcore ledtrig_audio rfkill tpm hw mon wmi battery ac video backlight pinctrl_amd acpi_cpufreq button efivarfs [5.183470] CPU: 1 PID: 684 Comm: udevd Not tainted 5.9.0-rc6-x86_64+ #170 [5.183471] Hardware name: LENOVO 20U50008GE/20U50008GE, BIOS R19ET26W (1.10 ) 06/22/2020 [5.183531] RIP: 0010:rn_clk_mgr_construct+0x242/0x389 [amdgpu] [5.183533] Code: 30 4d 85 c9 74 26 ba 03 00 00 00 83 bc d4 a8 00 00 00 00 89 d6 74 0a 83 bc d4 ac 00 00 00 00 75 40 48 ff ca 48 83 fa ff 75 e1 <0f> 0b 83 7 b 20 01 0f 84 13 01 00 00 81 bd e8 00 00 00 ff 14 37 00 [5.183533] RSP: 0018:c9000111f798 EFLAGS: 00010246 [5.183534] RAX: 8883fc1d8e00 RBX: 8883f925c9c0 RCX: [5.183535] RDX: RSI: RDI: 8883f8da70c8 [5.183535] RBP: 8883fe8da000 R08: R09: 8883f724fc00 [5.183535] R10: 7fc9117f R11: 8883f925c9c0 R12: 8883f925c900 [5.183536] R13: 8883f598 R14: R15: 0001 [5.183537] FS: 7f9e31a83d80() GS:88840ec4() knlGS: [5.183537] CS: 0010 DS: ES: CR0: 80050033 [5.183538] CR2: 55fdf9ec5568 CR3: 0003fb2b6000 CR4: 00350ee0 [5.183538] Call Trace: [5.183595] dc_clk_mgr_create+0x135/0x18b [amdgpu] [5.183651] dc_create+0x238/0x5e3 [amdgpu] [5.183708] amdgpu_dm_init+0x167/0x1101 [amdgpu] [5.183762] dm_hw_init+0xa/0x17 [amdgpu] [5.183805] amdgpu_device_init+0x1566/0x1853 [amdgpu] [5.183811] ? __kmalloc+0xad/0xbf [5.183852] ? amdgpu_driver_load_kms+0x1c/0x17f [amdgpu] [5.183892] amdgpu_driver_load_kms+0x41/0x17f [amdgpu] [5.183959] amdgpu_pci_probe+0x139/0x1c0 [amdgpu] [5.183967] pci_device_probe+0xc6/0x135 [5.183971] really_probe+0x157/0x32a [5.183974] driver_probe_device+0x63/0x97 [5.183976] device_driver_attach+0x37/0x50 [5.183978] __driver_attach+0x92/0x9a [5.183980] ? device_driver_attach+0x5
Haswell Regression in 5.9-rcX and lower 5.7.x, 5.8.x #2024 - Revert 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") ?
Hi David, Chris and lists I am inquiring about the current status of #2024 [1] Problem: Kernels 5.7.x , 5.8.x, current 5.9-rcs and drm-tip have a large regression on (some?) Haswell (HSW) This is verified by _multiple people_ using different methods. All his is documented in [1] , Kernel 5.6.19 was fine Result: no output, no usable desktop due to gpu crashes Hardware : 2x Acer C720 Chromebooks and potentially others Methods: - running mpv with vaapi enabled - glxgears - automatic desktop environment start (probably with acceleration) There is atm no fix in drm-tip integrated (5.9.0_rc5bisect_g30b3e38bd6d5 for example still errors) and no activity from Intel in the bug report beside the "working" suggested patches / hacks there There should be enough bisection info an there. Nobody asked there to get more info or different bisects/trees. So - the ticket is still open. Because Fedora uses newish Kernels I would like to use it "normally" without going for 5.4 LTS or waiting an unknown amount of time - as 5.9.x currently seems to have the same regression. Affected Hardware at my end: - C720 with a Intel Celeron 2955U - UEFI Bios instead of original Bios (mrchromebox.tech) if thats relevant for hardware init related bugs; But the Kernel should take care of the correct initialization anyway Feel free to comment which trees, branches, tags or patches we should try to help and what _more_ to report for "Report-By" , "Tested-By", "Verified-By" tagging so that [1] can be closed. Greetings, Dirk [1]https://gitlab.freedesktop.org/drm/intel/-/issues/2024
Re: kworker/0:3+pm hogging CPU
Hi, meanwhile, I convinced Dell that I have a hardware issue (and not a Linux issue), and Dell has replaced the mainboard of my laptop. After that, both the USB over-current kernel messages and the kworker processes with permanent high CPU load are gone. So, this was indeed a hardware issue! Many thanks for your feedback and help! Best regards, Dirk. Am 01.09.20 um 17:27 schrieb Michal Hocko: On Mon 31-08-20 14:37:10, Mathias Nyman wrote: [...] I can't come up with any good solution to this right now. Only bad ideas such as a. Add a sleep to the over-current case, doesn't solve anything else than the ~100% cpu hogging part of the problem This sounds like a better thing from the user space point of view. I do not have any insight on what kind of other side effects this might have so I didn't dare to try that on my piece of (broken) HW. I do not see the problem all the time and I plan to replace it soon anyway. Considering that tweaking the power management helps maybe that could be done automagically after many consecutive failures. Just my 2c
Re: [PATCH v2 1/3] kconfig: error out when seeing recursive dependency
Masahiro Yamada writes:
> Originally, recursive dependency was a fatal error for Kconfig
> because Kconfig cannot compute symbol values in such a situation.
>
> Commit d595cea62403 ("kconfig: print more info when we see a recursive
> dependency") changed it to a warning, which I guess was not intentional.
>
> Get it back to an error again.
>
> Also, rename the unit test directory "warn_recursive_dep" to
> "err_recursive_dep" so that it matches to the behavior.
>
> Signed-off-by: Masahiro Yamada
I tested v2 of this series and to me it looks all good, now:
Tested-by: Dirk Gouders
> ---
>
> Changes in v2:
> - Newly added
>
> scripts/kconfig/symbol.c | 3 ---
> .../tests/{warn_recursive_dep => err_recursive_dep}/Kconfig| 0
> scripts/kconfig/tests/err_recursive_dep/__init__.py| 10
> ++
> .../{warn_recursive_dep => err_recursive_dep}/expected_stderr | 0
> scripts/kconfig/tests/warn_recursive_dep/__init__.py | 9 -
> 5 files changed, 10 insertions(+), 12 deletions(-)
> rename scripts/kconfig/tests/{warn_recursive_dep =>
> err_recursive_dep}/Kconfig (100%)
> create mode 100644 scripts/kconfig/tests/err_recursive_dep/__init__.py
> rename scripts/kconfig/tests/{warn_recursive_dep =>
> err_recursive_dep}/expected_stderr (100%)
> delete mode 100644 scripts/kconfig/tests/warn_recursive_dep/__init__.py
>
> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index 4ec8b1f..688f487 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -1248,9 +1248,6 @@ struct symbol *sym_check_deps(struct symbol *sym)
> sym->flags &= ~SYMBOL_CHECK;
> }
>
> - if (sym2 && sym2 == sym)
> - sym2 = NULL;
> -
> return sym2;
> }
>
> diff --git a/scripts/kconfig/tests/warn_recursive_dep/Kconfig
> b/scripts/kconfig/tests/err_recursive_dep/Kconfig
> similarity index 100%
> rename from scripts/kconfig/tests/warn_recursive_dep/Kconfig
> rename to scripts/kconfig/tests/err_recursive_dep/Kconfig
> diff --git a/scripts/kconfig/tests/err_recursive_dep/__init__.py
> b/scripts/kconfig/tests/err_recursive_dep/__init__.py
> new file mode 100644
> index 000..5f3821b
> --- /dev/null
> +++ b/scripts/kconfig/tests/err_recursive_dep/__init__.py
> @@ -0,0 +1,10 @@
> +# SPDX-License-Identifier: GPL-2.0
> +"""
> +Detect recursive dependency error.
> +
> +Recursive dependency should be treated as an error.
> +"""
> +
> +def test(conf):
> +assert conf.oldaskconfig() == 1
> +assert conf.stderr_contains('expected_stderr')
> diff --git a/scripts/kconfig/tests/warn_recursive_dep/expected_stderr
> b/scripts/kconfig/tests/err_recursive_dep/expected_stderr
> similarity index 100%
> rename from scripts/kconfig/tests/warn_recursive_dep/expected_stderr
> rename to scripts/kconfig/tests/err_recursive_dep/expected_stderr
> diff --git a/scripts/kconfig/tests/warn_recursive_dep/__init__.py
> b/scripts/kconfig/tests/warn_recursive_dep/__init__.py
> deleted file mode 100644
> index adb2195..000
> --- a/scripts/kconfig/tests/warn_recursive_dep/__init__.py
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -"""
> -Warn recursive inclusion.
> -
> -Recursive dependency should be warned.
> -"""
> -
> -def test(conf):
> -assert conf.oldaskconfig() == 0
> -assert conf.stderr_contains('expected_stderr')
Re: [PATCH v2 1/3] kconfig: error out when seeing recursive dependency
Masahiro Yamada writes:
> Originally, recursive dependency was a fatal error for Kconfig
> because Kconfig cannot compute symbol values in such a situation.
>
> Commit d595cea62403 ("kconfig: print more info when we see a recursive
> dependency") changed it to a warning, which I guess was not intentional.
>
> Get it back to an error again.
>
> Also, rename the unit test directory "warn_recursive_dep" to
> "err_recursive_dep" so that it matches to the behavior.
>
> Signed-off-by: Masahiro Yamada
I tested v2 of this series and to me it looks all good, now:
Tested-by: Dirk Gouders
> ---
>
> Changes in v2:
> - Newly added
>
> scripts/kconfig/symbol.c | 3 ---
> .../tests/{warn_recursive_dep => err_recursive_dep}/Kconfig| 0
> scripts/kconfig/tests/err_recursive_dep/__init__.py| 10
> ++
> .../{warn_recursive_dep => err_recursive_dep}/expected_stderr | 0
> scripts/kconfig/tests/warn_recursive_dep/__init__.py | 9 -
> 5 files changed, 10 insertions(+), 12 deletions(-)
> rename scripts/kconfig/tests/{warn_recursive_dep =>
> err_recursive_dep}/Kconfig (100%)
> create mode 100644 scripts/kconfig/tests/err_recursive_dep/__init__.py
> rename scripts/kconfig/tests/{warn_recursive_dep =>
> err_recursive_dep}/expected_stderr (100%)
> delete mode 100644 scripts/kconfig/tests/warn_recursive_dep/__init__.py
>
> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index 4ec8b1f..688f487 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -1248,9 +1248,6 @@ struct symbol *sym_check_deps(struct symbol *sym)
> sym->flags &= ~SYMBOL_CHECK;
> }
>
> - if (sym2 && sym2 == sym)
> - sym2 = NULL;
> -
> return sym2;
> }
>
> diff --git a/scripts/kconfig/tests/warn_recursive_dep/Kconfig
> b/scripts/kconfig/tests/err_recursive_dep/Kconfig
> similarity index 100%
> rename from scripts/kconfig/tests/warn_recursive_dep/Kconfig
> rename to scripts/kconfig/tests/err_recursive_dep/Kconfig
> diff --git a/scripts/kconfig/tests/err_recursive_dep/__init__.py
> b/scripts/kconfig/tests/err_recursive_dep/__init__.py
> new file mode 100644
> index 000..5f3821b
> --- /dev/null
> +++ b/scripts/kconfig/tests/err_recursive_dep/__init__.py
> @@ -0,0 +1,10 @@
> +# SPDX-License-Identifier: GPL-2.0
> +"""
> +Detect recursive dependency error.
> +
> +Recursive dependency should be treated as an error.
> +"""
> +
> +def test(conf):
> +assert conf.oldaskconfig() == 1
> +assert conf.stderr_contains('expected_stderr')
> diff --git a/scripts/kconfig/tests/warn_recursive_dep/expected_stderr
> b/scripts/kconfig/tests/err_recursive_dep/expected_stderr
> similarity index 100%
> rename from scripts/kconfig/tests/warn_recursive_dep/expected_stderr
> rename to scripts/kconfig/tests/err_recursive_dep/expected_stderr
> diff --git a/scripts/kconfig/tests/warn_recursive_dep/__init__.py
> b/scripts/kconfig/tests/warn_recursive_dep/__init__.py
> deleted file mode 100644
> index adb2195..000
> --- a/scripts/kconfig/tests/warn_recursive_dep/__init__.py
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -"""
> -Warn recursive inclusion.
> -
> -Recursive dependency should be warned.
> -"""
> -
> -def test(conf):
> -assert conf.oldaskconfig() == 0
> -assert conf.stderr_contains('expected_stderr')
Re: [PATCH 1/2] kconfig: report recursive dependency involving 'imply'
Masahiro Yamada writes: > 2018-08-14 19:38 GMT+09:00 Dirk Gouders : >> Masahiro Yamada writes: >> >>> Currently, Kconfig does not report anything about the recursive >>> dependency where 'imply' keywords are involved. >>> >>> [Test Code] >>> >>> config A >>> bool "a" >>> >>> config B >>> bool "b" >>> imply A >>> depends on A >> >> Hello Masahiro, >> >> obviously, it is hard to find a reason why one wants to use dependencies >> like above but I also wonder how e.g. menuconfig handles this case: >> >> First, only "a" is visible, if I then select "a", "b" does not become >> visible but when I then reset "a" to "n", "b" becomes visible. If I then >> try to select "b", it becomes invisible... >> >> Perhaps it would be better to just error out instead of giving users the >> impression, Kconfig thinks such questionable behavior is OK. > > > Taking closer look at the code, the intention is 'recursive dependency > is error', > but the behavior changed probably by an accident. > > I fixed this: > https://patchwork.kernel.org/patch/10566301/ > >> Side note: perhaps, the documentation could be better when it comes to >>recursive dependencies. The documentation says "select" and >>"imply" can be used to specify lower limits whereas direct >>dependencies specify upper limits for symbol values and with >>this in mind, one might wonder why it is a problem to work >>with both limits in a recursive way. >> >>Not very unlikely that it is just me who still has to >>understand recursive dependencies or problems with reading >>English text, though. > > > To avoid confusion, two things should be discussed separately: > > [1] Unmet dependency >This is caused by a conflict between the upper limit from 'depends on' >and the lower limit from 'select'. > > This issue does not happen for 'imply' because the upper limit > specified by 'imply' is weaker. > > > [2] Recursive depenency > >This can happen for any combination of 'depends on', >'select', 'imply', 'if', 'default', etc. Yes, this is probably just a subject that I still have to get a deeper understanding for, hence I am easyly confused when faced with contradicting information. >> What definitely seems to get void with your patches is item c) in >> "Practical solutions to kconfig recursive issue" in >> Documentation/kbuild/kconfig-language: >> >> c) Consider the use of "imply" instead of "select" > > > I do not know why commit 237e3ad0f195d8 added this line. > > > Actually, I was also confused. > > I sent v2 based on your feedback. Thanks for your responses, making that all more understandable. Dirk > > >> Dirk >> >>> In the code above, Kconfig cannot calculate the symbol values correctly >>> due to the circular dependency. For example, allyesconfig followed by >>> syncconfig results in an odd behavior because CONFIG_B becomes visible >>> in syncconfig. >>> >>> $ make allyesconfig >>> scripts/kconfig/conf --allyesconfig Kconfig >>> # >>> # configuration written to .config >>> # >>> $ cat .config >>> # >>> # Automatically generated file; DO NOT EDIT. >>> # Main menu >>> # >>> CONFIG_A=y >>> $ make syncconfig >>> scripts/kconfig/conf --syncconfig Kconfig >>> * >>> * Restart config... >>> * >>> * >>> * Main menu >>> * >>> a (A) [Y/n/?] y >>> b (B) [N/y/?] (NEW) >>> >>> To report this correctly, sym_check_expr_deps() should recurse to >>> not only sym->rev_dep.expr but also sym->implied.expr . >>> >>> At this moment, sym_check_print_recursive() cannot distinguish >>> 'select' and 'imply' since it does not know the precise context >>> where the recursive dependency is hit. This will be solved by >>> the next commit. >>> >>> Signed-off-by: Masahiro Yamada >>> --- >>> >>> scripts/kconfig/symbol.c | 9 +++-- >>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c >>
Re: [PATCH 1/2] kconfig: report recursive dependency involving 'imply'
Masahiro Yamada writes: > 2018-08-14 19:38 GMT+09:00 Dirk Gouders : >> Masahiro Yamada writes: >> >>> Currently, Kconfig does not report anything about the recursive >>> dependency where 'imply' keywords are involved. >>> >>> [Test Code] >>> >>> config A >>> bool "a" >>> >>> config B >>> bool "b" >>> imply A >>> depends on A >> >> Hello Masahiro, >> >> obviously, it is hard to find a reason why one wants to use dependencies >> like above but I also wonder how e.g. menuconfig handles this case: >> >> First, only "a" is visible, if I then select "a", "b" does not become >> visible but when I then reset "a" to "n", "b" becomes visible. If I then >> try to select "b", it becomes invisible... >> >> Perhaps it would be better to just error out instead of giving users the >> impression, Kconfig thinks such questionable behavior is OK. > > > Taking closer look at the code, the intention is 'recursive dependency > is error', > but the behavior changed probably by an accident. > > I fixed this: > https://patchwork.kernel.org/patch/10566301/ > >> Side note: perhaps, the documentation could be better when it comes to >>recursive dependencies. The documentation says "select" and >>"imply" can be used to specify lower limits whereas direct >>dependencies specify upper limits for symbol values and with >>this in mind, one might wonder why it is a problem to work >>with both limits in a recursive way. >> >>Not very unlikely that it is just me who still has to >>understand recursive dependencies or problems with reading >>English text, though. > > > To avoid confusion, two things should be discussed separately: > > [1] Unmet dependency >This is caused by a conflict between the upper limit from 'depends on' >and the lower limit from 'select'. > > This issue does not happen for 'imply' because the upper limit > specified by 'imply' is weaker. > > > [2] Recursive depenency > >This can happen for any combination of 'depends on', >'select', 'imply', 'if', 'default', etc. Yes, this is probably just a subject that I still have to get a deeper understanding for, hence I am easyly confused when faced with contradicting information. >> What definitely seems to get void with your patches is item c) in >> "Practical solutions to kconfig recursive issue" in >> Documentation/kbuild/kconfig-language: >> >> c) Consider the use of "imply" instead of "select" > > > I do not know why commit 237e3ad0f195d8 added this line. > > > Actually, I was also confused. > > I sent v2 based on your feedback. Thanks for your responses, making that all more understandable. Dirk > > >> Dirk >> >>> In the code above, Kconfig cannot calculate the symbol values correctly >>> due to the circular dependency. For example, allyesconfig followed by >>> syncconfig results in an odd behavior because CONFIG_B becomes visible >>> in syncconfig. >>> >>> $ make allyesconfig >>> scripts/kconfig/conf --allyesconfig Kconfig >>> # >>> # configuration written to .config >>> # >>> $ cat .config >>> # >>> # Automatically generated file; DO NOT EDIT. >>> # Main menu >>> # >>> CONFIG_A=y >>> $ make syncconfig >>> scripts/kconfig/conf --syncconfig Kconfig >>> * >>> * Restart config... >>> * >>> * >>> * Main menu >>> * >>> a (A) [Y/n/?] y >>> b (B) [N/y/?] (NEW) >>> >>> To report this correctly, sym_check_expr_deps() should recurse to >>> not only sym->rev_dep.expr but also sym->implied.expr . >>> >>> At this moment, sym_check_print_recursive() cannot distinguish >>> 'select' and 'imply' since it does not know the precise context >>> where the recursive dependency is hit. This will be solved by >>> the next commit. >>> >>> Signed-off-by: Masahiro Yamada >>> --- >>> >>> scripts/kconfig/symbol.c | 9 +++-- >>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c >>
Re: [PATCH 1/2] kconfig: report recursive dependency involving 'imply'
Dirk Gouders writes:
> Masahiro Yamada writes:
>
>> Currently, Kconfig does not report anything about the recursive
>> dependency where 'imply' keywords are involved.
>>
>> [Test Code]
>>
>> config A
>> bool "a"
>>
>> config B
>> bool "b"
>> imply A
>> depends on A
>
> Hello Masahiro,
>
> obviously, it is hard to find a reason why one wants to use dependencies
> like above but I also wonder how e.g. menuconfig handles this case:
>
> First, only "a" is visible, if I then select "a", "b" does not become
> visible but when I then reset "a" to "n", "b" becomes visible. If I then
> try to select "b", it becomes invisible...
>
> Perhaps it would be better to just error out instead of giving users the
> impression, Kconfig thinks such questionable behavior is OK.
>
> Side note: perhaps, the documentation could be better when it comes to
>recursive dependencies. The documentation says "select" and
>"imply" can be used to specify lower limits whereas direct
>dependencies specify upper limits for symbol values and with
>this in mind, one might wonder why it is a problem to work
>with both limits in a recursive way.
>
>Not very unlikely that it is just me who still has to
>understand recursive dependencies or problems with reading
>English text, though.
>
> What definitely seems to get void with your patches is item c) in
> "Practical solutions to kconfig recursive issue" in
> Documentation/kbuild/kconfig-language:
>
> c) Consider the use of "imply" instead of "select"
Just some more information that adds to me feeling unsure about the
correct definition of recursive dependencies:
With commit 29c434f367ea (kconfig: tests: test if recursive dependencies
are detected) a test case similar to the example above was introduced,
explicitely stating it is _no_ recursive dependency:
+# depends on and imply
+# This is not recursive dependency
+
+config E1
+ bool "E1"
+ depends on E2
+ imply E2
+
+config E2
+ bool "E2"
Dirk
>
>> In the code above, Kconfig cannot calculate the symbol values correctly
>> due to the circular dependency. For example, allyesconfig followed by
>> syncconfig results in an odd behavior because CONFIG_B becomes visible
>> in syncconfig.
>>
>> $ make allyesconfig
>> scripts/kconfig/conf --allyesconfig Kconfig
>> #
>> # configuration written to .config
>> #
>> $ cat .config
>> #
>> # Automatically generated file; DO NOT EDIT.
>> # Main menu
>> #
>> CONFIG_A=y
>> $ make syncconfig
>> scripts/kconfig/conf --syncconfig Kconfig
>> *
>> * Restart config...
>> *
>> *
>> * Main menu
>> *
>> a (A) [Y/n/?] y
>> b (B) [N/y/?] (NEW)
>>
>> To report this correctly, sym_check_expr_deps() should recurse to
>> not only sym->rev_dep.expr but also sym->implied.expr .
>>
>> At this moment, sym_check_print_recursive() cannot distinguish
>> 'select' and 'imply' since it does not know the precise context
>> where the recursive dependency is hit. This will be solved by
>> the next commit.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> scripts/kconfig/symbol.c | 9 +++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
>> index 4ec8b1f..7de7463a 100644
>> --- a/scripts/kconfig/symbol.c
>> +++ b/scripts/kconfig/symbol.c
>> @@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol
>> *last_sym)
>> sym->name ? sym->name : "",
>> next_sym->name ? next_sym->name : "");
>> } else {
>> -fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n",
>> +fprintf(stderr, "%s:%d:\tsymbol %s is selected or
>> implied by %s\n",
>> prop->file->name, prop->lineno,
>> sym->name ? sym->name : "",
>> next_sym->name ? next_sym->name : "");
>> @@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct
>> symbol *sym)
>> if (sym2)
>> goto out;
>>
>> +sym2 = sym_check_expr_deps(sym->implied.expr);
>> +if (sym2)
>> +goto out;
>> +
>> for (prop = sym->prop; prop; prop = prop->next) {
>> -if (prop->type == P_CHOICE || prop->type == P_SELECT)
>> +if (prop->type == P_CHOICE || prop->type == P_SELECT ||
>> +prop->type == P_IMPLY)
>> continue;
>> stack.prop = prop;
>> sym2 = sym_check_expr_deps(prop->visible.expr);
Re: [PATCH 1/2] kconfig: report recursive dependency involving 'imply'
Dirk Gouders writes:
> Masahiro Yamada writes:
>
>> Currently, Kconfig does not report anything about the recursive
>> dependency where 'imply' keywords are involved.
>>
>> [Test Code]
>>
>> config A
>> bool "a"
>>
>> config B
>> bool "b"
>> imply A
>> depends on A
>
> Hello Masahiro,
>
> obviously, it is hard to find a reason why one wants to use dependencies
> like above but I also wonder how e.g. menuconfig handles this case:
>
> First, only "a" is visible, if I then select "a", "b" does not become
> visible but when I then reset "a" to "n", "b" becomes visible. If I then
> try to select "b", it becomes invisible...
>
> Perhaps it would be better to just error out instead of giving users the
> impression, Kconfig thinks such questionable behavior is OK.
>
> Side note: perhaps, the documentation could be better when it comes to
>recursive dependencies. The documentation says "select" and
>"imply" can be used to specify lower limits whereas direct
>dependencies specify upper limits for symbol values and with
>this in mind, one might wonder why it is a problem to work
>with both limits in a recursive way.
>
>Not very unlikely that it is just me who still has to
>understand recursive dependencies or problems with reading
>English text, though.
>
> What definitely seems to get void with your patches is item c) in
> "Practical solutions to kconfig recursive issue" in
> Documentation/kbuild/kconfig-language:
>
> c) Consider the use of "imply" instead of "select"
Just some more information that adds to me feeling unsure about the
correct definition of recursive dependencies:
With commit 29c434f367ea (kconfig: tests: test if recursive dependencies
are detected) a test case similar to the example above was introduced,
explicitely stating it is _no_ recursive dependency:
+# depends on and imply
+# This is not recursive dependency
+
+config E1
+ bool "E1"
+ depends on E2
+ imply E2
+
+config E2
+ bool "E2"
Dirk
>
>> In the code above, Kconfig cannot calculate the symbol values correctly
>> due to the circular dependency. For example, allyesconfig followed by
>> syncconfig results in an odd behavior because CONFIG_B becomes visible
>> in syncconfig.
>>
>> $ make allyesconfig
>> scripts/kconfig/conf --allyesconfig Kconfig
>> #
>> # configuration written to .config
>> #
>> $ cat .config
>> #
>> # Automatically generated file; DO NOT EDIT.
>> # Main menu
>> #
>> CONFIG_A=y
>> $ make syncconfig
>> scripts/kconfig/conf --syncconfig Kconfig
>> *
>> * Restart config...
>> *
>> *
>> * Main menu
>> *
>> a (A) [Y/n/?] y
>> b (B) [N/y/?] (NEW)
>>
>> To report this correctly, sym_check_expr_deps() should recurse to
>> not only sym->rev_dep.expr but also sym->implied.expr .
>>
>> At this moment, sym_check_print_recursive() cannot distinguish
>> 'select' and 'imply' since it does not know the precise context
>> where the recursive dependency is hit. This will be solved by
>> the next commit.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> scripts/kconfig/symbol.c | 9 +++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
>> index 4ec8b1f..7de7463a 100644
>> --- a/scripts/kconfig/symbol.c
>> +++ b/scripts/kconfig/symbol.c
>> @@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol
>> *last_sym)
>> sym->name ? sym->name : "",
>> next_sym->name ? next_sym->name : "");
>> } else {
>> -fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n",
>> +fprintf(stderr, "%s:%d:\tsymbol %s is selected or
>> implied by %s\n",
>> prop->file->name, prop->lineno,
>> sym->name ? sym->name : "",
>> next_sym->name ? next_sym->name : "");
>> @@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct
>> symbol *sym)
>> if (sym2)
>> goto out;
>>
>> +sym2 = sym_check_expr_deps(sym->implied.expr);
>> +if (sym2)
>> +goto out;
>> +
>> for (prop = sym->prop; prop; prop = prop->next) {
>> -if (prop->type == P_CHOICE || prop->type == P_SELECT)
>> +if (prop->type == P_CHOICE || prop->type == P_SELECT ||
>> +prop->type == P_IMPLY)
>> continue;
>> stack.prop = prop;
>> sym2 = sym_check_expr_deps(prop->visible.expr);
Re: [PATCH 1/2] kconfig: report recursive dependency involving 'imply'
Masahiro Yamada writes:
> Currently, Kconfig does not report anything about the recursive
> dependency where 'imply' keywords are involved.
>
> [Test Code]
>
> config A
> bool "a"
>
> config B
> bool "b"
> imply A
> depends on A
Hello Masahiro,
obviously, it is hard to find a reason why one wants to use dependencies
like above but I also wonder how e.g. menuconfig handles this case:
First, only "a" is visible, if I then select "a", "b" does not become
visible but when I then reset "a" to "n", "b" becomes visible. If I then
try to select "b", it becomes invisible...
Perhaps it would be better to just error out instead of giving users the
impression, Kconfig thinks such questionable behavior is OK.
Side note: perhaps, the documentation could be better when it comes to
recursive dependencies. The documentation says "select" and
"imply" can be used to specify lower limits whereas direct
dependencies specify upper limits for symbol values and with
this in mind, one might wonder why it is a problem to work
with both limits in a recursive way.
Not very unlikely that it is just me who still has to
understand recursive dependencies or problems with reading
English text, though.
What definitely seems to get void with your patches is item c) in
"Practical solutions to kconfig recursive issue" in
Documentation/kbuild/kconfig-language:
c) Consider the use of "imply" instead of "select"
Dirk
> In the code above, Kconfig cannot calculate the symbol values correctly
> due to the circular dependency. For example, allyesconfig followed by
> syncconfig results in an odd behavior because CONFIG_B becomes visible
> in syncconfig.
>
> $ make allyesconfig
> scripts/kconfig/conf --allyesconfig Kconfig
> #
> # configuration written to .config
> #
> $ cat .config
> #
> # Automatically generated file; DO NOT EDIT.
> # Main menu
> #
> CONFIG_A=y
> $ make syncconfig
> scripts/kconfig/conf --syncconfig Kconfig
> *
> * Restart config...
> *
> *
> * Main menu
> *
> a (A) [Y/n/?] y
> b (B) [N/y/?] (NEW)
>
> To report this correctly, sym_check_expr_deps() should recurse to
> not only sym->rev_dep.expr but also sym->implied.expr .
>
> At this moment, sym_check_print_recursive() cannot distinguish
> 'select' and 'imply' since it does not know the precise context
> where the recursive dependency is hit. This will be solved by
> the next commit.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/symbol.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index 4ec8b1f..7de7463a 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol
> *last_sym)
> sym->name ? sym->name : "",
> next_sym->name ? next_sym->name : "");
> } else {
> - fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n",
> + fprintf(stderr, "%s:%d:\tsymbol %s is selected or
> implied by %s\n",
> prop->file->name, prop->lineno,
> sym->name ? sym->name : "",
> next_sym->name ? next_sym->name : "");
> @@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct symbol
> *sym)
> if (sym2)
> goto out;
>
> + sym2 = sym_check_expr_deps(sym->implied.expr);
> + if (sym2)
> + goto out;
> +
> for (prop = sym->prop; prop; prop = prop->next) {
> - if (prop->type == P_CHOICE || prop->type == P_SELECT)
> + if (prop->type == P_CHOICE || prop->type == P_SELECT ||
> + prop->type == P_IMPLY)
> continue;
> stack.prop = prop;
> sym2 = sym_check_expr_deps(prop->visible.expr);
Re: [PATCH 1/2] kconfig: report recursive dependency involving 'imply'
Masahiro Yamada writes:
> Currently, Kconfig does not report anything about the recursive
> dependency where 'imply' keywords are involved.
>
> [Test Code]
>
> config A
> bool "a"
>
> config B
> bool "b"
> imply A
> depends on A
Hello Masahiro,
obviously, it is hard to find a reason why one wants to use dependencies
like above but I also wonder how e.g. menuconfig handles this case:
First, only "a" is visible, if I then select "a", "b" does not become
visible but when I then reset "a" to "n", "b" becomes visible. If I then
try to select "b", it becomes invisible...
Perhaps it would be better to just error out instead of giving users the
impression, Kconfig thinks such questionable behavior is OK.
Side note: perhaps, the documentation could be better when it comes to
recursive dependencies. The documentation says "select" and
"imply" can be used to specify lower limits whereas direct
dependencies specify upper limits for symbol values and with
this in mind, one might wonder why it is a problem to work
with both limits in a recursive way.
Not very unlikely that it is just me who still has to
understand recursive dependencies or problems with reading
English text, though.
What definitely seems to get void with your patches is item c) in
"Practical solutions to kconfig recursive issue" in
Documentation/kbuild/kconfig-language:
c) Consider the use of "imply" instead of "select"
Dirk
> In the code above, Kconfig cannot calculate the symbol values correctly
> due to the circular dependency. For example, allyesconfig followed by
> syncconfig results in an odd behavior because CONFIG_B becomes visible
> in syncconfig.
>
> $ make allyesconfig
> scripts/kconfig/conf --allyesconfig Kconfig
> #
> # configuration written to .config
> #
> $ cat .config
> #
> # Automatically generated file; DO NOT EDIT.
> # Main menu
> #
> CONFIG_A=y
> $ make syncconfig
> scripts/kconfig/conf --syncconfig Kconfig
> *
> * Restart config...
> *
> *
> * Main menu
> *
> a (A) [Y/n/?] y
> b (B) [N/y/?] (NEW)
>
> To report this correctly, sym_check_expr_deps() should recurse to
> not only sym->rev_dep.expr but also sym->implied.expr .
>
> At this moment, sym_check_print_recursive() cannot distinguish
> 'select' and 'imply' since it does not know the precise context
> where the recursive dependency is hit. This will be solved by
> the next commit.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/symbol.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index 4ec8b1f..7de7463a 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol
> *last_sym)
> sym->name ? sym->name : "",
> next_sym->name ? next_sym->name : "");
> } else {
> - fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n",
> + fprintf(stderr, "%s:%d:\tsymbol %s is selected or
> implied by %s\n",
> prop->file->name, prop->lineno,
> sym->name ? sym->name : "",
> next_sym->name ? next_sym->name : "");
> @@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct symbol
> *sym)
> if (sym2)
> goto out;
>
> + sym2 = sym_check_expr_deps(sym->implied.expr);
> + if (sym2)
> + goto out;
> +
> for (prop = sym->prop; prop; prop = prop->next) {
> - if (prop->type == P_CHOICE || prop->type == P_SELECT)
> + if (prop->type == P_CHOICE || prop->type == P_SELECT ||
> + prop->type == P_IMPLY)
> continue;
> stack.prop = prop;
> sym2 = sym_check_expr_deps(prop->visible.expr);
[PATCH] Kbuild: Makefile.modbuiltin: include auto.conf and tristate.conf mandatory
The files auto.conf and tristate.conf are mandatory for building modules.builtin files, therefore include them as such. Usually, the top-level Makefile ensures that those files exist but we want to make sure we get noticed if they are missing for whatever reason. Signed-off-by: Dirk Gouders --- scripts/Makefile.modbuiltin | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.modbuiltin b/scripts/Makefile.modbuiltin index 40867a41615b..a072a4267746 100644 --- a/scripts/Makefile.modbuiltin +++ b/scripts/Makefile.modbuiltin @@ -8,10 +8,10 @@ src := $(obj) PHONY := __modbuiltin __modbuiltin: --include include/config/auto.conf +include include/config/auto.conf # tristate.conf sets tristate variables to uppercase 'Y' or 'M' # That way, we get the list of built-in modules in obj-Y --include include/config/tristate.conf +include include/config/tristate.conf include scripts/Kbuild.include -- 2.16.4
[PATCH] Kbuild: Makefile.modbuiltin: include auto.conf and tristate.conf mandatory
The files auto.conf and tristate.conf are mandatory for building modules.builtin files, therefore include them as such. Usually, the top-level Makefile ensures that those files exist but we want to make sure we get noticed if they are missing for whatever reason. Signed-off-by: Dirk Gouders --- scripts/Makefile.modbuiltin | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.modbuiltin b/scripts/Makefile.modbuiltin index 40867a41615b..a072a4267746 100644 --- a/scripts/Makefile.modbuiltin +++ b/scripts/Makefile.modbuiltin @@ -8,10 +8,10 @@ src := $(obj) PHONY := __modbuiltin __modbuiltin: --include include/config/auto.conf +include include/config/auto.conf # tristate.conf sets tristate variables to uppercase 'Y' or 'M' # That way, we get the list of built-in modules in obj-Y --include include/config/tristate.conf +include include/config/tristate.conf include scripts/Kbuild.include -- 2.16.4
[PATCH] arm64: Check for errata before evaluating cpu features
From: Dirk Mueller
Since commit d3aec8a28be3b8 ("arm64: capabilities: Restrict KPTI
detection to boot-time CPUs") we rely on errata flags being already
populated during feature enumeration. The order of errata and
features was flipped as part of commit ed478b3f9e4a ("arm64:
capabilities: Group handling of features and errata workarounds").
Return to the orginal order of errata and feature evaluation to
ensure errata flags are present during feature evaluation.
Fixes: ed478b3f9e4a ("arm64: capabilities: Group handling of
features and errata workarounds")
CC: Suzuki K Poulose
CC: Marc Zyngier
Signed-off-by: Dirk Mueller
Reviewed-by: Suzuki K Poulose
---
arch/arm64/kernel/cpufeature.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index f24892a40d2c..c6d80743f4ed 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1351,9 +1351,9 @@ static void __update_cpu_capabilities(const struct
arm64_cpu_capabilities *caps,
static void update_cpu_capabilities(u16 scope_mask)
{
- __update_cpu_capabilities(arm64_features, scope_mask, "detected:");
__update_cpu_capabilities(arm64_errata, scope_mask,
"enabling workaround for");
+ __update_cpu_capabilities(arm64_features, scope_mask, "detected:");
}
static int __enable_cpu_capability(void *arg)
@@ -1408,8 +1408,8 @@ __enable_cpu_capabilities(const struct
arm64_cpu_capabilities *caps,
static void __init enable_cpu_capabilities(u16 scope_mask)
{
- __enable_cpu_capabilities(arm64_features, scope_mask);
__enable_cpu_capabilities(arm64_errata, scope_mask);
+ __enable_cpu_capabilities(arm64_features, scope_mask);
}
/*
--
2.18.0
[PATCH] arm64: Check for errata before evaluating cpu features
From: Dirk Mueller
Since commit d3aec8a28be3b8 ("arm64: capabilities: Restrict KPTI
detection to boot-time CPUs") we rely on errata flags being already
populated during feature enumeration. The order of errata and
features was flipped as part of commit ed478b3f9e4a ("arm64:
capabilities: Group handling of features and errata workarounds").
Return to the orginal order of errata and feature evaluation to
ensure errata flags are present during feature evaluation.
Fixes: ed478b3f9e4a ("arm64: capabilities: Group handling of
features and errata workarounds")
CC: Suzuki K Poulose
CC: Marc Zyngier
Signed-off-by: Dirk Mueller
Reviewed-by: Suzuki K Poulose
---
arch/arm64/kernel/cpufeature.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index f24892a40d2c..c6d80743f4ed 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1351,9 +1351,9 @@ static void __update_cpu_capabilities(const struct
arm64_cpu_capabilities *caps,
static void update_cpu_capabilities(u16 scope_mask)
{
- __update_cpu_capabilities(arm64_features, scope_mask, "detected:");
__update_cpu_capabilities(arm64_errata, scope_mask,
"enabling workaround for");
+ __update_cpu_capabilities(arm64_features, scope_mask, "detected:");
}
static int __enable_cpu_capability(void *arg)
@@ -1408,8 +1408,8 @@ __enable_cpu_capabilities(const struct
arm64_cpu_capabilities *caps,
static void __init enable_cpu_capabilities(u16 scope_mask)
{
- __enable_cpu_capabilities(arm64_features, scope_mask);
__enable_cpu_capabilities(arm64_errata, scope_mask);
+ __enable_cpu_capabilities(arm64_features, scope_mask);
}
/*
--
2.18.0
[PATCH] arm64: Check for errata before evaluating cpu features
Since commit d3aec8a28be3b8 ("arm64: capabilities: Restrict KPTI
detection to boot-time CPUs") we rely on errata flags being already
populated during feature enumeration. The order of errata and
features was flipped as part of commit ed478b3f9e4a ("arm64:
capabilities: Group handling of features and errata workarounds").
Return to the orginal order of errata and feature evaluation to
ensure errata flags are present during feature evaluation.
Fixes: d3aec8a28be3b8 ("arm64: capabilities: Restrict KPTI
detection to boot-time CPUs")
CC: Suzuki K Poulose
CC: Marc Zyngier
Signed-off-by: Dirk Mueller
---
arch/arm64/kernel/cpufeature.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index f24892a40d2c..c6d80743f4ed 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1351,9 +1351,9 @@ static void __update_cpu_capabilities(const struct
arm64_cpu_capabilities *caps,
static void update_cpu_capabilities(u16 scope_mask)
{
- __update_cpu_capabilities(arm64_features, scope_mask, "detected:");
__update_cpu_capabilities(arm64_errata, scope_mask,
"enabling workaround for");
+ __update_cpu_capabilities(arm64_features, scope_mask, "detected:");
}
static int __enable_cpu_capability(void *arg)
@@ -1408,8 +1408,8 @@ __enable_cpu_capabilities(const struct
arm64_cpu_capabilities *caps,
static void __init enable_cpu_capabilities(u16 scope_mask)
{
- __enable_cpu_capabilities(arm64_features, scope_mask);
__enable_cpu_capabilities(arm64_errata, scope_mask);
+ __enable_cpu_capabilities(arm64_features, scope_mask);
}
/*
--
2.18.0
[PATCH] arm64: Check for errata before evaluating cpu features
Since commit d3aec8a28be3b8 ("arm64: capabilities: Restrict KPTI
detection to boot-time CPUs") we rely on errata flags being already
populated during feature enumeration. The order of errata and
features was flipped as part of commit ed478b3f9e4a ("arm64:
capabilities: Group handling of features and errata workarounds").
Return to the orginal order of errata and feature evaluation to
ensure errata flags are present during feature evaluation.
Fixes: d3aec8a28be3b8 ("arm64: capabilities: Restrict KPTI
detection to boot-time CPUs")
CC: Suzuki K Poulose
CC: Marc Zyngier
Signed-off-by: Dirk Mueller
---
arch/arm64/kernel/cpufeature.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index f24892a40d2c..c6d80743f4ed 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1351,9 +1351,9 @@ static void __update_cpu_capabilities(const struct
arm64_cpu_capabilities *caps,
static void update_cpu_capabilities(u16 scope_mask)
{
- __update_cpu_capabilities(arm64_features, scope_mask, "detected:");
__update_cpu_capabilities(arm64_errata, scope_mask,
"enabling workaround for");
+ __update_cpu_capabilities(arm64_features, scope_mask, "detected:");
}
static int __enable_cpu_capability(void *arg)
@@ -1408,8 +1408,8 @@ __enable_cpu_capabilities(const struct
arm64_cpu_capabilities *caps,
static void __init enable_cpu_capabilities(u16 scope_mask)
{
- __enable_cpu_capabilities(arm64_features, scope_mask);
__enable_cpu_capabilities(arm64_errata, scope_mask);
+ __enable_cpu_capabilities(arm64_features, scope_mask);
}
/*
--
2.18.0
Re: [PATCH 4/9] kconfig: include common Kconfig files from top-level Kconfig
Christoph Hellwig writes:
> On Wed, Jul 18, 2018 at 12:06:26AM -0700, Randy Dunlap wrote:
>> All $ARCH look equivalent except for microblaze and nios2.
>> For those, the config SWAP in init/Kconfig (line 221) comes before (and
>> hence takes precedence) over arch/$(SRCARCH)/Kconfig settings, which is
>> def_bool n for both microblaze and nios2.
>
> Both of those are NOMMU architectures, so the default SWAP
> decaration should do the right thing.
>
> I wish the kconfig tools could warn about duplicate symbols, as they
> are basically always bogus or at least very problematic.
Your wish is our command ;-)
A big but: duplicate symbol definitions are explicitely allowed by the
kconfig language, so you find most of those duplicates are actually just
varying dependencies or default values. At least, it is interesting to
see how "duplicate" symbol definitions are used and perhaps this helps
you with your reordering.
This is just a prototype, that hopefully helps with your current task,
so I did not pay too much attention to make it beautiful. Please let me
know if anything is missing.
Anyway, apply the patch and then invoke "make symcheckconfig" at the
top-level directory.
Dirk
> I've update the kconfig-cleanup branch in git with the fixes, but
> I didn't have time to do anything but a trivial x86 test yet.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index a3ac2c91331c..52a0ee0637e9 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -222,3 +222,8 @@ $(obj)/.%conf-cfg: $(src)/%conf-cfg.sh FORCE
$(call filechk,conf_cfg)
clean-files += .*conf-cfg
+
+PHONY += symcheckconfig
+
+symcheckconfig: $(obj)/conf
+ $< $(silent) --$@ $(Kconfig)
diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 671ff5364497..1083ddcdd05e 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -33,6 +33,7 @@ enum input_mode {
savedefconfig,
listnewconfig,
olddefconfig,
+ symcheckconfig,
};
static enum input_mode input_mode = oldaskconfig;
@@ -466,6 +467,7 @@ static struct option long_opts[] = {
* value but not 'n') with the counter-intuitive name.
*/
{"oldnoconfig", no_argument, NULL, olddefconfig},
+ {"symcheckconfig", no_argument, NULL, symcheckconfig},
{NULL, 0, NULL, 0}
};
@@ -490,6 +492,31 @@ static void conf_usage(const char *progname)
printf(" --randconfigNew config with random answer to all
options\n");
}
+static void find_sym_dups(void)
+{
+ struct symbol *sym;
+ struct property *prop;
+ int i;
+ int cnt = 0;
+ char *file;
+ int lineno;
+
+ for_all_symbols(i, sym) {
+ for_all_properties(sym, prop, P_SYMBOL) {
+ if (cnt == 1) {
+ printf("Duplicate symbol %s\n\t(%s:%d):\n",
sym->name, file, lineno);
+ }
+ if (cnt)
+ printf("\t(%s:%d)\n", prop->file->name,
prop->lineno);
+
+ cnt += 1;
+ file = (char *)prop->file->name;
+ lineno = prop->lineno;
+ }
+ cnt = 0;
+ }
+}
+
int main(int ac, char **av)
{
const char *progname = av[0];
@@ -560,6 +587,12 @@ int main(int ac, char **av)
}
name = av[optind];
conf_parse(name);
+
+ if (input_mode == symcheckconfig) {
+ find_sym_dups();
+ exit(0);
+ }
+
//zconfdump(stdout);
if (sync_kconfig) {
name = conf_get_configname();
Re: [PATCH 4/9] kconfig: include common Kconfig files from top-level Kconfig
Christoph Hellwig writes:
> On Wed, Jul 18, 2018 at 12:06:26AM -0700, Randy Dunlap wrote:
>> All $ARCH look equivalent except for microblaze and nios2.
>> For those, the config SWAP in init/Kconfig (line 221) comes before (and
>> hence takes precedence) over arch/$(SRCARCH)/Kconfig settings, which is
>> def_bool n for both microblaze and nios2.
>
> Both of those are NOMMU architectures, so the default SWAP
> decaration should do the right thing.
>
> I wish the kconfig tools could warn about duplicate symbols, as they
> are basically always bogus or at least very problematic.
Your wish is our command ;-)
A big but: duplicate symbol definitions are explicitely allowed by the
kconfig language, so you find most of those duplicates are actually just
varying dependencies or default values. At least, it is interesting to
see how "duplicate" symbol definitions are used and perhaps this helps
you with your reordering.
This is just a prototype, that hopefully helps with your current task,
so I did not pay too much attention to make it beautiful. Please let me
know if anything is missing.
Anyway, apply the patch and then invoke "make symcheckconfig" at the
top-level directory.
Dirk
> I've update the kconfig-cleanup branch in git with the fixes, but
> I didn't have time to do anything but a trivial x86 test yet.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index a3ac2c91331c..52a0ee0637e9 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -222,3 +222,8 @@ $(obj)/.%conf-cfg: $(src)/%conf-cfg.sh FORCE
$(call filechk,conf_cfg)
clean-files += .*conf-cfg
+
+PHONY += symcheckconfig
+
+symcheckconfig: $(obj)/conf
+ $< $(silent) --$@ $(Kconfig)
diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 671ff5364497..1083ddcdd05e 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -33,6 +33,7 @@ enum input_mode {
savedefconfig,
listnewconfig,
olddefconfig,
+ symcheckconfig,
};
static enum input_mode input_mode = oldaskconfig;
@@ -466,6 +467,7 @@ static struct option long_opts[] = {
* value but not 'n') with the counter-intuitive name.
*/
{"oldnoconfig", no_argument, NULL, olddefconfig},
+ {"symcheckconfig", no_argument, NULL, symcheckconfig},
{NULL, 0, NULL, 0}
};
@@ -490,6 +492,31 @@ static void conf_usage(const char *progname)
printf(" --randconfigNew config with random answer to all
options\n");
}
+static void find_sym_dups(void)
+{
+ struct symbol *sym;
+ struct property *prop;
+ int i;
+ int cnt = 0;
+ char *file;
+ int lineno;
+
+ for_all_symbols(i, sym) {
+ for_all_properties(sym, prop, P_SYMBOL) {
+ if (cnt == 1) {
+ printf("Duplicate symbol %s\n\t(%s:%d):\n",
sym->name, file, lineno);
+ }
+ if (cnt)
+ printf("\t(%s:%d)\n", prop->file->name,
prop->lineno);
+
+ cnt += 1;
+ file = (char *)prop->file->name;
+ lineno = prop->lineno;
+ }
+ cnt = 0;
+ }
+}
+
int main(int ac, char **av)
{
const char *progname = av[0];
@@ -560,6 +587,12 @@ int main(int ac, char **av)
}
name = av[optind];
conf_parse(name);
+
+ if (input_mode == symcheckconfig) {
+ find_sym_dups();
+ exit(0);
+ }
+
//zconfdump(stdout);
if (sync_kconfig) {
name = conf_get_configname();
[PATCH v2] checkpatch: kbuild: if_changed: check for multiple calls in targets
The kbuild function if_changed should not be called more than once for
a target.
Because that function writes the command line to a .cmd file for later
tests, multiple calls of it within a target would result in overwrites
of previous values and effectively render the command line test
meaningless, resulting in flip-flop behaviour.
Add a check for makefiles and kbuild files and produce an error for
targets with multiple calls to if_changed.
Three examples that now could be detected:
98f78525371b55ccd (x86/boot: Refuse to build with data relocations)
6a8dfe1cac5c591ae (microblaze: support U-BOOT image format)
684151a75bf25f5ae (sparc32: added U-Boot build target: uImage)
Reviewed-by: Joe Perches
Suggested-by: Masahiro Yamada
Signed-off-by: Dirk Gouders
---
v2: rework commit message and regular expression
---
scripts/checkpatch.pl | 8
1 file changed, 8 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 447857ffaf6b..437e98414f74 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2911,6 +2911,14 @@ sub process {
"Use of $flag is deprecated, please use
\`$replacement->{$flag} instead.\n" . $herecurr) if ($replacement->{$flag});
}
+ # Check for multiple calls of if_changed within a target in
Makefiles
+ if (($realfile =~ /Makefile.*/ || $realfile =~ /Kbuild.*/) &&
+ ($prevline =~ /^[ +]\t\s*\$\(call\s+if_changed,/) &&
+ ($line =~ /^[ +]\t\s*\$\(call\s+if_changed,/)) {
+ ERROR("MULTIPLE_IF_CHANGED",
+ "Multiple calls of if_changed within a
target.\n" . $herecurr);
+ }
+
# check for DT compatible documentation
if (defined $root &&
(($realfile =~ /\.dtsi?$/ && $line =~
/^\+\s*compatible\s*=\s*\"/) ||
--
2.16.1
[PATCH v2] checkpatch: kbuild: if_changed: check for multiple calls in targets
The kbuild function if_changed should not be called more than once for
a target.
Because that function writes the command line to a .cmd file for later
tests, multiple calls of it within a target would result in overwrites
of previous values and effectively render the command line test
meaningless, resulting in flip-flop behaviour.
Add a check for makefiles and kbuild files and produce an error for
targets with multiple calls to if_changed.
Three examples that now could be detected:
98f78525371b55ccd (x86/boot: Refuse to build with data relocations)
6a8dfe1cac5c591ae (microblaze: support U-BOOT image format)
684151a75bf25f5ae (sparc32: added U-Boot build target: uImage)
Reviewed-by: Joe Perches
Suggested-by: Masahiro Yamada
Signed-off-by: Dirk Gouders
---
v2: rework commit message and regular expression
---
scripts/checkpatch.pl | 8
1 file changed, 8 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 447857ffaf6b..437e98414f74 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2911,6 +2911,14 @@ sub process {
"Use of $flag is deprecated, please use
\`$replacement->{$flag} instead.\n" . $herecurr) if ($replacement->{$flag});
}
+ # Check for multiple calls of if_changed within a target in
Makefiles
+ if (($realfile =~ /Makefile.*/ || $realfile =~ /Kbuild.*/) &&
+ ($prevline =~ /^[ +]\t\s*\$\(call\s+if_changed,/) &&
+ ($line =~ /^[ +]\t\s*\$\(call\s+if_changed,/)) {
+ ERROR("MULTIPLE_IF_CHANGED",
+ "Multiple calls of if_changed within a
target.\n" . $herecurr);
+ }
+
# check for DT compatible documentation
if (defined $root &&
(($realfile =~ /\.dtsi?$/ && $line =~
/^\+\s*compatible\s*=\s*\"/) ||
--
2.16.1
Re: [PATCH] kconfig: handle format string before calling conf_message_callback()
Masahiro Yamada writes:
> As you see in mconf.c and nconf.c, conf_message_callback() hooks are
> likely to end up with the boilerplate of vsnprintf(). Process the
> string format before calling conf_message_callback() so that it
> receives a simple string.
I looked at and tested this patch and found no issues -- perhaps: except
that it seems to require another series:
kbuild/kconfig: do not update config during installation
Dirk
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/confdata.c | 17 +++--
> scripts/kconfig/lkc_proto.h | 2 +-
> scripts/kconfig/mconf.c | 9 +++--
> scripts/kconfig/nconf.c | 7 ++-
> 4 files changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index 5af25a0..d0988a9 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
> @@ -105,16 +105,16 @@ static void conf_warning(const char *fmt, ...)
> conf_warnings++;
> }
>
> -static void conf_default_message_callback(const char *fmt, va_list ap)
> +static void conf_default_message_callback(const char *s)
> {
> printf("#\n# ");
> - vprintf(fmt, ap);
> + printf("%s", s);
> printf("\n#\n");
> }
>
> -static void (*conf_message_callback) (const char *fmt, va_list ap) =
> +static void (*conf_message_callback)(const char *s) =
> conf_default_message_callback;
> -void conf_set_message_callback(void (*fn) (const char *fmt, va_list ap))
> +void conf_set_message_callback(void (*fn)(const char *s))
> {
> conf_message_callback = fn;
> }
> @@ -122,10 +122,15 @@ void conf_set_message_callback(void (*fn) (const char
> *fmt, va_list ap))
> static void conf_message(const char *fmt, ...)
> {
> va_list ap;
> + char buf[4096];
> +
> + if (!conf_message_callback)
> + return;
>
> va_start(ap, fmt);
> - if (conf_message_callback)
> - conf_message_callback(fmt, ap);
> +
> + vsnprintf(buf, sizeof(buf), fmt, ap);
> + conf_message_callback(buf);
> va_end(ap);
> }
>
> diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
> index b0cd52f..86c2675 100644
> --- a/scripts/kconfig/lkc_proto.h
> +++ b/scripts/kconfig/lkc_proto.h
> @@ -10,7 +10,7 @@ int conf_write(const char *name);
> int conf_write_autoconf(int overwrite);
> bool conf_get_changed(void);
> void conf_set_changed_callback(void (*fn)(void));
> -void conf_set_message_callback(void (*fn)(const char *fmt, va_list ap));
> +void conf_set_message_callback(void (*fn)(const char *s));
>
> /* menu.c */
> extern struct menu rootmenu;
> diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
> index 82b27a0..83b5836 100644
> --- a/scripts/kconfig/mconf.c
> +++ b/scripts/kconfig/mconf.c
> @@ -772,16 +772,13 @@ static void show_helptext(const char *title, const char
> *text)
> show_textbox(title, text, 0, 0);
> }
>
> -static void conf_message_callback(const char *fmt, va_list ap)
> +static void conf_message_callback(const char *s)
> {
> - char buf[PATH_MAX+1];
> -
> - vsnprintf(buf, sizeof(buf), fmt, ap);
> if (save_and_exit) {
> if (!silent)
> - printf("%s", buf);
> + printf("%s", s);
> } else {
> - show_textbox(NULL, buf, 6, 60);
> + show_textbox(NULL, s, 6, 60);
> }
> }
>
> diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
> index 208f7be..1ef232a 100644
> --- a/scripts/kconfig/nconf.c
> +++ b/scripts/kconfig/nconf.c
> @@ -1211,12 +1211,9 @@ static void conf(struct menu *menu)
> }
> }
>
> -static void conf_message_callback(const char *fmt, va_list ap)
> +static void conf_message_callback(const char *s)
> {
> - char buf[1024];
> -
> - vsnprintf(buf, sizeof(buf), fmt, ap);
> - btn_dialog(main_window, buf, 1, "");
> + btn_dialog(main_window, s, 1, "");
> }
>
> static void show_help(struct menu *menu)
Re: [PATCH] kconfig: handle format string before calling conf_message_callback()
Masahiro Yamada writes:
> As you see in mconf.c and nconf.c, conf_message_callback() hooks are
> likely to end up with the boilerplate of vsnprintf(). Process the
> string format before calling conf_message_callback() so that it
> receives a simple string.
I looked at and tested this patch and found no issues -- perhaps: except
that it seems to require another series:
kbuild/kconfig: do not update config during installation
Dirk
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/confdata.c | 17 +++--
> scripts/kconfig/lkc_proto.h | 2 +-
> scripts/kconfig/mconf.c | 9 +++--
> scripts/kconfig/nconf.c | 7 ++-
> 4 files changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index 5af25a0..d0988a9 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
> @@ -105,16 +105,16 @@ static void conf_warning(const char *fmt, ...)
> conf_warnings++;
> }
>
> -static void conf_default_message_callback(const char *fmt, va_list ap)
> +static void conf_default_message_callback(const char *s)
> {
> printf("#\n# ");
> - vprintf(fmt, ap);
> + printf("%s", s);
> printf("\n#\n");
> }
>
> -static void (*conf_message_callback) (const char *fmt, va_list ap) =
> +static void (*conf_message_callback)(const char *s) =
> conf_default_message_callback;
> -void conf_set_message_callback(void (*fn) (const char *fmt, va_list ap))
> +void conf_set_message_callback(void (*fn)(const char *s))
> {
> conf_message_callback = fn;
> }
> @@ -122,10 +122,15 @@ void conf_set_message_callback(void (*fn) (const char
> *fmt, va_list ap))
> static void conf_message(const char *fmt, ...)
> {
> va_list ap;
> + char buf[4096];
> +
> + if (!conf_message_callback)
> + return;
>
> va_start(ap, fmt);
> - if (conf_message_callback)
> - conf_message_callback(fmt, ap);
> +
> + vsnprintf(buf, sizeof(buf), fmt, ap);
> + conf_message_callback(buf);
> va_end(ap);
> }
>
> diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
> index b0cd52f..86c2675 100644
> --- a/scripts/kconfig/lkc_proto.h
> +++ b/scripts/kconfig/lkc_proto.h
> @@ -10,7 +10,7 @@ int conf_write(const char *name);
> int conf_write_autoconf(int overwrite);
> bool conf_get_changed(void);
> void conf_set_changed_callback(void (*fn)(void));
> -void conf_set_message_callback(void (*fn)(const char *fmt, va_list ap));
> +void conf_set_message_callback(void (*fn)(const char *s));
>
> /* menu.c */
> extern struct menu rootmenu;
> diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
> index 82b27a0..83b5836 100644
> --- a/scripts/kconfig/mconf.c
> +++ b/scripts/kconfig/mconf.c
> @@ -772,16 +772,13 @@ static void show_helptext(const char *title, const char
> *text)
> show_textbox(title, text, 0, 0);
> }
>
> -static void conf_message_callback(const char *fmt, va_list ap)
> +static void conf_message_callback(const char *s)
> {
> - char buf[PATH_MAX+1];
> -
> - vsnprintf(buf, sizeof(buf), fmt, ap);
> if (save_and_exit) {
> if (!silent)
> - printf("%s", buf);
> + printf("%s", s);
> } else {
> - show_textbox(NULL, buf, 6, 60);
> + show_textbox(NULL, s, 6, 60);
> }
> }
>
> diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
> index 208f7be..1ef232a 100644
> --- a/scripts/kconfig/nconf.c
> +++ b/scripts/kconfig/nconf.c
> @@ -1211,12 +1211,9 @@ static void conf(struct menu *menu)
> }
> }
>
> -static void conf_message_callback(const char *fmt, va_list ap)
> +static void conf_message_callback(const char *s)
> {
> - char buf[1024];
> -
> - vsnprintf(buf, sizeof(buf), fmt, ap);
> - btn_dialog(main_window, buf, 1, "");
> + btn_dialog(main_window, s, 1, "");
> }
>
> static void show_help(struct menu *menu)
Re: [PATCH] checkpatch: if_changed: check for multiple calls in targets
Joe Perches writes:
> On Mon, 2018-07-16 at 14:39 +0200, Dirk Gouders wrote:
>> Because the kbuild function if_changed writes the command line to a
>> .cmd file for later tests, multiple calls of that function within a
>> target would result in overwrites of previous values and effectively
>> render the command line test meaningless, resulting in flip-flop
>> behaviour.
>>
>> Produce an error for targets with multiple calls to if_changed.
>
> Hi. Some questions:
>
> How is the existing use in arch/microblaze/boot/Makefile incorrect?
>
> $(obj)/simpleImage.%: vmlinux FORCE
> $(call if_changed,cp,.unstrip)
> $(call if_changed,objcopy)
> $(call if_changed,uimage)
> $(call if_changed,strip,.strip)
> @echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')'
Hi Joe,
thank you for the review.
Perhaps I should have started the commit message with:
"The kbuild function if_changed should not be called more than once for a
target." and then the explanatory text.
In case you are interested in the thread where Masahiro explained in detail the
real issues with those Makefiles that made them use if_changed too often:
https://marc.info/?l=linux-kernel=153149389303034=2
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
>> @@ -2911,6 +2911,14 @@ sub process {
>> "Use of $flag is deprecated, please use
>> \`$replacement->{$flag} instead.\n" . $herecurr) if ($replacement->{$flag});
>> }
>> i
>> +# Check for multiple calls of if_changed within a target in
>> Makefiles
>> +if (($realfile =~ /Makefile.*/ || $realfile =~ /Kbuild.*/) &&
>
> Why is any Kbuild file check useful?
Because Kbuild files are makefiles and if we want to check makefiles
they are also meant.
>> +($prevline =~ /^[ +]\t\$\(call if_changed,/) &&
>> +($line =~ /^[ +]\t\$\(call if_changed,/)) {
>
> What about if_changed_dep and if_changed_rule?
This patch tries to avoid just one single issue that actually showed
up and caused irritation.
>
>> +ERROR("MULTIPLE_IF_CHANGED",
>> + "Multiple calls of if_changed within a
>> target.\n" . $herecurr);
>> +}
>
> And some more style things:
>
> There are instances with multiple tabs so probably
> these should use '\t*' or '\s*' and not '\t'.
Oh yes, I missed that.
I guess, you mean e.g. arch/x86/purgatory/Makefile:
$(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
$(call if_changed,ld)
I did not check the log but it seems there was one commit that for some
reason used \t\t for the recipes.
Anyway, the first TAB is mandatory, because we want to check recipes,
only.
> This should probably not require a single space after
> if_changed so likely:
>
> 'call\s+if_changed'
Treewide, I did not find a single call of if_changed that uses other than
a single space but you are right, me might see variations.
So, according to your remarks, I would change the pattern to:
/^[ +]\t\s*\$\(call\s+if_changed,/
Dirk
Re: [PATCH] checkpatch: if_changed: check for multiple calls in targets
Joe Perches writes:
> On Mon, 2018-07-16 at 14:39 +0200, Dirk Gouders wrote:
>> Because the kbuild function if_changed writes the command line to a
>> .cmd file for later tests, multiple calls of that function within a
>> target would result in overwrites of previous values and effectively
>> render the command line test meaningless, resulting in flip-flop
>> behaviour.
>>
>> Produce an error for targets with multiple calls to if_changed.
>
> Hi. Some questions:
>
> How is the existing use in arch/microblaze/boot/Makefile incorrect?
>
> $(obj)/simpleImage.%: vmlinux FORCE
> $(call if_changed,cp,.unstrip)
> $(call if_changed,objcopy)
> $(call if_changed,uimage)
> $(call if_changed,strip,.strip)
> @echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')'
Hi Joe,
thank you for the review.
Perhaps I should have started the commit message with:
"The kbuild function if_changed should not be called more than once for a
target." and then the explanatory text.
In case you are interested in the thread where Masahiro explained in detail the
real issues with those Makefiles that made them use if_changed too often:
https://marc.info/?l=linux-kernel=153149389303034=2
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
>> @@ -2911,6 +2911,14 @@ sub process {
>> "Use of $flag is deprecated, please use
>> \`$replacement->{$flag} instead.\n" . $herecurr) if ($replacement->{$flag});
>> }
>> i
>> +# Check for multiple calls of if_changed within a target in
>> Makefiles
>> +if (($realfile =~ /Makefile.*/ || $realfile =~ /Kbuild.*/) &&
>
> Why is any Kbuild file check useful?
Because Kbuild files are makefiles and if we want to check makefiles
they are also meant.
>> +($prevline =~ /^[ +]\t\$\(call if_changed,/) &&
>> +($line =~ /^[ +]\t\$\(call if_changed,/)) {
>
> What about if_changed_dep and if_changed_rule?
This patch tries to avoid just one single issue that actually showed
up and caused irritation.
>
>> +ERROR("MULTIPLE_IF_CHANGED",
>> + "Multiple calls of if_changed within a
>> target.\n" . $herecurr);
>> +}
>
> And some more style things:
>
> There are instances with multiple tabs so probably
> these should use '\t*' or '\s*' and not '\t'.
Oh yes, I missed that.
I guess, you mean e.g. arch/x86/purgatory/Makefile:
$(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
$(call if_changed,ld)
I did not check the log but it seems there was one commit that for some
reason used \t\t for the recipes.
Anyway, the first TAB is mandatory, because we want to check recipes,
only.
> This should probably not require a single space after
> if_changed so likely:
>
> 'call\s+if_changed'
Treewide, I did not find a single call of if_changed that uses other than
a single space but you are right, me might see variations.
So, according to your remarks, I would change the pattern to:
/^[ +]\t\s*\$\(call\s+if_changed,/
Dirk
[PATCH] checkpatch: if_changed: check for multiple calls in targets
Because the kbuild function if_changed writes the command line to a
.cmd file for later tests, multiple calls of that function within a
target would result in overwrites of previous values and effectively
render the command line test meaningless, resulting in flip-flop
behaviour.
Produce an error for targets with multiple calls to if_changed.
Three examples that would now be detected:
98f78525371b55ccd (x86/boot: Refuse to build with data relocations)
6a8dfe1cac5c591ae (microblaze: support U-BOOT image format)
684151a75bf25f5ae (sparc32: added U-Boot build target: uImage)
Suggested-by: Masahiro Yamada
Signed-off-by: Dirk Gouders
---
scripts/checkpatch.pl | 8
1 file changed, 8 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 447857ffaf6b..b0aadf23148e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2911,6 +2911,14 @@ sub process {
"Use of $flag is deprecated, please use
\`$replacement->{$flag} instead.\n" . $herecurr) if ($replacement->{$flag});
}
+ # Check for multiple calls of if_changed within a target in
Makefiles
+ if (($realfile =~ /Makefile.*/ || $realfile =~ /Kbuild.*/) &&
+ ($prevline =~ /^[ +]\t\$\(call if_changed,/) &&
+ ($line =~ /^[ +]\t\$\(call if_changed,/)) {
+ ERROR("MULTIPLE_IF_CHANGED",
+ "Multiple calls of if_changed within a
target.\n" . $herecurr);
+ }
+
# check for DT compatible documentation
if (defined $root &&
(($realfile =~ /\.dtsi?$/ && $line =~
/^\+\s*compatible\s*=\s*\"/) ||
--
2.17.1
[PATCH] checkpatch: if_changed: check for multiple calls in targets
Because the kbuild function if_changed writes the command line to a
.cmd file for later tests, multiple calls of that function within a
target would result in overwrites of previous values and effectively
render the command line test meaningless, resulting in flip-flop
behaviour.
Produce an error for targets with multiple calls to if_changed.
Three examples that would now be detected:
98f78525371b55ccd (x86/boot: Refuse to build with data relocations)
6a8dfe1cac5c591ae (microblaze: support U-BOOT image format)
684151a75bf25f5ae (sparc32: added U-Boot build target: uImage)
Suggested-by: Masahiro Yamada
Signed-off-by: Dirk Gouders
---
scripts/checkpatch.pl | 8
1 file changed, 8 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 447857ffaf6b..b0aadf23148e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2911,6 +2911,14 @@ sub process {
"Use of $flag is deprecated, please use
\`$replacement->{$flag} instead.\n" . $herecurr) if ($replacement->{$flag});
}
+ # Check for multiple calls of if_changed within a target in
Makefiles
+ if (($realfile =~ /Makefile.*/ || $realfile =~ /Kbuild.*/) &&
+ ($prevline =~ /^[ +]\t\$\(call if_changed,/) &&
+ ($line =~ /^[ +]\t\$\(call if_changed,/)) {
+ ERROR("MULTIPLE_IF_CHANGED",
+ "Multiple calls of if_changed within a
target.\n" . $herecurr);
+ }
+
# check for DT compatible documentation
if (defined $root &&
(($realfile =~ /\.dtsi?$/ && $line =~
/^\+\s*compatible\s*=\s*\"/) ||
--
2.17.1
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Masahiro Yamada writes: > 2018-07-12 20:32 GMT+09:00 Dirk Gouders : >> Masahiro Yamada writes: >> >>> 2018-07-09 20:39 GMT+09:00 Dirk Gouders : >>>> Dirk Gouders writes: >>>> >>>> I think, I solved the puzzle and perhaps, that saves others some time: >>>> >>>> The problem is that "if_changed" was not designed for multiple use >>>> inside a recipe and in the case of compressed/vmlinux, the 2-fold use >>>> created a kind of flip-flop for situations when nothing has to be done >>>> to build the target. >>>> >>>> Because each of the two users of "if_changed" stores it's footprint in >>>> .vmlinux.cmd but that file then isn't re-read, one of the two >>>> "if_changed" calculates that nothing has to be done wheras the other one >>>> recognizes a change in the commandline, because it sees the command-line >>>> for the other part of the reciepe. >>>> >>>> In the next make, the roles flip, because the previously satisfied >>>> "if_changed" now sees the command-line of the other one. And so on... >>>> >>>> I am not a Kbuild expert but the attached patch fixes that problem by >>>> introducing "if_changed_multi" that accepts two commands -- one whose >>>> commandline should be checked and a second one that should be >>>> executed. >>> >>> >>> if_changed should not appear multiple times in one target. >>> >>> I think the simplest fix-up is to >>> create a new command that combines >>> 'cmd_check_data_rel' and 'cmd_ld'. >>> >>> >>> quiet_cmd_link-vmlinux = LD $@ >>> cmd_link-vmlinux = $(cmd_check_data_rel); $(cmd_ld) >>> >>> $(obj)/vmlinux: $(vmlinux-objs-y) FORCE >>> $(call if_changed,link-vmlinux) >>> >>> Kbuild also supports if_changed_rule, >>> but the usage is more complex. >>> >>> There are only a few usages: >>> https://github.com/torvalds/linux/blob/v4.17/scripts/Makefile.build#L288 >> >> Just for completeness I will copy in part of a reply from Kees that >> shows how double-colon rules can also avoid multiple use of if_changed >> for one target: >> >> -$(obj)/vmlinux: $(vmlinux-objs-y) FORCE >> - $(call if_changed,check_data_rel) >> +$(obj)/vmlinux:: $(vmlinux-objs-y) >> + $(call cmd,check_data_rel) >> +$(obj)/vmlinux:: $(vmlinux-objs-y) FORCE >> $(call if_changed,ld) > > It is difficult to use double-colon rules in a _sane_ way. > > The first one just checks data_rel, > but does not actually generate anything. > > Such targets should be marked as .PHONY, > but $(obj)/vmlinux is not a phony target. > This is strange. > >> The combined command seems to have the advantage that every command to >> build the target gets recorded in the .cmd file >> >> A search showed me that we have two more users that use if_changed more >> than once for a single target: >> >> arch/microblaze/boot/Makefile (fourfold) >> arch/sparc/boot/Makefile (2 times twofold) >> >> The sparc case seems to apply to any of the two suggested fixes, > > Neither is correct. > > > $(obj)/uImage: $(obj)/image.gz > $(call if_changed,uimage) > $(call if_changed,uimage.o) > > > should be split into two targets. > > > $(obj)/uImage: $(obj)/image.gz FORCE > $(call if_changed,uimage) > > $(obj)/uImage.o: $(obj)/uImage FORCE > $(call if_changed,uimage.o) > > > It is wrong in multiple ways. FORCE is missing too. > > but >> microblaze uses if_changed in a pattern rule and also makes use of >> parameter arguments in the sub-commands: >> >> $(obj)/simpleImage.%: vmlinux FORCE >> $(call if_changed,cp,.unstrip) >> $(call if_changed,objcopy) >> $(call if_changed,uimage) >> $(call if_changed,strip,.strip) >> @echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')' > > > Probably, this is the same. > > Create a target for each step. > > >> In this case, double colons would have a different meaning and the >> combined command solution would result in a change of the sub-commands, >> as well. I note this in case Michal perhaps has other preferences. >> >> >> In addition to extend the documentation, we could modify if_changed to >> warn about it is b
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Masahiro Yamada writes: > 2018-07-12 20:32 GMT+09:00 Dirk Gouders : >> Masahiro Yamada writes: >> >>> 2018-07-09 20:39 GMT+09:00 Dirk Gouders : >>>> Dirk Gouders writes: >>>> >>>> I think, I solved the puzzle and perhaps, that saves others some time: >>>> >>>> The problem is that "if_changed" was not designed for multiple use >>>> inside a recipe and in the case of compressed/vmlinux, the 2-fold use >>>> created a kind of flip-flop for situations when nothing has to be done >>>> to build the target. >>>> >>>> Because each of the two users of "if_changed" stores it's footprint in >>>> .vmlinux.cmd but that file then isn't re-read, one of the two >>>> "if_changed" calculates that nothing has to be done wheras the other one >>>> recognizes a change in the commandline, because it sees the command-line >>>> for the other part of the reciepe. >>>> >>>> In the next make, the roles flip, because the previously satisfied >>>> "if_changed" now sees the command-line of the other one. And so on... >>>> >>>> I am not a Kbuild expert but the attached patch fixes that problem by >>>> introducing "if_changed_multi" that accepts two commands -- one whose >>>> commandline should be checked and a second one that should be >>>> executed. >>> >>> >>> if_changed should not appear multiple times in one target. >>> >>> I think the simplest fix-up is to >>> create a new command that combines >>> 'cmd_check_data_rel' and 'cmd_ld'. >>> >>> >>> quiet_cmd_link-vmlinux = LD $@ >>> cmd_link-vmlinux = $(cmd_check_data_rel); $(cmd_ld) >>> >>> $(obj)/vmlinux: $(vmlinux-objs-y) FORCE >>> $(call if_changed,link-vmlinux) >>> >>> Kbuild also supports if_changed_rule, >>> but the usage is more complex. >>> >>> There are only a few usages: >>> https://github.com/torvalds/linux/blob/v4.17/scripts/Makefile.build#L288 >> >> Just for completeness I will copy in part of a reply from Kees that >> shows how double-colon rules can also avoid multiple use of if_changed >> for one target: >> >> -$(obj)/vmlinux: $(vmlinux-objs-y) FORCE >> - $(call if_changed,check_data_rel) >> +$(obj)/vmlinux:: $(vmlinux-objs-y) >> + $(call cmd,check_data_rel) >> +$(obj)/vmlinux:: $(vmlinux-objs-y) FORCE >> $(call if_changed,ld) > > It is difficult to use double-colon rules in a _sane_ way. > > The first one just checks data_rel, > but does not actually generate anything. > > Such targets should be marked as .PHONY, > but $(obj)/vmlinux is not a phony target. > This is strange. > >> The combined command seems to have the advantage that every command to >> build the target gets recorded in the .cmd file >> >> A search showed me that we have two more users that use if_changed more >> than once for a single target: >> >> arch/microblaze/boot/Makefile (fourfold) >> arch/sparc/boot/Makefile (2 times twofold) >> >> The sparc case seems to apply to any of the two suggested fixes, > > Neither is correct. > > > $(obj)/uImage: $(obj)/image.gz > $(call if_changed,uimage) > $(call if_changed,uimage.o) > > > should be split into two targets. > > > $(obj)/uImage: $(obj)/image.gz FORCE > $(call if_changed,uimage) > > $(obj)/uImage.o: $(obj)/uImage FORCE > $(call if_changed,uimage.o) > > > It is wrong in multiple ways. FORCE is missing too. > > but >> microblaze uses if_changed in a pattern rule and also makes use of >> parameter arguments in the sub-commands: >> >> $(obj)/simpleImage.%: vmlinux FORCE >> $(call if_changed,cp,.unstrip) >> $(call if_changed,objcopy) >> $(call if_changed,uimage) >> $(call if_changed,strip,.strip) >> @echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')' > > > Probably, this is the same. > > Create a target for each step. > > >> In this case, double colons would have a different meaning and the >> combined command solution would result in a change of the sub-commands, >> as well. I note this in case Michal perhaps has other preferences. >> >> >> In addition to extend the documentation, we could modify if_changed to >> warn about it is b
Re: [PATCH v3 00/12] kbuild/kconfig: do not update config during installation
Masahiro Yamada writes:
> 2018-07-10 20:34 GMT+09:00 Dirk Gouders :
>> Masahiro Yamada writes:
>>
>>> The main motivation of this patch series is to suppress the syncconfig
>>> during running installation targets.
>>>
>>> V1 consisted of only two patches:
>>> https://patchwork.kernel.org/patch/10468105/
>>> https://patchwork.kernel.org/patch/10468103/
>>>
>>> I noticed that installation targets would continue running
>>> even if the source tree is not configured at all
>>> because the inclusion of include/config/auto.conf was optional.
>>>
>>> So, I added one more patch in V2:
>>> https://patchwork.kernel.org/patch/10483637/
>>>
>>> However, kbuild test robot reported a new warning message was displayed:
>>>
>>> Makefile:592: include/config/auto.conf: No such file or directory
>>>
>>> This warning is displayed only for Make 4.1 or older.
>>>
>>> To fix this annoying warning, I changed Kconfig too,
>>> which leaded to more clean-up, improvements in Kconfig.
>>>
>>> So, V3 is a big patch series.
>>
>> Hello Masahiro,
>>
>> I tested your series for a while, now. I did not notice real issues
>> with it but want to leave some remarks about what I noticed in
>> the surroundings of your patches.
>>
>>
>>> Masahiro Yamada (12):
>>> kconfig: rename file_write_dep and move it to confdata.c
>>
>> I might be missing some trivial use-case, but when looking at this
>> patch, I noticed an inconsistency with the file names auto.conf and
>> auto.conf.cmd.
>>
>> The first can be modified by an environment variable but when this
>> happens, auto.conf.cmd remains as is. I noticed that only the
>> Documentation mentions that KCONFIG_AUTOCONFIG exists and confdata.c
>> uses it to serve the file name -- no other use anywhere.
>
> Indeed.
>
> I had also noticed this.
>
> Probably, replacing the hardcoded 'include/config/auto.conf.cmd'
> with get_env('KCONFIG_AUTOCONFIG') + 'cmd' will be nice.
>
>
> I did not touch it since it thought it was less important
> for this patch set.
>
> If you are willing to contribute to this,
> a patch is welcome (after this series).
Yes, it is not that important but it would probably help people new to
kbuild/kconfig if we make this a bit more consistent. I will send a
patch that also adds some words to the documentation of
KCONFIG_AUTOCONFIG.
>> Now, I am wondering if I just don't see an important case when the
>> use of KCONFIG_AUTOCONFIG is really helpful or even mandatory.
>
>
> I do not know the historical background,
> but I guess predecessors wanted to implement Kconfig
> as generic/flexible as possible.
>
>
>>
>>> kconfig: split out helpers to check file/directory, create directory
>>> kconfig: remove unneeded directory generation from local*config
>>> kconfig: create directories needed for syncconfig by itself
>>> kconfig: make syncconfig update .config regardless of sym_change_count
>>
>> For this patch, I already mentioned that `conf --help' perhaps could be
>> updated.
>
> What do you want 'conf --help' to look like ?
As I said, --help does not say a lot about which files are updated, so I
probably was too pedantic. For --syncconfig it currently says:
--syncconfigSimilar to oldconfig but generates configuration in
include/{generated/,config/}
which could let someone guess .config isn't touched (because of the
"but"). If you also think so, the text could perhaps say:
--syncconfigSimilar to oldconfig but generates configuration in
include/{generated/,config/} in addition.
>
>> On the other side, none of the entries there tells us such
>> details, so there is probably no need for syncconfig to do so.
>>
>>> kconfig: allow all config targets to write auto.conf if missing
>>> kbuild: use 'include' directive to load auto.conf from top Makefile
>>> kbuild: add .DELETE_ON_ERROR special target
>>> kbuild: do not update config when running install targets
>>> kbuild: do not update config for 'make kernelrelease'
>>> kbuild: remove auto.conf and tristate.conf from prerequisites
>>
>> In the surrounding of this patch I noticed -include of auto.conf and
>> tristate.conf in scripts/Makfile.modbuildin. I tried it in some ways
>> but was not able to trigger that file being used with a missing
>> auto.conf.
>
> Right. auto.conf and tristate.conf are mandatory there.
>
>
Re: [PATCH v3 00/12] kbuild/kconfig: do not update config during installation
Masahiro Yamada writes:
> 2018-07-10 20:34 GMT+09:00 Dirk Gouders :
>> Masahiro Yamada writes:
>>
>>> The main motivation of this patch series is to suppress the syncconfig
>>> during running installation targets.
>>>
>>> V1 consisted of only two patches:
>>> https://patchwork.kernel.org/patch/10468105/
>>> https://patchwork.kernel.org/patch/10468103/
>>>
>>> I noticed that installation targets would continue running
>>> even if the source tree is not configured at all
>>> because the inclusion of include/config/auto.conf was optional.
>>>
>>> So, I added one more patch in V2:
>>> https://patchwork.kernel.org/patch/10483637/
>>>
>>> However, kbuild test robot reported a new warning message was displayed:
>>>
>>> Makefile:592: include/config/auto.conf: No such file or directory
>>>
>>> This warning is displayed only for Make 4.1 or older.
>>>
>>> To fix this annoying warning, I changed Kconfig too,
>>> which leaded to more clean-up, improvements in Kconfig.
>>>
>>> So, V3 is a big patch series.
>>
>> Hello Masahiro,
>>
>> I tested your series for a while, now. I did not notice real issues
>> with it but want to leave some remarks about what I noticed in
>> the surroundings of your patches.
>>
>>
>>> Masahiro Yamada (12):
>>> kconfig: rename file_write_dep and move it to confdata.c
>>
>> I might be missing some trivial use-case, but when looking at this
>> patch, I noticed an inconsistency with the file names auto.conf and
>> auto.conf.cmd.
>>
>> The first can be modified by an environment variable but when this
>> happens, auto.conf.cmd remains as is. I noticed that only the
>> Documentation mentions that KCONFIG_AUTOCONFIG exists and confdata.c
>> uses it to serve the file name -- no other use anywhere.
>
> Indeed.
>
> I had also noticed this.
>
> Probably, replacing the hardcoded 'include/config/auto.conf.cmd'
> with get_env('KCONFIG_AUTOCONFIG') + 'cmd' will be nice.
>
>
> I did not touch it since it thought it was less important
> for this patch set.
>
> If you are willing to contribute to this,
> a patch is welcome (after this series).
Yes, it is not that important but it would probably help people new to
kbuild/kconfig if we make this a bit more consistent. I will send a
patch that also adds some words to the documentation of
KCONFIG_AUTOCONFIG.
>> Now, I am wondering if I just don't see an important case when the
>> use of KCONFIG_AUTOCONFIG is really helpful or even mandatory.
>
>
> I do not know the historical background,
> but I guess predecessors wanted to implement Kconfig
> as generic/flexible as possible.
>
>
>>
>>> kconfig: split out helpers to check file/directory, create directory
>>> kconfig: remove unneeded directory generation from local*config
>>> kconfig: create directories needed for syncconfig by itself
>>> kconfig: make syncconfig update .config regardless of sym_change_count
>>
>> For this patch, I already mentioned that `conf --help' perhaps could be
>> updated.
>
> What do you want 'conf --help' to look like ?
As I said, --help does not say a lot about which files are updated, so I
probably was too pedantic. For --syncconfig it currently says:
--syncconfigSimilar to oldconfig but generates configuration in
include/{generated/,config/}
which could let someone guess .config isn't touched (because of the
"but"). If you also think so, the text could perhaps say:
--syncconfigSimilar to oldconfig but generates configuration in
include/{generated/,config/} in addition.
>
>> On the other side, none of the entries there tells us such
>> details, so there is probably no need for syncconfig to do so.
>>
>>> kconfig: allow all config targets to write auto.conf if missing
>>> kbuild: use 'include' directive to load auto.conf from top Makefile
>>> kbuild: add .DELETE_ON_ERROR special target
>>> kbuild: do not update config when running install targets
>>> kbuild: do not update config for 'make kernelrelease'
>>> kbuild: remove auto.conf and tristate.conf from prerequisites
>>
>> In the surrounding of this patch I noticed -include of auto.conf and
>> tristate.conf in scripts/Makfile.modbuildin. I tried it in some ways
>> but was not able to trigger that file being used with a missing
>> auto.conf.
>
> Right. auto.conf and tristate.conf are mandatory there.
>
>
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Dirk Gouders writes: > Masahiro Yamada writes: > >> 2018-07-09 20:39 GMT+09:00 Dirk Gouders : >>> Dirk Gouders writes: >>> >>>> Dirk Gouders writes: >>>> >>>>> Masahiro Yamada writes: >>>>> >>>>>> syncconfig updates the .config only when sym_change_count > 0, i.e. >>>>>> any change in config symbols has been detected. >>>>>> >>>>>> Not only symbols but also comments are contained in the .config file. >>>>>> If only comments are updated, they are not fed back to the .config, >>>>>> then the stale comments are left-over. Of course, this is just a >>>>>> matter of comments, but why not fix it. >>>>> >>>>> Hello Masahiro, >>>>> >>>>> I am currently looking at and testing this series. >>>>> >>>>> First: For this patch I would suggest to also edit the syncconfig >>>>>section of "conf --help". >>>>> >>>>> Further, on a slow laptop, I was suspecting, this patch to cause full >>>>> rebuilds of everything, each time I ran "make syncconfig" followed by >>>>> "make" but could not verify this on another machine, so perhaps I am >>>>> just (for testing purposes) removing the wrong files (modules.builtin >>>>> for example) -- I am still testing. >>>>> >>>>> But, what irritates me with testing is that (also without your >>>>> patches) two consecutive "make" produce different output, one of them >>>>> always shows a warning and this is reproducable. I just want to make >>>>> sure there is no other problem that influences my testing: >>>>> >>>>> $ make >>>>> CALLscripts/checksyscalls.sh >>>>> DESCEND objtool >>>>> CHK include/generated/compile.h >>>>> DATAREL arch/x86/boot/compressed/vmlinux >>>>> Kernel: arch/x86/boot/bzImage is ready (#15) >>>>> Building modules, stage 2. >>>>> MODPOST 211 modules >>>>> >>>>> $ make >>>>> CALLscripts/checksyscalls.sh >>>>> DESCEND objtool >>>>> CHK include/generated/compile.h >>>>> LD arch/x86/boot/compressed/vmlinux >>>>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only >>>>> section `.head.text' >>>>> ld: warning: creating a DT_TEXTREL in object. >>>>> ZOFFSET arch/x86/boot/zoffset.h >>>>> AS arch/x86/boot/header.o >>>>> LD arch/x86/boot/setup.elf >>>>> OBJCOPY arch/x86/boot/setup.bin >>>>> OBJCOPY arch/x86/boot/vmlinux.bin >>>>> BUILD arch/x86/boot/bzImage >>>>> Setup is 15580 bytes (padded to 15872 bytes). >>>>> System is 8069 kB >>>>> CRC e01d75ec >>>>> Kernel: arch/x86/boot/bzImage is ready (#15) >>>>> Building modules, stage 2. >>>>> MODPOST 211 modules >>>> >>>> I spent some more time with the behaviour described above and bisected >>>> to the commit after that two consecutive invocations of "make" (on an >>>> already compiled tree) seem to do different things. That commit is >>>> 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I >>>> put Kees and Ingo on CC. >>>> >>>> I did the bisecting on another system, so I'll provide the output of two >>>> consecutive "make" on an already compiled tree on that machine: >>>> >>>> $ make >>>> CALLscripts/checksyscalls.sh >>>> DESCEND objtool >>>> CHK include/generated/compile.h >>>> DATAREL arch/x86/boot/compressed/vmlinux >>>> Kernel: arch/x86/boot/bzImage is ready (#48) >>>> Building modules, stage 2. >>>> MODPOST 165 modules >>>> >>>> $ make >>>> CALLscripts/checksyscalls.sh >>>> DESCEND objtool >>>> CHK include/generated/compile.h >>>> LD arch/x86/boot/compressed/vmlinux >>>> ZOFFSET arch/x86/boot/zoffset.h >>>> AS arch/x86/boot/header.o >>>> LD arch/x86/boot/setup.elf >>>> OBJCOPY arch/x86/boot/setup.bin >>>> OBJC
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Dirk Gouders writes: > Masahiro Yamada writes: > >> 2018-07-09 20:39 GMT+09:00 Dirk Gouders : >>> Dirk Gouders writes: >>> >>>> Dirk Gouders writes: >>>> >>>>> Masahiro Yamada writes: >>>>> >>>>>> syncconfig updates the .config only when sym_change_count > 0, i.e. >>>>>> any change in config symbols has been detected. >>>>>> >>>>>> Not only symbols but also comments are contained in the .config file. >>>>>> If only comments are updated, they are not fed back to the .config, >>>>>> then the stale comments are left-over. Of course, this is just a >>>>>> matter of comments, but why not fix it. >>>>> >>>>> Hello Masahiro, >>>>> >>>>> I am currently looking at and testing this series. >>>>> >>>>> First: For this patch I would suggest to also edit the syncconfig >>>>>section of "conf --help". >>>>> >>>>> Further, on a slow laptop, I was suspecting, this patch to cause full >>>>> rebuilds of everything, each time I ran "make syncconfig" followed by >>>>> "make" but could not verify this on another machine, so perhaps I am >>>>> just (for testing purposes) removing the wrong files (modules.builtin >>>>> for example) -- I am still testing. >>>>> >>>>> But, what irritates me with testing is that (also without your >>>>> patches) two consecutive "make" produce different output, one of them >>>>> always shows a warning and this is reproducable. I just want to make >>>>> sure there is no other problem that influences my testing: >>>>> >>>>> $ make >>>>> CALLscripts/checksyscalls.sh >>>>> DESCEND objtool >>>>> CHK include/generated/compile.h >>>>> DATAREL arch/x86/boot/compressed/vmlinux >>>>> Kernel: arch/x86/boot/bzImage is ready (#15) >>>>> Building modules, stage 2. >>>>> MODPOST 211 modules >>>>> >>>>> $ make >>>>> CALLscripts/checksyscalls.sh >>>>> DESCEND objtool >>>>> CHK include/generated/compile.h >>>>> LD arch/x86/boot/compressed/vmlinux >>>>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only >>>>> section `.head.text' >>>>> ld: warning: creating a DT_TEXTREL in object. >>>>> ZOFFSET arch/x86/boot/zoffset.h >>>>> AS arch/x86/boot/header.o >>>>> LD arch/x86/boot/setup.elf >>>>> OBJCOPY arch/x86/boot/setup.bin >>>>> OBJCOPY arch/x86/boot/vmlinux.bin >>>>> BUILD arch/x86/boot/bzImage >>>>> Setup is 15580 bytes (padded to 15872 bytes). >>>>> System is 8069 kB >>>>> CRC e01d75ec >>>>> Kernel: arch/x86/boot/bzImage is ready (#15) >>>>> Building modules, stage 2. >>>>> MODPOST 211 modules >>>> >>>> I spent some more time with the behaviour described above and bisected >>>> to the commit after that two consecutive invocations of "make" (on an >>>> already compiled tree) seem to do different things. That commit is >>>> 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I >>>> put Kees and Ingo on CC. >>>> >>>> I did the bisecting on another system, so I'll provide the output of two >>>> consecutive "make" on an already compiled tree on that machine: >>>> >>>> $ make >>>> CALLscripts/checksyscalls.sh >>>> DESCEND objtool >>>> CHK include/generated/compile.h >>>> DATAREL arch/x86/boot/compressed/vmlinux >>>> Kernel: arch/x86/boot/bzImage is ready (#48) >>>> Building modules, stage 2. >>>> MODPOST 165 modules >>>> >>>> $ make >>>> CALLscripts/checksyscalls.sh >>>> DESCEND objtool >>>> CHK include/generated/compile.h >>>> LD arch/x86/boot/compressed/vmlinux >>>> ZOFFSET arch/x86/boot/zoffset.h >>>> AS arch/x86/boot/header.o >>>> LD arch/x86/boot/setup.elf >>>> OBJCOPY arch/x86/boot/setup.bin >>>> OBJC
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Masahiro Yamada writes: > 2018-07-09 20:39 GMT+09:00 Dirk Gouders : >> Dirk Gouders writes: >> >>> Dirk Gouders writes: >>> >>>> Masahiro Yamada writes: >>>> >>>>> syncconfig updates the .config only when sym_change_count > 0, i.e. >>>>> any change in config symbols has been detected. >>>>> >>>>> Not only symbols but also comments are contained in the .config file. >>>>> If only comments are updated, they are not fed back to the .config, >>>>> then the stale comments are left-over. Of course, this is just a >>>>> matter of comments, but why not fix it. >>>> >>>> Hello Masahiro, >>>> >>>> I am currently looking at and testing this series. >>>> >>>> First: For this patch I would suggest to also edit the syncconfig >>>>section of "conf --help". >>>> >>>> Further, on a slow laptop, I was suspecting, this patch to cause full >>>> rebuilds of everything, each time I ran "make syncconfig" followed by >>>> "make" but could not verify this on another machine, so perhaps I am >>>> just (for testing purposes) removing the wrong files (modules.builtin >>>> for example) -- I am still testing. >>>> >>>> But, what irritates me with testing is that (also without your >>>> patches) two consecutive "make" produce different output, one of them >>>> always shows a warning and this is reproducable. I just want to make >>>> sure there is no other problem that influences my testing: >>>> >>>> $ make >>>> CALLscripts/checksyscalls.sh >>>> DESCEND objtool >>>> CHK include/generated/compile.h >>>> DATAREL arch/x86/boot/compressed/vmlinux >>>> Kernel: arch/x86/boot/bzImage is ready (#15) >>>> Building modules, stage 2. >>>> MODPOST 211 modules >>>> >>>> $ make >>>> CALLscripts/checksyscalls.sh >>>> DESCEND objtool >>>> CHK include/generated/compile.h >>>> LD arch/x86/boot/compressed/vmlinux >>>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only >>>> section `.head.text' >>>> ld: warning: creating a DT_TEXTREL in object. >>>> ZOFFSET arch/x86/boot/zoffset.h >>>> AS arch/x86/boot/header.o >>>> LD arch/x86/boot/setup.elf >>>> OBJCOPY arch/x86/boot/setup.bin >>>> OBJCOPY arch/x86/boot/vmlinux.bin >>>> BUILD arch/x86/boot/bzImage >>>> Setup is 15580 bytes (padded to 15872 bytes). >>>> System is 8069 kB >>>> CRC e01d75ec >>>> Kernel: arch/x86/boot/bzImage is ready (#15) >>>> Building modules, stage 2. >>>> MODPOST 211 modules >>> >>> I spent some more time with the behaviour described above and bisected >>> to the commit after that two consecutive invocations of "make" (on an >>> already compiled tree) seem to do different things. That commit is >>> 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I >>> put Kees and Ingo on CC. >>> >>> I did the bisecting on another system, so I'll provide the output of two >>> consecutive "make" on an already compiled tree on that machine: >>> >>> $ make >>> CALLscripts/checksyscalls.sh >>> DESCEND objtool >>> CHK include/generated/compile.h >>> DATAREL arch/x86/boot/compressed/vmlinux >>> Kernel: arch/x86/boot/bzImage is ready (#48) >>> Building modules, stage 2. >>> MODPOST 165 modules >>> >>> $ make >>> CALLscripts/checksyscalls.sh >>> DESCEND objtool >>> CHK include/generated/compile.h >>> LD arch/x86/boot/compressed/vmlinux >>> ZOFFSET arch/x86/boot/zoffset.h >>> AS arch/x86/boot/header.o >>> LD arch/x86/boot/setup.elf >>> OBJCOPY arch/x86/boot/setup.bin >>> OBJCOPY arch/x86/boot/vmlinux.bin >>> BUILD arch/x86/boot/bzImage >>> Setup is 15644 bytes (padded to 15872 bytes). >>> System is 6663 kB >>> CRC 3eb90f40 >>> Kernel: arch/x86/boot/bzImage is ready (#48) >>> Building modules, stage 2. >>> MODPOST 165 modules >>> >>> If I comment out $(call if_changed,check_data_rel)
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Masahiro Yamada writes: > 2018-07-09 20:39 GMT+09:00 Dirk Gouders : >> Dirk Gouders writes: >> >>> Dirk Gouders writes: >>> >>>> Masahiro Yamada writes: >>>> >>>>> syncconfig updates the .config only when sym_change_count > 0, i.e. >>>>> any change in config symbols has been detected. >>>>> >>>>> Not only symbols but also comments are contained in the .config file. >>>>> If only comments are updated, they are not fed back to the .config, >>>>> then the stale comments are left-over. Of course, this is just a >>>>> matter of comments, but why not fix it. >>>> >>>> Hello Masahiro, >>>> >>>> I am currently looking at and testing this series. >>>> >>>> First: For this patch I would suggest to also edit the syncconfig >>>>section of "conf --help". >>>> >>>> Further, on a slow laptop, I was suspecting, this patch to cause full >>>> rebuilds of everything, each time I ran "make syncconfig" followed by >>>> "make" but could not verify this on another machine, so perhaps I am >>>> just (for testing purposes) removing the wrong files (modules.builtin >>>> for example) -- I am still testing. >>>> >>>> But, what irritates me with testing is that (also without your >>>> patches) two consecutive "make" produce different output, one of them >>>> always shows a warning and this is reproducable. I just want to make >>>> sure there is no other problem that influences my testing: >>>> >>>> $ make >>>> CALLscripts/checksyscalls.sh >>>> DESCEND objtool >>>> CHK include/generated/compile.h >>>> DATAREL arch/x86/boot/compressed/vmlinux >>>> Kernel: arch/x86/boot/bzImage is ready (#15) >>>> Building modules, stage 2. >>>> MODPOST 211 modules >>>> >>>> $ make >>>> CALLscripts/checksyscalls.sh >>>> DESCEND objtool >>>> CHK include/generated/compile.h >>>> LD arch/x86/boot/compressed/vmlinux >>>> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only >>>> section `.head.text' >>>> ld: warning: creating a DT_TEXTREL in object. >>>> ZOFFSET arch/x86/boot/zoffset.h >>>> AS arch/x86/boot/header.o >>>> LD arch/x86/boot/setup.elf >>>> OBJCOPY arch/x86/boot/setup.bin >>>> OBJCOPY arch/x86/boot/vmlinux.bin >>>> BUILD arch/x86/boot/bzImage >>>> Setup is 15580 bytes (padded to 15872 bytes). >>>> System is 8069 kB >>>> CRC e01d75ec >>>> Kernel: arch/x86/boot/bzImage is ready (#15) >>>> Building modules, stage 2. >>>> MODPOST 211 modules >>> >>> I spent some more time with the behaviour described above and bisected >>> to the commit after that two consecutive invocations of "make" (on an >>> already compiled tree) seem to do different things. That commit is >>> 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I >>> put Kees and Ingo on CC. >>> >>> I did the bisecting on another system, so I'll provide the output of two >>> consecutive "make" on an already compiled tree on that machine: >>> >>> $ make >>> CALLscripts/checksyscalls.sh >>> DESCEND objtool >>> CHK include/generated/compile.h >>> DATAREL arch/x86/boot/compressed/vmlinux >>> Kernel: arch/x86/boot/bzImage is ready (#48) >>> Building modules, stage 2. >>> MODPOST 165 modules >>> >>> $ make >>> CALLscripts/checksyscalls.sh >>> DESCEND objtool >>> CHK include/generated/compile.h >>> LD arch/x86/boot/compressed/vmlinux >>> ZOFFSET arch/x86/boot/zoffset.h >>> AS arch/x86/boot/header.o >>> LD arch/x86/boot/setup.elf >>> OBJCOPY arch/x86/boot/setup.bin >>> OBJCOPY arch/x86/boot/vmlinux.bin >>> BUILD arch/x86/boot/bzImage >>> Setup is 15644 bytes (padded to 15872 bytes). >>> System is 6663 kB >>> CRC 3eb90f40 >>> Kernel: arch/x86/boot/bzImage is ready (#48) >>> Building modules, stage 2. >>> MODPOST 165 modules >>> >>> If I comment out $(call if_changed,check_data_rel)
Re: [PATCH v3 00/12] kbuild/kconfig: do not update config during installation
Masahiro Yamada writes: > The main motivation of this patch series is to suppress the syncconfig > during running installation targets. > > V1 consisted of only two patches: > https://patchwork.kernel.org/patch/10468105/ > https://patchwork.kernel.org/patch/10468103/ > > I noticed that installation targets would continue running > even if the source tree is not configured at all > because the inclusion of include/config/auto.conf was optional. > > So, I added one more patch in V2: > https://patchwork.kernel.org/patch/10483637/ > > However, kbuild test robot reported a new warning message was displayed: > > Makefile:592: include/config/auto.conf: No such file or directory > > This warning is displayed only for Make 4.1 or older. > > To fix this annoying warning, I changed Kconfig too, > which leaded to more clean-up, improvements in Kconfig. > > So, V3 is a big patch series. Hello Masahiro, I tested your series for a while, now. I did not notice real issues with it but want to leave some remarks about what I noticed in the surroundings of your patches. > Masahiro Yamada (12): > kconfig: rename file_write_dep and move it to confdata.c I might be missing some trivial use-case, but when looking at this patch, I noticed an inconsistency with the file names auto.conf and auto.conf.cmd. The first can be modified by an environment variable but when this happens, auto.conf.cmd remains as is. I noticed that only the Documentation mentions that KCONFIG_AUTOCONFIG exists and confdata.c uses it to serve the file name -- no other use anywhere. Now, I am wondering if I just don't see an important case when the use of KCONFIG_AUTOCONFIG is really helpful or even mandatory. > kconfig: split out helpers to check file/directory, create directory > kconfig: remove unneeded directory generation from local*config > kconfig: create directories needed for syncconfig by itself > kconfig: make syncconfig update .config regardless of sym_change_count For this patch, I already mentioned that `conf --help' perhaps could be updated. On the other side, none of the entries there tells us such details, so there is probably no need for syncconfig to do so. > kconfig: allow all config targets to write auto.conf if missing > kbuild: use 'include' directive to load auto.conf from top Makefile > kbuild: add .DELETE_ON_ERROR special target > kbuild: do not update config when running install targets > kbuild: do not update config for 'make kernelrelease' > kbuild: remove auto.conf and tristate.conf from prerequisites In the surrounding of this patch I noticed -include of auto.conf and tristate.conf in scripts/Makfile.modbuildin. I tried it in some ways but was not able to trigger that file being used with a missing auto.conf. On the other hand, if I now manually remove tristate.conf, that would not be fixed or even noticed, because of -include and I wonder if it is safer to also change the -includes in that file. It seems, if one of those files is missing, one must have done it manually or some other serious issue is present that we probably want to notice. Dirk > kbuild: replace include/config/%.conf with include/config/auto.conf > > Makefile| 46 +-- > scripts/Kbuild.include | 3 + > scripts/kconfig/Makefile| 16 ++--- > scripts/kconfig/conf.c | 39 +++-- > scripts/kconfig/confdata.c | 139 > +--- > scripts/kconfig/gconf.c | 1 + > scripts/kconfig/lkc.h | 1 - > scripts/kconfig/lkc_proto.h | 2 +- > scripts/kconfig/mconf.c | 1 + > scripts/kconfig/nconf.c | 1 + > scripts/kconfig/qconf.cc| 2 + > scripts/kconfig/util.c | 30 -- > 12 files changed, 182 insertions(+), 99 deletions(-)
Re: [PATCH v3 00/12] kbuild/kconfig: do not update config during installation
Masahiro Yamada writes: > The main motivation of this patch series is to suppress the syncconfig > during running installation targets. > > V1 consisted of only two patches: > https://patchwork.kernel.org/patch/10468105/ > https://patchwork.kernel.org/patch/10468103/ > > I noticed that installation targets would continue running > even if the source tree is not configured at all > because the inclusion of include/config/auto.conf was optional. > > So, I added one more patch in V2: > https://patchwork.kernel.org/patch/10483637/ > > However, kbuild test robot reported a new warning message was displayed: > > Makefile:592: include/config/auto.conf: No such file or directory > > This warning is displayed only for Make 4.1 or older. > > To fix this annoying warning, I changed Kconfig too, > which leaded to more clean-up, improvements in Kconfig. > > So, V3 is a big patch series. Hello Masahiro, I tested your series for a while, now. I did not notice real issues with it but want to leave some remarks about what I noticed in the surroundings of your patches. > Masahiro Yamada (12): > kconfig: rename file_write_dep and move it to confdata.c I might be missing some trivial use-case, but when looking at this patch, I noticed an inconsistency with the file names auto.conf and auto.conf.cmd. The first can be modified by an environment variable but when this happens, auto.conf.cmd remains as is. I noticed that only the Documentation mentions that KCONFIG_AUTOCONFIG exists and confdata.c uses it to serve the file name -- no other use anywhere. Now, I am wondering if I just don't see an important case when the use of KCONFIG_AUTOCONFIG is really helpful or even mandatory. > kconfig: split out helpers to check file/directory, create directory > kconfig: remove unneeded directory generation from local*config > kconfig: create directories needed for syncconfig by itself > kconfig: make syncconfig update .config regardless of sym_change_count For this patch, I already mentioned that `conf --help' perhaps could be updated. On the other side, none of the entries there tells us such details, so there is probably no need for syncconfig to do so. > kconfig: allow all config targets to write auto.conf if missing > kbuild: use 'include' directive to load auto.conf from top Makefile > kbuild: add .DELETE_ON_ERROR special target > kbuild: do not update config when running install targets > kbuild: do not update config for 'make kernelrelease' > kbuild: remove auto.conf and tristate.conf from prerequisites In the surrounding of this patch I noticed -include of auto.conf and tristate.conf in scripts/Makfile.modbuildin. I tried it in some ways but was not able to trigger that file being used with a missing auto.conf. On the other hand, if I now manually remove tristate.conf, that would not be fixed or even noticed, because of -include and I wonder if it is safer to also change the -includes in that file. It seems, if one of those files is missing, one must have done it manually or some other serious issue is present that we probably want to notice. Dirk > kbuild: replace include/config/%.conf with include/config/auto.conf > > Makefile| 46 +-- > scripts/Kbuild.include | 3 + > scripts/kconfig/Makefile| 16 ++--- > scripts/kconfig/conf.c | 39 +++-- > scripts/kconfig/confdata.c | 139 > +--- > scripts/kconfig/gconf.c | 1 + > scripts/kconfig/lkc.h | 1 - > scripts/kconfig/lkc_proto.h | 2 +- > scripts/kconfig/mconf.c | 1 + > scripts/kconfig/nconf.c | 1 + > scripts/kconfig/qconf.cc| 2 + > scripts/kconfig/util.c | 30 -- > 12 files changed, 182 insertions(+), 99 deletions(-)
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Dirk Gouders writes: > Dirk Gouders writes: > >> Masahiro Yamada writes: >> >>> syncconfig updates the .config only when sym_change_count > 0, i.e. >>> any change in config symbols has been detected. >>> >>> Not only symbols but also comments are contained in the .config file. >>> If only comments are updated, they are not fed back to the .config, >>> then the stale comments are left-over. Of course, this is just a >>> matter of comments, but why not fix it. >> >> Hello Masahiro, >> >> I am currently looking at and testing this series. >> >> First: For this patch I would suggest to also edit the syncconfig >>section of "conf --help". >> >> Further, on a slow laptop, I was suspecting, this patch to cause full >> rebuilds of everything, each time I ran "make syncconfig" followed by >> "make" but could not verify this on another machine, so perhaps I am >> just (for testing purposes) removing the wrong files (modules.builtin >> for example) -- I am still testing. >> >> But, what irritates me with testing is that (also without your >> patches) two consecutive "make" produce different output, one of them >> always shows a warning and this is reproducable. I just want to make >> sure there is no other problem that influences my testing: >> >> $ make >> CALLscripts/checksyscalls.sh >> DESCEND objtool >> CHK include/generated/compile.h >> DATAREL arch/x86/boot/compressed/vmlinux >> Kernel: arch/x86/boot/bzImage is ready (#15) >> Building modules, stage 2. >> MODPOST 211 modules >> >> $ make >> CALLscripts/checksyscalls.sh >> DESCEND objtool >> CHK include/generated/compile.h >> LD arch/x86/boot/compressed/vmlinux >> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only >> section `.head.text' >> ld: warning: creating a DT_TEXTREL in object. >> ZOFFSET arch/x86/boot/zoffset.h >> AS arch/x86/boot/header.o >> LD arch/x86/boot/setup.elf >> OBJCOPY arch/x86/boot/setup.bin >> OBJCOPY arch/x86/boot/vmlinux.bin >> BUILD arch/x86/boot/bzImage >> Setup is 15580 bytes (padded to 15872 bytes). >> System is 8069 kB >> CRC e01d75ec >> Kernel: arch/x86/boot/bzImage is ready (#15) >> Building modules, stage 2. >> MODPOST 211 modules > > I spent some more time with the behaviour described above and bisected > to the commit after that two consecutive invocations of "make" (on an > already compiled tree) seem to do different things. That commit is > 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I > put Kees and Ingo on CC. > > I did the bisecting on another system, so I'll provide the output of two > consecutive "make" on an already compiled tree on that machine: > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > DATAREL arch/x86/boot/compressed/vmlinux > Kernel: arch/x86/boot/bzImage is ready (#48) > Building modules, stage 2. > MODPOST 165 modules > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > LD arch/x86/boot/compressed/vmlinux > ZOFFSET arch/x86/boot/zoffset.h > AS arch/x86/boot/header.o > LD arch/x86/boot/setup.elf > OBJCOPY arch/x86/boot/setup.bin > OBJCOPY arch/x86/boot/vmlinux.bin > BUILD arch/x86/boot/bzImage > Setup is 15644 bytes (padded to 15872 bytes). > System is 6663 kB > CRC 3eb90f40 > Kernel: arch/x86/boot/bzImage is ready (#48) > Building modules, stage 2. > MODPOST 165 modules > > If I comment out $(call if_changed,check_data_rel) in > arch/x86/boot/compressed/Makefile, two consecutive "make" produce > identical output i.e. seem to not do different things: > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > Kernel: arch/x86/boot/bzImage is ready (#49) > Building modules, stage 2. > MODPOST 165 modules > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > Kernel: arch/x86/boot/bzImage is ready (#49) > Building modules, stage 2. > MODPOST 165 modules > > So, I guess this different behaviour of two consecutive "make" is not > intentional but I am failing to understand why it happens. I think, I solved the puzzle and perhaps, that saves others some time: The problem is that &
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Dirk Gouders writes: > Dirk Gouders writes: > >> Masahiro Yamada writes: >> >>> syncconfig updates the .config only when sym_change_count > 0, i.e. >>> any change in config symbols has been detected. >>> >>> Not only symbols but also comments are contained in the .config file. >>> If only comments are updated, they are not fed back to the .config, >>> then the stale comments are left-over. Of course, this is just a >>> matter of comments, but why not fix it. >> >> Hello Masahiro, >> >> I am currently looking at and testing this series. >> >> First: For this patch I would suggest to also edit the syncconfig >>section of "conf --help". >> >> Further, on a slow laptop, I was suspecting, this patch to cause full >> rebuilds of everything, each time I ran "make syncconfig" followed by >> "make" but could not verify this on another machine, so perhaps I am >> just (for testing purposes) removing the wrong files (modules.builtin >> for example) -- I am still testing. >> >> But, what irritates me with testing is that (also without your >> patches) two consecutive "make" produce different output, one of them >> always shows a warning and this is reproducable. I just want to make >> sure there is no other problem that influences my testing: >> >> $ make >> CALLscripts/checksyscalls.sh >> DESCEND objtool >> CHK include/generated/compile.h >> DATAREL arch/x86/boot/compressed/vmlinux >> Kernel: arch/x86/boot/bzImage is ready (#15) >> Building modules, stage 2. >> MODPOST 211 modules >> >> $ make >> CALLscripts/checksyscalls.sh >> DESCEND objtool >> CHK include/generated/compile.h >> LD arch/x86/boot/compressed/vmlinux >> ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only >> section `.head.text' >> ld: warning: creating a DT_TEXTREL in object. >> ZOFFSET arch/x86/boot/zoffset.h >> AS arch/x86/boot/header.o >> LD arch/x86/boot/setup.elf >> OBJCOPY arch/x86/boot/setup.bin >> OBJCOPY arch/x86/boot/vmlinux.bin >> BUILD arch/x86/boot/bzImage >> Setup is 15580 bytes (padded to 15872 bytes). >> System is 8069 kB >> CRC e01d75ec >> Kernel: arch/x86/boot/bzImage is ready (#15) >> Building modules, stage 2. >> MODPOST 211 modules > > I spent some more time with the behaviour described above and bisected > to the commit after that two consecutive invocations of "make" (on an > already compiled tree) seem to do different things. That commit is > 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I > put Kees and Ingo on CC. > > I did the bisecting on another system, so I'll provide the output of two > consecutive "make" on an already compiled tree on that machine: > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > DATAREL arch/x86/boot/compressed/vmlinux > Kernel: arch/x86/boot/bzImage is ready (#48) > Building modules, stage 2. > MODPOST 165 modules > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > LD arch/x86/boot/compressed/vmlinux > ZOFFSET arch/x86/boot/zoffset.h > AS arch/x86/boot/header.o > LD arch/x86/boot/setup.elf > OBJCOPY arch/x86/boot/setup.bin > OBJCOPY arch/x86/boot/vmlinux.bin > BUILD arch/x86/boot/bzImage > Setup is 15644 bytes (padded to 15872 bytes). > System is 6663 kB > CRC 3eb90f40 > Kernel: arch/x86/boot/bzImage is ready (#48) > Building modules, stage 2. > MODPOST 165 modules > > If I comment out $(call if_changed,check_data_rel) in > arch/x86/boot/compressed/Makefile, two consecutive "make" produce > identical output i.e. seem to not do different things: > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > Kernel: arch/x86/boot/bzImage is ready (#49) > Building modules, stage 2. > MODPOST 165 modules > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > Kernel: arch/x86/boot/bzImage is ready (#49) > Building modules, stage 2. > MODPOST 165 modules > > So, I guess this different behaviour of two consecutive "make" is not > intentional but I am failing to understand why it happens. I think, I solved the puzzle and perhaps, that saves others some time: The problem is that &
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Dirk Gouders writes: > Masahiro Yamada writes: > >> syncconfig updates the .config only when sym_change_count > 0, i.e. >> any change in config symbols has been detected. >> >> Not only symbols but also comments are contained in the .config file. >> If only comments are updated, they are not fed back to the .config, >> then the stale comments are left-over. Of course, this is just a >> matter of comments, but why not fix it. > > Hello Masahiro, > > I am currently looking at and testing this series. > > First: For this patch I would suggest to also edit the syncconfig >section of "conf --help". > > Further, on a slow laptop, I was suspecting, this patch to cause full > rebuilds of everything, each time I ran "make syncconfig" followed by > "make" but could not verify this on another machine, so perhaps I am > just (for testing purposes) removing the wrong files (modules.builtin > for example) -- I am still testing. > > But, what irritates me with testing is that (also without your > patches) two consecutive "make" produce different output, one of them > always shows a warning and this is reproducable. I just want to make > sure there is no other problem that influences my testing: > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > DATAREL arch/x86/boot/compressed/vmlinux > Kernel: arch/x86/boot/bzImage is ready (#15) > Building modules, stage 2. > MODPOST 211 modules > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > LD arch/x86/boot/compressed/vmlinux > ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only > section `.head.text' > ld: warning: creating a DT_TEXTREL in object. > ZOFFSET arch/x86/boot/zoffset.h > AS arch/x86/boot/header.o > LD arch/x86/boot/setup.elf > OBJCOPY arch/x86/boot/setup.bin > OBJCOPY arch/x86/boot/vmlinux.bin > BUILD arch/x86/boot/bzImage > Setup is 15580 bytes (padded to 15872 bytes). > System is 8069 kB > CRC e01d75ec > Kernel: arch/x86/boot/bzImage is ready (#15) > Building modules, stage 2. > MODPOST 211 modules I spent some more time with the behaviour described above and bisected to the commit after that two consecutive invocations of "make" (on an already compiled tree) seem to do different things. That commit is 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I put Kees and Ingo on CC. I did the bisecting on another system, so I'll provide the output of two consecutive "make" on an already compiled tree on that machine: $ make CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h DATAREL arch/x86/boot/compressed/vmlinux Kernel: arch/x86/boot/bzImage is ready (#48) Building modules, stage 2. MODPOST 165 modules $ make CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h LD arch/x86/boot/compressed/vmlinux ZOFFSET arch/x86/boot/zoffset.h AS arch/x86/boot/header.o LD arch/x86/boot/setup.elf OBJCOPY arch/x86/boot/setup.bin OBJCOPY arch/x86/boot/vmlinux.bin BUILD arch/x86/boot/bzImage Setup is 15644 bytes (padded to 15872 bytes). System is 6663 kB CRC 3eb90f40 Kernel: arch/x86/boot/bzImage is ready (#48) Building modules, stage 2. MODPOST 165 modules If I comment out $(call if_changed,check_data_rel) in arch/x86/boot/compressed/Makefile, two consecutive "make" produce identical output i.e. seem to not do different things: $ make CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h Kernel: arch/x86/boot/bzImage is ready (#49) Building modules, stage 2. MODPOST 165 modules $ make CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h Kernel: arch/x86/boot/bzImage is ready (#49) Building modules, stage 2. MODPOST 165 modules So, I guess this different behaviour of two consecutive "make" is not intentional but I am failing to understand why it happens. Dirk > > Dirk > >> I see some scenarios where this happens. >> >> Scenario A: >> >> 1. You have a source tree that has already been configured. >> >> 2. Linus increments the version number in the top-level Makefile >> (i.e. he commits a new release) >> >> 3. You pull it, and run 'make' >> >> 4. syncconfig is invoked because the environment variable, >> KERNELVERSION is updated, but the .config is not updated since >> no config symbol is changed. >> >> 5. The .config file contains a kernel version in the top lin
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Dirk Gouders writes: > Masahiro Yamada writes: > >> syncconfig updates the .config only when sym_change_count > 0, i.e. >> any change in config symbols has been detected. >> >> Not only symbols but also comments are contained in the .config file. >> If only comments are updated, they are not fed back to the .config, >> then the stale comments are left-over. Of course, this is just a >> matter of comments, but why not fix it. > > Hello Masahiro, > > I am currently looking at and testing this series. > > First: For this patch I would suggest to also edit the syncconfig >section of "conf --help". > > Further, on a slow laptop, I was suspecting, this patch to cause full > rebuilds of everything, each time I ran "make syncconfig" followed by > "make" but could not verify this on another machine, so perhaps I am > just (for testing purposes) removing the wrong files (modules.builtin > for example) -- I am still testing. > > But, what irritates me with testing is that (also without your > patches) two consecutive "make" produce different output, one of them > always shows a warning and this is reproducable. I just want to make > sure there is no other problem that influences my testing: > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > DATAREL arch/x86/boot/compressed/vmlinux > Kernel: arch/x86/boot/bzImage is ready (#15) > Building modules, stage 2. > MODPOST 211 modules > > $ make > CALLscripts/checksyscalls.sh > DESCEND objtool > CHK include/generated/compile.h > LD arch/x86/boot/compressed/vmlinux > ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only > section `.head.text' > ld: warning: creating a DT_TEXTREL in object. > ZOFFSET arch/x86/boot/zoffset.h > AS arch/x86/boot/header.o > LD arch/x86/boot/setup.elf > OBJCOPY arch/x86/boot/setup.bin > OBJCOPY arch/x86/boot/vmlinux.bin > BUILD arch/x86/boot/bzImage > Setup is 15580 bytes (padded to 15872 bytes). > System is 8069 kB > CRC e01d75ec > Kernel: arch/x86/boot/bzImage is ready (#15) > Building modules, stage 2. > MODPOST 211 modules I spent some more time with the behaviour described above and bisected to the commit after that two consecutive invocations of "make" (on an already compiled tree) seem to do different things. That commit is 98f78525371b55cc (x86/boot: Refuse to build with data relocations), so I put Kees and Ingo on CC. I did the bisecting on another system, so I'll provide the output of two consecutive "make" on an already compiled tree on that machine: $ make CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h DATAREL arch/x86/boot/compressed/vmlinux Kernel: arch/x86/boot/bzImage is ready (#48) Building modules, stage 2. MODPOST 165 modules $ make CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h LD arch/x86/boot/compressed/vmlinux ZOFFSET arch/x86/boot/zoffset.h AS arch/x86/boot/header.o LD arch/x86/boot/setup.elf OBJCOPY arch/x86/boot/setup.bin OBJCOPY arch/x86/boot/vmlinux.bin BUILD arch/x86/boot/bzImage Setup is 15644 bytes (padded to 15872 bytes). System is 6663 kB CRC 3eb90f40 Kernel: arch/x86/boot/bzImage is ready (#48) Building modules, stage 2. MODPOST 165 modules If I comment out $(call if_changed,check_data_rel) in arch/x86/boot/compressed/Makefile, two consecutive "make" produce identical output i.e. seem to not do different things: $ make CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h Kernel: arch/x86/boot/bzImage is ready (#49) Building modules, stage 2. MODPOST 165 modules $ make CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h Kernel: arch/x86/boot/bzImage is ready (#49) Building modules, stage 2. MODPOST 165 modules So, I guess this different behaviour of two consecutive "make" is not intentional but I am failing to understand why it happens. Dirk > > Dirk > >> I see some scenarios where this happens. >> >> Scenario A: >> >> 1. You have a source tree that has already been configured. >> >> 2. Linus increments the version number in the top-level Makefile >> (i.e. he commits a new release) >> >> 3. You pull it, and run 'make' >> >> 4. syncconfig is invoked because the environment variable, >> KERNELVERSION is updated, but the .config is not updated since >> no config symbol is changed. >> >> 5. The .config file contains a kernel version in the top lin
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Masahiro Yamada writes:
> syncconfig updates the .config only when sym_change_count > 0, i.e.
> any change in config symbols has been detected.
>
> Not only symbols but also comments are contained in the .config file.
> If only comments are updated, they are not fed back to the .config,
> then the stale comments are left-over. Of course, this is just a
> matter of comments, but why not fix it.
Hello Masahiro,
I am currently looking at and testing this series.
First: For this patch I would suggest to also edit the syncconfig
section of "conf --help".
Further, on a slow laptop, I was suspecting, this patch to cause full
rebuilds of everything, each time I ran "make syncconfig" followed by
"make" but could not verify this on another machine, so perhaps I am
just (for testing purposes) removing the wrong files (modules.builtin
for example) -- I am still testing.
But, what irritates me with testing is that (also without your
patches) two consecutive "make" produce different output, one of them
always shows a warning and this is reproducable. I just want to make
sure there is no other problem that influences my testing:
$ make
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
DATAREL arch/x86/boot/compressed/vmlinux
Kernel: arch/x86/boot/bzImage is ready (#15)
Building modules, stage 2.
MODPOST 211 modules
$ make
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
LD arch/x86/boot/compressed/vmlinux
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only
section `.head.text'
ld: warning: creating a DT_TEXTREL in object.
ZOFFSET arch/x86/boot/zoffset.h
AS arch/x86/boot/header.o
LD arch/x86/boot/setup.elf
OBJCOPY arch/x86/boot/setup.bin
OBJCOPY arch/x86/boot/vmlinux.bin
BUILD arch/x86/boot/bzImage
Setup is 15580 bytes (padded to 15872 bytes).
System is 8069 kB
CRC e01d75ec
Kernel: arch/x86/boot/bzImage is ready (#15)
Building modules, stage 2.
MODPOST 211 modules
Dirk
> I see some scenarios where this happens.
>
> Scenario A:
>
> 1. You have a source tree that has already been configured.
>
> 2. Linus increments the version number in the top-level Makefile
> (i.e. he commits a new release)
>
> 3. You pull it, and run 'make'
>
> 4. syncconfig is invoked because the environment variable,
> KERNELVERSION is updated, but the .config is not updated since
> no config symbol is changed.
>
> 5. The .config file contains a kernel version in the top line:
>
> # Automatically generated file; DO NOT EDIT.
> # Linux/arm64 4.18.0-rc2 Kernel Configuration
>
> ... which points to a previous version.
>
> Scenario B:
>
> 1. You have a source tree that has already been configured.
>
> 2. You upgrade the compiler, but it still has the same version number.
> This may happen if you regularly build the latest compiler from
> the source code.
>
> 3. You run 'make'
>
> 4. syncconfig is invoked because the environment variable,
> CC_VERSION_TEXT is updated, but the .config is not updated since
> no config symbol is changed.
>
> 5. The .config file contains the version string of the compiler:
>
> #
> # Compiler: aarch64-linux-gcc (GCC) 9.0.0 20180628 (experimental)
> #
>
> ... which carries the information of the old compiler.
>
> If KCONFIG_NOSILENTUPDATE is set, syncconfig is not allowed to update
> the .config file. Otherwise, it is fine to update it regardless of
> sym_change_count.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/conf.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
> index 671ff53..5af8991 100644
> --- a/scripts/kconfig/conf.c
> +++ b/scripts/kconfig/conf.c
> @@ -496,6 +496,7 @@ int main(int ac, char **av)
> int opt;
> const char *name, *defconfig_file = NULL /* gcc uninit */;
> struct stat tmpstat;
> + int no_conf_write = 0;
>
> tty_stdio = isatty(0) && isatty(1);
>
> @@ -633,13 +634,14 @@ int main(int ac, char **av)
> }
>
> if (sync_kconfig) {
> - if (conf_get_changed()) {
> - name = getenv("KCONFIG_NOSILENTUPDATE");
> - if (name && *name) {
> + name = getenv("KCONFIG_NOSILENTUPDATE");
> + if (name && *name) {
> + if (conf_get_changed()) {
> fprintf(stderr,
> "\n*** The configuration requires
> explicit update.\n\n"
Re: [PATCH v3 05/12] kconfig: make syncconfig update .config regardless of sym_change_count
Masahiro Yamada writes:
> syncconfig updates the .config only when sym_change_count > 0, i.e.
> any change in config symbols has been detected.
>
> Not only symbols but also comments are contained in the .config file.
> If only comments are updated, they are not fed back to the .config,
> then the stale comments are left-over. Of course, this is just a
> matter of comments, but why not fix it.
Hello Masahiro,
I am currently looking at and testing this series.
First: For this patch I would suggest to also edit the syncconfig
section of "conf --help".
Further, on a slow laptop, I was suspecting, this patch to cause full
rebuilds of everything, each time I ran "make syncconfig" followed by
"make" but could not verify this on another machine, so perhaps I am
just (for testing purposes) removing the wrong files (modules.builtin
for example) -- I am still testing.
But, what irritates me with testing is that (also without your
patches) two consecutive "make" produce different output, one of them
always shows a warning and this is reproducable. I just want to make
sure there is no other problem that influences my testing:
$ make
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
DATAREL arch/x86/boot/compressed/vmlinux
Kernel: arch/x86/boot/bzImage is ready (#15)
Building modules, stage 2.
MODPOST 211 modules
$ make
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
LD arch/x86/boot/compressed/vmlinux
ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only
section `.head.text'
ld: warning: creating a DT_TEXTREL in object.
ZOFFSET arch/x86/boot/zoffset.h
AS arch/x86/boot/header.o
LD arch/x86/boot/setup.elf
OBJCOPY arch/x86/boot/setup.bin
OBJCOPY arch/x86/boot/vmlinux.bin
BUILD arch/x86/boot/bzImage
Setup is 15580 bytes (padded to 15872 bytes).
System is 8069 kB
CRC e01d75ec
Kernel: arch/x86/boot/bzImage is ready (#15)
Building modules, stage 2.
MODPOST 211 modules
Dirk
> I see some scenarios where this happens.
>
> Scenario A:
>
> 1. You have a source tree that has already been configured.
>
> 2. Linus increments the version number in the top-level Makefile
> (i.e. he commits a new release)
>
> 3. You pull it, and run 'make'
>
> 4. syncconfig is invoked because the environment variable,
> KERNELVERSION is updated, but the .config is not updated since
> no config symbol is changed.
>
> 5. The .config file contains a kernel version in the top line:
>
> # Automatically generated file; DO NOT EDIT.
> # Linux/arm64 4.18.0-rc2 Kernel Configuration
>
> ... which points to a previous version.
>
> Scenario B:
>
> 1. You have a source tree that has already been configured.
>
> 2. You upgrade the compiler, but it still has the same version number.
> This may happen if you regularly build the latest compiler from
> the source code.
>
> 3. You run 'make'
>
> 4. syncconfig is invoked because the environment variable,
> CC_VERSION_TEXT is updated, but the .config is not updated since
> no config symbol is changed.
>
> 5. The .config file contains the version string of the compiler:
>
> #
> # Compiler: aarch64-linux-gcc (GCC) 9.0.0 20180628 (experimental)
> #
>
> ... which carries the information of the old compiler.
>
> If KCONFIG_NOSILENTUPDATE is set, syncconfig is not allowed to update
> the .config file. Otherwise, it is fine to update it regardless of
> sym_change_count.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/conf.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
> index 671ff53..5af8991 100644
> --- a/scripts/kconfig/conf.c
> +++ b/scripts/kconfig/conf.c
> @@ -496,6 +496,7 @@ int main(int ac, char **av)
> int opt;
> const char *name, *defconfig_file = NULL /* gcc uninit */;
> struct stat tmpstat;
> + int no_conf_write = 0;
>
> tty_stdio = isatty(0) && isatty(1);
>
> @@ -633,13 +634,14 @@ int main(int ac, char **av)
> }
>
> if (sync_kconfig) {
> - if (conf_get_changed()) {
> - name = getenv("KCONFIG_NOSILENTUPDATE");
> - if (name && *name) {
> + name = getenv("KCONFIG_NOSILENTUPDATE");
> + if (name && *name) {
> + if (conf_get_changed()) {
> fprintf(stderr,
> "\n*** The configuration requires
> explicit update.\n\n"
[RFC v9 1/1] mconf: global i-search in menu prompts
Some menus in the kernel configuration are rather large and it can be time-consuming for a user to navigate through several menu items to reach the menu entry that he wants to modify -- for users with less than 100% healthy eyes, this process can also be challenging. An i-search functionality could safe the user from a lot of reading if he knows a keyword that can be used for navigation and this patch implements an i-search navigation concept for mconf based on an idea by Sam Ravnborg: * mconf now distinguishes if the focus is on the menu items or the buttons below it. * At startup focus is on the menu items and printable characters (details see below) entered are used to form a string that is searched for in the menu prompts. This patch implements a global cyclic i-search in the prompts of the complete menu tree. For this, a new helper function menu_get_next() is used. This function returns the successor of any node in the menu tree in cyclic depth-first traversal order. Given this function and the following tree a - c - d - f | | b e the successor of each node is the one in alphabetical order and the successor of the last node 'f' is 'a'. Operation - The TAB key is reserved to toggle the focus between menu and bottons. Focus is on the buttons if one of the buttens (the active one) is hightlighted, otherwise it is on the menu. When the focus is on the buttons, mconf operates as before with the exception of the TAB key. When the focus is on the menu, mconf operates in i-search mode and the following input has special meaning: * <\> (backslash) can be used to search for other occurences of an already entered string. On empty search strings, nothing happens. * Any other printable character than backslash and '\n' is appended to the current search string and a match is searched for. If a match is found, it is immediately navigated to. * BACKSPACE is used to remove the last character of the search string. * DEL clears the search string. * ENTER can be used to enter a submenu. * ESC ESC exits the current isearch and clears the search string. * Horizontal arrow keys still cycle between the buttons but also switch focus to the buttons. * Vertical arroy keys navigate the menu items. At any time, at most one i-search is active and the navigation path to the current menu is displayed in the subtitle, the second line in the menu window. Navigation example: To navigate to options concerning NFS file systems, simply type 'n', 'f' and 's'. Hint: use the 'z' key with focus on buttons to search for invisible prompts. Particular changes to existing code --- * New function menu_get_next() that returns the successor of any node in the menu tree in cyclic depth-first order. * The function print_autowrap() only printed non-whitespace characters and thus could not be used to overwrite existing text. It was extended by a parameter "height" and in combination with the parameter "width" it now makes sure that the whole region (width x height) is overwritten. * The function conf() now returns the key the user pressed so that calling functions can operate depending on that key. Signed-off-by: Dirk Gouders Tested-by: Randy Dunlap --- scripts/kconfig/lkc.h| 1 + scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 9 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 179 ++- scripts/kconfig/lxdialog/util.c | 45 - scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 169 +++-- scripts/kconfig/menu.c | 28 ++ 9 files changed, 398 insertions(+), 39 deletions(-) diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h index ed3ff88e60ba..22b96530234d 100644 --- a/scripts/kconfig/lkc.h +++ b/scripts/kconfig/lkc.h @@ -81,6 +81,7 @@ static inline void xfwrite(const void *str, size_t len, size_t count, FILE *out) } /* menu.c */ +struct menu *menu_get_next(struct menu *m); void _menu_init(void); void menu_warn(struct menu *menu, const char *fmt, ...); struct menu *menu_add_menu(void); diff --git a/scripts/kconfig/lxdialog/checklist.c b/scripts/kconfig/lxdialog/checklist.c index 2e96323ad11b..2a8bd877af72 100644 --- a/scripts/kconfig/lxdialog/checklist.c +++ b/scripts/kconfig/lxdialog/checklist.c @@ -160,7 +160,7 @@ int dialog_checklist(const char *title, const char *prompt, int height, print_title(dialog, title, width); wattrset(dialog, dlg.dialog.atr); - print_autowrap(dialog, prompt, width - 2, 1, 3); + print_autowrap(dialog, prompt, width - 2, 3, 1, 3); list_width = width - 6; box_y = height - list_height - 5; diff --git a/scripts/kconfig/lxdialog/dialog.h b/scripts/kconfig/lxdialog/dialog.h index 0b00be5abaa6..801cca2
[RFC v9 0/1] mconf: global i-search in menu prompts
Hello, v9 of this RFC mainly fixes an issue reported by Randy, I tested this fix a lot and it seems it is ready to send out. Dirk Changes in v9: * Move global variable declarations to lxdialog/dialog.h * Don't do unnecessary initialization of isearch_str. * Fix an issue with '-' and '+' not added to the search pattern. The historical handling of those characters now (again) happens after input has been checked for i-search relevance. * Ensure the unused part of isearch_str is filled with '\0' so there is no need to do string termination each time a character is added. Changes in v8: * Get rid of flat_array and use a short helper function menu_get_next() for tree traversal. * Correct typos reported by Randy Dunlap. Changes in v7: * make menu_isearch() return void * Suggested-by removed, ask for Sam's permission * Rework i-search instructions text * Remember exact starting position in menu * Stay on menu item if it matches pattern with a character added * Fix print_autowrap for short texts * Focus on buttons: use A_STANDOUT for current menu item * Fix compiler warnings * Don't exclude comments in searches * ESC also clears search string * Remove the last parameter of print_isearch and use focus_on_buttons instead * Document changes to print_autowrap and conf() in commit message * Rework comments in the code * Rework commit message, add a motivation part * Free serialized menu array on exit Changes in v6: * The modification of the function print_autowrap() was reworked and is no longer a separate function. * The i-search navigation was completely reworked and now works on the whole menu tree. * Hotkeys are back, because they do not interfere that much with this version of i-search navigation. Changes in v5: * More thoroughly tested code * Hotkey navigation concept completely dropped * Printable characters except special ones form the search string * Focus-sensitive help text above menu * DEL erases search string * Matching string is highlighted in selected menu item * README help text adjusted Changes in v4: * Prototype: consequent i-search navigation concept Changes in v3: * Use current git tree to make the patch apply. * Eliminate debugging output to stderr. Changes in v2: * Additionally to CTRL-s, \ can be used to start isearch. * Raw mode is off by default an can be enabled by an environment variable MENUCONFIG_RAW_MODE. * I also added a variable for toggling raw mode but did not implement anything else. * The isearch indicator is now displayed as soon as isearch is started. * Any key except \, CTRL-s, alphanumeric characters and space terminates isearch and -- except ESC ESC -- is further processed, e.g. ENTER terminates isearch and is then used to navigate into a submenu. * Problems with mismatches and matches above the current position were fixed. Dirk Gouders (1): mconf: global i-search in menu prompts scripts/kconfig/lkc.h| 1 + scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 9 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 179 ++- scripts/kconfig/lxdialog/util.c | 45 - scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 169 +++-- scripts/kconfig/menu.c | 28 ++ 9 files changed, 398 insertions(+), 39 deletions(-) -- 2.13.6
[RFC v9 1/1] mconf: global i-search in menu prompts
Some menus in the kernel configuration are rather large and it can be time-consuming for a user to navigate through several menu items to reach the menu entry that he wants to modify -- for users with less than 100% healthy eyes, this process can also be challenging. An i-search functionality could safe the user from a lot of reading if he knows a keyword that can be used for navigation and this patch implements an i-search navigation concept for mconf based on an idea by Sam Ravnborg: * mconf now distinguishes if the focus is on the menu items or the buttons below it. * At startup focus is on the menu items and printable characters (details see below) entered are used to form a string that is searched for in the menu prompts. This patch implements a global cyclic i-search in the prompts of the complete menu tree. For this, a new helper function menu_get_next() is used. This function returns the successor of any node in the menu tree in cyclic depth-first traversal order. Given this function and the following tree a - c - d - f | | b e the successor of each node is the one in alphabetical order and the successor of the last node 'f' is 'a'. Operation - The TAB key is reserved to toggle the focus between menu and bottons. Focus is on the buttons if one of the buttens (the active one) is hightlighted, otherwise it is on the menu. When the focus is on the buttons, mconf operates as before with the exception of the TAB key. When the focus is on the menu, mconf operates in i-search mode and the following input has special meaning: * <\> (backslash) can be used to search for other occurences of an already entered string. On empty search strings, nothing happens. * Any other printable character than backslash and '\n' is appended to the current search string and a match is searched for. If a match is found, it is immediately navigated to. * BACKSPACE is used to remove the last character of the search string. * DEL clears the search string. * ENTER can be used to enter a submenu. * ESC ESC exits the current isearch and clears the search string. * Horizontal arrow keys still cycle between the buttons but also switch focus to the buttons. * Vertical arroy keys navigate the menu items. At any time, at most one i-search is active and the navigation path to the current menu is displayed in the subtitle, the second line in the menu window. Navigation example: To navigate to options concerning NFS file systems, simply type 'n', 'f' and 's'. Hint: use the 'z' key with focus on buttons to search for invisible prompts. Particular changes to existing code --- * New function menu_get_next() that returns the successor of any node in the menu tree in cyclic depth-first order. * The function print_autowrap() only printed non-whitespace characters and thus could not be used to overwrite existing text. It was extended by a parameter "height" and in combination with the parameter "width" it now makes sure that the whole region (width x height) is overwritten. * The function conf() now returns the key the user pressed so that calling functions can operate depending on that key. Signed-off-by: Dirk Gouders Tested-by: Randy Dunlap --- scripts/kconfig/lkc.h| 1 + scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 9 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 179 ++- scripts/kconfig/lxdialog/util.c | 45 - scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 169 +++-- scripts/kconfig/menu.c | 28 ++ 9 files changed, 398 insertions(+), 39 deletions(-) diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h index ed3ff88e60ba..22b96530234d 100644 --- a/scripts/kconfig/lkc.h +++ b/scripts/kconfig/lkc.h @@ -81,6 +81,7 @@ static inline void xfwrite(const void *str, size_t len, size_t count, FILE *out) } /* menu.c */ +struct menu *menu_get_next(struct menu *m); void _menu_init(void); void menu_warn(struct menu *menu, const char *fmt, ...); struct menu *menu_add_menu(void); diff --git a/scripts/kconfig/lxdialog/checklist.c b/scripts/kconfig/lxdialog/checklist.c index 2e96323ad11b..2a8bd877af72 100644 --- a/scripts/kconfig/lxdialog/checklist.c +++ b/scripts/kconfig/lxdialog/checklist.c @@ -160,7 +160,7 @@ int dialog_checklist(const char *title, const char *prompt, int height, print_title(dialog, title, width); wattrset(dialog, dlg.dialog.atr); - print_autowrap(dialog, prompt, width - 2, 1, 3); + print_autowrap(dialog, prompt, width - 2, 3, 1, 3); list_width = width - 6; box_y = height - list_height - 5; diff --git a/scripts/kconfig/lxdialog/dialog.h b/scripts/kconfig/lxdialog/dialog.h index 0b00be5abaa6..801cca2
[RFC v9 0/1] mconf: global i-search in menu prompts
Hello, v9 of this RFC mainly fixes an issue reported by Randy, I tested this fix a lot and it seems it is ready to send out. Dirk Changes in v9: * Move global variable declarations to lxdialog/dialog.h * Don't do unnecessary initialization of isearch_str. * Fix an issue with '-' and '+' not added to the search pattern. The historical handling of those characters now (again) happens after input has been checked for i-search relevance. * Ensure the unused part of isearch_str is filled with '\0' so there is no need to do string termination each time a character is added. Changes in v8: * Get rid of flat_array and use a short helper function menu_get_next() for tree traversal. * Correct typos reported by Randy Dunlap. Changes in v7: * make menu_isearch() return void * Suggested-by removed, ask for Sam's permission * Rework i-search instructions text * Remember exact starting position in menu * Stay on menu item if it matches pattern with a character added * Fix print_autowrap for short texts * Focus on buttons: use A_STANDOUT for current menu item * Fix compiler warnings * Don't exclude comments in searches * ESC also clears search string * Remove the last parameter of print_isearch and use focus_on_buttons instead * Document changes to print_autowrap and conf() in commit message * Rework comments in the code * Rework commit message, add a motivation part * Free serialized menu array on exit Changes in v6: * The modification of the function print_autowrap() was reworked and is no longer a separate function. * The i-search navigation was completely reworked and now works on the whole menu tree. * Hotkeys are back, because they do not interfere that much with this version of i-search navigation. Changes in v5: * More thoroughly tested code * Hotkey navigation concept completely dropped * Printable characters except special ones form the search string * Focus-sensitive help text above menu * DEL erases search string * Matching string is highlighted in selected menu item * README help text adjusted Changes in v4: * Prototype: consequent i-search navigation concept Changes in v3: * Use current git tree to make the patch apply. * Eliminate debugging output to stderr. Changes in v2: * Additionally to CTRL-s, \ can be used to start isearch. * Raw mode is off by default an can be enabled by an environment variable MENUCONFIG_RAW_MODE. * I also added a variable for toggling raw mode but did not implement anything else. * The isearch indicator is now displayed as soon as isearch is started. * Any key except \, CTRL-s, alphanumeric characters and space terminates isearch and -- except ESC ESC -- is further processed, e.g. ENTER terminates isearch and is then used to navigate into a submenu. * Problems with mismatches and matches above the current position were fixed. Dirk Gouders (1): mconf: global i-search in menu prompts scripts/kconfig/lkc.h| 1 + scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 9 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 179 ++- scripts/kconfig/lxdialog/util.c | 45 - scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 169 +++-- scripts/kconfig/menu.c | 28 ++ 9 files changed, 398 insertions(+), 39 deletions(-) -- 2.13.6
Re: [RFC v8 1/1] mconf: global i-search in menu prompts
Randy Dunlap writes: > On 06/20/2018 11:55 AM, Dirk Gouders wrote: >> Randy Dunlap writes: >> >>> Hi, >>> >>> On 06/20/2018 01:42 AM, Dirk Gouders wrote: >>>> >>>> Operation >>>> - >>>> The TAB key is reserved to toggle the focus between menu and bottons. >>>> Focus is on the buttons if one of the buttens (the active one) is >>>> hightlighted, otherwise it is on the menu. >>>> >>>> When the focus is on the buttons, mconf operates as before with the >>>> exception of the TAB key. >>>> >>>> When the focus is on the menu, mconf operates in i-search mode and the >>>> following input has special meaning: >>>> >>>> * <\> (backslash) can be used to search for other occurences of an >>>> already entered string. On empty search strings, nothing happens. >>>> >>>> * Any other printable character than backslash and '\n' is appended to >>>> the current search string and a match is searched for. If a match >>>> is found, it is immediately navigated to. >>> >>> About that paragraph above: I tried to search for "fs-cache", as in: >>> >>> config FSCACHE_DEBUG >>> bool "Debug FS-Cache" >>> >>> but i-search does not allow me to enter a '-' character. Seems odd to me. >> >> Hi Randy, >> >> thanks for all your testing. >> >> '-' and '+' previously had the same meaning as , , >> respectively. If you are on the top menu item and press '-' there is >> nothing to scroll up so it appears as if the pressed key wasn't >> processed. >> >> I-search should add those characters to the pattern but I broke that two >> or three versions before when I fixed another issue. >> >> I will add this to my list of test cases so this won't happen again. >> >> Dirk >> >> >>> Still doing other testing... > > I haven't hit any other issues. Thank you for testing! The issue concerning '-' and '+' I will fix. Dirk
Re: [RFC v8 1/1] mconf: global i-search in menu prompts
Randy Dunlap writes: > On 06/20/2018 11:55 AM, Dirk Gouders wrote: >> Randy Dunlap writes: >> >>> Hi, >>> >>> On 06/20/2018 01:42 AM, Dirk Gouders wrote: >>>> >>>> Operation >>>> - >>>> The TAB key is reserved to toggle the focus between menu and bottons. >>>> Focus is on the buttons if one of the buttens (the active one) is >>>> hightlighted, otherwise it is on the menu. >>>> >>>> When the focus is on the buttons, mconf operates as before with the >>>> exception of the TAB key. >>>> >>>> When the focus is on the menu, mconf operates in i-search mode and the >>>> following input has special meaning: >>>> >>>> * <\> (backslash) can be used to search for other occurences of an >>>> already entered string. On empty search strings, nothing happens. >>>> >>>> * Any other printable character than backslash and '\n' is appended to >>>> the current search string and a match is searched for. If a match >>>> is found, it is immediately navigated to. >>> >>> About that paragraph above: I tried to search for "fs-cache", as in: >>> >>> config FSCACHE_DEBUG >>> bool "Debug FS-Cache" >>> >>> but i-search does not allow me to enter a '-' character. Seems odd to me. >> >> Hi Randy, >> >> thanks for all your testing. >> >> '-' and '+' previously had the same meaning as , , >> respectively. If you are on the top menu item and press '-' there is >> nothing to scroll up so it appears as if the pressed key wasn't >> processed. >> >> I-search should add those characters to the pattern but I broke that two >> or three versions before when I fixed another issue. >> >> I will add this to my list of test cases so this won't happen again. >> >> Dirk >> >> >>> Still doing other testing... > > I haven't hit any other issues. Thank you for testing! The issue concerning '-' and '+' I will fix. Dirk
Re: [RFC v8 1/1] mconf: global i-search in menu prompts
Randy Dunlap writes: > Hi, > > On 06/20/2018 01:42 AM, Dirk Gouders wrote: >> >> Operation >> - >> The TAB key is reserved to toggle the focus between menu and bottons. >> Focus is on the buttons if one of the buttens (the active one) is >> hightlighted, otherwise it is on the menu. >> >> When the focus is on the buttons, mconf operates as before with the >> exception of the TAB key. >> >> When the focus is on the menu, mconf operates in i-search mode and the >> following input has special meaning: >> >> * <\> (backslash) can be used to search for other occurences of an >> already entered string. On empty search strings, nothing happens. >> >> * Any other printable character than backslash and '\n' is appended to >> the current search string and a match is searched for. If a match >> is found, it is immediately navigated to. > > About that paragraph above: I tried to search for "fs-cache", as in: > > config FSCACHE_DEBUG > bool "Debug FS-Cache" > > but i-search does not allow me to enter a '-' character. Seems odd to me. Hi Randy, thanks for all your testing. '-' and '+' previously had the same meaning as , , respectively. If you are on the top menu item and press '-' there is nothing to scroll up so it appears as if the pressed key wasn't processed. I-search should add those characters to the pattern but I broke that two or three versions before when I fixed another issue. I will add this to my list of test cases so this won't happen again. Dirk > Still doing other testing... > > >> * BACKSPACE is used to remove the last character of the search string. >> >> * DEL clears the search string. >> >> * ENTER can be used to enter a submenu. >> >> * ESC ESC exits the current isearch and clears the search string. >> >> * Horizontal arrow keys still cycle between the buttons but also >> switch focus to the buttons. >> >> * Vertical arroy keys navigate the menu items. >> >> At any time, at most one i-search is active and the navigation path to >> the current menu is displayed in the subtitle, the second line in the >> menu window. >> >> Navigation example: >> >> To navigate to options concerning NFS file systems, simply type 'n', >> 'f' and 's'. >> >> Hint: use the 'z' key with focus on buttons to search for invisible >> prompts.
Re: [RFC v8 1/1] mconf: global i-search in menu prompts
Randy Dunlap writes: > Hi, > > On 06/20/2018 01:42 AM, Dirk Gouders wrote: >> >> Operation >> - >> The TAB key is reserved to toggle the focus between menu and bottons. >> Focus is on the buttons if one of the buttens (the active one) is >> hightlighted, otherwise it is on the menu. >> >> When the focus is on the buttons, mconf operates as before with the >> exception of the TAB key. >> >> When the focus is on the menu, mconf operates in i-search mode and the >> following input has special meaning: >> >> * <\> (backslash) can be used to search for other occurences of an >> already entered string. On empty search strings, nothing happens. >> >> * Any other printable character than backslash and '\n' is appended to >> the current search string and a match is searched for. If a match >> is found, it is immediately navigated to. > > About that paragraph above: I tried to search for "fs-cache", as in: > > config FSCACHE_DEBUG > bool "Debug FS-Cache" > > but i-search does not allow me to enter a '-' character. Seems odd to me. Hi Randy, thanks for all your testing. '-' and '+' previously had the same meaning as , , respectively. If you are on the top menu item and press '-' there is nothing to scroll up so it appears as if the pressed key wasn't processed. I-search should add those characters to the pattern but I broke that two or three versions before when I fixed another issue. I will add this to my list of test cases so this won't happen again. Dirk > Still doing other testing... > > >> * BACKSPACE is used to remove the last character of the search string. >> >> * DEL clears the search string. >> >> * ENTER can be used to enter a submenu. >> >> * ESC ESC exits the current isearch and clears the search string. >> >> * Horizontal arrow keys still cycle between the buttons but also >> switch focus to the buttons. >> >> * Vertical arroy keys navigate the menu items. >> >> At any time, at most one i-search is active and the navigation path to >> the current menu is displayed in the subtitle, the second line in the >> menu window. >> >> Navigation example: >> >> To navigate to options concerning NFS file systems, simply type 'n', >> 'f' and 's'. >> >> Hint: use the 'z' key with focus on buttons to search for invisible >> prompts.
[RFC v8 0/1] mconf: global i-search in menu prompts
Hello, Randy noticed segfaults with the last version and although that could be fixed, this version got rid of the additional data structure, because it is not needed to do the traversal. As everything is in place more or less now, it became rather forcibly clear that the tree traversal can be done with just a short helper function (see commit message). What I meanwhile noticed is that a search for 'retpoline' did not match any prompt, whereas the same search in config symbols gets a hit. That made me think if i-search should search the symbol names as well but in this case, it would not be immediately clear to users why menu items produced a hit... Anyway, this time, I provide a sample Kconfig file that can be used to easily watch the traversal as shown in the example in the commit message (just repeatedly search for 'a' from any position in the menu): config a bool "a" config b bool "b / a" depends on a config c bool "c / a" menu "d / a" config e bool "e / a" endmenu config f bool "f / a" Dirk Changes in v8: * Get rid of flat_array and use a short helper function menu_get_next() for tree traversal. * Correct typos reported by Randy Dunlap. Changes in v7: * make menu_isearch() return void * Suggested-by removed, ask for Sam's permission * Rework i-search instructions text * Remember exact starting position in menu * Stay on menu item if it matches pattern with a character added * Fix print_autowrap for short texts * Focus on buttons: use A_STANDOUT for current menu item * Fix compiler warnings * Don't exclude comments in searches * ESC also clears search string * Remove the last parameter of print_isearch and use focus_on_buttons instead * Document changes to print_autowrap and conf() in commit message * Rework comments in the code * Rework commit message, add a motivation part * Free serialized menu array on exit Changes in v6: * The modification of the function print_autowrap() was reworked and is no longer a separate function. * The i-search navigation was completely reworked and now works on the whole menu tree. * Hotkeys are back, because they do not interfere that much with this version of i-search navigation. Changes in v5: * More thoroughly tested code * Hotkey navigation concept completely dropped * Printable characters except special ones form the search string * Focus-sensitive help text above menu * DEL erases search string * Matching string is highlighted in selected menu item * README help text adjusted Changes in v4: * Prototype: consequent i-search navigation concept Changes in v3: * Use current git tree to make the patch apply. * Eliminate debugging output to stderr. Changes in v2: * Additionally to CTRL-s, \ can be used to start isearch. * Raw mode is off by default an can be enabled by an environment variable MENUCONFIG_RAW_MODE. * I also added a variable for toggling raw mode but did not implement anything else. * The isearch indicator is now displayed as soon as isearch is started. * Any key except \, CTRL-s, alphanumeric characters and space terminates isearch and -- except ESC ESC -- is further processed, e.g. ENTER terminates isearch and is then used to navigate into a submenu. * Problems with mismatches and matches above the current position were fixed. Dirk Gouders (1): mconf: global i-search in menu prompts scripts/kconfig/lkc.h| 1 + scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 181 ++- scripts/kconfig/lxdialog/util.c | 45 - scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 173 +++-- scripts/kconfig/menu.c | 28 ++ 9 files changed, 398 insertions(+), 39 deletions(-) -- 2.13.6
[RFC v8 0/1] mconf: global i-search in menu prompts
Hello, Randy noticed segfaults with the last version and although that could be fixed, this version got rid of the additional data structure, because it is not needed to do the traversal. As everything is in place more or less now, it became rather forcibly clear that the tree traversal can be done with just a short helper function (see commit message). What I meanwhile noticed is that a search for 'retpoline' did not match any prompt, whereas the same search in config symbols gets a hit. That made me think if i-search should search the symbol names as well but in this case, it would not be immediately clear to users why menu items produced a hit... Anyway, this time, I provide a sample Kconfig file that can be used to easily watch the traversal as shown in the example in the commit message (just repeatedly search for 'a' from any position in the menu): config a bool "a" config b bool "b / a" depends on a config c bool "c / a" menu "d / a" config e bool "e / a" endmenu config f bool "f / a" Dirk Changes in v8: * Get rid of flat_array and use a short helper function menu_get_next() for tree traversal. * Correct typos reported by Randy Dunlap. Changes in v7: * make menu_isearch() return void * Suggested-by removed, ask for Sam's permission * Rework i-search instructions text * Remember exact starting position in menu * Stay on menu item if it matches pattern with a character added * Fix print_autowrap for short texts * Focus on buttons: use A_STANDOUT for current menu item * Fix compiler warnings * Don't exclude comments in searches * ESC also clears search string * Remove the last parameter of print_isearch and use focus_on_buttons instead * Document changes to print_autowrap and conf() in commit message * Rework comments in the code * Rework commit message, add a motivation part * Free serialized menu array on exit Changes in v6: * The modification of the function print_autowrap() was reworked and is no longer a separate function. * The i-search navigation was completely reworked and now works on the whole menu tree. * Hotkeys are back, because they do not interfere that much with this version of i-search navigation. Changes in v5: * More thoroughly tested code * Hotkey navigation concept completely dropped * Printable characters except special ones form the search string * Focus-sensitive help text above menu * DEL erases search string * Matching string is highlighted in selected menu item * README help text adjusted Changes in v4: * Prototype: consequent i-search navigation concept Changes in v3: * Use current git tree to make the patch apply. * Eliminate debugging output to stderr. Changes in v2: * Additionally to CTRL-s, \ can be used to start isearch. * Raw mode is off by default an can be enabled by an environment variable MENUCONFIG_RAW_MODE. * I also added a variable for toggling raw mode but did not implement anything else. * The isearch indicator is now displayed as soon as isearch is started. * Any key except \, CTRL-s, alphanumeric characters and space terminates isearch and -- except ESC ESC -- is further processed, e.g. ENTER terminates isearch and is then used to navigate into a submenu. * Problems with mismatches and matches above the current position were fixed. Dirk Gouders (1): mconf: global i-search in menu prompts scripts/kconfig/lkc.h| 1 + scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 181 ++- scripts/kconfig/lxdialog/util.c | 45 - scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 173 +++-- scripts/kconfig/menu.c | 28 ++ 9 files changed, 398 insertions(+), 39 deletions(-) -- 2.13.6
[RFC v8 1/1] mconf: global i-search in menu prompts
Some menus in the kernel configuration are rather large and it can be time-consuming for a user to navigate through several menu items to reach the menu entry that he wants to modify -- for users with less than 100% healthy eyes, this process can also be challenging. An i-search functionality could safe the user from a lot of reading if he knows a keyword that can be used for navigation and this patch implements an i-search navigation concept for mconf based on an idea by Sam Ravnborg: * mconf now distinguishes if the focus is on the menu items or the buttons below it. * At startup focus is on the menu items and printable characters (details see below) entered are used to form a string that is searched for in the menu prompts. This patch implements a global cyclic i-search in the prompts of the complete menu tree. For this, a new helper function menu_get_next() is used. This function returns the successor of any node in the menu tree in cyclic depth-first traversal order. Given this function and the following tree a - c - d - f | | b e the successor of each node is the one in alphabetical order and the successor of the last node 'f' is 'a'. Operation - The TAB key is reserved to toggle the focus between menu and bottons. Focus is on the buttons if one of the buttens (the active one) is hightlighted, otherwise it is on the menu. When the focus is on the buttons, mconf operates as before with the exception of the TAB key. When the focus is on the menu, mconf operates in i-search mode and the following input has special meaning: * <\> (backslash) can be used to search for other occurences of an already entered string. On empty search strings, nothing happens. * Any other printable character than backslash and '\n' is appended to the current search string and a match is searched for. If a match is found, it is immediately navigated to. * BACKSPACE is used to remove the last character of the search string. * DEL clears the search string. * ENTER can be used to enter a submenu. * ESC ESC exits the current isearch and clears the search string. * Horizontal arrow keys still cycle between the buttons but also switch focus to the buttons. * Vertical arroy keys navigate the menu items. At any time, at most one i-search is active and the navigation path to the current menu is displayed in the subtitle, the second line in the menu window. Navigation example: To navigate to options concerning NFS file systems, simply type 'n', 'f' and 's'. Hint: use the 'z' key with focus on buttons to search for invisible prompts. Particular changes to existing code --- * New function menu_get_next() that returns the successor of any node in the menu tree in cyclic depth-first order. * The function print_autowrap() only printed non-whitespace characters and thus could not be used to overwrite existing text. It was extended by a parameter "height" and in combination with the parameter "width" it now makes sure that the whole region (width x height) is overwritten. * The function conf() now returns the key the user pressed so that calling functions can operate depending on that key. Signed-off-by: Dirk Gouders Tested-by: Randy Dunlap --- scripts/kconfig/lkc.h| 1 + scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 181 ++- scripts/kconfig/lxdialog/util.c | 45 - scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 173 +++-- scripts/kconfig/menu.c | 28 ++ 9 files changed, 398 insertions(+), 39 deletions(-) diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h index ed3ff88e60ba..22b96530234d 100644 --- a/scripts/kconfig/lkc.h +++ b/scripts/kconfig/lkc.h @@ -81,6 +81,7 @@ static inline void xfwrite(const void *str, size_t len, size_t count, FILE *out) } /* menu.c */ +struct menu *menu_get_next(struct menu *m); void _menu_init(void); void menu_warn(struct menu *menu, const char *fmt, ...); struct menu *menu_add_menu(void); diff --git a/scripts/kconfig/lxdialog/checklist.c b/scripts/kconfig/lxdialog/checklist.c index 2e96323ad11b..2a8bd877af72 100644 --- a/scripts/kconfig/lxdialog/checklist.c +++ b/scripts/kconfig/lxdialog/checklist.c @@ -160,7 +160,7 @@ int dialog_checklist(const char *title, const char *prompt, int height, print_title(dialog, title, width); wattrset(dialog, dlg.dialog.atr); - print_autowrap(dialog, prompt, width - 2, 1, 3); + print_autowrap(dialog, prompt, width - 2, 3, 1, 3); list_width = width - 6; box_y = height - list_height - 5; diff --git a/scripts/kconfig/lxdialog/dialog.h b/scripts/kconfig/lxdialog/dialog.h index 0b00be5abaa6..9396ed2
[RFC v8 1/1] mconf: global i-search in menu prompts
Some menus in the kernel configuration are rather large and it can be time-consuming for a user to navigate through several menu items to reach the menu entry that he wants to modify -- for users with less than 100% healthy eyes, this process can also be challenging. An i-search functionality could safe the user from a lot of reading if he knows a keyword that can be used for navigation and this patch implements an i-search navigation concept for mconf based on an idea by Sam Ravnborg: * mconf now distinguishes if the focus is on the menu items or the buttons below it. * At startup focus is on the menu items and printable characters (details see below) entered are used to form a string that is searched for in the menu prompts. This patch implements a global cyclic i-search in the prompts of the complete menu tree. For this, a new helper function menu_get_next() is used. This function returns the successor of any node in the menu tree in cyclic depth-first traversal order. Given this function and the following tree a - c - d - f | | b e the successor of each node is the one in alphabetical order and the successor of the last node 'f' is 'a'. Operation - The TAB key is reserved to toggle the focus between menu and bottons. Focus is on the buttons if one of the buttens (the active one) is hightlighted, otherwise it is on the menu. When the focus is on the buttons, mconf operates as before with the exception of the TAB key. When the focus is on the menu, mconf operates in i-search mode and the following input has special meaning: * <\> (backslash) can be used to search for other occurences of an already entered string. On empty search strings, nothing happens. * Any other printable character than backslash and '\n' is appended to the current search string and a match is searched for. If a match is found, it is immediately navigated to. * BACKSPACE is used to remove the last character of the search string. * DEL clears the search string. * ENTER can be used to enter a submenu. * ESC ESC exits the current isearch and clears the search string. * Horizontal arrow keys still cycle between the buttons but also switch focus to the buttons. * Vertical arroy keys navigate the menu items. At any time, at most one i-search is active and the navigation path to the current menu is displayed in the subtitle, the second line in the menu window. Navigation example: To navigate to options concerning NFS file systems, simply type 'n', 'f' and 's'. Hint: use the 'z' key with focus on buttons to search for invisible prompts. Particular changes to existing code --- * New function menu_get_next() that returns the successor of any node in the menu tree in cyclic depth-first order. * The function print_autowrap() only printed non-whitespace characters and thus could not be used to overwrite existing text. It was extended by a parameter "height" and in combination with the parameter "width" it now makes sure that the whole region (width x height) is overwritten. * The function conf() now returns the key the user pressed so that calling functions can operate depending on that key. Signed-off-by: Dirk Gouders Tested-by: Randy Dunlap --- scripts/kconfig/lkc.h| 1 + scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 181 ++- scripts/kconfig/lxdialog/util.c | 45 - scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 173 +++-- scripts/kconfig/menu.c | 28 ++ 9 files changed, 398 insertions(+), 39 deletions(-) diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h index ed3ff88e60ba..22b96530234d 100644 --- a/scripts/kconfig/lkc.h +++ b/scripts/kconfig/lkc.h @@ -81,6 +81,7 @@ static inline void xfwrite(const void *str, size_t len, size_t count, FILE *out) } /* menu.c */ +struct menu *menu_get_next(struct menu *m); void _menu_init(void); void menu_warn(struct menu *menu, const char *fmt, ...); struct menu *menu_add_menu(void); diff --git a/scripts/kconfig/lxdialog/checklist.c b/scripts/kconfig/lxdialog/checklist.c index 2e96323ad11b..2a8bd877af72 100644 --- a/scripts/kconfig/lxdialog/checklist.c +++ b/scripts/kconfig/lxdialog/checklist.c @@ -160,7 +160,7 @@ int dialog_checklist(const char *title, const char *prompt, int height, print_title(dialog, title, width); wattrset(dialog, dlg.dialog.atr); - print_autowrap(dialog, prompt, width - 2, 1, 3); + print_autowrap(dialog, prompt, width - 2, 3, 1, 3); list_width = width - 6; box_y = height - list_height - 5; diff --git a/scripts/kconfig/lxdialog/dialog.h b/scripts/kconfig/lxdialog/dialog.h index 0b00be5abaa6..9396ed2
Re: [RFC v7 1/1] mconf: global i-search in menu prompts
Randy Dunlap writes: > On 06/19/2018 11:47 AM, Dirk Gouders wrote: >> Randy Dunlap writes: >> >>> Hi Dirk, >>> >>> On 06/17/2018 05:15 AM, Dirk Gouders wrote: >>>> >>>> At any time, at most one i-search is active and the navigation path to >>>> the current menu is displayed in the subtitle, the second line in the >>>> menu window. >>> >>> Nice. >>> >>> And the highlight of the current menu item is also nice when TAB is used to >>> switch to the buttons. As well as toggling the help text based on context. >>> >>> >>>> Navigation example: >>>> >>>> To navigate to options concerning NFS file systems, simply type 'n', >>>> 'f' and 's'. >>>> >>>> Hint: use the 'z' key with focus on buttons to search for invisible >>>> prompts. >>> >>> I think what this says is that the 'z' key is a toggle for the display of >>> some (invisible) prompts. Is that correct? >>> >>> >>> >>> I reliably (consistently) get a segfault. I have hit it several times. >>> Here is one way to get it: >>> >>> $ make menuconfig >>> and then enter: >>> /debug\ >> >> Hello Randy, >> >> thank you for testing and your comments! >> >> Concerning the segfault, I already have a version 8 prepared but wanted >> to do more testing before disturbing people, again. >> >> The initialization and operation of the serialized menu was ugly and >> wrong. I did not notice segfaults so far, but I can imagine the >> segfaults you noticed are caused by this, because the code you tested >> did not operate only on propper initialized array elements. >> >> Before sending out version 8, I would like to include your other >> suggestions as well, so could you please try the attached patch if that >> also produces the segfaults? > > Yes, this one is working for me without faults. Thank you very much. I will prepare a v8 with your comments on the diff also respected. Dirk
Re: [RFC v7 1/1] mconf: global i-search in menu prompts
Randy Dunlap writes: > On 06/19/2018 11:47 AM, Dirk Gouders wrote: >> Randy Dunlap writes: >> >>> Hi Dirk, >>> >>> On 06/17/2018 05:15 AM, Dirk Gouders wrote: >>>> >>>> At any time, at most one i-search is active and the navigation path to >>>> the current menu is displayed in the subtitle, the second line in the >>>> menu window. >>> >>> Nice. >>> >>> And the highlight of the current menu item is also nice when TAB is used to >>> switch to the buttons. As well as toggling the help text based on context. >>> >>> >>>> Navigation example: >>>> >>>> To navigate to options concerning NFS file systems, simply type 'n', >>>> 'f' and 's'. >>>> >>>> Hint: use the 'z' key with focus on buttons to search for invisible >>>> prompts. >>> >>> I think what this says is that the 'z' key is a toggle for the display of >>> some (invisible) prompts. Is that correct? >>> >>> >>> >>> I reliably (consistently) get a segfault. I have hit it several times. >>> Here is one way to get it: >>> >>> $ make menuconfig >>> and then enter: >>> /debug\ >> >> Hello Randy, >> >> thank you for testing and your comments! >> >> Concerning the segfault, I already have a version 8 prepared but wanted >> to do more testing before disturbing people, again. >> >> The initialization and operation of the serialized menu was ugly and >> wrong. I did not notice segfaults so far, but I can imagine the >> segfaults you noticed are caused by this, because the code you tested >> did not operate only on propper initialized array elements. >> >> Before sending out version 8, I would like to include your other >> suggestions as well, so could you please try the attached patch if that >> also produces the segfaults? > > Yes, this one is working for me without faults. Thank you very much. I will prepare a v8 with your comments on the diff also respected. Dirk
Re: [RFC v7 1/1] mconf: global i-search in menu prompts
Randy Dunlap writes: > Hi Dirk, > > On 06/17/2018 05:15 AM, Dirk Gouders wrote: >> >> At any time, at most one i-search is active and the navigation path to >> the current menu is displayed in the subtitle, the second line in the >> menu window. > > Nice. > > And the highlight of the current menu item is also nice when TAB is used to > switch to the buttons. As well as toggling the help text based on context. > > >> Navigation example: >> >> To navigate to options concerning NFS file systems, simply type 'n', >> 'f' and 's'. >> >> Hint: use the 'z' key with focus on buttons to search for invisible >> prompts. > > I think what this says is that the 'z' key is a toggle for the display of > some (invisible) prompts. Is that correct? > > > > I reliably (consistently) get a segfault. I have hit it several times. > Here is one way to get it: > > $ make menuconfig > and then enter: > /debug\ Hello Randy, thank you for testing and your comments! Concerning the segfault, I already have a version 8 prepared but wanted to do more testing before disturbing people, again. The initialization and operation of the serialized menu was ugly and wrong. I did not notice segfaults so far, but I can imagine the segfaults you noticed are caused by this, because the code you tested did not operate only on propper initialized array elements. Before sending out version 8, I would like to include your other suggestions as well, so could you please try the attached patch if that also produces the segfaults? Thanks, Dirk >From 2da56e80fa17adbcb11c8fc86e253f55001f1494 Mon Sep 17 00:00:00 2001 From: Dirk Gouders Date: Fri, 15 Jun 2018 23:07:28 +0200 Subject: [PATCH 1/1] mconf: global i-search in menu prompts Some menus in the kernel configuration are rather large and it can be time-consuming for a user to navigate through several menu items to reach the menu entry that he wants to modify -- for users with less than 100% healthy eyes, this process can also be challenging. An i-search functionality could safe the user from a lot of reading if he knows a keyword that can be used for navigation and this patch implements an i-search navigation concept for mconf based on an idea by Sam Ravnborg: * mconf now distinguishes if the focus is on the menu items or the buttons below it. * At startup focus is on the menu items and printable characters (details see below) entered are used to form a string that is searched for in the menu prompts. This patch implements a global cyclic i-search in the prompts of the complete menu tree. For ease of cyclic searches, the menu tree is serialized into an array at startup. For example, the following tree a1 - b1 - c1 - d1 - e1 | | b2d2 - d3 | d4 is serialized to a1 - b1 - b2 - c1 - d1 - d2 - d4 - d3 - e1 Operation - The TAB key is reserved to toggle the focus between menu and bottons. Focus is on the buttons if one of the buttens (the active one) is hightlighted, otherwise it is on the menu. When the focus is on the buttons, mconf operates as before with the exception of the TAB key. When the focus is on the menu, mconf operates in i-search mode and the following input has special meaning: * <\> (backslash) can be used to search for other occurences of an already entered string. On empty search strings, nothing happens. * Any other printable character than backslash and '\n' is appended to the current search string and a match is searched for. If a match is found, it is immediately navigated to. * BACKSPACE is used to remove the last character of the search string. * DEL clears the search string. * ENTER can be used to enter a submenu. * ESC ESC exits the current isearch and clears the search string. * Horizontal arrow keys still cycle between the buttons but also switch focus to the buttons. * Vertical arroy keys navigate the menu items. At any time, at most one i-search is active and the navigation path to the current menu is displayed in the subtitle, the second line in the menu window. Navigation example: To navigate to options concerning NFS file systems, simply type 'n', 'f' and 's'. Hint: use the 'z' key with focus on buttons to search for invisible prompts. Particular changes to existing code --- * The function print_autowrap() only printed non-whitespace characters and thus could not be used to overwrite existing text. It was extended by a parameter "height" and in combination with the parameter "width" it now makes sure that the whole region (width x height) is overwritten. * The function conf() now returns the key the user pressed so that calling functions can operate depending on that key. Signed-off-by: Dirk Gouders --- scripts/kconfig/lxdial
Re: [RFC v7 1/1] mconf: global i-search in menu prompts
Randy Dunlap writes: > Hi Dirk, > > On 06/17/2018 05:15 AM, Dirk Gouders wrote: >> >> At any time, at most one i-search is active and the navigation path to >> the current menu is displayed in the subtitle, the second line in the >> menu window. > > Nice. > > And the highlight of the current menu item is also nice when TAB is used to > switch to the buttons. As well as toggling the help text based on context. > > >> Navigation example: >> >> To navigate to options concerning NFS file systems, simply type 'n', >> 'f' and 's'. >> >> Hint: use the 'z' key with focus on buttons to search for invisible >> prompts. > > I think what this says is that the 'z' key is a toggle for the display of > some (invisible) prompts. Is that correct? > > > > I reliably (consistently) get a segfault. I have hit it several times. > Here is one way to get it: > > $ make menuconfig > and then enter: > /debug\ Hello Randy, thank you for testing and your comments! Concerning the segfault, I already have a version 8 prepared but wanted to do more testing before disturbing people, again. The initialization and operation of the serialized menu was ugly and wrong. I did not notice segfaults so far, but I can imagine the segfaults you noticed are caused by this, because the code you tested did not operate only on propper initialized array elements. Before sending out version 8, I would like to include your other suggestions as well, so could you please try the attached patch if that also produces the segfaults? Thanks, Dirk >From 2da56e80fa17adbcb11c8fc86e253f55001f1494 Mon Sep 17 00:00:00 2001 From: Dirk Gouders Date: Fri, 15 Jun 2018 23:07:28 +0200 Subject: [PATCH 1/1] mconf: global i-search in menu prompts Some menus in the kernel configuration are rather large and it can be time-consuming for a user to navigate through several menu items to reach the menu entry that he wants to modify -- for users with less than 100% healthy eyes, this process can also be challenging. An i-search functionality could safe the user from a lot of reading if he knows a keyword that can be used for navigation and this patch implements an i-search navigation concept for mconf based on an idea by Sam Ravnborg: * mconf now distinguishes if the focus is on the menu items or the buttons below it. * At startup focus is on the menu items and printable characters (details see below) entered are used to form a string that is searched for in the menu prompts. This patch implements a global cyclic i-search in the prompts of the complete menu tree. For ease of cyclic searches, the menu tree is serialized into an array at startup. For example, the following tree a1 - b1 - c1 - d1 - e1 | | b2d2 - d3 | d4 is serialized to a1 - b1 - b2 - c1 - d1 - d2 - d4 - d3 - e1 Operation - The TAB key is reserved to toggle the focus between menu and bottons. Focus is on the buttons if one of the buttens (the active one) is hightlighted, otherwise it is on the menu. When the focus is on the buttons, mconf operates as before with the exception of the TAB key. When the focus is on the menu, mconf operates in i-search mode and the following input has special meaning: * <\> (backslash) can be used to search for other occurences of an already entered string. On empty search strings, nothing happens. * Any other printable character than backslash and '\n' is appended to the current search string and a match is searched for. If a match is found, it is immediately navigated to. * BACKSPACE is used to remove the last character of the search string. * DEL clears the search string. * ENTER can be used to enter a submenu. * ESC ESC exits the current isearch and clears the search string. * Horizontal arrow keys still cycle between the buttons but also switch focus to the buttons. * Vertical arroy keys navigate the menu items. At any time, at most one i-search is active and the navigation path to the current menu is displayed in the subtitle, the second line in the menu window. Navigation example: To navigate to options concerning NFS file systems, simply type 'n', 'f' and 's'. Hint: use the 'z' key with focus on buttons to search for invisible prompts. Particular changes to existing code --- * The function print_autowrap() only printed non-whitespace characters and thus could not be used to overwrite existing text. It was extended by a parameter "height" and in combination with the parameter "width" it now makes sure that the whole region (width x height) is overwritten. * The function conf() now returns the key the user pressed so that calling functions can operate depending on that key. Signed-off-by: Dirk Gouders --- scripts/kconfig/lxdial
[RFC v7 1/1] mconf: global i-search in menu prompts
Some menus in the kernel configuration are rather large and it can be time-consuming for a user to navigate through several menu items to reach the menu entry that he wants to modify -- for users with less than 100% healthy eyes, this process can also be challenging. An i-search functionality could safe the user from a lot of reading if he knows a keyword that can be used for navigation and this patch implements an i-search navigation concept for mconf based on an idea by Sam Ravnborg: * mconf now distinguishes if the focus is on the menu items or the buttons below it. * At startup focus is on the menu items and printable characters (details see below) entered are used to form a string that is searched for in the menu prompts. This patch implements a global cyclic i-search in the prompts of the complete menu tree. For ease of cyclic searches, the menu tree is serialized into an array at startup. For example, the following tree a1 - b1 - c1 - d1 - e1 | | b2d2 - d3 | d4 is serialized to a1 - b1 - b2 - c1 - d1 - d2 - d4 - d3 - e1 Operation - The TAB key is reserved to toggle the focus between menu and bottons. Focus is on the buttons if one of the buttens (the active one) is hightlighted, otherwise it is on the menu. When the focus is on the buttons, mconf operates as before with the exception of the TAB key. When the focus is on the menu, mconf operates in i-search mode and the following input has special meaning: * <\> (backslash) can be used to search for other occurences of an already entered string. On empty search strings, nothing happens. * Any other printable character than backslash and '\n' is appended to the current search string and a match is searched for. If a match is found, it is immediately navigated to. * BACKSPACE is used to remove the last character of the search string. * DEL clears the search string. * ENTER can be used to enter a submenu. * ESC ESC exits the current isearch and clears the search string. * Horizontal arrow keys still cycle between the buttons but also switch focus to the buttons. * Vertical arroy keys navigate the menu items. At any time, at most one i-search is active and the navigation path to the current menu is displayed in the subtitle, the second line in the menu window. Navigation example: To navigate to options concerning NFS file systems, simply type 'n', 'f' and 's'. Hint: use the 'z' key with focus on buttons to search for invisible prompts. Particular changes to existing code --- * The function print_autowrap() only printed non-whitespace characters and thus could not be used to overwrite existing text. It was extended by a parameter "height" and in combination with the parameter "width" it now makes sure that the whole region (width x height) is overwritten. * The function conf() now returns the key the user pressed so that calling functions can operate depending on that key. Signed-off-by: Dirk Gouders --- scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 181 +--- scripts/kconfig/lxdialog/util.c | 45 +- scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 202 +-- 7 files changed, 398 insertions(+), 39 deletions(-) diff --git a/scripts/kconfig/lxdialog/checklist.c b/scripts/kconfig/lxdialog/checklist.c index 2e96323ad11b..2a8bd877af72 100644 --- a/scripts/kconfig/lxdialog/checklist.c +++ b/scripts/kconfig/lxdialog/checklist.c @@ -160,7 +160,7 @@ int dialog_checklist(const char *title, const char *prompt, int height, print_title(dialog, title, width); wattrset(dialog, dlg.dialog.atr); - print_autowrap(dialog, prompt, width - 2, 1, 3); + print_autowrap(dialog, prompt, width - 2, 3, 1, 3); list_width = width - 6; box_y = height - list_height - 5; diff --git a/scripts/kconfig/lxdialog/dialog.h b/scripts/kconfig/lxdialog/dialog.h index 0b00be5abaa6..9396ed2122f9 100644 --- a/scripts/kconfig/lxdialog/dialog.h +++ b/scripts/kconfig/lxdialog/dialog.h @@ -214,7 +214,8 @@ void set_dialog_subtitles(struct subtitle_list *subtitles); void end_dialog(int x, int y); void attr_clear(WINDOW * win, int height, int width, chtype attr); void dialog_clear(void); -void print_autowrap(WINDOW * win, const char *prompt, int width, int y, int x); +void print_autowrap(WINDOW * win, const char *prompt, + int width, int height, int y, int x); void print_button(WINDOW * win, const char *label, int y, int x, int selected); void print_title(WINDOW *dialog, const char *title, int width); void draw_box(WINDOW * win, int y, int x, int height, int width, chtype box, diff --git a/scripts/kconfig/lxdialog/inputbox.c
[RFC v7 1/1] mconf: global i-search in menu prompts
Some menus in the kernel configuration are rather large and it can be time-consuming for a user to navigate through several menu items to reach the menu entry that he wants to modify -- for users with less than 100% healthy eyes, this process can also be challenging. An i-search functionality could safe the user from a lot of reading if he knows a keyword that can be used for navigation and this patch implements an i-search navigation concept for mconf based on an idea by Sam Ravnborg: * mconf now distinguishes if the focus is on the menu items or the buttons below it. * At startup focus is on the menu items and printable characters (details see below) entered are used to form a string that is searched for in the menu prompts. This patch implements a global cyclic i-search in the prompts of the complete menu tree. For ease of cyclic searches, the menu tree is serialized into an array at startup. For example, the following tree a1 - b1 - c1 - d1 - e1 | | b2d2 - d3 | d4 is serialized to a1 - b1 - b2 - c1 - d1 - d2 - d4 - d3 - e1 Operation - The TAB key is reserved to toggle the focus between menu and bottons. Focus is on the buttons if one of the buttens (the active one) is hightlighted, otherwise it is on the menu. When the focus is on the buttons, mconf operates as before with the exception of the TAB key. When the focus is on the menu, mconf operates in i-search mode and the following input has special meaning: * <\> (backslash) can be used to search for other occurences of an already entered string. On empty search strings, nothing happens. * Any other printable character than backslash and '\n' is appended to the current search string and a match is searched for. If a match is found, it is immediately navigated to. * BACKSPACE is used to remove the last character of the search string. * DEL clears the search string. * ENTER can be used to enter a submenu. * ESC ESC exits the current isearch and clears the search string. * Horizontal arrow keys still cycle between the buttons but also switch focus to the buttons. * Vertical arroy keys navigate the menu items. At any time, at most one i-search is active and the navigation path to the current menu is displayed in the subtitle, the second line in the menu window. Navigation example: To navigate to options concerning NFS file systems, simply type 'n', 'f' and 's'. Hint: use the 'z' key with focus on buttons to search for invisible prompts. Particular changes to existing code --- * The function print_autowrap() only printed non-whitespace characters and thus could not be used to overwrite existing text. It was extended by a parameter "height" and in combination with the parameter "width" it now makes sure that the whole region (width x height) is overwritten. * The function conf() now returns the key the user pressed so that calling functions can operate depending on that key. Signed-off-by: Dirk Gouders --- scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 181 +--- scripts/kconfig/lxdialog/util.c | 45 +- scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 202 +-- 7 files changed, 398 insertions(+), 39 deletions(-) diff --git a/scripts/kconfig/lxdialog/checklist.c b/scripts/kconfig/lxdialog/checklist.c index 2e96323ad11b..2a8bd877af72 100644 --- a/scripts/kconfig/lxdialog/checklist.c +++ b/scripts/kconfig/lxdialog/checklist.c @@ -160,7 +160,7 @@ int dialog_checklist(const char *title, const char *prompt, int height, print_title(dialog, title, width); wattrset(dialog, dlg.dialog.atr); - print_autowrap(dialog, prompt, width - 2, 1, 3); + print_autowrap(dialog, prompt, width - 2, 3, 1, 3); list_width = width - 6; box_y = height - list_height - 5; diff --git a/scripts/kconfig/lxdialog/dialog.h b/scripts/kconfig/lxdialog/dialog.h index 0b00be5abaa6..9396ed2122f9 100644 --- a/scripts/kconfig/lxdialog/dialog.h +++ b/scripts/kconfig/lxdialog/dialog.h @@ -214,7 +214,8 @@ void set_dialog_subtitles(struct subtitle_list *subtitles); void end_dialog(int x, int y); void attr_clear(WINDOW * win, int height, int width, chtype attr); void dialog_clear(void); -void print_autowrap(WINDOW * win, const char *prompt, int width, int y, int x); +void print_autowrap(WINDOW * win, const char *prompt, + int width, int height, int y, int x); void print_button(WINDOW * win, const char *label, int y, int x, int selected); void print_title(WINDOW *dialog, const char *title, int width); void draw_box(WINDOW * win, int y, int x, int height, int width, chtype box, diff --git a/scripts/kconfig/lxdialog/inputbox.c
[RFC v7 0/1] mconf: global i-search in menu prompts
Hello, I reworked this RFC and checked it against submitting-patches.rst so the quality should have raised. In that document, I read that permission of the person should be asked for before adding a Suggested-by. So, apologies go to Sam. I removed that line from the commit message and am now asking for your permission to add it. Most noticeable changes are that the exact starting position before doing i-search is now remebered and i-search stays on the current item if a character was added and the new string also matches this item. Also, compiler warnings were eliminated and A_UNDERLINE was replaced with A_STANDOUT to mark active menu items when the focus is on the buttons, because I tested mconf on a tty where underlines were not visible. For a complete list of changes see below. Dirk Changes in v7: * make menu_isearch() return void * Suggested-by removed, ask for Sam's permission * Rework i-search instructions text * Remember exact starting position in menu * Stay on menu item if it matches pattern with a character added * Fix print_autowrap for short texts * Focus on buttons: use A_STANDOUT for current menu item * Fix compiler warnings * Don't exclude comments in searches * ESC also clears search string * Remove the last parameter of print_isearch and use focus_on_buttons instead * Document changes to print_autowrap and conf() in commit message * Rework comments in the code * Rework commit message, add a motivation part * Free serialized menu array on exit Changes in v6: * The modification of the function print_autowrap() was reworked and is no longer a separate function. * The i-search navigation was completely reworked and now works on the whole menu tree. * Hotkeys are back, because they do not interfere that much with this version of i-search navigation. Changes in v5: * More thoroughly tested code * Hotkey navigation concept completely dropped * Printable characters except special ones form the search string * Focus-sensitive help text above menu * DEL erases search string * Matching string is highlighted in selected menu item * README help text adjusted Changes in v4: * Prototype: consequent i-search navigation concept Changes in v3: * Use current git tree to make the patch apply. * Eliminate debugging output to stderr. Changes in v2: * Additionally to CTRL-s, \ can be used to start isearch. * Raw mode is off by default an can be enabled by an environment variable MENUCONFIG_RAW_MODE. * I also added a variable for toggling raw mode but did not implement anything else. * The isearch indicator is now displayed as soon as isearch is started. * Any key except \, CTRL-s, alphanumeric characters and space terminates isearch and -- except ESC ESC -- is further processed, e.g. ENTER terminates isearch and is then used to navigate into a submenu. * Problems with mismatches and matches above the current position were fixed. Dirk Gouders (1): mconf: global i-search in menu prompts scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 181 +--- scripts/kconfig/lxdialog/util.c | 45 +- scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 202 +-- 7 files changed, 398 insertions(+), 39 deletions(-) -- 2.17.1
[RFC v7 0/1] mconf: global i-search in menu prompts
Hello, I reworked this RFC and checked it against submitting-patches.rst so the quality should have raised. In that document, I read that permission of the person should be asked for before adding a Suggested-by. So, apologies go to Sam. I removed that line from the commit message and am now asking for your permission to add it. Most noticeable changes are that the exact starting position before doing i-search is now remebered and i-search stays on the current item if a character was added and the new string also matches this item. Also, compiler warnings were eliminated and A_UNDERLINE was replaced with A_STANDOUT to mark active menu items when the focus is on the buttons, because I tested mconf on a tty where underlines were not visible. For a complete list of changes see below. Dirk Changes in v7: * make menu_isearch() return void * Suggested-by removed, ask for Sam's permission * Rework i-search instructions text * Remember exact starting position in menu * Stay on menu item if it matches pattern with a character added * Fix print_autowrap for short texts * Focus on buttons: use A_STANDOUT for current menu item * Fix compiler warnings * Don't exclude comments in searches * ESC also clears search string * Remove the last parameter of print_isearch and use focus_on_buttons instead * Document changes to print_autowrap and conf() in commit message * Rework comments in the code * Rework commit message, add a motivation part * Free serialized menu array on exit Changes in v6: * The modification of the function print_autowrap() was reworked and is no longer a separate function. * The i-search navigation was completely reworked and now works on the whole menu tree. * Hotkeys are back, because they do not interfere that much with this version of i-search navigation. Changes in v5: * More thoroughly tested code * Hotkey navigation concept completely dropped * Printable characters except special ones form the search string * Focus-sensitive help text above menu * DEL erases search string * Matching string is highlighted in selected menu item * README help text adjusted Changes in v4: * Prototype: consequent i-search navigation concept Changes in v3: * Use current git tree to make the patch apply. * Eliminate debugging output to stderr. Changes in v2: * Additionally to CTRL-s, \ can be used to start isearch. * Raw mode is off by default an can be enabled by an environment variable MENUCONFIG_RAW_MODE. * I also added a variable for toggling raw mode but did not implement anything else. * The isearch indicator is now displayed as soon as isearch is started. * Any key except \, CTRL-s, alphanumeric characters and space terminates isearch and -- except ESC ESC -- is further processed, e.g. ENTER terminates isearch and is then used to navigate into a submenu. * Problems with mismatches and matches above the current position were fixed. Dirk Gouders (1): mconf: global i-search in menu prompts scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 181 +--- scripts/kconfig/lxdialog/util.c | 45 +- scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 202 +-- 7 files changed, 398 insertions(+), 39 deletions(-) -- 2.17.1
[RFC v6 1/1] mconf: global i-search in menu structure
This patch implements an i-search navigation concept for mconf based on an idea of Sam Ravnborg: * mconf now distinguishes if the focus is on the menu items or the buttons below it. * At startup focus is on the menu items and printable characters (details see below) entered are used to form a string that is searched for. This patch implements a global cyclic i-search in the complete menu tree. For ease of cyclic searches, the menu tree is serialized into an array at startup. For example, the following tree a1 - b1 - c1 - d1 - e1 | | b2d2 - d3 | d4 is serialized to a1 - b1 - b2 - c1 - d1 - d2 - d4 - d3 - e1 Operation - The TAB key is reserved to toggle the focus between menu and bottons. When the focus is on the buttons, mconf operates as before with the exception of the TAB key. When the focus is on the menu, mconf operates in i-search mode and the following input has special meaning: * <\> (backslash) can be used to search for other occurences of an already entered string. On empty search strings, nothing happens. * Any other printable character than backslash is appended to the current search string and a match is searched for. * BACKSPACE is used to remove the last character of the search string. * DEL clears the search string. * ENTER can be used to enter a submenu. * ESC ESC exits the current isearch. * Horizontal arrow keys still cycle between the buttons but also switch focus to the buttons. * Vertical arroy keys navigate the menu items. At any time, only one i-search is active and the navigation path to the current menu is displayed in the subtitle, the second line in the menu window. Navigation example: To navigate to options concerning NFS file systems, simply type 'n', 'f' and 's'. Hint: use the 'z' key with focus on buttons to search for invisible prompts. Signed-off-by: Dirk Gouders Suggested-by: Sam Ravnborg --- scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 177 +- scripts/kconfig/lxdialog/util.c | 37 ++- scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 181 +-- 7 files changed, 364 insertions(+), 40 deletions(-) diff --git a/scripts/kconfig/lxdialog/checklist.c b/scripts/kconfig/lxdialog/checklist.c index 2e96323ad11b..2a8bd877af72 100644 --- a/scripts/kconfig/lxdialog/checklist.c +++ b/scripts/kconfig/lxdialog/checklist.c @@ -160,7 +160,7 @@ int dialog_checklist(const char *title, const char *prompt, int height, print_title(dialog, title, width); wattrset(dialog, dlg.dialog.atr); - print_autowrap(dialog, prompt, width - 2, 1, 3); + print_autowrap(dialog, prompt, width - 2, 3, 1, 3); list_width = width - 6; box_y = height - list_height - 5; diff --git a/scripts/kconfig/lxdialog/dialog.h b/scripts/kconfig/lxdialog/dialog.h index 0b00be5abaa6..9396ed2122f9 100644 --- a/scripts/kconfig/lxdialog/dialog.h +++ b/scripts/kconfig/lxdialog/dialog.h @@ -214,7 +214,8 @@ void set_dialog_subtitles(struct subtitle_list *subtitles); void end_dialog(int x, int y); void attr_clear(WINDOW * win, int height, int width, chtype attr); void dialog_clear(void); -void print_autowrap(WINDOW * win, const char *prompt, int width, int y, int x); +void print_autowrap(WINDOW * win, const char *prompt, + int width, int height, int y, int x); void print_button(WINDOW * win, const char *label, int y, int x, int selected); void print_title(WINDOW *dialog, const char *title, int width); void draw_box(WINDOW * win, int y, int x, int height, int width, chtype box, diff --git a/scripts/kconfig/lxdialog/inputbox.c b/scripts/kconfig/lxdialog/inputbox.c index fe82ff6d744e..121ac6b810f3 100644 --- a/scripts/kconfig/lxdialog/inputbox.c +++ b/scripts/kconfig/lxdialog/inputbox.c @@ -82,7 +82,7 @@ int dialog_inputbox(const char *title, const char *prompt, int height, int width print_title(dialog, title, width); wattrset(dialog, dlg.dialog.atr); - print_autowrap(dialog, prompt, width - 2, 1, 3); + print_autowrap(dialog, prompt, width - 2, 2, 1, 3); /* Draw the input field box */ box_width = width - 6; diff --git a/scripts/kconfig/lxdialog/menubox.c b/scripts/kconfig/lxdialog/menubox.c index d70cab36137e..18de050a7dcc 100644 --- a/scripts/kconfig/lxdialog/menubox.c +++ b/scripts/kconfig/lxdialog/menubox.c @@ -58,21 +58,38 @@ #include "dialog.h" +#define ISEARCH_LEN 32 +char isearch_str[ISEARCH_LEN] = ""; + static int menu_width, item_x; +int focus_on_buttons; + +static const char isearch_instructions[] = + "I-search: Arrow keys navigate the menu. " + " selects submenus and/or clears i-search string.
[RFC v6 1/1] mconf: global i-search in menu structure
This patch implements an i-search navigation concept for mconf based on an idea of Sam Ravnborg: * mconf now distinguishes if the focus is on the menu items or the buttons below it. * At startup focus is on the menu items and printable characters (details see below) entered are used to form a string that is searched for. This patch implements a global cyclic i-search in the complete menu tree. For ease of cyclic searches, the menu tree is serialized into an array at startup. For example, the following tree a1 - b1 - c1 - d1 - e1 | | b2d2 - d3 | d4 is serialized to a1 - b1 - b2 - c1 - d1 - d2 - d4 - d3 - e1 Operation - The TAB key is reserved to toggle the focus between menu and bottons. When the focus is on the buttons, mconf operates as before with the exception of the TAB key. When the focus is on the menu, mconf operates in i-search mode and the following input has special meaning: * <\> (backslash) can be used to search for other occurences of an already entered string. On empty search strings, nothing happens. * Any other printable character than backslash is appended to the current search string and a match is searched for. * BACKSPACE is used to remove the last character of the search string. * DEL clears the search string. * ENTER can be used to enter a submenu. * ESC ESC exits the current isearch. * Horizontal arrow keys still cycle between the buttons but also switch focus to the buttons. * Vertical arroy keys navigate the menu items. At any time, only one i-search is active and the navigation path to the current menu is displayed in the subtitle, the second line in the menu window. Navigation example: To navigate to options concerning NFS file systems, simply type 'n', 'f' and 's'. Hint: use the 'z' key with focus on buttons to search for invisible prompts. Signed-off-by: Dirk Gouders Suggested-by: Sam Ravnborg --- scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 177 +- scripts/kconfig/lxdialog/util.c | 37 ++- scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 181 +-- 7 files changed, 364 insertions(+), 40 deletions(-) diff --git a/scripts/kconfig/lxdialog/checklist.c b/scripts/kconfig/lxdialog/checklist.c index 2e96323ad11b..2a8bd877af72 100644 --- a/scripts/kconfig/lxdialog/checklist.c +++ b/scripts/kconfig/lxdialog/checklist.c @@ -160,7 +160,7 @@ int dialog_checklist(const char *title, const char *prompt, int height, print_title(dialog, title, width); wattrset(dialog, dlg.dialog.atr); - print_autowrap(dialog, prompt, width - 2, 1, 3); + print_autowrap(dialog, prompt, width - 2, 3, 1, 3); list_width = width - 6; box_y = height - list_height - 5; diff --git a/scripts/kconfig/lxdialog/dialog.h b/scripts/kconfig/lxdialog/dialog.h index 0b00be5abaa6..9396ed2122f9 100644 --- a/scripts/kconfig/lxdialog/dialog.h +++ b/scripts/kconfig/lxdialog/dialog.h @@ -214,7 +214,8 @@ void set_dialog_subtitles(struct subtitle_list *subtitles); void end_dialog(int x, int y); void attr_clear(WINDOW * win, int height, int width, chtype attr); void dialog_clear(void); -void print_autowrap(WINDOW * win, const char *prompt, int width, int y, int x); +void print_autowrap(WINDOW * win, const char *prompt, + int width, int height, int y, int x); void print_button(WINDOW * win, const char *label, int y, int x, int selected); void print_title(WINDOW *dialog, const char *title, int width); void draw_box(WINDOW * win, int y, int x, int height, int width, chtype box, diff --git a/scripts/kconfig/lxdialog/inputbox.c b/scripts/kconfig/lxdialog/inputbox.c index fe82ff6d744e..121ac6b810f3 100644 --- a/scripts/kconfig/lxdialog/inputbox.c +++ b/scripts/kconfig/lxdialog/inputbox.c @@ -82,7 +82,7 @@ int dialog_inputbox(const char *title, const char *prompt, int height, int width print_title(dialog, title, width); wattrset(dialog, dlg.dialog.atr); - print_autowrap(dialog, prompt, width - 2, 1, 3); + print_autowrap(dialog, prompt, width - 2, 2, 1, 3); /* Draw the input field box */ box_width = width - 6; diff --git a/scripts/kconfig/lxdialog/menubox.c b/scripts/kconfig/lxdialog/menubox.c index d70cab36137e..18de050a7dcc 100644 --- a/scripts/kconfig/lxdialog/menubox.c +++ b/scripts/kconfig/lxdialog/menubox.c @@ -58,21 +58,38 @@ #include "dialog.h" +#define ISEARCH_LEN 32 +char isearch_str[ISEARCH_LEN] = ""; + static int menu_width, item_x; +int focus_on_buttons; + +static const char isearch_instructions[] = + "I-search: Arrow keys navigate the menu. " + " selects submenus and/or clears i-search string.
[RFC v6 0/1] mconf: global i-search in menu structure
Hello, version 6 of this RFC was mainly influenced by a discussion with Randy Dunlap about a patch for i-search in nconf. In that discussion I stated that it would be a lot of work to implement a global i-search but while thinking about that statement afterwards, I realized that most of the needed functionality is already there in search_conf(), the search function for config symbols. The menu tree is converted in a flat menu to ease the implementation of a cyclic i-search and the rest of the implementation does no longer interfere so much with current menu handling. Dirk Changes in v6: * The modification of the function print_autowrap() was reworked and is no longer a separate function. * The i-search navigation was completely reworked and now works on the whole menu tree. * Hotkeys are back, because they do not interfere that much with this version of i-search navigation. Changes in v5: * More thoroughly tested code * Hotkey navigation concept completely dropped * Printable characters except special ones form the search string * Focus-sensitive help text above menu * DEL erases search string * Matching string is highlighted in selected menu item * README help text adjusted Changes in v4: * Prototype: consequent i-search navigation concept Changes in v3: * Use current git tree to make the patch apply. * Eliminate debugging output to stderr. Changes in v2: * Additionally to CTRL-s, \ can be used to start isearch. * Raw mode is off by default an can be enabled by an environment variable MENUCONFIG_RAW_MODE. * I also added a variable for toggling raw mode but did not implement anything else. * The isearch indicator is now displayed as soon as isearch is started. * Any key except \, CTRL-s, alphanumeric characters and space terminates isearch and -- except ESC ESC -- is further processed, e.g. ENTER terminates isearch and is then used to navigate into a submenu. * Problems with mismatches and matches above the current position were fixed. Dirk Gouders (1): mconf: global i-search in menu structure scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 177 +- scripts/kconfig/lxdialog/util.c | 37 ++- scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 181 +-- 7 files changed, 364 insertions(+), 40 deletions(-) -- 2.16.4
[RFC v6 0/1] mconf: global i-search in menu structure
Hello, version 6 of this RFC was mainly influenced by a discussion with Randy Dunlap about a patch for i-search in nconf. In that discussion I stated that it would be a lot of work to implement a global i-search but while thinking about that statement afterwards, I realized that most of the needed functionality is already there in search_conf(), the search function for config symbols. The menu tree is converted in a flat menu to ease the implementation of a cyclic i-search and the rest of the implementation does no longer interfere so much with current menu handling. Dirk Changes in v6: * The modification of the function print_autowrap() was reworked and is no longer a separate function. * The i-search navigation was completely reworked and now works on the whole menu tree. * Hotkeys are back, because they do not interfere that much with this version of i-search navigation. Changes in v5: * More thoroughly tested code * Hotkey navigation concept completely dropped * Printable characters except special ones form the search string * Focus-sensitive help text above menu * DEL erases search string * Matching string is highlighted in selected menu item * README help text adjusted Changes in v4: * Prototype: consequent i-search navigation concept Changes in v3: * Use current git tree to make the patch apply. * Eliminate debugging output to stderr. Changes in v2: * Additionally to CTRL-s, \ can be used to start isearch. * Raw mode is off by default an can be enabled by an environment variable MENUCONFIG_RAW_MODE. * I also added a variable for toggling raw mode but did not implement anything else. * The isearch indicator is now displayed as soon as isearch is started. * Any key except \, CTRL-s, alphanumeric characters and space terminates isearch and -- except ESC ESC -- is further processed, e.g. ENTER terminates isearch and is then used to navigate into a submenu. * Problems with mismatches and matches above the current position were fixed. Dirk Gouders (1): mconf: global i-search in menu structure scripts/kconfig/lxdialog/checklist.c | 2 +- scripts/kconfig/lxdialog/dialog.h| 3 +- scripts/kconfig/lxdialog/inputbox.c | 2 +- scripts/kconfig/lxdialog/menubox.c | 177 +- scripts/kconfig/lxdialog/util.c | 37 ++- scripts/kconfig/lxdialog/yesno.c | 2 +- scripts/kconfig/mconf.c | 181 +-- 7 files changed, 364 insertions(+), 40 deletions(-) -- 2.16.4
[RFC v5 0/1] i-search navigation for mconf
Hello, I reworked the prototype for the i-search navigation concept. It is now more thoroughly tested and hopefully not a waste of time to have a look at it. For the focus-sensitive help text, I modified the function print_autowrap() and for now called it print_autowrap_fill(). It could replace the old function but does a bit more work than it. With this navigation concept, mconf's behavior (in i-search mode) is quite different from the known one, most noticeably the need to switch focus to the buttons to be able to use . Ideas are very welcome. Interesting in i-search mode is the ability to not only search item strings, but also their selection marks. So, one can search for items selected as a module, for example. Dirk Changes in v5: * More thoroughly tested code * Hotkey navigation concept completely dropped * Printable characters except special ones form the search string * Focus-sensitive help text above menu * DEL erases search string * Matching string is highlighted in selected menu item * README help text adjusted Changes in v4: * Prototype: consequent i-search navigation concept Changes in v3: * Use current git tree to make the patch apply. * Eliminate debugging output to stderr. Changes in v2: * Additionally to CTRL-s, \ can be used to start isearch. * Raw mode is off by default an can be enabled by an environment variable MENUCONFIG_RAW_MODE. * I also added a variable for toggling raw mode but did not implement anything else. * The isearch indicator is now displayed as soon as isearch is started. * Any key except \, CTRL-s, alphanumeric characters and space terminates isearch and -- except ESC ESC -- is further processed, e.g. ENTER terminates isearch and is then used to navigate into a submenu. * Problems with mismatches and matches above the current position were fixed. Dirk Gouders (1): i-search navigation for mconf scripts/kconfig/lxdialog/dialog.h | 3 + scripts/kconfig/lxdialog/menubox.c | 489 +++-- scripts/kconfig/lxdialog/util.c| 106 +++- scripts/kconfig/mconf.c| 68 -- 4 files changed, 506 insertions(+), 160 deletions(-) -- 2.16.4
[RFC v5 0/1] i-search navigation for mconf
Hello, I reworked the prototype for the i-search navigation concept. It is now more thoroughly tested and hopefully not a waste of time to have a look at it. For the focus-sensitive help text, I modified the function print_autowrap() and for now called it print_autowrap_fill(). It could replace the old function but does a bit more work than it. With this navigation concept, mconf's behavior (in i-search mode) is quite different from the known one, most noticeably the need to switch focus to the buttons to be able to use . Ideas are very welcome. Interesting in i-search mode is the ability to not only search item strings, but also their selection marks. So, one can search for items selected as a module, for example. Dirk Changes in v5: * More thoroughly tested code * Hotkey navigation concept completely dropped * Printable characters except special ones form the search string * Focus-sensitive help text above menu * DEL erases search string * Matching string is highlighted in selected menu item * README help text adjusted Changes in v4: * Prototype: consequent i-search navigation concept Changes in v3: * Use current git tree to make the patch apply. * Eliminate debugging output to stderr. Changes in v2: * Additionally to CTRL-s, \ can be used to start isearch. * Raw mode is off by default an can be enabled by an environment variable MENUCONFIG_RAW_MODE. * I also added a variable for toggling raw mode but did not implement anything else. * The isearch indicator is now displayed as soon as isearch is started. * Any key except \, CTRL-s, alphanumeric characters and space terminates isearch and -- except ESC ESC -- is further processed, e.g. ENTER terminates isearch and is then used to navigate into a submenu. * Problems with mismatches and matches above the current position were fixed. Dirk Gouders (1): i-search navigation for mconf scripts/kconfig/lxdialog/dialog.h | 3 + scripts/kconfig/lxdialog/menubox.c | 489 +++-- scripts/kconfig/lxdialog/util.c| 106 +++- scripts/kconfig/mconf.c| 68 -- 4 files changed, 506 insertions(+), 160 deletions(-) -- 2.16.4
[RFC v5 1/1] i-search navigation for mconf
This patch implements an i-search navigation concept for mconf based
on an idea of Sam Ravnborg:
* mconf now distinguishes if the focus is on the menu items or the
buttons below it.
* At startup focus is on the menu items and printable characters
(except the keys below) entered are used to form a string that is
searched for.
* Hotkeys were sacrificed for the i-search navigation concept.
However, focus on the buttons offers most of mconf's known behavior,
except the TAB key and a change in the highlighting of menu items.
Keys with special meaning:
* BACKSPACE is used to remove the last character of the search string
* DEL clears the search string
* ENTER can be used to enter a submenu; it also clears the search string
* Horizontal arrow keys still cycle between the buttons but also
switch focus to the buttons.
* The TAB key is now exclusively used to toggle the focus.
* Vertical arrow keys work everywhere.
* When the focus is on the buttons, all keys work the
same as before this change -- except TAB and hotkeys.
* <\> (backslash) can be used to search for other occurences of an
already entered string.
* To use y|n|m| on an item, focus has to be on the buttons.
An example to navigate into the USB support menu under Device Drivers:
1) de# Navigates to the item "Device Drivers"
2) ENTER # Enter the submenu
3) USB # Navigate to the item "USB support"
4) ENTER # Enter the submenu
Suggested-by: Sam Ravnborg
Signed-off-by: Dirk Gouders
---
scripts/kconfig/lxdialog/dialog.h | 3 +
scripts/kconfig/lxdialog/menubox.c | 489 +++--
scripts/kconfig/lxdialog/util.c| 106 +++-
scripts/kconfig/mconf.c| 68 --
4 files changed, 506 insertions(+), 160 deletions(-)
diff --git a/scripts/kconfig/lxdialog/dialog.h
b/scripts/kconfig/lxdialog/dialog.h
index 0b00be5abaa6..28a3b42fdf71 100644
--- a/scripts/kconfig/lxdialog/dialog.h
+++ b/scripts/kconfig/lxdialog/dialog.h
@@ -215,6 +215,8 @@ void end_dialog(int x, int y);
void attr_clear(WINDOW * win, int height, int width, chtype attr);
void dialog_clear(void);
void print_autowrap(WINDOW * win, const char *prompt, int width, int y, int x);
+void print_autowrap_fill(WINDOW * win, const char *prompt, int width,
+ int height, int y, int x);
void print_button(WINDOW * win, const char *label, int y, int x, int selected);
void print_title(WINDOW *dialog, const char *title, int width);
void draw_box(WINDOW * win, int y, int x, int height, int width, chtype box,
@@ -238,6 +240,7 @@ int dialog_checklist(const char *title, const char *prompt,
int height,
int width, int list_height);
int dialog_inputbox(const char *title, const char *prompt, int height,
int width, const char *init);
+int do_isearch(char *str, int choice, int scroll);
/*
* This is the base for fictitious keys, which activate
diff --git a/scripts/kconfig/lxdialog/menubox.c
b/scripts/kconfig/lxdialog/menubox.c
index d70cab36137e..7b22ec813d3c 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -56,22 +56,38 @@
* fscanf would read in 'scroll', and eventually that value would get used.
*/
+#include
#include "dialog.h"
+#define ISEARCH_LEN 32
+static char isearch_str[ISEARCH_LEN] = "";
+
static int menu_width, item_x;
+static int focus_on_buttons;
+
+static const char isearch_instructions[] =
+ "I-search: Arrow keys navigate the menu. "
+ " selects submenus and/or clears i-search string. "
+ "Type any character to search for menu items, "
+ "press <\\> to find further matches, to exit. "
+ "Legend: [*] built-in [ ] excluded module < > module capable";
/*
* Print menu item
*/
static void do_print_item(WINDOW * win, const char *item, int line_y,
- int selected, int hotkey)
+ int selected)
{
- int j;
+ int i;
+ int isearch_match_pos;
+ char *isearch_match;
char *menu_item = malloc(menu_width + 1);
strncpy(menu_item, item, menu_width - item_x);
menu_item[menu_width - item_x] = '\0';
- j = first_alpha(menu_item, "YyNnMmHh");
+
+ isearch_match = strcasestr(menu_item, isearch_str);
+ isearch_match_pos = isearch_match - menu_item;
/* Clear 'residue' of last item */
wattrset(win, dlg.menubox.atr);
@@ -85,14 +101,24 @@ static void do_print_item(WINDOW * win, const char *item,
int line_y,
#else
wclrtoeol(win);
#endif
- wattrset(win, selected ? dlg.item_selected.atr : dlg.item.atr);
+ if (focus_on_buttons)
+ wattrset(win, selected ? A_UNDERLINE : dlg.item.atr);
+ else
+ wattrset(win, s
[RFC v5 1/1] i-search navigation for mconf
This patch implements an i-search navigation concept for mconf based
on an idea of Sam Ravnborg:
* mconf now distinguishes if the focus is on the menu items or the
buttons below it.
* At startup focus is on the menu items and printable characters
(except the keys below) entered are used to form a string that is
searched for.
* Hotkeys were sacrificed for the i-search navigation concept.
However, focus on the buttons offers most of mconf's known behavior,
except the TAB key and a change in the highlighting of menu items.
Keys with special meaning:
* BACKSPACE is used to remove the last character of the search string
* DEL clears the search string
* ENTER can be used to enter a submenu; it also clears the search string
* Horizontal arrow keys still cycle between the buttons but also
switch focus to the buttons.
* The TAB key is now exclusively used to toggle the focus.
* Vertical arrow keys work everywhere.
* When the focus is on the buttons, all keys work the
same as before this change -- except TAB and hotkeys.
* <\> (backslash) can be used to search for other occurences of an
already entered string.
* To use y|n|m| on an item, focus has to be on the buttons.
An example to navigate into the USB support menu under Device Drivers:
1) de# Navigates to the item "Device Drivers"
2) ENTER # Enter the submenu
3) USB # Navigate to the item "USB support"
4) ENTER # Enter the submenu
Suggested-by: Sam Ravnborg
Signed-off-by: Dirk Gouders
---
scripts/kconfig/lxdialog/dialog.h | 3 +
scripts/kconfig/lxdialog/menubox.c | 489 +++--
scripts/kconfig/lxdialog/util.c| 106 +++-
scripts/kconfig/mconf.c| 68 --
4 files changed, 506 insertions(+), 160 deletions(-)
diff --git a/scripts/kconfig/lxdialog/dialog.h
b/scripts/kconfig/lxdialog/dialog.h
index 0b00be5abaa6..28a3b42fdf71 100644
--- a/scripts/kconfig/lxdialog/dialog.h
+++ b/scripts/kconfig/lxdialog/dialog.h
@@ -215,6 +215,8 @@ void end_dialog(int x, int y);
void attr_clear(WINDOW * win, int height, int width, chtype attr);
void dialog_clear(void);
void print_autowrap(WINDOW * win, const char *prompt, int width, int y, int x);
+void print_autowrap_fill(WINDOW * win, const char *prompt, int width,
+ int height, int y, int x);
void print_button(WINDOW * win, const char *label, int y, int x, int selected);
void print_title(WINDOW *dialog, const char *title, int width);
void draw_box(WINDOW * win, int y, int x, int height, int width, chtype box,
@@ -238,6 +240,7 @@ int dialog_checklist(const char *title, const char *prompt,
int height,
int width, int list_height);
int dialog_inputbox(const char *title, const char *prompt, int height,
int width, const char *init);
+int do_isearch(char *str, int choice, int scroll);
/*
* This is the base for fictitious keys, which activate
diff --git a/scripts/kconfig/lxdialog/menubox.c
b/scripts/kconfig/lxdialog/menubox.c
index d70cab36137e..7b22ec813d3c 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -56,22 +56,38 @@
* fscanf would read in 'scroll', and eventually that value would get used.
*/
+#include
#include "dialog.h"
+#define ISEARCH_LEN 32
+static char isearch_str[ISEARCH_LEN] = "";
+
static int menu_width, item_x;
+static int focus_on_buttons;
+
+static const char isearch_instructions[] =
+ "I-search: Arrow keys navigate the menu. "
+ " selects submenus and/or clears i-search string. "
+ "Type any character to search for menu items, "
+ "press <\\> to find further matches, to exit. "
+ "Legend: [*] built-in [ ] excluded module < > module capable";
/*
* Print menu item
*/
static void do_print_item(WINDOW * win, const char *item, int line_y,
- int selected, int hotkey)
+ int selected)
{
- int j;
+ int i;
+ int isearch_match_pos;
+ char *isearch_match;
char *menu_item = malloc(menu_width + 1);
strncpy(menu_item, item, menu_width - item_x);
menu_item[menu_width - item_x] = '\0';
- j = first_alpha(menu_item, "YyNnMmHh");
+
+ isearch_match = strcasestr(menu_item, isearch_str);
+ isearch_match_pos = isearch_match - menu_item;
/* Clear 'residue' of last item */
wattrset(win, dlg.menubox.atr);
@@ -85,14 +101,24 @@ static void do_print_item(WINDOW * win, const char *item,
int line_y,
#else
wclrtoeol(win);
#endif
- wattrset(win, selected ? dlg.item_selected.atr : dlg.item.atr);
+ if (focus_on_buttons)
+ wattrset(win, selected ? A_UNDERLINE : dlg.item.atr);
+ else
+ wattrset(win, s
Re: [RFC v4 0/1] i-search functionality for mconf
Sam Ravnborg writes: > Hi Dirk. > > On Fri, Jun 08, 2018 at 08:46:05PM +0200, Dirk Gouders wrote: >> Hello, >> >> this version is a prototype of the idea, Sam suggested -- I hope I >> undestood it correctly. >> >> This is a remarkable change to mconf in it's behavior; mainly it now >> differentiates two focuses and operates differently, depending on the >> focus. When the focus is on the menu, mconf is in i-search mode, for >> a detailed description see 1/1. >> >> As stated earlier, this is just a prototype, documentation is missing >> and the code is not ready for a real commit. > > When trying this out it started to work as envisioned. > But somehw I manage to get stuck in the menus and cannot navigate to > the buttons. > > Consider to remove the old short-cut for the menus. > (Most/all the first_alph thingy in menubox.c) > That will avoid two confliting navigations principles and likely > make the code simpler to read. > > I am not sure, but maybe you can get rid of all the hotkey > support in print_item with this change too. Hi Sam, thank you (and also to Randy) for having a look at it. Next, I will prepare a patch, more thorougly tested, documentation included and with hotkey support removed. You are right, trying to support two navigation principles makes everything too complex and I was too eager to keep as much of today's functionality as possible. Dirk
Re: [RFC v4 0/1] i-search functionality for mconf
Sam Ravnborg writes: > Hi Dirk. > > On Fri, Jun 08, 2018 at 08:46:05PM +0200, Dirk Gouders wrote: >> Hello, >> >> this version is a prototype of the idea, Sam suggested -- I hope I >> undestood it correctly. >> >> This is a remarkable change to mconf in it's behavior; mainly it now >> differentiates two focuses and operates differently, depending on the >> focus. When the focus is on the menu, mconf is in i-search mode, for >> a detailed description see 1/1. >> >> As stated earlier, this is just a prototype, documentation is missing >> and the code is not ready for a real commit. > > When trying this out it started to work as envisioned. > But somehw I manage to get stuck in the menus and cannot navigate to > the buttons. > > Consider to remove the old short-cut for the menus. > (Most/all the first_alph thingy in menubox.c) > That will avoid two confliting navigations principles and likely > make the code simpler to read. > > I am not sure, but maybe you can get rid of all the hotkey > support in print_item with this change too. Hi Sam, thank you (and also to Randy) for having a look at it. Next, I will prepare a patch, more thorougly tested, documentation included and with hotkey support removed. You are right, trying to support two navigation principles makes everything too complex and I was too eager to keep as much of today's functionality as possible. Dirk
[RFC v4 0/1] i-search functionality for mconf
Hello, this version is a prototype of the idea, Sam suggested -- I hope I undestood it correctly. This is a remarkable change to mconf in it's behavior; mainly it now differentiates two focuses and operates differently, depending on the focus. When the focus is on the menu, mconf is in i-search mode, for a detailed description see 1/1. As stated earlier, this is just a prototype, documentation is missing and the code is not ready for a real commit. Dirk Dirk Gouders (1): Isearch functionality for mconf scripts/kconfig/lxdialog/dialog.h | 3 + scripts/kconfig/lxdialog/menubox.c | 207 + 2 files changed, 189 insertions(+), 21 deletions(-) -- 2.16.4
[RFC v4 1/1] i-search functionality for mconf
This patch prototypes isearch functionality for mconf based on an idea of
Sam Ravnborg:
* mconf now distinguishes if the focus is on the menu items or the
buttons below it.
* At startup focus is on the menu items and alphanumeric
characters or space entered are used to form a string that is
searched for.
* BACKSPACE is used to remove the last character of the search string.
* ENTER can be used to enter a submenu.
* Horizontal arrow keys put focus on the buttons with the known
behavior.
* The TAB key is now exclusively used to toggle the focus.
* Vertical arrow keys work anywhere.
* When the focus is on the buttons, all keys (e.g. hotkeys) work the
same as before this change.
* '\' can be used to search for other occurences of an already entered
string.
* To use y|n|m on an item, focus has to be on the buttons.
An example to navigate into the USB support menu under Device Drivers:
1) de# Navigates to the item "Device Drivers"
2) ENTER # Enter the submenu
3) USB # Navigate to the item "USB support"
4) ENTER # Enter the submenu
---
scripts/kconfig/lxdialog/dialog.h | 3 +
scripts/kconfig/lxdialog/menubox.c | 207 +
2 files changed, 189 insertions(+), 21 deletions(-)
diff --git a/scripts/kconfig/lxdialog/dialog.h
b/scripts/kconfig/lxdialog/dialog.h
index 0b00be5abaa6..02b036435919 100644
--- a/scripts/kconfig/lxdialog/dialog.h
+++ b/scripts/kconfig/lxdialog/dialog.h
@@ -50,6 +50,8 @@
#define TR(params) _tracef params
#define KEY_ESC 27
+#define KEY_CTRL_S 19
+#define KEY_ENTR 10
#define TAB 9
#define MAX_LEN 2048
#define BUF_SIZE (10*1024)
@@ -238,6 +240,7 @@ int dialog_checklist(const char *title, const char *prompt,
int height,
int width, int list_height);
int dialog_inputbox(const char *title, const char *prompt, int height,
int width, const char *init);
+int do_isearch(char *str, int choice, int scroll);
/*
* This is the base for fictitious keys, which activate
diff --git a/scripts/kconfig/lxdialog/menubox.c
b/scripts/kconfig/lxdialog/menubox.c
index d70cab36137e..e49280115b52 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -56,10 +56,17 @@
* fscanf would read in 'scroll', and eventually that value would get used.
*/
+#include
#include "dialog.h"
+#define ISEARCH_LEN 32
+#define ISEARCH_INDICATOR_LEN (ISEARCH_LEN + 8)
+static char isearch_str[ISEARCH_LEN] = "";
+
static int menu_width, item_x;
+static int focus_on_buttons;
+
/*
* Print menu item
*/
@@ -85,7 +92,10 @@ static void do_print_item(WINDOW * win, const char *item,
int line_y,
#else
wclrtoeol(win);
#endif
- wattrset(win, selected ? dlg.item_selected.atr : dlg.item.atr);
+ if (focus_on_buttons)
+ wattrset(win, selected ? A_UNDERLINE : dlg.item.atr);
+ else
+ wattrset(win, selected ? dlg.item_selected.atr : dlg.item.atr);
mvwaddstr(win, line_y, item_x, menu_item);
if (hotkey) {
wattrset(win, selected ? dlg.tag_key_selected.atr
@@ -105,6 +115,32 @@ do {
\
do_print_item(menu, item_str(), choice, selected, !item_is_tag(':')); \
} while (0)
+
+/*
+* Print the isearch indicator.
+*/
+static void print_isearch(WINDOW * win, int y, int x, int height, bool isearch)
+{
+ unsigned char i = 0;
+
+ wmove(win, y, x);
+
+ y = y + height + 1;
+ wmove(win, y, x);
+
+ if (isearch) {
+ wattrset(win, dlg.button_key_inactive.atr);
+ waddstr(win, "isearch: ");
+ waddstr(win, isearch_str);
+ i = ISEARCH_INDICATOR_LEN - strlen(isearch_str);
+ }
+
+ wattrset(win, dlg.menubox_border.atr);
+
+ for ( ; i < ISEARCH_INDICATOR_LEN; i++ )
+ waddch(win, ACS_HLINE);
+}
+
/*
* Print the scroll indicators.
*/
@@ -157,6 +193,9 @@ static void print_buttons(WINDOW * win, int height, int
width, int selected)
int x = width / 2 - 28;
int y = height - 2;
+ if (!focus_on_buttons)
+ selected = -1;
+
print_button(win, "Select", y, x, selected == 0);
print_button(win, " Exit ", y, x + 12, selected == 1);
print_button(win, " Help ", y, x + 24, selected == 2);
@@ -178,6 +217,32 @@ static void do_scroll(WINDOW *win, int *scroll, int n)
wrefresh(win);
}
+/*
+ * Incremental search for text in dialog menu entries.
+ * The search operates as a ring search, continuing at the top after
+ * the last entry has been visited.
+ *
+ * Returned is -1 if no match was found, else the absolute index of
+ * the matching item.
+ */
+int do_isearch(char *str, int choice, int scroll)
+{
+ int found = 0;
+ int i;
+
+ for (i = 0; i < item_count(); i++) {
+ item_set((choice +
[RFC v4 0/1] i-search functionality for mconf
Hello, this version is a prototype of the idea, Sam suggested -- I hope I undestood it correctly. This is a remarkable change to mconf in it's behavior; mainly it now differentiates two focuses and operates differently, depending on the focus. When the focus is on the menu, mconf is in i-search mode, for a detailed description see 1/1. As stated earlier, this is just a prototype, documentation is missing and the code is not ready for a real commit. Dirk Dirk Gouders (1): Isearch functionality for mconf scripts/kconfig/lxdialog/dialog.h | 3 + scripts/kconfig/lxdialog/menubox.c | 207 + 2 files changed, 189 insertions(+), 21 deletions(-) -- 2.16.4
[RFC v4 1/1] i-search functionality for mconf
This patch prototypes isearch functionality for mconf based on an idea of
Sam Ravnborg:
* mconf now distinguishes if the focus is on the menu items or the
buttons below it.
* At startup focus is on the menu items and alphanumeric
characters or space entered are used to form a string that is
searched for.
* BACKSPACE is used to remove the last character of the search string.
* ENTER can be used to enter a submenu.
* Horizontal arrow keys put focus on the buttons with the known
behavior.
* The TAB key is now exclusively used to toggle the focus.
* Vertical arrow keys work anywhere.
* When the focus is on the buttons, all keys (e.g. hotkeys) work the
same as before this change.
* '\' can be used to search for other occurences of an already entered
string.
* To use y|n|m on an item, focus has to be on the buttons.
An example to navigate into the USB support menu under Device Drivers:
1) de# Navigates to the item "Device Drivers"
2) ENTER # Enter the submenu
3) USB # Navigate to the item "USB support"
4) ENTER # Enter the submenu
---
scripts/kconfig/lxdialog/dialog.h | 3 +
scripts/kconfig/lxdialog/menubox.c | 207 +
2 files changed, 189 insertions(+), 21 deletions(-)
diff --git a/scripts/kconfig/lxdialog/dialog.h
b/scripts/kconfig/lxdialog/dialog.h
index 0b00be5abaa6..02b036435919 100644
--- a/scripts/kconfig/lxdialog/dialog.h
+++ b/scripts/kconfig/lxdialog/dialog.h
@@ -50,6 +50,8 @@
#define TR(params) _tracef params
#define KEY_ESC 27
+#define KEY_CTRL_S 19
+#define KEY_ENTR 10
#define TAB 9
#define MAX_LEN 2048
#define BUF_SIZE (10*1024)
@@ -238,6 +240,7 @@ int dialog_checklist(const char *title, const char *prompt,
int height,
int width, int list_height);
int dialog_inputbox(const char *title, const char *prompt, int height,
int width, const char *init);
+int do_isearch(char *str, int choice, int scroll);
/*
* This is the base for fictitious keys, which activate
diff --git a/scripts/kconfig/lxdialog/menubox.c
b/scripts/kconfig/lxdialog/menubox.c
index d70cab36137e..e49280115b52 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -56,10 +56,17 @@
* fscanf would read in 'scroll', and eventually that value would get used.
*/
+#include
#include "dialog.h"
+#define ISEARCH_LEN 32
+#define ISEARCH_INDICATOR_LEN (ISEARCH_LEN + 8)
+static char isearch_str[ISEARCH_LEN] = "";
+
static int menu_width, item_x;
+static int focus_on_buttons;
+
/*
* Print menu item
*/
@@ -85,7 +92,10 @@ static void do_print_item(WINDOW * win, const char *item,
int line_y,
#else
wclrtoeol(win);
#endif
- wattrset(win, selected ? dlg.item_selected.atr : dlg.item.atr);
+ if (focus_on_buttons)
+ wattrset(win, selected ? A_UNDERLINE : dlg.item.atr);
+ else
+ wattrset(win, selected ? dlg.item_selected.atr : dlg.item.atr);
mvwaddstr(win, line_y, item_x, menu_item);
if (hotkey) {
wattrset(win, selected ? dlg.tag_key_selected.atr
@@ -105,6 +115,32 @@ do {
\
do_print_item(menu, item_str(), choice, selected, !item_is_tag(':')); \
} while (0)
+
+/*
+* Print the isearch indicator.
+*/
+static void print_isearch(WINDOW * win, int y, int x, int height, bool isearch)
+{
+ unsigned char i = 0;
+
+ wmove(win, y, x);
+
+ y = y + height + 1;
+ wmove(win, y, x);
+
+ if (isearch) {
+ wattrset(win, dlg.button_key_inactive.atr);
+ waddstr(win, "isearch: ");
+ waddstr(win, isearch_str);
+ i = ISEARCH_INDICATOR_LEN - strlen(isearch_str);
+ }
+
+ wattrset(win, dlg.menubox_border.atr);
+
+ for ( ; i < ISEARCH_INDICATOR_LEN; i++ )
+ waddch(win, ACS_HLINE);
+}
+
/*
* Print the scroll indicators.
*/
@@ -157,6 +193,9 @@ static void print_buttons(WINDOW * win, int height, int
width, int selected)
int x = width / 2 - 28;
int y = height - 2;
+ if (!focus_on_buttons)
+ selected = -1;
+
print_button(win, "Select", y, x, selected == 0);
print_button(win, " Exit ", y, x + 12, selected == 1);
print_button(win, " Help ", y, x + 24, selected == 2);
@@ -178,6 +217,32 @@ static void do_scroll(WINDOW *win, int *scroll, int n)
wrefresh(win);
}
+/*
+ * Incremental search for text in dialog menu entries.
+ * The search operates as a ring search, continuing at the top after
+ * the last entry has been visited.
+ *
+ * Returned is -1 if no match was found, else the absolute index of
+ * the matching item.
+ */
+int do_isearch(char *str, int choice, int scroll)
+{
+ int found = 0;
+ int i;
+
+ for (i = 0; i < item_count(); i++) {
+ item_set((choice +
[RFC v3 1/1] Emacs-like isearch for mconf.
This patch implements isearch functionality for mconf as follows:
* isearch is started by pressing \ or CTRL-s; those keys can also be
used to find further matches of an already entered string.
* isearch is implemented as a ring search.
* Once isearch is started, all alphanumerical characters and
are appended to a search string that is then be used to find matches
in the menu.
* Any other character pressed terminates isearch and -- except ESC ESC
-- that character is further processed, e.g. ENTER to enter a submenu
without further input.
* To be able to use CTRL-s to start isearch, the terminal has to be
put into raw mode and this can be done by setting the environment
variable MENUCONFIG_RAW_MODE to a numeric value != 0.
An input example to navigate into the USB support menu under device
drivers:
1) \# start isearch
2) de # navigate to Device Drivers
3) ENTER# terminate isearch and enter submenu
4) \# start isearch
5) USB # navigate to USB support
6) ENTER# terminate isearch and enter submenu
Signed-off-by: Dirk Gouders
---
Documentation/kbuild/kconfig.txt | 18 +++-
scripts/kconfig/lxdialog/dialog.h | 6 ++
scripts/kconfig/lxdialog/menubox.c | 171 +
scripts/kconfig/lxdialog/util.c| 14 +++
scripts/kconfig/mconf.c| 47 ++
5 files changed, 254 insertions(+), 2 deletions(-)
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index 7233118f3a05..71270dcfa112 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -147,9 +147,11 @@ Its default value is "include/generated/autoconf.h".
menuconfig
--
-SEARCHING for CONFIG symbols
+Menuconfig offers two search capabilities:
+ 1) SEARCHING for CONFIG symbols
+ 2) Incremental search in menus
-Searching in menuconfig:
+Searching for CONFIG symbols:
The Search function searches for kernel configuration symbol
names, so you have to know something close to what you are
@@ -178,6 +180,18 @@ Searching in menuconfig:
first (and in alphabetical order), then come all other symbols,
sorted in alphabetical order.
+Incremental search in menus:
+
+ Isearch is started by pressing <\>. After that, any alphanumerical
+ character typed in is used to form a growing string that is searched
+ for in the menu items.
+
+ Isearch is realized as a ring search, restarting at the top if it
+ reaches the last menu item.
+
+ Further matches of an already entered string can be found by
+ pressing <\> instead of more alphanumerical characters.
+
__
User interface options for 'menuconfig'
diff --git a/scripts/kconfig/lxdialog/dialog.h
b/scripts/kconfig/lxdialog/dialog.h
index 0b00be5abaa6..271bd5a4bc13 100644
--- a/scripts/kconfig/lxdialog/dialog.h
+++ b/scripts/kconfig/lxdialog/dialog.h
@@ -50,6 +50,8 @@
#define TR(params) _tracef params
#define KEY_ESC 27
+#define KEY_CTRL_S 19
+#define KEY_ENTR 10
#define TAB 9
#define MAX_LEN 2048
#define BUF_SIZE (10*1024)
@@ -145,6 +147,7 @@ struct dialog_info {
extern struct dialog_info dlg;
extern char dialog_input_result[];
extern int saved_x, saved_y; /* Needed in signal handler in mconf.c
*/
+extern int raw_mode; /* Toggle raw mode */
/*
* Function prototypes
@@ -238,6 +241,9 @@ int dialog_checklist(const char *title, const char *prompt,
int height,
int width, int list_height);
int dialog_inputbox(const char *title, const char *prompt, int height,
int width, const char *init);
+int do_isearch(char *str, int choice, int scroll);
+int dialog_isearch(WINDOW *menu, WINDOW *dialog, int *choice, int max_choice,
+ int box_x, int box_y, int menu_height, int *scroll);
/*
* This is the base for fictitious keys, which activate
diff --git a/scripts/kconfig/lxdialog/menubox.c
b/scripts/kconfig/lxdialog/menubox.c
index d70cab36137e..20a14fa1c96f 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -56,8 +56,13 @@
* fscanf would read in 'scroll', and eventually that value would get used.
*/
+#include
#include "dialog.h"
+#define ISEARCH_LEN 32
+#define ISEARCH_INDICATOR_LEN (ISEARCH_LEN + 8)
+static char isearch_str[ISEARCH_LEN] = "";
+
static int menu_width, item_x;
/*
@@ -105,6 +110,32 @@ do {
\
do_print_item(menu, item_str(), choice, selected, !item_is_tag(':')); \
} while (0)
+
+/*
+* Print the isearch indicator.
+*/
+static void print_isearch(WINDOW * win, int y, int x, int height, bool isearch)
+{
+
[RFC v3 1/1] Emacs-like isearch for mconf.
This patch implements isearch functionality for mconf as follows:
* isearch is started by pressing \ or CTRL-s; those keys can also be
used to find further matches of an already entered string.
* isearch is implemented as a ring search.
* Once isearch is started, all alphanumerical characters and
are appended to a search string that is then be used to find matches
in the menu.
* Any other character pressed terminates isearch and -- except ESC ESC
-- that character is further processed, e.g. ENTER to enter a submenu
without further input.
* To be able to use CTRL-s to start isearch, the terminal has to be
put into raw mode and this can be done by setting the environment
variable MENUCONFIG_RAW_MODE to a numeric value != 0.
An input example to navigate into the USB support menu under device
drivers:
1) \# start isearch
2) de # navigate to Device Drivers
3) ENTER# terminate isearch and enter submenu
4) \# start isearch
5) USB # navigate to USB support
6) ENTER# terminate isearch and enter submenu
Signed-off-by: Dirk Gouders
---
Documentation/kbuild/kconfig.txt | 18 +++-
scripts/kconfig/lxdialog/dialog.h | 6 ++
scripts/kconfig/lxdialog/menubox.c | 171 +
scripts/kconfig/lxdialog/util.c| 14 +++
scripts/kconfig/mconf.c| 47 ++
5 files changed, 254 insertions(+), 2 deletions(-)
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index 7233118f3a05..71270dcfa112 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -147,9 +147,11 @@ Its default value is "include/generated/autoconf.h".
menuconfig
--
-SEARCHING for CONFIG symbols
+Menuconfig offers two search capabilities:
+ 1) SEARCHING for CONFIG symbols
+ 2) Incremental search in menus
-Searching in menuconfig:
+Searching for CONFIG symbols:
The Search function searches for kernel configuration symbol
names, so you have to know something close to what you are
@@ -178,6 +180,18 @@ Searching in menuconfig:
first (and in alphabetical order), then come all other symbols,
sorted in alphabetical order.
+Incremental search in menus:
+
+ Isearch is started by pressing <\>. After that, any alphanumerical
+ character typed in is used to form a growing string that is searched
+ for in the menu items.
+
+ Isearch is realized as a ring search, restarting at the top if it
+ reaches the last menu item.
+
+ Further matches of an already entered string can be found by
+ pressing <\> instead of more alphanumerical characters.
+
__
User interface options for 'menuconfig'
diff --git a/scripts/kconfig/lxdialog/dialog.h
b/scripts/kconfig/lxdialog/dialog.h
index 0b00be5abaa6..271bd5a4bc13 100644
--- a/scripts/kconfig/lxdialog/dialog.h
+++ b/scripts/kconfig/lxdialog/dialog.h
@@ -50,6 +50,8 @@
#define TR(params) _tracef params
#define KEY_ESC 27
+#define KEY_CTRL_S 19
+#define KEY_ENTR 10
#define TAB 9
#define MAX_LEN 2048
#define BUF_SIZE (10*1024)
@@ -145,6 +147,7 @@ struct dialog_info {
extern struct dialog_info dlg;
extern char dialog_input_result[];
extern int saved_x, saved_y; /* Needed in signal handler in mconf.c
*/
+extern int raw_mode; /* Toggle raw mode */
/*
* Function prototypes
@@ -238,6 +241,9 @@ int dialog_checklist(const char *title, const char *prompt,
int height,
int width, int list_height);
int dialog_inputbox(const char *title, const char *prompt, int height,
int width, const char *init);
+int do_isearch(char *str, int choice, int scroll);
+int dialog_isearch(WINDOW *menu, WINDOW *dialog, int *choice, int max_choice,
+ int box_x, int box_y, int menu_height, int *scroll);
/*
* This is the base for fictitious keys, which activate
diff --git a/scripts/kconfig/lxdialog/menubox.c
b/scripts/kconfig/lxdialog/menubox.c
index d70cab36137e..20a14fa1c96f 100644
--- a/scripts/kconfig/lxdialog/menubox.c
+++ b/scripts/kconfig/lxdialog/menubox.c
@@ -56,8 +56,13 @@
* fscanf would read in 'scroll', and eventually that value would get used.
*/
+#include
#include "dialog.h"
+#define ISEARCH_LEN 32
+#define ISEARCH_INDICATOR_LEN (ISEARCH_LEN + 8)
+static char isearch_str[ISEARCH_LEN] = "";
+
static int menu_width, item_x;
/*
@@ -105,6 +110,32 @@ do {
\
do_print_item(menu, item_str(), choice, selected, !item_is_tag(':')); \
} while (0)
+
+/*
+* Print the isearch indicator.
+*/
+static void print_isearch(WINDOW * win, int y, int x, int height, bool isearch)
+{
+
[RFC v3 0/1] Emacs-like isearch for mconf.
Hello, v2 went out incomplete, without the patch. Better so, because it would have just wasted people's time. For v4 I am planning to implement Sam's idea to kind of being in a permanent isearch when not using special keys. Changes in v3: * Use current git tree to make the patch apply. * Eliminate debugging output to stderr. Changes in v2: * Additionally to CTRL-s, \ can be used to start isearch. * Raw mode is off by default an can be enabled by an environment variable MENUCONFIG_RAW_MODE. * I also added a variable for toggling raw mode but did not implement anything else. * The isearch indicator is now displayed as soon as isearch is started. * Any key except \, CTRL-s, alphanumeric characters and space terminates isearch and -- except ESC ESC -- is further processed, e.g. ENTER terminates isearch and is then used to navigate into a submenu. * Problems with mismatches and matches above the current position were fixed. Dirk Gouders (1): Emacs-like isearch for mconf. Documentation/kbuild/kconfig.txt | 18 +++- scripts/kconfig/lxdialog/dialog.h | 6 ++ scripts/kconfig/lxdialog/menubox.c | 171 + scripts/kconfig/lxdialog/util.c| 14 +++ scripts/kconfig/mconf.c| 47 ++ 5 files changed, 254 insertions(+), 2 deletions(-) -- 2.16.4
