Re: CVS commit: src
On Tue, Dec 3, 2013 at 9:26 PM, Alexander Nasonov wrote: > Lourival Vieira Neto wrote: >> I wasn't in that thread at that time. However, I'll carefully read it. > > If you haven't done so yet, it's a good idea to subscribe to > source-changes-d@. Yes, I subscribed already =). I just hadn't at that time. >> Anyway, I think that the missing implementation of luai_numpow() >> doesn't break anything. > > Do you have a test to prove that 'return 2^3' doesn't break in the > kernel? Yes; you can just load the script you've mentioned. There is no reason to break anything. It is just defined as the multiplication operator. >> Is there an issue with lua_error? > > I don't think that lua_error would work because lua_State isn't passed > to luai_numpow(a,b). I wanted to say that you need a stub that breaks > in a very noticeable way. I really miss your point here. Why lua_State should be passed to luai_numpow()? Anyway, I just checked and lua_error is working fine. Do you have an example that breaks it? If you want a verbose output, just push your error message (like, lua_pushstring(L, "my error")) and call lua_error(L). If kern.lua.verbose is set, you will get "my error" printed. >> I don't think I've created a problem to myself. We discussed it on the >> list and _we_ come to a conclusion. Note, I don't think that this >> overflow is a huge problem. The worst that could happen is to have a >> truncation of a greater number instead of 0. Anyway, I think it must >> be fixed and that any of the two presented solutions is fine. However, >> I also have no problem to step back and use 'long long', if _we_ >> choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long >> long' is a good argument for that. I do prefer explicit width type, >> but my main argument is that 'long long' width could be lesser than 64 >> bit. > > Lua is external software and we should keep our copy close to the > original. If this sense long long is the best choice. However, Lua > 5.3 isn't released yet and Lua team may change their minds. They will > have to go through similar problem with strtoll replacement, though. I agree, we should keep the implementation close to the original. However, the whole point about luaconf.h is to adapt Lua without changing its implementation. IMO, we should choose the best LUA_NUMBER type for us. In this case, I think it is intmax_t (as already stated by Christos), if we won't use a fixed width type. Regards, -- Lourival Vieira Neto
Re: CVS commit: src
Lourival Vieira Neto wrote: > I wasn't in that thread at that time. However, I'll carefully read it. If you haven't done so yet, it's a good idea to subscribe to source-changes-d@. > Anyway, I think that the missing implementation of luai_numpow() > doesn't break anything. Do you have a test to prove that 'return 2^3' doesn't break in the kernel? > Is there an issue with lua_error? I don't think that lua_error would work because lua_State isn't passed to luai_numpow(a,b). I wanted to say that you need a stub that breaks in a very noticeable way. > I don't think I've created a problem to myself. We discussed it on the > list and _we_ come to a conclusion. Note, I don't think that this > overflow is a huge problem. The worst that could happen is to have a > truncation of a greater number instead of 0. Anyway, I think it must > be fixed and that any of the two presented solutions is fine. However, > I also have no problem to step back and use 'long long', if _we_ > choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long > long' is a good argument for that. I do prefer explicit width type, > but my main argument is that 'long long' width could be lesser than 64 > bit. Lua is external software and we should keep our copy close to the original. If this sense long long is the best choice. However, Lua 5.3 isn't released yet and Lua team may change their minds. They will have to go through similar problem with strtoll replacement, though. Alex
Re: CVS commit: src
On Dec 3, 10:04pm, jus...@specialbusservice.com (Justin Cormack) wrote: -- Subject: Re: CVS commit: src | No that is a bad side effect. It must always be 64 bits. In the kernel you | have to deal with uint64_t which will behave differently if intmax_t is | ever bigger than 64 bits, so code will break. So either use int64_t or what | Lua uses and assert that that is 64 bits. So far this is true (all intmax_t's are 64 bits). We can add a static assertion to protect us if that changes. christos
Re: CVS commit: src
On Tue, Dec 3, 2013 at 8:15 PM, Lourival Vieira Neto wrote: > Hi Justin, > > On Tue, Dec 3, 2013 at 8:04 PM, Justin Cormack > wrote: >> >> On 3 Dec 2013 16:02, "Christos Zoulas" wrote: >>> >>> On Dec 3, 11:45am, ln...@netbsd.org (Lourival Vieira Neto) wrote: >>> -- Subject: Re: CVS commit: src >>> >>> | Also, moving to intmax_t, would help in string library. It needs a >>> | length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no >>> | length modifier defined for int64_t. Using intmax_t we could just use >>> | "j". >>> >>> Yes, the other good side effect of intmax_t is that this is "the best >>> the machine" can do in terms of integer range. >>> >> >> No that is a bad side effect. It must always be 64 bits. In the kernel you >> have to deal with uint64_t which will behave differently if intmax_t is ever >> bigger than 64 bits, so code will break. So either use int64_t or what Lua >> uses and assert that that is 64 bits. > > What side effect? Why it must always be 64 bit? Also, I don't get the > unsigned problem. What it will break? Moreover, if we don't have a > 64-bit int type, what we should do? Disable Lua? just got the 'side effect' part.. =) -- Lourival Vieira Neto
Re: CVS commit: src
Hi Justin, On Tue, Dec 3, 2013 at 8:04 PM, Justin Cormack wrote: > > On 3 Dec 2013 16:02, "Christos Zoulas" wrote: >> >> On Dec 3, 11:45am, ln...@netbsd.org (Lourival Vieira Neto) wrote: >> -- Subject: Re: CVS commit: src >> >> | Also, moving to intmax_t, would help in string library. It needs a >> | length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no >> | length modifier defined for int64_t. Using intmax_t we could just use >> | "j". >> >> Yes, the other good side effect of intmax_t is that this is "the best >> the machine" can do in terms of integer range. >> > > No that is a bad side effect. It must always be 64 bits. In the kernel you > have to deal with uint64_t which will behave differently if intmax_t is ever > bigger than 64 bits, so code will break. So either use int64_t or what Lua > uses and assert that that is 64 bits. What side effect? Why it must always be 64 bit? Also, I don't get the unsigned problem. What it will break? Moreover, if we don't have a 64-bit int type, what we should do? Disable Lua? Regards, -- Lourival Vieira Neto
Re: CVS commit: src/sys/arch/xen/xen
On Tue, Dec 03, 2013 at 08:51:00PM +, Manuel Bouyer wrote: > Module Name: src > Committed By: bouyer > Date: Tue Dec 3 20:51:00 UTC 2013 > > Modified Files: > src/sys/arch/xen/xen: evtchn.c > > Log Message: > Remove the "evtchn_do_event: handler %p didn't lower ipl %d %d\n" printf. > With help from Robert Elz we've finally figured out what's going on, and > it actually isn't a bug in the handler, but related to spin mutexes. > When a spin mutex is released, the IPL isn't lowered back if the > curcpu is holding other spin mutexes. This is because mutexes may not > be released in order (and, in this case, the CPU in interrupted while > it holds a spin mutex at IPL < IPL_SCHED). Hmmm... that can lead to unexpected long periods with interrupts disabled. Or, more likely, high priority interrupts being disabled for longer than expected - because spin locks aren't normally used unless some interrupt need to be disabled and are rarely held for long. Saving the old spl in the mutex always seems like a good idea - until you start needing to do lock chaining. And if you bad lock chaining there are bigger problems. I guess it is nothing like as bad as systems that try to avoid priority inversion problems by raising the priority of a thread that holds a sleep lock when a higher priority thread waits for it - and then only drop the priority when the thread holds no locks. That can cause serious problems because low priority threads can quite reasonably hold sleep locks (that are contended by other similar processes) for very long periods. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/xen/xen
On 12/3/13 12:51 PM, Manuel Bouyer wrote: Module Name:src Committed By: bouyer Date: Tue Dec 3 20:51:00 UTC 2013 Modified Files: src/sys/arch/xen/xen: evtchn.c Log Message: Remove the "evtchn_do_event: handler %p didn't lower ipl %d %d\n" printf. With help from Robert Elz we've finally figured out what's going on, and it actually isn't a bug in the handler, but related to spin mutexes. When a spin mutex is released, the IPL isn't lowered back if the curcpu is holding other spin mutexes. This is because mutexes may not be released in order (and, in this case, the CPU in interrupted while it holds a spin mutex at IPL < IPL_SCHED). Also remove the test and resetting the IPL, it will be reset anyway inside the loop, or at the end of the loop. Thanks for figuring this one out! It's been bothering me for a while... +j
Re: CVS commit: src
On Tue, Dec 3, 2013 at 2:05 PM, Christos Zoulas wrote: > In article > , > Lourival Vieira Neto wrote: >>Hi Valery, >> >>On Tue, Dec 3, 2013 at 11:58 AM, Valery Ushakov wrote: >>> On Tue, Dec 03, 2013 at 11:45:15 -0200, Lourival Vieira Neto wrote: >>> Also, moving to intmax_t, would help in string library. It needs a length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no length modifier defined for int64_t. Using intmax_t we could just use "j". >>> >>> There is: PRId64 &c. >> >>I think PRI/SCNd64 are conversion specifiers. In practice, I think >>they will always expand to the same thing. But the standard >>differentiates these two kind of specifiers. Doesn't it? > > They don't. On i386 for example PRId64 expands to "lld" and on amd64 > it expands to "ld". I mean, they will expand to the same "type". That is, 'conversion specifiers' and 'length specifiers' are the same thing in practice, but two different things on the standard. That is what I understood reading it, anyway. So, is it alright to change lua_Number to intmax_t or we should move this discussion to tech-kern again? Regards, -- Lourival Vieira Neto
Re: CVS commit: src
In article , Lourival Vieira Neto wrote: >Hi Valery, > >On Tue, Dec 3, 2013 at 11:58 AM, Valery Ushakov wrote: >> On Tue, Dec 03, 2013 at 11:45:15 -0200, Lourival Vieira Neto wrote: >> >>> Also, moving to intmax_t, would help in string library. It needs a >>> length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no >>> length modifier defined for int64_t. Using intmax_t we could just use >>> "j". >> >> There is: PRId64 &c. > >I think PRI/SCNd64 are conversion specifiers. In practice, I think >they will always expand to the same thing. But the standard >differentiates these two kind of specifiers. Doesn't it? They don't. On i386 for example PRId64 expands to "lld" and on amd64 it expands to "ld". christos
Re: CVS commit: src
On Dec 3, 11:45am, ln...@netbsd.org (Lourival Vieira Neto) wrote: -- Subject: Re: CVS commit: src | Also, moving to intmax_t, would help in string library. It needs a | length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no | length modifier defined for int64_t. Using intmax_t we could just use | "j". Yes, the other good side effect of intmax_t is that this is "the best the machine" can do in terms of integer range. christos
Re: CVS commit: src
Hi Valery, On Tue, Dec 3, 2013 at 11:58 AM, Valery Ushakov wrote: > On Tue, Dec 03, 2013 at 11:45:15 -0200, Lourival Vieira Neto wrote: > >> Also, moving to intmax_t, would help in string library. It needs a >> length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no >> length modifier defined for int64_t. Using intmax_t we could just use >> "j". > > There is: PRId64 &c. I think PRI/SCNd64 are conversion specifiers. In practice, I think they will always expand to the same thing. But the standard differentiates these two kind of specifiers. Doesn't it? Regards, -- Lourival Vieira Neto
Re: CVS commit: src
On Tue, Dec 03, 2013 at 11:45:15 -0200, Lourival Vieira Neto wrote: > Also, moving to intmax_t, would help in string library. It needs a > length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no > length modifier defined for int64_t. Using intmax_t we could just use > "j". There is: PRId64 &c. -uwe
Re: CVS commit: src
Hi Christos, On Tue, Dec 3, 2013 at 11:22 AM, Christos Zoulas wrote: > In article <20131203082610.ga21...@mail.duskware.de>, > Martin Husemann wrote: >>On Mon, Dec 02, 2013 at 10:33:05PM -0200, Lourival Vieira Neto wrote: >>> I also have no problem to step back and use 'long long', if _we_ >>> choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long >>> long' is a good argument for that. I do prefer explicit width type, >>> but my main argument is that 'long long' width could be lesser than 64 >>> bit. >> >>Using long long is as arbitrary as using int64_t. >>The only reasonable other choice would be intmax_t (and I'm suprised >>Lua did not pick that). >> >>However, none of these make a difference with any of the currently >>supported architectures, so this argument is of cosmetic nature. > > Heh, this is why I suggested using intmax_t in the first place :-) Also, moving to intmax_t, would help in string library. It needs a length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no length modifier defined for int64_t. Using intmax_t we could just use "j". Regards, -- Lourival Vieira Neto
Re: CVS commit: src
Hi Martin, On Tue, Dec 3, 2013 at 6:26 AM, Martin Husemann wrote: > On Mon, Dec 02, 2013 at 10:33:05PM -0200, Lourival Vieira Neto wrote: >> I also have no problem to step back and use 'long long', if _we_ >> choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long >> long' is a good argument for that. I do prefer explicit width type, >> but my main argument is that 'long long' width could be lesser than 64 >> bit. > > Using long long is as arbitrary as using int64_t. I don't think so. If int64_t is defined, its width is 64 bit. > The only reasonable other choice would be intmax_t (and I'm suprised > Lua did not pick that). Maybe we should move to intmax_t. My argument to use int64_t instead of intmax_t was the Lua 5.3 manual (which states that integers have 64 bit width). However, the implementation uses 'long long' by default. I see no reason to do not use intmax_t anymore (even preferring fixed width, intmax_t looks like a better option). > However, none of these make a difference with any of the currently > supported architectures, so this argument is of cosmetic nature. I agree. However, I think we should choose the more coherent type, even that these types are the same in practice. Regards, -- Lourival Vieira Neto
Re: CVS commit: src
In article <20131203082610.ga21...@mail.duskware.de>, Martin Husemann wrote: >On Mon, Dec 02, 2013 at 10:33:05PM -0200, Lourival Vieira Neto wrote: >> I also have no problem to step back and use 'long long', if _we_ >> choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long >> long' is a good argument for that. I do prefer explicit width type, >> but my main argument is that 'long long' width could be lesser than 64 >> bit. > >Using long long is as arbitrary as using int64_t. >The only reasonable other choice would be intmax_t (and I'm suprised >Lua did not pick that). > >However, none of these make a difference with any of the currently >supported architectures, so this argument is of cosmetic nature. Heh, this is why I suggested using intmax_t in the first place :-) christos
Re: CVS commit: src/lib/libc/compiler_rt
On Mon, Dec 02, 2013 at 11:10:43PM -0800, Matt Thomas wrote: > > On Dec 2, 2013, at 6:28 PM, Joerg Sonnenberger wrote: > > > Module Name:src > > Committed By: joerg > > Date: Tue Dec 3 02:28:51 UTC 2013 > > > > Modified Files: > > src/lib/libc/compiler_rt: Makefile.inc > > > > Log Message: > > Add ARM (EABI) specific sources. Split off code that requires C11, > > unwind support in libc or overlaps with soft-float in preparation for > > using compiler-rt in the non-clang case. > > How will interact with libkern? I have a plugin Makefile which is structured similar to this. I'm currently in the process of testing a random subset of architectures for building... Joerg
Re: CVS commit: src
On Mon, Dec 02, 2013 at 10:33:05PM -0200, Lourival Vieira Neto wrote: > I also have no problem to step back and use 'long long', if _we_ > choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long > long' is a good argument for that. I do prefer explicit width type, > but my main argument is that 'long long' width could be lesser than 64 > bit. Using long long is as arbitrary as using int64_t. The only reasonable other choice would be intmax_t (and I'm suprised Lua did not pick that). However, none of these make a difference with any of the currently supported architectures, so this argument is of cosmetic nature. Martin
