lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 11 Apr 2007 21:32:36 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/30] Use menuconfig objects

Jan Engelhardt wrote:
> On Apr 11 2007 07:42, Al Boldi wrote:
> >Jan Engelhardt wrote:
> >
> >Correct, no oversight here; but it may be more meaningful, if you could
> >default select child-options based on the parent-state, like HW_RANDOM.
>
> A symbol will already have the 'magic' you describe if its creator wrote
> it that way. Changing to 'menuconfig' tokens does not change that I
> think. Consider:
>
> menu "foobar"
> config FOOBAR
>   bool "foobar"
>   default y
>
> config HW_RANDOM
>   depends on FOOBAR
>   default y
>
> endmenu
>
> This example should do things as you describe -- if FOOBAR is changed
> from n to y, HW_RANDOM should automatically do the same since it is a
> new option then.

I don't think so. But this might:

menu "foobar"
 config FOOBAR
   bool "foobar"
   default y

 config HW_RANDOM
   depends on FOOBAR
   default FOOBAR

endmenu

>
> menuconfig FOOBAR
>   bool "foobar"
>   default y
>
> if FOOBAR
>
> config HW_RANDOM
>   default y
>
> endif
>
> inhibits the same behavior AFAICS.

I think you mean "exhibits"?

>
> >Also, I don't think it's necessary to touch any of the "depends on"; keep
> >them as is, as they don't hurt staying that way, and may actually be
> >necessary under certain circumstances.  (see EMBEDDED)
>
> Simplifying the depends lines is a good thing IMO.

You are replacing the depends with an if block, which seems to add 
complexity, as we now have two constructs, if and depends.

IMHO, leave the depends as is, for simplicity and correctness and 
maintainability.

So if we have something like this:

menu "foobar"
 config FOOBAR
   bool "foobar"
   default y

 config FOOBAR_SUB1
   tristate "FOOBAR SUB1"
   depends on FOOBAR
   default m

 config FOOBAR_SUB2
   bool "FOOBAR SUB2"
   depends on FOOBAR
   default y

endmenu

Change it to something like this:

menuconfig FOOBAR
   tristate "foobar"
   default y

 config FOOBAR_SUB1
   tristate "FOOBAR SUB1"
   depends on FOOBAR
   default FOOBAR

 config FOOBAR_SUB2
   bool "FOOBAR SUB2"
   depends on FOOBAR
   default FOOBAR

without any if blocks, and maybe even in its own Kconfig.


Thanks!

--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ