Re: ptrdiff_t in the kernel
dyo...@pobox.com (David Young) writes: >I would prefer for this to suffice both for the kernel and userland: > #include /* for bool */ > #include /* for size_t */ I bet that most places would need something like: #include #include #if defined(_KERNEL) || defined(_STANDALONE) #include #endif because the kernel needs a lot more types than provided by the standard C environment. If you want to make kernel code use standard C headers, and I think that's a good idea, then you have to attack a lot more code. Providing only stdbool.h and stddef.h in the kernel doesn't help, it just makes things ... different.
Re: [patch] put ptrdiff_t in the kernel and create sys/stddef.h
Hi David, Alan and Matt, On Wed, Dec 4, 2013 at 7:38 PM, Matt Thomas wrote: > > On Dec 4, 2013, at 1:33 PM, Alan Barrett wrote: > >> On Wed, 04 Dec 2013, David Holland wrote: >>> (*) A complete scheme for doing it right removes all the _BSD_FOO_T_ >>> drivel and ifdefs scattered in userland headers in favor of: >>> - a single header file that defines all the needed types prefixed >>>with __, which can be included anywhere; >>> - in userland, include-guarded header files akin to sys/null.h >>>that define single or common groups of the names without the >>>__ prefixes, e.g. ; >>> - including these header files in the proper places, such as in >>>standard userland header files like stddef.h; >>> - in the kernel, a single header file that defines all the types >>>without the __, that is or is exposed to sys/types.h but does >>>not affect userland. >> >> Yes, that's one way of doing it right. >> >> Until such time as somebody does it right, please follow the pattern of >> what's done already. > > which is what my suggested patch does. I got your point. Regards, -- Lourival Vieira Neto
Re: [patch] put ptrdiff_t in the kernel and create sys/stddef.h
On Dec 4, 2013, at 1:33 PM, Alan Barrett wrote: > On Wed, 04 Dec 2013, David Holland wrote: >> (*) A complete scheme for doing it right removes all the _BSD_FOO_T_ >> drivel and ifdefs scattered in userland headers in favor of: >> - a single header file that defines all the needed types prefixed >>with __, which can be included anywhere; >> - in userland, include-guarded header files akin to sys/null.h >>that define single or common groups of the names without the >>__ prefixes, e.g. ; >> - including these header files in the proper places, such as in >>standard userland header files like stddef.h; >> - in the kernel, a single header file that defines all the types >>without the __, that is or is exposed to sys/types.h but does >>not affect userland. > > Yes, that's one way of doing it right. > > Until such time as somebody does it right, please follow the pattern of > what's done already. which is what my suggested patch does.
Re: [patch] put ptrdiff_t in the kernel and create sys/stddef.h
On Wed, 04 Dec 2013, David Holland wrote: (*) A complete scheme for doing it right removes all the _BSD_FOO_T_ drivel and ifdefs scattered in userland headers in favor of: - a single header file that defines all the needed types prefixed with __, which can be included anywhere; - in userland, include-guarded header files akin to sys/null.h that define single or common groups of the names without the __ prefixes, e.g. ; - including these header files in the proper places, such as in standard userland header files like stddef.h; - in the kernel, a single header file that defines all the types without the __, that is or is exposed to sys/types.h but does not affect userland. Yes, that's one way of doing it right. Until such time as somebody does it right, please follow the pattern of what's done already. --apb (Alan Barrett)
Re: ~5 percent kernel performance loss in the last 3 weeks
On Wed, Dec 04, 2013 at 02:09:49PM +0100, Christoph Badura wrote: > I was able to pin this down on the pcu/fpu changes. A kernel from just > before that change doesn't have the performance loss. Those have been reverted. Thomas
Re: [patch] put ptrdiff_t in the kernel and create sys/stddef.h
On Wed, Dec 04, 2013 at 01:54:56PM -0200, Lourival Vieira Neto wrote: > >> > Why sys/stddef.h? Just keep them in sys/types.h please. > >> > >> To avoid redefining ptrdiff_t on stddef.h. I think it would be more > >> coherent, since ptrdiff_t is a stddef.h definition and stddef.h > >> shouldn't include sys/types.h. > > > > Weak reason. stddef.h must not include sys/types.h, but it doesn't mean > > they can't both define it. > > I didn't state that it can't be defined by both. I just said it would > be more coherent to define it in just one place. Why it is a bad idea? Because doing it *right* is a bigger cleanup than you've done(*) and the way consistent with the scheme already in place for handling these issues is what Matt posted. (*) A complete scheme for doing it right removes all the _BSD_FOO_T_ drivel and ifdefs scattered in userland headers in favor of: - a single header file that defines all the needed types prefixed with __, which can be included anywhere; - in userland, include-guarded header files akin to sys/null.h that define single or common groups of the names without the __ prefixes, e.g. ; - including these header files in the proper places, such as in standard userland header files like stddef.h; - in the kernel, a single header file that defines all the types without the __, that is or is exposed to sys/types.h but does not affect userland. This is not a small undertaking; don't try it at home. :-/ It is also probably impossible to pull off cleanly until the kernel/userland header namespace gets cleaned. -- David A. Holland dholl...@netbsd.org
Re: ptrdiff_t in the kernel
On Wed, Dec 04, 2013 at 10:13:14AM -0600, David Young wrote: > I would prefer for this to suffice both for the kernel and userland: > > #include /* for bool */ > #include /* for size_t */ > > ISTM that the reasons things are not that simple are merely historical > reasons, but I am open to other explanations. Doing this in a sane way requires a fairly large directory reorg. This is something that I am going to do once we have SCM rename support and don't really want to begin on until then. (Well, "requires", in the sense that we could create src/sys/include and put some stuff there without doing the full cleanup to move src/sys/sys to src/sys/include/sys, or stop sharing sys/*.h directly between kernel and userland. But I don't think this is a good idea -- the kernel include namespace is confusing enough as it is.) -- David A. Holland dholl...@netbsd.org
Re: ptrdiff_t in the kernel
On Wed, Dec 04, 2013 at 12:07:42PM -0200, Lourival Vieira Neto wrote: > >>> No, is not allowed in the kernel. Symbols from it are > >>> provided via other means. > >> > >> I know. In fact, I'm asking if it would be alright to allow that. > >> AFAIK, it would be inoffensive if available in the kernel. > > > > Actually, it would be offensive. > > Why? I would also like to know why that would be offensive! I'm always disappointed when I have to write something like this in order to share code between the userland and kernel, #if defined(_KERNEL) || defined(_STANDALONE) #include /* for bool, size_t---XXX not right? */ #else #include /* for bool */ #include /* for size_t */ #endif Apparently, is the correct header for size_t, so that is more properly written like this, #if defined(_KERNEL) || defined(_STANDALONE) #include /* for bool, size_t---XXX not right? */ #else #include /* for bool */ #include /* for size_t */ #endif I would prefer for this to suffice both for the kernel and userland: #include /* for bool */ #include /* for size_t */ ISTM that the reasons things are not that simple are merely historical reasons, but I am open to other explanations. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: [patch] put ptrdiff_t in the kernel and create sys/stddef.h
Hi Joerg, On Wed, Dec 4, 2013 at 12:25 PM, Joerg Sonnenberger wrote: > On Wed, Dec 04, 2013 at 12:04:23PM -0200, Lourival Vieira Neto wrote: >> Hi Mindaugas, >> >> >> Here is a patch that puts ptrdiff_t in the kernel. It also creates a >> >> sys/stddef.h header. >> > >> > Why sys/stddef.h? Just keep them in sys/types.h please. >> >> To avoid redefining ptrdiff_t on stddef.h. I think it would be more >> coherent, since ptrdiff_t is a stddef.h definition and stddef.h >> shouldn't include sys/types.h. > > Weak reason. stddef.h must not include sys/types.h, but it doesn't mean > they can't both define it. I didn't state that it can't be defined by both. I just said it would be more coherent to define it in just one place. Why it is a bad idea? Regards, -- Lourival Vieira Neto
Re: [patch] put ptrdiff_t in the kernel and create sys/stddef.h
On Wed, Dec 04, 2013 at 12:04:23PM -0200, Lourival Vieira Neto wrote: > Hi Mindaugas, > > >> Here is a patch that puts ptrdiff_t in the kernel. It also creates a > >> sys/stddef.h header. > > > > Why sys/stddef.h? Just keep them in sys/types.h please. > > To avoid redefining ptrdiff_t on stddef.h. I think it would be more > coherent, since ptrdiff_t is a stddef.h definition and stddef.h > shouldn't include sys/types.h. Weak reason. stddef.h must not include sys/types.h, but it doesn't mean they can't both define it. Joerg
Re: ptrdiff_t in the kernel
Is there a reason to do not have ptrdiff_t defined in the kernel? Shouldn't be OK to define it in sys/cdefs.h? Or even for having stddef.h itself in the kernel? >>> >>> It is defined in the kernel and comes from via >>> . >> >> Actually, it isn't. Only _BSD_PTRDIFF_T_ is defined by machine/ansi.h. >> The ptrdiff_t type is defined only in stddef.h. > > That surprises me. Easy enough to add. > > http://www.netbsd.org/~matt/ptrdiff-diff.txt I replied this in http://mail-index.netbsd.org/tech-kern/2013/12/04/msg016211.html. >>> No, is not allowed in the kernel. Symbols from it are >>> provided via other means. >> >> I know. In fact, I'm asking if it would be alright to allow that. >> AFAIK, it would be inoffensive if available in the kernel. > > Actually, it would be offensive. Why? Regards, -- Lourival Vieira Neto
Re: [patch] put ptrdiff_t in the kernel and create sys/stddef.h
Hi Mindaugas, >> Here is a patch that puts ptrdiff_t in the kernel. It also creates a >> sys/stddef.h header. > > Why sys/stddef.h? Just keep them in sys/types.h please. To avoid redefining ptrdiff_t on stddef.h. I think it would be more coherent, since ptrdiff_t is a stddef.h definition and stddef.h shouldn't include sys/types.h. Regards, -- Lourival Vieira Neto
Re: Lua in the kernel...
On Mon, Dec 02, 2013 at 08:33:38PM +0100, Marc Balmer wrote: > Some Illumos developers consider adding Lua to the kernel to provide > what they call ZFS Channel Programs: > > http://www.youtube.com/watch?v=EGKek5sZ2Xw&list=PLaUVvul17xSdWMBt5tAC8Hu7bbeWskD_q > > Lua part starts at approx 1:13 Really I would like to know why is it that you insist in installing Lua in the kernel of NetBSD. I find it very disgusting that in order to justify your activity of adding Lua in NetBSD's kernel you say "Look! others are doing it." Illumnos is Illumnos. It isn't NetBSD. If Illumnos wants to install an impurity like Lua right into it's kernel, that's it's problem. I myself have the most respect for NetBSD. Lua is a project which not controlled by NetBSD. It is controlled by the developers of Lua which are not NetBSD developers. By installing Lua in the kernel, you make NetBSD dependant of a peace of software that is controlled by an entity that is external to NetBSD. This is the definition of cancer. You are trying to install a cancer in the very kernel of NetBSD. If Illumnos developers don't know how to program in C, and needs Lua to implement what they call ZFS Channel Programs, that's their problem. The spread of Lua among NetBSD developers will cause a schism in NetBSD and make it difficult for NetBSD developers to work together. But maybe it is exactly what you are seeking. I dislike very much your activity of contaminating everything in NetBSD with Lua. You are causing me great harm with that. You started by pushing it in main. Then you attacked the kernel, then sysinstall. You mentioned contaminating rm(1) with Lua, in order to implent Lua in the mind of a certain user. I find you activity pointless, and insidious. You talk in the name of NetBSD to say : "we provide Lua so that people can do magic with it". If there is a language with which one can do magic, it is C. UNIX + C define a mathematical universe in which the programer is a mage and can do magic base on very strong, sane, and correct laws and fondations. If a person wants to pollute himself with Lua or whatever language that is in vogue at the time, let him do so. But in his own space. Why insisting on polluting others with their fantasy of the moment ? Each time something is trying to tell you about the problem of Lua, you are just ignoring their point, and use subtle psychological tactics to force Lua into their programs, their kernel, their community, and their mind. When a person doesn't know how to program in C, he shouldn't play with NetBSD's kernel.
Re: ~5 percent kernel performance loss in the last 3 weeks
On Tue, Nov 19, 2013 at 04:02:51PM +0100, Christoph Badura wrote: > After updating my -current kernel from 6.99.24 to 6.99.27 so I could > commit my ubsec(4) changes I noticed that under 6.99.27 I get between > 3 and 8 percent less throughput on accelerated crypto ops. I was able to pin this down on the pcu/fpu changes. A kernel from just before that change doesn't have the performance loss. --chris
Re: [patch] put ptrdiff_t in the kernel and create sys/stddef.h
Lourival Vieira Neto wrote: > Hi Folks, > > Here is a patch that puts ptrdiff_t in the kernel. It also creates a > sys/stddef.h header. Why sys/stddef.h? Just keep them in sys/types.h please. -- Mindaugas
Re: posix message queues and multiple receivers
da...@l8s.co.uk (David Laight) writes: >But what tends to happen is that the disk 'elevator' algorithm makes >one of the server process wait ages for its disk access to complete, >by which time the client has timed out and resubmitted the RPC request. The NFS client does not resubmit the RPC request because it uses TCP and it's not the IRIX implementation.
