Hello all,
Today's planned meeting has been postponed to the 25th August (the time
of the next regular meeting) based on a voting of the participants
present at 19:39 UTC. These were:
* Giannis Adamopoulos
* Javier Agustìn Fernàndez Arroyo
* Maciej Bialas
* Thomas Faber
* Colin Finck
* Ziliang Guo
* Cameron Gutman
* Rafal Harabien
* Timo Kreuzer
* Matthias Kupfer
* Igor Paliychuk
* Sylvain Petreolle
* Daniel Reimer
* Pierre Schweitzer
* Samuel Serapion
* Olaf Siejka
○ Result:
[19:44] <VoteBot> Question: Please vote for a date for postponing
this meeting.
[19:44] <VoteBot> Answers:
[19:44] <VoteBot> Abstention - 7 votes
[19:44] <VoteBot> 11th August (in 2 weeks) - 3 votes
[19:44] <VoteBot> 25th August (in 4 weeks, regular next meeting) -
6 votes
[19:44] <VoteBot> Total number of votes: 16
○ Main reasons were that the following people were still not present
at the time of voting:
* Aleksey Bragin (supposed meeting leader and key person in the
Arwinss and Release preparation agenda points)
* Amine Khaldi (supposed backup meeting leader and key person in the
CMake agenda point)
* Ged Murphy (key person in the GSoC and Driver Signing agenda
points)
○ Unfortunately, nobody has been prepared for this kind of situation,
so a lot of time has been wasted and confusing decisions might have
been made.
○ Postponing the points also gives Aleksey time to prepare a new
Arwinss build and the Build Environment guys (Daniel, me, anybody
wants to join?) time to prepare a final CMake version of RosBE, which
might be a factor when deciding about doing the migration to CMake.
○ The IRC Server has been closed at 20:03 UTC.
To allow the participants to get an unbiased idea about today's meeting,
I will post the original IRC log by the server to ros-priv. Would
actually like to make it public on ros-dev as well, but will abstain
from doing so until Ged's confusion about the openness of our meetings
is cleared.
If people have already prepared texts for this meeting (status updates,
whatever else you wanted to say), please send them to my E-Mail address
within the next 3 days and I'll compose a summary out of them, which I
will send to ros-dev.
If you think that these texts don't just deserve a simple summary, keep
them for the next meeting or do whatever you want about them.
And finally a personal note: Please keep in mind that it was not an easy
decision for me to just close the IRC Server after I believed that main
discussions were over. If I had left it running, it would have
invalidated the voting (again) and participants would have treated the
meeting even more as a joke. By closing it, I obviously received
complaints from people who had prepared stuff for this meeting and
wanted to revive it.
In good hopes,
Colin
Hello,
Let me invite you to the monthly status meeting taking place last thursday
of this month, 28th of July, 19:00 UTC.
The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in the
channel #meeting. Note that the IRC service will only be started shortly
before the meeting. Everyone is invited to listen, and active community
members have their passwords so that they can participate in the discussion.
If someone doesn't have a password - please don't hesitate to email Colin to
get one. Colin - would you publish the most up-to-date list of participants?
Proposed agenda for the meeting:
1. Arwinss adoption voting.
2. CMake status report?. (Do we need to decide anything? If not, then let's
move discussion to the mailing list)
3. Release preparation status report. (Decide when to do winesyncs and
branch off the release)
More suggestions are welcome.
With the best regards,
Aleksey Bragin.
Hi,
Several times now cmake build has been broken. Time for some action!
Last meeting I asked everyone to test/use cmake. It was also mentioned
that if questions arise, we (Amine and me) would be happy to help out. I
can't remember anyone has asked how it works, so I assume noone had any
problems. There's also a pretty good wiki entry describing the whole
procedure for n00bs.
Now people tell me it's complicated, people are complaining that its
ridiculous to have 2 build systems, etc.
And probably noone has ever tried it.
We really need to move on.
I don't like having 2 build systems as well.
Current blocker is the debugging which has some issues, Arty is working
on that. Another problem is a boot problem on real hardware, but no I
don't know on which configuration it doesn't work, so we need more
people testing it on their real hardware setup and report any issues.
Here's a list with current issues:
http://www.reactos.org/wiki/CMake_Todo
So please:
If you are missing something, let us know.
If you like to make it better, make suggestions.
But stop ignoring cmake!
If noone cares and everyone just thinks he can give a s^Z damn until we
officially switch, then we can as well delete all cmake stuff and keep
rbuild. It has a lot of awesome advantages, like you only have to type
one command to build everything and you don't need to install cmake and
you can export whatever you want from kernel32 even if the functions
don't exist. Also you can enjoy the rbuild-loop again and again.
Or we can do it the hard way and delete rbuild, so people are forced to
use cmake. I'm sure this approach would be *really* appreaciated.
Thanks,
Timo
This won't work, since new Fibers, created with CreateFiber(Ex) don't
push a "return address" on the stack, but set the Eip member to
BaseFiberStartup.
Am 23.07.2011 14:08, schrieb ion(a)svn.reactos.org:
> Author: ion
> Date: Sat Jul 23 12:08:36 2011
> New Revision: 52807
>
> URL: http://svn.reactos.org/svn/reactos?rev=52807&view=rev
> Log:
> [KERNEL32]: Optimize SwitchToFiber to simply use "ret" to jump between fibers, instead of saving EIP and doing a JMP.
> Bug #50: SwitchToFiber needs to check if FXSR is *NOT* present in order to skip using ldmxcsr/stmxcsr. Previously, it would check if it's unsupported, and jump past the instruction if it was (resulting in invalid opcode instructions on older systems)
> 50 bugs. Penance has been paid.
>
> Modified:
> trunk/reactos/dll/win32/kernel32/client/i386/fiber.S
>
> Modified: trunk/reactos/dll/win32/kernel32/client/i386/fiber.S
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/…
> ==============================================================================
> --- trunk/reactos/dll/win32/kernel32/client/i386/fiber.S [iso-8859-1] (original)
> +++ trunk/reactos/dll/win32/kernel32/client/i386/fiber.S [iso-8859-1] Sat Jul 23 12:08:36 2011
> @@ -26,20 +26,16 @@
> mov [eax+FIBER_CONTEXT_EDI], edi
> mov [eax+FIBER_CONTEXT_EBP], ebp
>
> - /* Save the return address */
> - mov ebx, [esp]
> - mov [eax+FIBER_CONTEXT_EIP], ebx
> -
> /* Check if we're to save FPU State */
> cmp dword ptr [eax+FIBER_CONTEXT_FLAGS], CONTEXT_FULL OR CONTEXT_FLOATING_POINT
> jnz NoFpuStateSave
>
> /* Save the FPU State (Status and Control)*/
> fstsw [eax+FIBER_CONTEXT_FLOAT_SAVE_STATUS_WORD]
> - fstcw [eax+FIBER_CONTEXT_FLOAT_SAVE_CONTROL_WORD]
> + fnstcw [eax+FIBER_CONTEXT_FLOAT_SAVE_CONTROL_WORD]
>
> /* Check if the CPU supports SIMD MXCSR State Save */
> - cmp byte ptr ds:[PROCESSOR_FEATURE_FXSR], 0
> + cmp byte ptr ds:[PROCESSOR_FEATURE_FXSR], 1
> jnz NoFpuStateSave
> stmxcsr [eax+FIBER_CONTEXT_DR6]
>
> @@ -103,7 +99,7 @@
> ControlWordEqual:
>
> /* Load the new one */
> - cmp byte ptr ds:[PROCESSOR_FEATURE_FXSR], 0
> + cmp byte ptr ds:[PROCESSOR_FEATURE_FXSR], 1
> jnz NoFpuStateRestore
> ldmxcsr [ecx+FIBER_CONTEXT_DR6]
>
> @@ -121,7 +117,8 @@
> mov [edx+TEB_FLS_DATA], eax
>
> /* Jump to new fiber */
> - jmp dword ptr [ecx+FIBER_CONTEXT_EIP]
> + mov esp, [ecx+FIBER_CONTEXT_ESP]
> + ret 4
> +END
>
> -END
> /* EOF */
>
>
>
Am 23.07.2011 14:05, schrieb ion(a)svn.reactos.org:
> Author: ion
> Date: Sat Jul 23 12:05:38 2011
> New Revision: 52806
>
> URL: http://svn.reactos.org/svn/reactos?rev=52806&view=rev
> Log:
> [KERNEL32]: Implement BaseFiberStartup in ASM, just like the thread/process thunks, so we get a "naked" thunk without any compiler-generated crap.
I don't see the point in this change.
That "crap" is setting up a stack frame, which is pretty useful for
debugging. It consists of 3 instructions:
push ebp
mov ebp, esp
sub esp, 8
Your change also broke compilation with MSVC (the END directive is only
at the end of the file!) and deleted the function for amd64.
The function is not performance critical and the asm code doesn't really
add any performace gain anyway.
So why are we going back?
I'm asking, because I've been working on converting more asm code to C
code and IMO thats the way to go.
Regards,
Timo