Re: CVS commit: src/sys/arch/hppa
On Sunday 14 November 2010 03:16:05 Masao Uebayashi wrote: Module Name: src Committed By: uebayasi Date: Sun Nov 14 03:16:05 UTC 2010 Modified Files: src/sys/arch/hppa/hppa: pmap.c src/sys/arch/hppa/include: mutex.h vmparam.h Log Message: Don't rely on global APIs from internal. Why is this change necessary? Thanks, Nick To generate a diff of this commit: cvs rdiff -u -r1.78 -r1.79 src/sys/arch/hppa/hppa/pmap.c cvs rdiff -u -r1.9 -r1.10 src/sys/arch/hppa/include/mutex.h cvs rdiff -u -r1.16 -r1.17 src/sys/arch/hppa/include/vmparam.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch/hppa
On Sun, Nov 14, 2010 at 10:36:26AM +, Nick Hudson wrote: On Sunday 14 November 2010 03:16:05 Masao Uebayashi wrote: Module Name:src Committed By: uebayasi Date: Sun Nov 14 03:16:05 UTC 2010 Modified Files: src/sys/arch/hppa/hppa: pmap.c src/sys/arch/hppa/include: mutex.h vmparam.h Log Message: Don't rely on global APIs from internal. Why is this change necessary? Thanks, Nick To reduce unnecessary dependencies. kmutex_t is for users. machine/mutex.h is internal, it knows what it's typedef'ed from. All other machine/mutex.h uses struct kmutex. Do you have a specific reason to use kmutex_t? vm_page_md should be moved to machine/pmap.h too. It's not really a parameter. To generate a diff of this commit: cvs rdiff -u -r1.78 -r1.79 src/sys/arch/hppa/hppa/pmap.c cvs rdiff -u -r1.9 -r1.10 src/sys/arch/hppa/include/mutex.h cvs rdiff -u -r1.16 -r1.17 src/sys/arch/hppa/include/vmparam.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch/hppa
Did you check that a kernel still builds? I'll respond more fully later... Nick Sent from my iPhone On 14 Nov 2010, at 12:30, Masao Uebayashi uebay...@tombi.co.jp wrote: On Sun, Nov 14, 2010 at 10:36:26AM +, Nick Hudson wrote: On Sunday 14 November 2010 03:16:05 Masao Uebayashi wrote: Module Name:src Committed By:uebayasi Date:Sun Nov 14 03:16:05 UTC 2010 Modified Files: src/sys/arch/hppa/hppa: pmap.c src/sys/arch/hppa/include: mutex.h vmparam.h Log Message: Don't rely on global APIs from internal. Why is this change necessary? Thanks, Nick To reduce unnecessary dependencies. kmutex_t is for users. machine/mutex.h is internal, it knows what it's typedef'ed from. All other machine/mutex.h uses struct kmutex. Do you have a specific reason to use kmutex_t? vm_page_md should be moved to machine/pmap.h too. It's not really a parameter. To generate a diff of this commit: cvs rdiff -u -r1.78 -r1.79 src/sys/arch/hppa/hppa/pmap.c cvs rdiff -u -r1.9 -r1.10 src/sys/arch/hppa/include/mutex.h cvs rdiff -u -r1.16 -r1.17 src/sys/arch/hppa/include/vmparam.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch/powerpc/oea
On Sun, Nov 14, 2010 at 05:52:51AM +, David Holland wrote: On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote: XXX What is the conclusion about direct vs. indirect #include from headers? Every header file should include the things it requires to compile. Therefore, there should in principle be no cases where a header file (or source file) needs to #include something it doesn't itself use. This clarifies my long-unanswered question, thanks! I've (re)built about 300 kernels in the last days. I've found: - sys/sysctl.h's struct kinfo_proc should be moved into sys/proc.h (I've done this locally). Otherwise all sysctl node providers includes sys/proc.h and uvm/uvm_extern.h. (This is where I started...) - sys/syscallargs.h should be split into pieces, otherwise all its users have to know unrelated types (sys/mount.h, sys/cpu.h). - sys/proc.h's tsleep(), wakeup(), and friends should be moved into some common header, because it's widely used API. sys/proc.h will be used only for struct proc related things.
Re: CVS commit: src/sys/arch/powerpc/oea
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote: On Sun, Nov 14, 2010 at 05:52:51AM +, David Holland wrote: On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote: XXX What is the conclusion about direct vs. indirect #include from headers? Every header file should include the things it requires to compile. Therefore, there should in principle be no cases where a header file (or source file) needs to #include something it doesn't itself use. This clarifies my long-unanswered question, thanks! I've (re)built about 300 kernels in the last days. I've found: - sys/sysctl.h's struct kinfo_proc should be moved into sys/proc.h (I've done this locally). Otherwise all sysctl node providers includes sys/proc.h and uvm/uvm_extern.h. (This is where I started...) - sys/syscallargs.h should be split into pieces, otherwise all its users have to know unrelated types (sys/mount.h, sys/cpu.h). - sys/proc.h's tsleep(), wakeup(), and friends should be moved into some common header, because it's widely used API. sys/proc.h will be used only for struct proc related things. Note that none of ltsleep(), tsleep(), and wakeup() use struct proc as part of interface.
Re: CVS commit: src/sys/arch/powerpc/oea
On Sun, 14 Nov 2010 05:52:51 +, David Holland dholland-sourcechan...@netbsd.org said: On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote: XXX What is the conclusion about direct vs. indirect #include from headers? Every header file should include the things it requires to compile. Therefore, there should in principle be no cases where a header file (or source file) needs to #include something it doesn't itself use. Well, there is another thing which has to be considered. That is name space pollution. Header files which are exported to userland (for userland visible APIs) should not export random symbols. Only symbols which are defined as the interface of the header file are allowed to be exported. It seems the sys/param.h change is safe about this point though, because all definitions of the uvm_param.h seem to be protected by defined(_KERNEL). -- soda
Re: CVS commit: src/sys/arch/powerpc/oea
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote: On Sun, Nov 14, 2010 at 05:52:51AM +, David Holland wrote: On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote: XXX What is the conclusion about direct vs. indirect #include from headers? Every header file should include the things it requires to compile. Therefore, there should in principle be no cases where a header file (or source file) needs to #include something it doesn't itself use. This clarifies my long-unanswered question, thanks! I've (re)built about 300 kernels in the last days. I've found: - sys/sysctl.h's struct kinfo_proc should be moved into sys/proc.h (I've done this locally). Otherwise all sysctl node providers includes sys/proc.h and uvm/uvm_extern.h. (This is where I started...) - sys/syscallargs.h should be split into pieces, otherwise all its users have to know unrelated types (sys/mount.h, sys/cpu.h). - sys/proc.h's tsleep(), wakeup(), and friends should be moved into some common header, because it's widely used API. sys/proc.h will be used only for struct proc related things. What are the issues here that we need to fix this right now? Can you please post changes and/or start a thread about all this before you do them on tech-kern? Bernd
Re: CVS commit: src/sys/arch/powerpc/oea
On Nov,Monday 15 2010, at 7:16 AM, Bernd Ernesti wrote: On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote: On Sun, Nov 14, 2010 at 05:52:51AM +, David Holland wrote: On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote: XXX What is the conclusion about direct vs. indirect #include from headers? Every header file should include the things it requires to compile. Therefore, there should in principle be no cases where a header file (or source file) needs to #include something it doesn't itself use. This clarifies my long-unanswered question, thanks! I've (re)built about 300 kernels in the last days. I've found: - sys/sysctl.h's struct kinfo_proc should be moved into sys/proc.h (I've done this locally). Otherwise all sysctl node providers includes sys/proc.h and uvm/uvm_extern.h. (This is where I started...) - sys/syscallargs.h should be split into pieces, otherwise all its users have to know unrelated types (sys/mount.h, sys/cpu.h). - sys/proc.h's tsleep(), wakeup(), and friends should be moved into some common header, because it's widely used API. sys/proc.h will be used only for struct proc related things. What are the issues here that we need to fix this right now? I think that it's quite good time to fix, it would be much harder to do this after 6.0 branch. Regards Adam.
