Re: [patch] put Lua standard libraries into the kernel
On Wed, Nov 27, 2013 at 7:23 PM, Martin Husemann wrote: > Can't it be a per-state option, passed by luactl when creating the state? I think this is a better option. Regards, -- Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
On Wed, Nov 27, 2013 at 6:15 PM, dieter roelants wrote: > On Tue, 26 Nov 2013 12:50:16 +0100 > Marc Balmer wrote: > >> My suggestion is this: >> >> Build with lauxlib and also build the standard libraries >> Create a new sysctl kern.lua.stdlib, set to one by default >> If a new state is created in lua(4), run lua_openlib(...) on that state >> if kern.lua.stdlib is set to a vaue != 0 >> >> So by default a kernel Lua state would then have the stdlibs available, >> much you have them available when running lua(1). > > Maybe it's just me, but it seems strange to have this depend on a > (global) sysctl. I assume you have a reason for being able to disable > it. But if you then want to run other lua code that needs the stdlibs, > it will be enabled for your original code as well. Did I misunderstand? Yes, you're right. Regards, -- Lourival Vieira Neto
Re: [patch] put Lua standard libraries into the kernel
Can't it be a per-state option, passed by luactl when creating the state? Martin
Re: [patch] put Lua standard libraries into the kernel
On Tue, 26 Nov 2013 12:50:16 +0100 Marc Balmer wrote: > My suggestion is this: > > Build with lauxlib and also build the standard libraries > Create a new sysctl kern.lua.stdlib, set to one by default > If a new state is created in lua(4), run lua_openlib(...) on that state > if kern.lua.stdlib is set to a vaue != 0 > > So by default a kernel Lua state would then have the stdlibs available, > much you have them available when running lua(1). Maybe it's just me, but it seems strange to have this depend on a (global) sysctl. I assume you have a reason for being able to disable it. But if you then want to run other lua code that needs the stdlibs, it will be enabled for your original code as well. Did I misunderstand? kind regards dieter
Re: mpt(4) timeout recovery improvements
Hello. An initial review looks pretty good. I want to incorporate your patch into a reworked version of my original patch which handles more error conditions and give it a whirl. If you're amenable, I'll send you a new diff with the complete set of patches for testing. If both of us test good, I think we can commit the fixes and submit pullup requests for NetBSD-6 and NetBSD-5. To answer your specific question, I don't think you've made anything worse and I don't think you've introduced any new races. It will be a little while, i.e. a couple of weeks, before I can complete this work as I'm in the midst of a different project with a hard deadline. However, I'm very interested in seeing fixes for this driver hit the NetBSD source tree so support for this hardware will be much better going forward. -thanks -Brian On Nov 27, 5:49pm, Edgar =?iso-8859-1?B?RnXf?= wrote: } Subject: Re: mpt(4) timeout recovery improvements } > Could somebody please review it, especially whether I got the locking } > etc. right? } I'm still eager for someone with an understanding of NetBSD device drivers } to comment on what I've done. } } >From my experiments, I know that the patch does ~TRT for my MPT hardware, } but I'm pretty afraid I could have introduced some dumb race condition, } resource leakage, locking issue or whatever beginner's mistake one can make. >-- End of excerpt from Edgar =?iso-8859-1?B?RnXf?=
Re: mpt(4) timeout recovery improvements
> Could somebody please review it, especially whether I got the locking > etc. right? I'm still eager for someone with an understanding of NetBSD device drivers to comment on what I've done. >From my experiments, I know that the patch does ~TRT for my MPT hardware, but I'm pretty afraid I could have introduced some dumb race condition, resource leakage, locking issue or whatever beginner's mistake one can make.
Re: in which we present an ugly hack to make sys/queue.h CIRCLEQ work
On 27 Nov 2013 06:50, "Mouse" wrote: > > > Let me get on the record. It's basically ridiculous to allow GCC 4.8 > > to redefine the set of permitted C expressions such that it breaks > > BSD. > > gcc 4.8 isn't. C99 did; what's distinctive about gcc 4.8 is that > before that gcc didn't take advantage of the leeway C99 said it had. > These macros have been out-of-spec since the day NetBSD decided it was > going to use C99 rather than some older version of C; it's just that > only now is that out-of-spec-ness actually biting anyone. (That > decision may have been implicit in a compiler version change.) The decision to detect them and then optimise to broken code rather than a compile time error is what annoys me. Justin
