Re: CVS commit: src/sys/arch/powerpc/oea
On Mon, Nov 15, 2010 at 02:48:29PM +0900, SODA Noriyuki wrote: 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. Indeed. Properly speaking though, headers that are exported to userland should define only the precise symbols that userland needs; kernel-only material should be kept elsewhere. We're a long way from that. Someday I'll clean it all up, but I think it had better wait until after we get version control that supports rename. In the meantime, wrapping in _KERNEL is the best we can do... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch/powerpc/oea
(moving this to tech-kern because it's the right place and per request) On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote: 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! *bow* 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...) I'm not sure this is a good plan in the long run. Shouldn't it at some point be unhooked fully from the real proc structure? - sys/syscallargs.h should be split into pieces, otherwise all its users have to know unrelated types (sys/mount.h, sys/cpu.h). Since system calls don't in general pass structures by value, it shouldn't need most of those header files, just forward declarations of the structs. (this is, btw, one of the reasons to avoid silly typedefs) - 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. Given that this is a deprecated API in the long term I'm not sure it's worthwhile. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/arch/powerpc/oea
On Mon, Nov 15, 2010 at 08:50:34AM +, David Holland wrote: On Mon, Nov 15, 2010 at 02:48:29PM +0900, SODA Noriyuki wrote: 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. Indeed. Properly speaking though, headers that are exported to userland should define only the precise symbols that userland needs; kernel-only material should be kept elsewhere. One start would be to add a sys/proc_internal.h so that sys/proc can be reduced to only stuff that userspace and some kernel parts are really expected to use. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/powerpc/oea
Hi, On Mon, Nov 15, 2010 at 5:41 PM, David Laight da...@l8s.co.uk wrote: On Mon, Nov 15, 2010 at 08:50:34AM +, David Holland wrote: On Mon, Nov 15, 2010 at 02:48:29PM +0900, SODA Noriyuki wrote: 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. Indeed. Properly speaking though, headers that are exported to userland should define only the precise symbols that userland needs; kernel-only material should be kept elsewhere. One start would be to add a sys/proc_internal.h so that sys/proc can be reduced to only stuff that userspace and some kernel parts are really expected to use. For the record, Linux kernels do sanitize their header before installation. One of the tools (unifdef) used still has a __IDSTRING(NetBSD, $NetBSD: unifdef.c,v 1.8 2000/07/03 02:51:36 matt Exp $); and __FBSDID($FreeBSD: /repoman/r/ncvs/src/usr.bin/unifdef/unifdef.c,v 1.20 2005/05/21 09:55:09 ru Exp $); so I guess it should already be in the tree, but maybe not the latest version. It is ran with -U__KERNEL__ by a headers install script, they wrote it in perl, but there it is not doing anything special sed(1) would not do. - Arnaud
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. Another thing: - We should provide sysconf() for kernel modules (device drivers) too, otherwise we have to expose unnecessary symbols (uvmexp).
Re: CVS commit: src/sys/arch/powerpc/oea
On Tue, Nov 16, 2010 at 10:20:46AM +0900, Masao Uebayashi wrote: Another thing: - We should provide sysconf() for kernel modules (device drivers) too, otherwise we have to expose unnecessary symbols (uvmexp). Why not the complete sysctl tree? -- David A. Holland dholl...@netbsd.org
