View previous topic :: View next topic |
Author |
Message |
Ulfalizer n00b
Joined: 09 Dec 2012 Posts: 3
|
Posted: Sun Dec 09, 2012 9:28 pm Post subject: |
|
|
smartass wrote: | Damn this world is small
Ulfalizer, no offense, but your API isn't well suited for dependency evaluations, that's all.
If you'd want it too, you'd most likely have to reimplement the core to support having tokens as instances and what not.
But that may not be worth it, because you'd be reimplementing the wheel, since there's already the flex/bison Kconfig parser. So maybe it would be better, if we tried to reimplement kconfiglib.py on top of something like pyBison, because then me and fpemud could get what we want and you could get an API that would be faster as it could be based on a C library. Also, if it used some of the C headers for parser definitions, you could be sure it is be compatible with the C implementation of the Kconfig version at hand.
And if it was implemented in such a way, maybe people would consider integrating it into the mainline kernel tree, as it would have a lot more potential with a an API exposing the Bison parsing. |
I don't see what parsing has to do with it. Kconfiglib already parses Kconfig very well (well enough to generate character-for-character identical output to the 'make *config' targets for all arches and defconfigs), and all the relevant expressions you'd need are already captured. It's not like it's painfully slow either - parsing the Kconfigs for x86 takes less than 1.5 seconds on my Core i5 system, even though it's a pure Python implementation. Sure, I could copy over rules from scripts/kconfig/zconf.{l,y} and use some Python Flex/Bison library, but I'm not sure it would be an improvement.
The real problem is that Kconfiglib lacks dependency APIs besides the internal ones, and those serve a different purpose (caching and invalidation) than what you're after. foo._get_dependent() returns all the symbols that would need to be invalidated if the value of foo changes for example, meaning you can't use their cached value any more.
I don't think adding some dependency inspection APIs to Kconfiglib should be very hard though, if only you tell me (roughly) what APIs you'd want.
Edit: Oh, and even if Flex and Bison were used, I don't think there'd be a way to make Kconfiglib automatically compatible with Kconfig changes and new features. The Flex/Bison rules from zconf.{l,y} are in C and interface with internals in the scripts/kconfig/*conf tools. The best you could do would be to copy over the grammar and rewrite rules in Python I think. |
|
Back to top |
|
|
aramis_qc Tux's lil' helper
Joined: 24 Sep 2006 Posts: 106 Location: Québec - Canada
|
Posted: Mon Dec 10, 2012 2:33 pm Post subject: |
|
|
A nice way to know which modules are needed is to boot on a LiveCD, for example SystemRescueCd. Running lsmod and saving output will help later. Here how I do things. I've done so for many years and I've always been successful.
- make defconfig
- output from lsmod (nconfig +search for CONFIG_)
- uncheck everything about debug options set by defconfig
- make <M> instead of <*> where possible except for filesystems in order to prevent from kernel panic
- usage of lspci along with some tips picked from http://files.kroah.com/lkn/lkn_pdf/ch07.pdf
- lsusb may be helpful in pluging/unpluging devices. Never say Y to USB printer because CUPS won't work
- emerge linux-firmware
- in doubt set options as per recommandation
When I update kernel, I simply hit ENTER to each question of oldconfig. _________________ Profil et systèmes |
|
Back to top |
|
|
smartass Apprentice
Joined: 04 Jul 2011 Posts: 189 Location: right behind you ... (you did turn around, didn't you?)
|
Posted: Wed Dec 12, 2012 7:54 am Post subject: |
|
|
Ulfalizer, what I and fpemud are after is to be able to inspect the dependencies of symbols. The most usable would be something like several dictionaries of symbols e.g. Symbol.referenced, Symbol.selected, Symbol.selected_by, Symbol.prompt, where these dictionaries could be something like Code: | {<some symbol> :
{ 'if yes' : [ <symbols>, ],
'depend' : [<symbols>]
},
} | , the nested dictionaries with lists would expose the context dependent evaluation, but that still isn't very clear, is it And I still wonder how to expose the logical && and || stuff.
The goal: Evaluate dependencies in Python.
aramis_qc, did you read the first post? because I'm not after having the necessary for boot modules, but having most of them in a sane manner. |
|
Back to top |
|
|
fpemud Guru
Joined: 15 Feb 2012 Posts: 349
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|