[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080504150130.GB24008@flower.upol.cz>
Date: Sun, 4 May 2008 17:01:30 +0200
From: Oleg Verych <olecom@...wer.upol.cz>
To: David Collier-Brown <davecb@....com>
Cc: Sam Ravnborg <sam@...nborg.org>,
Roman Zippel <zippel@...ux-m68k.org>,
linux-kbuild <linux-kbuild@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: kconfig - a suggestion how to fix the select issue
David Collier-Brown @ Sun, May 04, 2008 at 08:55:12AM -0400:
[]
> I speculate that having two ways to express a dependency,
> and the addtition of visibility control makes the
> dependency tree-walk into a problem which is no longer
> solvable in trivial logic. That in turn makes my head
> explode (;-))
In short:
mixing all together and applying resolving and UI heuristics on top.
> I wonder if one could simplify back into a flat set of
> selections without visibility rules and a backwards-
> chaining "you need to select these too" message emitter,
> and if that would be worthwhile.
No need to hide anything and invent complexity. Flexible and
human-friendly interface. (Batch things like def_condig are done by
humans, randconfig -- useless if there's no heuristics, allyes - simple.)
Just UI part for now. Automation of selection can be applied only, after
one can see whole picture. Say, you have [ UCcamers ] which depends on
USB, Video, etc.
+-- Navigation ---------------------------------------------------+
| ... [ arch ] [ atm ] [ w-less speaker] |
| [ kernel ] --> [ drivers ] --> [ fun ] --> [ camerass ] |
| [ klibc ] [ file sys ] [ mtd ] [ manual DMA ] |
| ... ... ... ... |
+-----------------------------------------------------------------+
+-- needs ------+ +-- configure -----+ +-- options ---+
| ++Universal S bus++++ | | ... | | build: y [m] n |
| --Video capture--- |<-+-[* UCcamera ]-+->| RGB support y |
| --sysfs kernel for u- | | * LPTcamera | | YUV support y |
| | | * RS232camera | | HSB support y |
+-----------------------+ +------------------+ +----------------+
+-- command line/text editor -- olecom@kit[configure] ------------+
$ build = m \n
$ go <
+-- walk tags ---------+ +------------- Description ------------+
| intro, kernel, drivers,| | USB camera with foo bar features |
| fun, [camerass] | | with dual-core toaster and coffee |
| | | machine inside |
| | | |
| | | Options: |
| | | * RGB enables RGB |
| | | .... |
+------------------------+ +--------------------------------------+
So, after 'go <' command (visually or command-lineually) we will be in
[--Video capture--] which isn't configured/enabled yet (due to --)
Now,
+-- Navigation ---------------------------------------------------+
| ... [ arch ] [ atm ] [ w-less speaker] |
| [ kernel ] --> [ drivers ] --> [*fun*] --> [ camerass ] |
| [ klibc ] [ file sys ] [ mtd ] [ manual DMA ] |
| ... ... ... ... |
+-----------------------------------------------------------------+
+-- needs ------+ +-- configure -----+ +-- options ---+
| ++Universal S bus++++ | | ... | | build: y [m] n |
| [-Video capture--] |<-+-[* UCcamera ]-+->| RGB support y |
| --sysfs kernel for u- | | * LPTcamera | | YUV support y |
| | | * RS232camera | | HSB support y |
+-----------------------+ +------------------+ +----------------+
+-- command line/text editor -- olecom@kit[ needs ] ------------+
$ build = m \n
$ go < \n
$ we are here, hitting enter on needs/video
+-- walk tags ---------+ +------------- Description ------------+
| intro, kernel, drivers,| | Video processing for everyone |
| fun, cameras, [videoP] | | all is supported all works with no |
| | | OOP and shaman drums |
| | | |
| | | Inside MMA: |
| | | * conf: DEBUG |
| | | * build: chip1... |
+------------------------+ +--------------------------------------+
we will have:
+-- Navigation ---------------------------------------------------+
| [ arch ] [ mtd ] [ radio ] [ bt8xx ] |
| [ drivers ] -> [ media ] -> [*video*] -> [ cpia2 ] |
| [ file sys ] [ ps3 ] [ common] [ usbvideo ] |
| ... ... ... ... |
+-----------------------------------------------------------------+
+-- needs ------+ +-- configure -----+ +-- options ---+
| --V4L1-- | | ... | | menu: |
| --V4L2-- |<-+-[*Video capture]-+->| * DEBUG_FOO |
| --V4W7-- | | * Video decode | | * bt8xx |
| | | * Video improve | | ... |
+-----------------------+ +------------------+ +----------------+
+-- command line/text editor -- olecom@kit[configure] ------------+
$ go < \n
$ we are here, hitting enter on needs/video
$
+-- walk tags ---------+ +------------- Description ------------+
| intro, kernel, drivers,| | Video processing for everyone |
| fun, cameras, [video] | | all is supported all works with no |
| | | OOP and shaman drums |
| | | |
| | | Inside MMA: |
| | | * this is menu |
| | | |
+------------------------+ +--------------------------------------+
== [ rant ] ==
Can some of those PS3 or KDE teams design proper "Konfigure Linux"
game for kernel hackers? I try to do this with TERM=linux, `sh`, and
`sed`. Patching paper work isn't for such tasks.
On collecting CONFIG_ info by gcc in sources, thus generating symbol
dependency automatically, was told to shut up. Let's see what will
happen next. Don't forget to use cultural skills, imagination and
creativity.
--
sed 'sed && sh + olecom = love' << ''
-o--=O`C
#oo'L O
<___=E M
--
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