Re: CVS commit: src/sys/arch/x86/x86
Hi, Christos. (2013/11/12 2:02), Christos Zoulas wrote: Module Name:src Committed By: christos Date: Mon Nov 11 17:02:53 UTC 2013 Modified Files: src/sys/arch/x86/x86: intel_busclock.c Log Message: CID 1128377: Comment out unreachable code; model is only 4 bits wide, so none of these constants can ever match. To generate a diff of this commit: cvs rdiff -u -r1.14 -r1.15 src/sys/arch/x86/x86/intel_busclock.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Thank you for the change. I was wrong and our code is little bad about using (extended) cpu family and (extended) cpu model. I'll write the change to fix the problem and to reduce the code duplication. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/sys/arch/x86/pci
On 12.11.13 16:08, SAITOH Masanobu wrote: Module Name: src Committed By: msaitoh Date: Tue Nov 12 15:08:01 UTC 2013 Modified Files: src/sys/arch/x86/pci: amdtemp.c Log Message: Calcurate the processor family correctly. The extended family bits should be added only when the base family is 0xf. The old code is correct as the extended family bits are 0 when base family is 0xf. Also, the amdtemp driver does not attach on such old cpus. Christoph
Re: CVS commit: src/sys/arch/x86/pci
(2013/11/13 0:12), Christoph Egger wrote: On 12.11.13 16:08, SAITOH Masanobu wrote: Module Name: src Committed By:msaitoh Date:Tue Nov 12 15:08:01 UTC 2013 Modified Files: src/sys/arch/x86/pci: amdtemp.c Log Message: Calcurate the processor family correctly. The extended family bits should be added only when the base family is 0xf. The old code is correct as the extended family bits are 0 when base family is 0xf. Also, the amdtemp driver does not attach on such old cpus. Christoph My change doesn't break anything, right? It's intentional. I'm now fixing and rewriting macros for cpu family and model to avoid trivial bugs and to reduce the code duplication. The change of rev. 1.17 is to make future changes clear. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/sys/arch/x86/pci
On 12.11.13 16:38, SAITOH Masanobu wrote: (2013/11/13 0:12), Christoph Egger wrote: On 12.11.13 16:08, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Tue Nov 12 15:08:01 UTC 2013 Modified Files: src/sys/arch/x86/pci: amdtemp.c Log Message: Calcurate the processor family correctly. The extended family bits should be added only when the base family is 0xf. The old code is correct as the extended family bits are 0 when base family is 0xf. Also, the amdtemp driver does not attach on such old cpus. Christoph My change doesn't break anything, right? It's intentional. No, it does not break anything. I'm now fixing and rewriting macros for cpu family and model to avoid trivial bugs and to reduce the code duplication. Ok. Christoph
Re: CVS commit: src/sys/arch/x86/pci
(2013/11/13 0:40), Christoph Egger wrote: On 12.11.13 16:38, SAITOH Masanobu wrote: (2013/11/13 0:12), Christoph Egger wrote: On 12.11.13 16:08, SAITOH Masanobu wrote: Module Name: src Committed By: msaitoh Date: Tue Nov 12 15:08:01 UTC 2013 Modified Files: src/sys/arch/x86/pci: amdtemp.c Log Message: Calcurate the processor family correctly. The extended family bits should be added only when the base family is 0xf. The old code is correct as the extended family bits are 0 when base family is 0xf. Also, the amdtemp driver does not attach on such old cpus. Christoph My change doesn't break anything, right? It's intentional. No, it does not break anything. Thanks. The reason why I didn't write Fix a bug that... was that I knew it wasn't broken :) I'm now fixing and rewriting macros for cpu family and model to avoid trivial bugs and to reduce the code duplication. Ok. Christoph I'll add some bugfixes with individual commit to state each bug. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/lib/lua/syslog
In article 20131112143203.8cd3...@cvs.netbsd.org, Marc Balmer source-changes-d@NetBSD.org wrote: -=-=-=-=-=- Module Name: src Committed By: mbalmer Date: Tue Nov 12 14:32:03 UTC 2013 Added Files: src/lib/lua/syslog: Makefile syslog.c Log Message: Add a syslog(3) binding for Lua (not yet linked to the build.) Is there any reason not to use the modern syslog (thread-safe) functions openlog_r(), syslog_r(), syslogp_r()? christos
Re: CVS commit: src/lib/lua/syslog
Am 12.11.13 17:04, schrieb Christos Zoulas: In article 20131112143203.8cd3...@cvs.netbsd.org, Marc Balmer source-changes-d@NetBSD.org wrote: -=-=-=-=-=- Module Name: src Committed By:mbalmer Date:Tue Nov 12 14:32:03 UTC 2013 Added Files: src/lib/lua/syslog: Makefile syslog.c Log Message: Add a syslog(3) binding for Lua (not yet linked to the build.) Is there any reason not to use the modern syslog (thread-safe) functions openlog_r(), syslog_r(), syslogp_r()? Good question. We would have to keep the context somewhere (certainly solvable), then, I wonder I Lua is ever used threaded? Could the problem arise in reality (it did not in our stuff since Jan 1st 2009) Maybe if two threads create separate states, and then both threads use syslog at the same time? (can not happen at this moment).
Re: CVS commit: src/lib/lua/syslog
On Tue, Nov 12, 2013 at 4:29 PM, Marc Balmer m...@msys.ch wrote: Am 12.11.13 17:04, schrieb Christos Zoulas: In article 20131112143203.8cd3...@cvs.netbsd.org, Marc Balmer source-changes-d@NetBSD.org wrote: -=-=-=-=-=- Module Name: src Committed By:mbalmer Date:Tue Nov 12 14:32:03 UTC 2013 Added Files: src/lib/lua/syslog: Makefile syslog.c Log Message: Add a syslog(3) binding for Lua (not yet linked to the build.) Is there any reason not to use the modern syslog (thread-safe) functions openlog_r(), syslog_r(), syslogp_r()? Good question. We would have to keep the context somewhere (certainly solvable), then, I wonder I Lua is ever used threaded? Could the problem arise in reality (it did not in our stuff since Jan 1st 2009) Maybe if two threads create separate states, and then both threads use syslog at the same time? (can not happen at this moment). People do use it threaded sometimes. I would just return a userdata with a _gc method to the user. Justin
Re: CVS commit: src/lib/lua/syslog
On Nov 12, 5:29pm, m...@msys.ch (Marc Balmer) wrote: -- Subject: Re: CVS commit: src/lib/lua/syslog | Good question. We would have to keep the context somewhere (certainly | solvable), then, I wonder I Lua is ever used threaded? Could the | problem arise in reality (it did not in our stuff since Jan 1st 2009) | | Maybe if two threads create separate states, and then both threads use | syslog at the same time? (can not happen at this moment). If lua is never threaded then this is a non-issue... christos
