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