Re: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Randy Dunlap wrote: C99 spec that Al referred you to (available for around US$18 as a pdf) says in 6.7.8, para. 14 (where Al said): "An array of character type may be initialized by a character string literal, optionally enclosed in braces. Successive characters of the character string literal (including the terminating null character if there is room or if the array is of unknown size) initialize the elements of the array." Wow... So, the terminating '\0' in the string constant IS "special" and "optional"... Ok, then, THIS does answer my question, THIS I can understand, and, ghm, accept... Thanks to all who tried to explain this to me and sorry it took so long... You should not have asked in the first place. The declaration char c[4] = "abcd" is perfectly valid. There is no cause for debate about it :) Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote:
On Thu, 2 Aug 2007, Robert Hancock wrote:
Because 5 characters will not fit in a 4 character array, even without the
null terminator.
On Fri, 3 Aug 2007, Stefan Richter wrote:
How should gcc know whether you actually wanted that char foo[len] to
contain a \0 as last element?
Robert, Stefan, I am sorry, I think, you are VERY wrong here. There is no
"even" and no guessing. The "string" DOES include a terminating '\0'. It
is EQUIVALENT to {'s', 't', 'r', 'i', 'n', 'g', '\0'}. And it contains
SEVEN characters. Please, re-read your K Specifically, the Section
"Initialization" in the "Function and Program Structure" chapter (section
4.9 in my copy), the paragraph about initialization with a string, which I
quoted in an earlier email.
Guennadi,
The declaration
char c[4] = "abcd";
is perfectly valid.
If other versions of gcc give warnings with that declaration, then those
warnings may be useful but it does not mean to say that other versions of
gcc follow the standards or not.
K is good as a reference but not as an authority. They drafted the book
as an informal specification of C. C has evolved throughout the decades.
The current standard is C99. And as quoted earlier in this thread,
character array initializations are described as:
6.7.8.14 of C99:
An array of character type may be initialized by a character string
literal, optionally enclosed in braces. Successive characters of the
character string literal (including the terminating null character if there
is room or if the array is of unknown size) initialize the elements of the
array.
The gcc warning you see on other versions is a warning that does not have
anything to do with the current C standard. The other versions of gcc that
do not emit such character initialization warnings do not mean that they
are buggy in that respect.
IOW, the fact that you did not see the warning in a certain gcc version
does not mean that it is buggy in that respect.
Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
-
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: [ck] Re: ck vs. cfs : realtime audio performance
Martin Steigerwald wrote: Am Donnerstag 02 August 2007 schrieb Martin Steigerwald: The tone I see on responses to posts that are CCed to LKML in my perception often is just completely and utterly awfully unfriendly. And often those responses actual include factual inaccuracies and preliminary assumptions as well. Is that how Linux Kernel Management Style is supposed to work? I hope not. [...] Well, if Carlo is not a Linux Kernel manager this comment of mine is inapprobiate. Sorry for that. I am not a kernel manager, just a simple Linux user. I'm very very sorry if I have hurt anyone in this thread. Thank you very much. Best Regards. Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: ck vs. cfs : realtime audio performance
Klaus Schulz wrote: Hello Carlo. The ranters! comment: I can understand your way of looking at things. But you'd better be a bit more careful with statements like these below, if you don't really know what's going on. Just FYI: All possible traces - Ingo asked for - are on Ingos desk! Then that's very good :) I was just wondering on what possibly happened to the problem since the person who forwarded your concern from the ck list to the lkml (I don't subscribe to the ck list) didn't have a follow-up after a few days. And as far as the public list archives are concerned, there were no stats posted as Ingo had asked for. It seems though that you had done privately, then that's very good. Since your problem had already been posted online, I thought that any person who might've had a similar problem like yours would benefit from knowing what steps got undertaken to address the problem. I particularly was interested in your problem since I myself do a lot of music in Linux. I'm very sure that if your problem got discussed on-line, many linux-user musicians/programmers would benefit from it, like myself. Sorry if I have offended you and please accept my apologies. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: ck vs. cfs : realtime audio performance
Lenar Lõhmus wrote: Klaus Schulz wrote: I am currently testing the 2.6.22.1 cfs-rt9 vs. ck1 on my rather pure realtime high-end-audio setup. (NO X, just a terminal, streaming .wav. I am using my own written player and brutefir as the audio engine.) Comment: This is not a standard (amarok or xmms setup), all buffers in the chain are very small. Any problem will immidetialy end up in xruns. The sounddriver, HW (pci-bus etc.) are tweaked accordingly Until now ck1 on 2.6.22 is giving me better results (less audible distortions) and runs extremely stable compared to cfs. Under ck I ran my player with schedtool -R -p 98, which was better than running it e.g. with nice -20 Both setups under cfs were giving me worse results than ck. With CFS I also experienced XRUNS from time to time, what never happened with ck. See, this is exactly the problem of the SD ranters. A ranter posts a problem, doesn't give reproducability hints, and neither provides technical detail, not even the slightest relevant stats. And the most irritating part is that the code that the OP wrote (or at least its relevant parts) is not even available for download. I was wondering why the OP need timers for audio playback. What type of audio? PCM, MIDI? Once does not need timers for PCM playback but for MIDI. SD ranters. Pure rants. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: ck vs. cfs : realtime audio performance
Lenar Lõhmus wrote: Klaus Schulz wrote: I am currently testing the 2.6.22.1 cfs-rt9 vs. ck1 on my rather pure realtime high-end-audio setup. (NO X, just a terminal, streaming .wav. I am using my own written player and brutefir as the audio engine.) Comment: This is not a standard (amarok or xmms setup), all buffers in the chain are very small. Any problem will immidetialy end up in xruns. The sounddriver, HW (pci-bus etc.) are tweaked accordingly Until now ck1 on 2.6.22 is giving me better results (less audible distortions) and runs extremely stable compared to cfs. Under ck I ran my player with schedtool -R -p 98, which was better than running it e.g. with nice -20 Both setups under cfs were giving me worse results than ck. With CFS I also experienced XRUNS from time to time, what never happened with ck. See, this is exactly the problem of the SD ranters. A ranter posts a problem, doesn't give reproducability hints, and neither provides technical detail, not even the slightest relevant stats. And the most irritating part is that the code that the OP wrote (or at least its relevant parts) is not even available for download. I was wondering why the OP need timers for audio playback. What type of audio? PCM, MIDI? Once does not need timers for PCM playback but for MIDI. SD ranters. Pure rants. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: ck vs. cfs : realtime audio performance
Klaus Schulz wrote: Hello Carlo. The ranters! comment: I can understand your way of looking at things. But you'd better be a bit more careful with statements like these below, if you don't really know what's going on. Just FYI: All possible traces - Ingo asked for - are on Ingos desk! Then that's very good :) I was just wondering on what possibly happened to the problem since the person who forwarded your concern from the ck list to the lkml (I don't subscribe to the ck list) didn't have a follow-up after a few days. And as far as the public list archives are concerned, there were no stats posted as Ingo had asked for. It seems though that you had done privately, then that's very good. Since your problem had already been posted online, I thought that any person who might've had a similar problem like yours would benefit from knowing what steps got undertaken to address the problem. I particularly was interested in your problem since I myself do a lot of music in Linux. I'm very sure that if your problem got discussed on-line, many linux-user musicians/programmers would benefit from it, like myself. Sorry if I have offended you and please accept my apologies. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [ck] Re: ck vs. cfs : realtime audio performance
Martin Steigerwald wrote: Am Donnerstag 02 August 2007 schrieb Martin Steigerwald: The tone I see on responses to posts that are CCed to LKML in my perception often is just completely and utterly awfully unfriendly. And often those responses actual include factual inaccuracies and preliminary assumptions as well. Is that how Linux Kernel Management Style is supposed to work? I hope not. [...] Well, if Carlo is not a Linux Kernel manager this comment of mine is inapprobiate. Sorry for that. I am not a kernel manager, just a simple Linux user. I'm very very sorry if I have hurt anyone in this thread. Thank you very much. Best Regards. Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote:
On Thu, 2 Aug 2007, Robert Hancock wrote:
Because 5 characters will not fit in a 4 character array, even without the
null terminator.
On Fri, 3 Aug 2007, Stefan Richter wrote:
How should gcc know whether you actually wanted that char foo[len] to
contain a \0 as last element?
Robert, Stefan, I am sorry, I think, you are VERY wrong here. There is no
even and no guessing. The string DOES include a terminating '\0'. It
is EQUIVALENT to {'s', 't', 'r', 'i', 'n', 'g', '\0'}. And it contains
SEVEN characters. Please, re-read your KR. Specifically, the Section
Initialization in the Function and Program Structure chapter (section
4.9 in my copy), the paragraph about initialization with a string, which I
quoted in an earlier email.
Guennadi,
The declaration
char c[4] = abcd;
is perfectly valid.
If other versions of gcc give warnings with that declaration, then those
warnings may be useful but it does not mean to say that other versions of
gcc follow the standards or not.
KR is good as a reference but not as an authority. They drafted the book
as an informal specification of C. C has evolved throughout the decades.
The current standard is C99. And as quoted earlier in this thread,
character array initializations are described as:
6.7.8.14 of C99:
An array of character type may be initialized by a character string
literal, optionally enclosed in braces. Successive characters of the
character string literal (including the terminating null character if there
is room or if the array is of unknown size) initialize the elements of the
array.
The gcc warning you see on other versions is a warning that does not have
anything to do with the current C standard. The other versions of gcc that
do not emit such character initialization warnings do not mean that they
are buggy in that respect.
IOW, the fact that you did not see the warning in a certain gcc version
does not mean that it is buggy in that respect.
Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
-
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: gcc fixed size char array initialization bug - known?
Guennadi Liakhovetski wrote: On Thu, 2 Aug 2007, Randy Dunlap wrote: C99 spec that Al referred you to (available for around US$18 as a pdf) says in 6.7.8, para. 14 (where Al said): An array of character type may be initialized by a character string literal, optionally enclosed in braces. Successive characters of the character string literal (including the terminating null character if there is room or if the array is of unknown size) initialize the elements of the array. Wow... So, the terminating '\0' in the string constant IS special and optional... Ok, then, THIS does answer my question, THIS I can understand, and, ghm, accept... Thanks to all who tried to explain this to me and sorry it took so long... You should not have asked in the first place. The declaration char c[4] = abcd is perfectly valid. There is no cause for debate about it :) Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Arjan van de Ven wrote: Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. This, I think, is what really really matters in the end. I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying "if you had done you would have had ". Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. (and merging the code that is cleaning up/smallest is a reasonable one to pick for someone like Linus, likewise for the "which is likely to be maintained best" arguments) Very rational. I would now have to contend that CFS didn't lose and neither did SD. Linux won. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [ck] Re: Linus 2.6.23-rc1
Hua Zhong wrote: I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I agree with you here. It's not simply code superiority that matters but a balance of attitude and the code's corroboration with numbers. Both had numbers to show but I think that one's attitude was preferred over the other. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. I don't see where credit was lacking. As far as I've observed, SD's author was given acknowledgment on what he did and even got praise. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [ck] Re: Linus 2.6.23-rc1
Hua Zhong wrote: I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I agree with you here. It's not simply code superiority that matters but a balance of attitude and the code's corroboration with numbers. Both had numbers to show but I think that one's attitude was preferred over the other. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. I don't see where credit was lacking. As far as I've observed, SD's author was given acknowledgment on what he did and even got praise. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
Arjan van de Ven wrote: Let me repeat the key message: It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. It does not matter who's code gets merged. What matters is that the problem gets solved and that the Linux kernel innovates forward. This, I think, is what really really matters in the end. I've had several cases myself where I spent quite some time solving a problem, just to get some random remark from someone smart on lkml saying if you had done this simple thing you would have had this simple and superior solution. Was I pissed off that my patch didn't get merged but that this better approach got picked? NO! The problem that I needed to solve got solved in a really good way. Mission accomplished. (and merging the code that is cleaning up/smallest is a reasonable one to pick for someone like Linus, likewise for the which is likely to be maintained best arguments) Very rational. I would now have to contend that CFS didn't lose and neither did SD. Linux won. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [ck] Re: Linus 2.6.23-rc1
Roman Zippel wrote: When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. When Ingo wrote something that went head-on with what Con wrote, it was his prerogative to do so. There's no speaking here of rights to do or not to do since as matter of evidence, in the open source world, that which is superior (i.e. code, function, not person) has the right to exist and the inferior to die away. Did Ingo have the obligation to improve Con's work? Definitely not. Did Con have a right to get Ingo's improvements or suggestions? Definitely not. There are no such rights in this open source development framework (TM). What Ingo did, I think, was what he wanted and he has the right to do that. I believe that Ingo does not have an obligation to be responsible for what Con felt. You feel what you feel because you choose to feel that way. Let us remember that "Happiness is a choice, not a state." And let's just look at the attitudes on how both Ingo and Con reacted to the issues regarding their respective schedulers. I won't list them here now since they're all there in the archives. Since attitude also plays a big part in getting your code in mainline, I think we would know the reason why one got chosen for the other. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [ck] Re: Linus 2.6.23-rc1
Bill Huey (hui) wrote: On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. Legitimate emotional reaction for being locked out of the development process. There's a very human aspect to this, yes, a negative human aspect that pervade Linux kernel development and is overly defensive and protective of new ideas. Yes, the reaction was legitimate but it could have been better. It would have benefited everyone if instead of posting rants, numbers and patches or suggested solutions were posted. Up until today, some posters that complain on how CFS fairs worse than SD simply post reports that say: "I use this system in this way and it does not fair well with cfs!" Look at this one for example: http://lkml.org/lkml/2007/7/31/199 It looks technical but it isn't. The author simply stated that he built his own lightweight Linux box that specializes in audio but there has not been any technical characteristic of the problem. We don't even know the audio libraries he's using but simply claimed that he wrote his own. The report, if I were the one to debug it, is completely useless since it does not even give some reproducability hints nor technical characteristics of the system. This is what some of the SD fan-boys do. Rant. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [ck] Re: Linus 2.6.23-rc1
Bill Huey (hui) wrote: On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. Legitimate emotional reaction for being locked out of the development process. There's a very human aspect to this, yes, a negative human aspect that pervade Linux kernel development and is overly defensive and protective of new ideas. Yes, the reaction was legitimate but it could have been better. It would have benefited everyone if instead of posting rants, numbers and patches or suggested solutions were posted. Up until today, some posters that complain on how CFS fairs worse than SD simply post reports that say: I use this system in this way and it does not fair well with cfs! Look at this one for example: http://lkml.org/lkml/2007/7/31/199 It looks technical but it isn't. The author simply stated that he built his own lightweight Linux box that specializes in audio but there has not been any technical characteristic of the problem. We don't even know the audio libraries he's using but simply claimed that he wrote his own. The report, if I were the one to debug it, is completely useless since it does not even give some reproducability hints nor technical characteristics of the system. This is what some of the SD fan-boys do. Rant. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [ck] Re: Linus 2.6.23-rc1
Roman Zippel wrote: When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. When Ingo wrote something that went head-on with what Con wrote, it was his prerogative to do so. There's no speaking here of rights to do or not to do since as matter of evidence, in the open source world, that which is superior (i.e. code, function, not person) has the right to exist and the inferior to die away. Did Ingo have the obligation to improve Con's work? Definitely not. Did Con have a right to get Ingo's improvements or suggestions? Definitely not. There are no such rights in this open source development framework (TM). What Ingo did, I think, was what he wanted and he has the right to do that. I believe that Ingo does not have an obligation to be responsible for what Con felt. You feel what you feel because you choose to feel that way. Let us remember that Happiness is a choice, not a state. And let's just look at the attitudes on how both Ingo and Con reacted to the issues regarding their respective schedulers. I won't list them here now since they're all there in the archives. Since attitude also plays a big part in getting your code in mainline, I think we would know the reason why one got chosen for the other. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [ck] Re: Linus 2.6.23-rc1
Martin Steigerwald wrote: The current kernel development process tries to pretend that there is no human involvement. Which is plain inaccurate: It is *all* human involvement, without a human not a single bit of kernel code would change. IMHO, the above statements are all plain conjectures. How could you assert that the kernel development process is without human development? If you've followed the list for a while, you'd realize that the list is very human. The fact that flames fly and abound, and the fact that individual persons tend to be very strong with respect to their opinions indicate that there is a rather high level of human dealings that happen on the list. And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. We obviously all saw how the particular authors tried to address the issues. Ingo tried to address all concerns while Con simply ranted about his scheduler being better. If this is what you think about being a bit more human, then I think that this has no place in the lkml. We've all heard the "show me the numbers" argument, and as far as I can see, CFS now fairs much better than SD. That's the issue. The best one will emerge to be at the top. From several months of tests and improvements, it seems CFS is emerging to be the better scheduler. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [ck] Re: Linus 2.6.23-rc1
Martin Steigerwald wrote: The current kernel development process tries to pretend that there is no human involvement. Which is plain inaccurate: It is *all* human involvement, without a human not a single bit of kernel code would change. IMHO, the above statements are all plain conjectures. How could you assert that the kernel development process is without human development? If you've followed the list for a while, you'd realize that the list is very human. The fact that flames fly and abound, and the fact that individual persons tend to be very strong with respect to their opinions indicate that there is a rather high level of human dealings that happen on the list. And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. We obviously all saw how the particular authors tried to address the issues. Ingo tried to address all concerns while Con simply ranted about his scheduler being better. If this is what you think about being a bit more human, then I think that this has no place in the lkml. We've all heard the show me the numbers argument, and as far as I can see, CFS now fairs much better than SD. That's the issue. The best one will emerge to be at the top. From several months of tests and improvements, it seems CFS is emerging to be the better scheduler. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [LINUX POETRY] Boring limeriks (was: [PATCH 1/7] lguest: documentation pt I: Preparation)
Carlo Florendo wrote: Alan Cox wrote: On Tue, 24 Jul 2007 10:24:17 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: I thought limericks were supposed to be dirty... :) If I post limericks that are dirty Someone is bound to get shirty They'll rant and they'll rage for page after page Instead of coding new drivers to help me THE STAIR AND THE FAIR Please tell me, you'd say My darling, I pray That's one for the guess for (he) who knows best him -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [LINUX POETRY] Boring limeriks (was: [PATCH 1/7] lguest: documentation pt I: Preparation)
Alan Cox wrote: On Tue, 24 Jul 2007 10:24:17 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: I thought limericks were supposed to be dirty... :) If I post limericks that are dirty Someone is bound to get shirty They'll rant and they'll rage for page after page Instead of coding new drivers to help me THE STAIR AND THE FAIR There once was some code That scheduled all loads Then came what they call The staircase that rolled "But wait", said the fair who came without flair Let's see how they play Then choose who would stay The staircase seemed naught But some agreed not The fair then moved on As others got drawn They say life's not fair But that, you should bear The challenge, the draw seemed endless, I saw But one day, the other said no more for yonder So now there is peace And silence there is But camps would not rest 'Til they see the best And what is the best? The stair or the fair? I wouldn't just say Else flames won't abate You judge by the art The elegant part The order, not linear "But log!" said the fair The stair, said "one" "My order is one" Now both are just one But someone said "done" The fair and the stair An exciting affair! I hope there is more Discussions on fore O, Linux! Your ways! Some drool but some praise. For me, I am simple I cannot just mingle But seeing what's there I read all with care Lest I be confused With just what to use Just what do I use? I wouldn't dare muse Please tell me, you'd say My darling, I pray That's one for the guess for he who knows best -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [LINUX POETRY] Boring limeriks (was: [PATCH 1/7] lguest: documentation pt I: Preparation)
Alan Cox wrote: On Tue, 24 Jul 2007 10:24:17 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: I thought limericks were supposed to be dirty... :) If I post limericks that are dirty Someone is bound to get shirty They'll rant and they'll rage for page after page Instead of coding new drivers to help me THE STAIR AND THE FAIR There once was some code That scheduled all loads Then came what they call The staircase that rolled But wait, said the fair who came without flair Let's see how they play Then choose who would stay The staircase seemed naught But some agreed not The fair then moved on As others got drawn They say life's not fair But that, you should bear The challenge, the draw seemed endless, I saw But one day, the other said no more for yonder So now there is peace And silence there is But camps would not rest 'Til they see the best And what is the best? The stair or the fair? I wouldn't just say Else flames won't abate You judge by the art The elegant part The order, not linear But log! said the fair The stair, said one My order is one Now both are just one But someone said done The fair and the stair An exciting affair! I hope there is more Discussions on fore O, Linux! Your ways! Some drool but some praise. For me, I am simple I cannot just mingle But seeing what's there I read all with care Lest I be confused With just what to use Just what do I use? I wouldn't dare muse Please tell me, you'd say My darling, I pray That's one for the guess for he who knows best -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: [LINUX POETRY] Boring limeriks (was: [PATCH 1/7] lguest: documentation pt I: Preparation)
Carlo Florendo wrote: Alan Cox wrote: On Tue, 24 Jul 2007 10:24:17 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: I thought limericks were supposed to be dirty... :) If I post limericks that are dirty Someone is bound to get shirty They'll rant and they'll rage for page after page Instead of coding new drivers to help me THE STAIR AND THE FAIR Please tell me, you'd say My darling, I pray That's one for the guess for (he) who knows best him -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: Question about core file generation
Ravinandan Arakali (rarakali) wrote: Hi, When a process dumps core, the do_coredump() initiates the core file generation. Is this operation synchronous(does the kernel wait for core to be completely written to disk) ? The operations whereby (1) a process is in the process of exiting while; (2) the kernel is doing a coredump is asynchronous with respect to each other, since the process could have received an abort signal while the the kernel initiated the core dump. Basically, if I have the parent process waiting for exit of child which dumped core, can the parent access the core immediately on receipt of "child exit" message ? Is it possible that the core is still in the process of being written ? If so, what's the event the parent needs to wait for to be assured of a complete core. When a child exits, check if the core dump file is still opened by a handle (HINT: lsof). AFAICS from the kernel code, the core dump data or file routine is mutexed to ensure that there is only one process handling the core dump file. You could check if there are still open file handles on the dump. If there are none, it means that the dump had been completed. HTH. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: Question about core file generation
Ravinandan Arakali (rarakali) wrote: Hi, When a process dumps core, the do_coredump() initiates the core file generation. Is this operation synchronous(does the kernel wait for core to be completely written to disk) ? The operations whereby (1) a process is in the process of exiting while; (2) the kernel is doing a coredump is asynchronous with respect to each other, since the process could have received an abort signal while the the kernel initiated the core dump. Basically, if I have the parent process waiting for exit of child which dumped core, can the parent access the core immediately on receipt of child exit message ? Is it possible that the core is still in the process of being written ? If so, what's the event the parent needs to wait for to be assured of a complete core. When a child exits, check if the core dump file is still opened by a handle (HINT: lsof). AFAICS from the kernel code, the core dump data or file routine is mutexed to ensure that there is only one process handling the core dump file. You could check if there are still open file handles on the dump. If there are none, it means that the dump had been completed. HTH. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: Is it time for remove (crap) ALSA from kernel tree ?
Tomasz Kłoczko wrote: Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 for Linux: http://www.opensound.com/press/2007/oss-gpl-cddl.txt So this source without problems code can be integragrated in Linus tree and after this Linux can provide much better soud supoport than with current ALSA. Actually, ALSA is doing fine and doing great. There are issues of course, and some bugs too, but they've got their mailing list and Takashi Iwai fixes things quite well (and fast). Calling something crap will be useless until you can prove it. One minor complaint I have with ALSA is its documentation. It provides basic stuff but one has to do a lot of cross-references, IMHO, to understand its API. Other than that, with a mature open code base, ALSA is more excellent than OSS. Before calling things crap, you should be more technical and realistic (i.e. prove it with example). Otherwise, you will just be wasting your time whining. It shows too your lack of technical skill since you complain without knowing what you're complaining about. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: Is it time for remove (crap) ALSA from kernel tree ?
Tomasz Kłoczko wrote: On Sun, 24 Jun 2007, Alan Cox wrote: [..] Years ago Linux dumped OSS for ALSA because ALSA offered far better functionality and support. Why would we go back to the stone age ? Its something useful to various other platforms with basically no hardware support but Linux has ALSA and very good hardware support and ALSA even has emulation for back compatibility with old OSS apps. Ten years ago it would probably have made a difference, five maybe, today its a release of historical code at best, and since they shipped binary modules for Linux more like 'getting around to complying with the licence' than anything else. Sory Alan but I don't want philosophical/historical discuss. Try to answer on question "ALSA or OSS ?" using *only* technical arguments. You dare to demand technical arguments while you have not provided a single one. How dare you? -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: Is it time for remove (crap) ALSA from kernel tree ?
Tomasz Kłoczko wrote: On Sun, 24 Jun 2007, Alan Cox wrote: [..] Years ago Linux dumped OSS for ALSA because ALSA offered far better functionality and support. Why would we go back to the stone age ? Its something useful to various other platforms with basically no hardware support but Linux has ALSA and very good hardware support and ALSA even has emulation for back compatibility with old OSS apps. Ten years ago it would probably have made a difference, five maybe, today its a release of historical code at best, and since they shipped binary modules for Linux more like 'getting around to complying with the licence' than anything else. Sory Alan but I don't want philosophical/historical discuss. Try to answer on question ALSA or OSS ? using *only* technical arguments. You dare to demand technical arguments while you have not provided a single one. How dare you? -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: Is it time for remove (crap) ALSA from kernel tree ?
Tomasz Kłoczko wrote: Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 for Linux: http://www.opensound.com/press/2007/oss-gpl-cddl.txt So this source without problems code can be integragrated in Linus tree and after this Linux can provide much better soud supoport than with current ALSA. Actually, ALSA is doing fine and doing great. There are issues of course, and some bugs too, but they've got their mailing list and Takashi Iwai fixes things quite well (and fast). Calling something crap will be useless until you can prove it. One minor complaint I have with ALSA is its documentation. It provides basic stuff but one has to do a lot of cross-references, IMHO, to understand its API. Other than that, with a mature open code base, ALSA is more excellent than OSS. Before calling things crap, you should be more technical and realistic (i.e. prove it with example). Otherwise, you will just be wasting your time whining. It shows too your lack of technical skill since you complain without knowing what you're complaining about. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: Security computation within Linux kernel
JanuGerman wrote: Hi every one, I have one question regarding security libraries, already shipped with Linux Kernel. That is, all PKI, RSA libraries, as provided by OpenSSL are already integrated within the linux kernel source code? OR, one have to use OpenSSL seperately in this regard. IIRC, The kernel does some encryption functions, involving TCP, NFS, and IPsec since all these are part of the kernel itself. If you intend to write your own apps that have to use encryption functions, it would be best to use the relevant encryption libraries, such as OpenSSL. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: "menu" versus "menuconfig" -- they're *both* a bad idea
Robert P. J. Day wrote: (in short, if i, the builder, explicitly choose *not* to add a certain feature to my build, i think i have every right to expect that some other part of my configuration isn't quietly going to put some sub-choice of that feature back in behind my back.) I agree with this. However, if another feature actually depends on another explicitly unselected feature, there should at least be a warning prompt that such is the case. It probably would be hard though to track all dependencies. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: menu versus menuconfig -- they're *both* a bad idea
Robert P. J. Day wrote: (in short, if i, the builder, explicitly choose *not* to add a certain feature to my build, i think i have every right to expect that some other part of my configuration isn't quietly going to put some sub-choice of that feature back in behind my back.) I agree with this. However, if another feature actually depends on another explicitly unselected feature, there should at least be a warning prompt that such is the case. It probably would be hard though to track all dependencies. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: Security computation within Linux kernel
JanuGerman wrote: Hi every one, I have one question regarding security libraries, already shipped with Linux Kernel. That is, all PKI, RSA libraries, as provided by OpenSSL are already integrated within the linux kernel source code? OR, one have to use OpenSSL seperately in this regard. IIRC, The kernel does some encryption functions, involving TCP, NFS, and IPsec since all these are part of the kernel itself. If you intend to write your own apps that have to use encryption functions, it would be best to use the relevant encryption libraries, such as OpenSSL. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: kernel source dependency
Jan Engelhardt wrote: On Apr 3 2007 08:18, Randy Dunlap wrote: Hi, Without ncurses installed, you should see these messages: echo " *** Unable to find the ncurses libraries." echo " *** make menuconfig require the ncurses libraries" echo " *** " echo " *** Install ncurses (ncurses-devel) and try again" echo " *** " Do you not see them? or do you need something different? Perhaps libreadline-devel? Though ncurses-devel will *most likely* have a dependency on that, more even than the kernel does on ncurses-devel ;-) That is not so :) The kernel-source's 'menuconfig' target does not need libreadline-devel. Besides, there is no readline functionality that is evident at menuconfig. Menu navigation is entirely done by ncurses calls. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: kernel source dependency
Randy Dunlap wrote: On Tue, 03 Apr 2007 16:22:22 +0800 Carlo Florendo wrote: Hello, I'm not sure whether a fix is necessary for the following scenario. The kernel configure target "make menuconfig" requires ncurses. FWIW, it could probably be better if the error message would indicate that that ncurses is necessary for "make menuconfig" to run and that the user could be prompted to install the package. Hi, Without ncurses installed, you should see these messages: echo " *** Unable to find the ncurses libraries." echo " *** make menuconfig require the ncurses libraries" echo " *** " echo " *** Install ncurses (ncurses-devel) and try again" echo " *** " Do you not see them? or do you need something different? Thanks. It seems I just made noise. I saw exactly the same thing you posted, now that I've rested and it's 9:30AM. I didn't see it the other day at 2:30AM. Maybe I need more sleep :) Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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/
kernel source dependency
Hello, I'm not sure whether a fix is necessary for the following scenario. The kernel configure target "make menuconfig" requires ncurses. FWIW, it could probably be better if the error message would indicate that that ncurses is necessary for "make menuconfig" to run and that the user could be prompted to install the package. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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/
kernel source dependency
Hello, I'm not sure whether a fix is necessary for the following scenario. The kernel configure target make menuconfig requires ncurses. FWIW, it could probably be better if the error message would indicate that that ncurses is necessary for make menuconfig to run and that the user could be prompted to install the package. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: kernel source dependency
Randy Dunlap wrote: On Tue, 03 Apr 2007 16:22:22 +0800 Carlo Florendo wrote: Hello, I'm not sure whether a fix is necessary for the following scenario. The kernel configure target make menuconfig requires ncurses. FWIW, it could probably be better if the error message would indicate that that ncurses is necessary for make menuconfig to run and that the user could be prompted to install the package. Hi, Without ncurses installed, you should see these messages: echo *** Unable to find the ncurses libraries. echo *** make menuconfig require the ncurses libraries echo *** echo *** Install ncurses (ncurses-devel) and try again echo *** Do you not see them? or do you need something different? Thanks. It seems I just made noise. I saw exactly the same thing you posted, now that I've rested and it's 9:30AM. I didn't see it the other day at 2:30AM. Maybe I need more sleep :) Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: kernel source dependency
Jan Engelhardt wrote: On Apr 3 2007 08:18, Randy Dunlap wrote: Hi, Without ncurses installed, you should see these messages: echo *** Unable to find the ncurses libraries. echo *** make menuconfig require the ncurses libraries echo *** echo *** Install ncurses (ncurses-devel) and try again echo *** Do you not see them? or do you need something different? Perhaps libreadline-devel? Though ncurses-devel will *most likely* have a dependency on that, more even than the kernel does on ncurses-devel ;-) That is not so :) The kernel-source's 'menuconfig' target does not need libreadline-devel. Besides, there is no readline functionality that is evident at menuconfig. Menu navigation is entirely done by ncurses calls. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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/
