Re: A Framework to automatically configure a Kernel
--- Emmanuel Fleury <[EMAIL PROTECTED]> wrote: > Hi, > > Ahmad Reza Cheraghi wrote: > > > > I install right now a gcc 4.0 debian-packege on my > > system and it still works. But I attached another > > patch(I thik I did a mistake in the patch;-)). > > Might be as well ! :) > > But, I'll give it a try when you'll get this fixed ! > > >>2) Why is the target called "auconfig" and not > >>"autoconfig" (just like > >>we have a "menuconfig") ? > > > > I thought that autoconfig will be to large for > that > > reaseon i called it auconfig. > > Well, "menuconfig" is not that small either ! :) > More explicit you are, better it is (within some > reasonable limit). > > > If you mean with your question that, why there are > > less rules and why they don't get its information > from > > /sys or /proc etc. The answer will be: > > > > Not that much. Most of the information will be > > obtained from lspci and dmesg. The only one that > gets > > its inforamation directly from the I/O of the > Hardware > > is lspci. The other one like dmesg, /proc... anre > > based on the Kernel installation and on drivers > > installation. And it might happened that you won't > > find Hardware that are on your system but aren't > > installed from your Kernel. > > It was what I meant (sorry to have been unclear). > > > But if you mean with your question, that why it > dosn't > > first of all create list of all of the information > > given from /proc, ...? The answer is: > > > > That the basic Idea of the framework is to extend > it > > easily. And the rules can be changed they way > someody > > knew its right and ok. > > Ok. > > Regards > -- > Emmanuel Fleury > > Assistant Professor | Office: B1-201 > Computer Science Department, | Phone: +45 96 35 72 > 23 > Aalborg University, | Mobile: +45 26 22 98 > 03 > Fredriks Bajersvej 7E, | E-mail: > [EMAIL PROTECTED] > 9220 Aalborg East, Denmark | URL: > www.cs.aau.dk/~fleury > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A Framework to automatically configure a Kernel
Nice idea ! I really would like to have such feature. I tried a bit your stuff, unfortunately, I got this: [EMAIL PROTECTED] linux-2.6.13-autoconf]$ make auconfig HOSTCC scripts/kconfig/auto_conf.o scripts/kconfig/auto_conf.c: In function 'auto_conf': scripts/kconfig/auto_conf.c:288: warning: pointer targets in passing argument 2 of '__builtin_strncpy' differ in signedness scripts/kconfig/auto_conf.c: In function 'must_have': scripts/kconfig/auto_conf.c:301: error: syntax error at end of input make[1]: *** [scripts/kconfig/auto_conf.o] Error 1 make: *** [auconfig] Error 2 Seems that you don't use gcc-4 ! Two questions: 1) Isn't the XML parser a bit overkilling 2) Why is the target called "auconfig" and not "autoconfig" (just like we have a "menuconfig") ? Speaking about this autoconfig thingy, haven't been any serious attempt to grab as much information as possible from lspci, /proc, /sys and so on to build at least a skeleton for the .config ? Regards -- Emmanuel Fleury Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A Framework to automatically configure a Kernel
Nice idea ! I really would like to have such feature. I tried a bit your stuff, unfortunately, I got this: [EMAIL PROTECTED] linux-2.6.13-autoconf]$ make auconfig HOSTCC scripts/kconfig/auto_conf.o scripts/kconfig/auto_conf.c: In function 'auto_conf': scripts/kconfig/auto_conf.c:288: warning: pointer targets in passing argument 2 of '__builtin_strncpy' differ in signedness scripts/kconfig/auto_conf.c: In function 'must_have': scripts/kconfig/auto_conf.c:301: error: syntax error at end of input make[1]: *** [scripts/kconfig/auto_conf.o] Error 1 make: *** [auconfig] Error 2 Seems that you don't use gcc-4 ! Two questions: 1) Isn't the XML parser a bit overkilling 2) Why is the target called auconfig and not autoconfig (just like we have a menuconfig) ? Speaking about this autoconfig thingy, haven't been any serious attempt to grab as much information as possible from lspci, /proc, /sys and so on to build at least a skeleton for the .config ? Regards -- Emmanuel Fleury Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A Framework to automatically configure a Kernel
--- Emmanuel Fleury [EMAIL PROTECTED] wrote: Hi, Ahmad Reza Cheraghi wrote: I install right now a gcc 4.0 debian-packege on my system and it still works. But I attached another patch(I thik I did a mistake in the patch;-)). Might be as well ! :) But, I'll give it a try when you'll get this fixed ! 2) Why is the target called auconfig and not autoconfig (just like we have a menuconfig) ? I thought that autoconfig will be to large for that reaseon i called it auconfig. Well, menuconfig is not that small either ! :) More explicit you are, better it is (within some reasonable limit). If you mean with your question that, why there are less rules and why they don't get its information from /sys or /proc etc. The answer will be: Not that much. Most of the information will be obtained from lspci and dmesg. The only one that gets its inforamation directly from the I/O of the Hardware is lspci. The other one like dmesg, /proc... anre based on the Kernel installation and on drivers installation. And it might happened that you won't find Hardware that are on your system but aren't installed from your Kernel. It was what I meant (sorry to have been unclear). But if you mean with your question, that why it dosn't first of all create list of all of the information given from /proc, ...? The answer is: That the basic Idea of the framework is to extend it easily. And the rules can be changed they way someody knew its right and ok. Ok. Regards -- Emmanuel Fleury Assistant Professor | Office: B1-201 Computer Science Department, | Phone: +45 96 35 72 23 Aalborg University, | Mobile: +45 26 22 98 03 Fredriks Bajersvej 7E, | E-mail: [EMAIL PROTECTED] 9220 Aalborg East, Denmark | URL: www.cs.aau.dk/~fleury __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
