Ros-dev April 2017

ros-dev@reactos.org

19 participants
15 discussions

Re: [ros-dev] Microsoft switched to Git
by Alex Ionescu 10 May '17

10 May '17

Sounds like a bug in their migration/etc tool. MS has history going back to 1984 and migrated everything to Git with zero problems. At some point you should apply Ionescu's Razor: "Hmmm, a company of 150,000 developers and the most complicated and oldest series of repositories in the world, was able to move to Git, including while employing people who have been there for 30 years and used to other, older systems.... but 30 open source developers can't make that change because X". It follows from this that X is bullshit. On the polluting history, again, just read commits that have [FOOBAR] in them, and ignore others. Write a post-commit hook to rewrite/squash them. Best regards, Alex Ionescu On Thu, Feb 16, 2017 at 9:41 AM, Zachary Gorden <drakekaizer666(a)gmail.com> wrote: > The project that I worked with using git has history going back to 1988. > They certainly didn't start with git, nor did they necessarily start with > any revision control at the beginning, but after they migrated to it they > discovered the history problem. > > On Thu, Feb 16, 2017 at 10:42 AM, Colin Finck <colin(a)reactos.org> wrote: >> >> Am 16.02.2017 um 14:40 schrieb Alex Ionescu: >> > That being said, that type of "dirty history" only happens if you >> > heavily work with branches. That's not how reactos developers work -- we >> > don't open PRs and separate branches for every checkin. >> > >> > These ALL sound like manufactured problems or poor/strange use of git. >> >> That merge hell is easily reproducible using my default Git setup: >> >> 1) Change something in your clone of master and do a "git commit". >> 2) Let someone else change something in his clone of master and let him >> "git commit" and "git push" it. >> 3) Try to "git push" your commit, won't work because of the commit of >> the other person. >> 4) Do a "git pull" to fix the problem in 3) -> Bam! Git will do an >> automatic merge of both masters and pollute your history. >> >> You see, not a single extra branch is involved and yet we get two >> parallel streams of history. >> >> Rafal's mentioned "pull.rebase" option sounds promising, but can we >> enforce that somehow? >> >> >> - Colin >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

3 2

OpenAwards: Last 24 hours to cast votes for ReactOS!
by victor martinez 28 Apr '17

28 Apr '17

Hi guys! We made it! But we need your help to be in the top 5! Just 24 hours to do it! ReactOS has been selected as one of the most important projects in two different categories in the OpenAwards, an international opensource event based in Madrid. The 5 most voted will be widely announced, PRed, and finally one of them will be selected as a winner. The exposure is a need for us, you know that, so please help us by casting a vote. Takes just a second. Categories are: - Best Opensource Community: https://a.cstmapp.com/p/18092?fromgroup=1# <https://a.cstmapp.com/p/18092?fromgroup=1#> - Most innovative project: https://a.cstmapp.com/p/18085?fromgroup=1 Instructions: - Find ReactOS in each link. - Click in the button which says "Votar" (Vote) next to it. - It asks for a Name, Surname, an a valid email. Please confirm the vote!. - Done. I'm sure we can push ReactOS to the top! Let's surprise them with our voting boost!

2 1

New ideas added to GSoC Ideas list
by Colin Finck 25 Apr '17

25 Apr '17

Hi all! Daniel and me collected some additional ideas for GSoC today, which I've added to our Wiki Ideas list: https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas In particular: * Fundamental WiFi components * USBXHCI driver for supporting USB 3.x controllers * Bluetooth Stack * WebKit-based MSHTML implementation I'm open for comments and suggestions! We can still add ideas until March 20, so let's give students a large pool to draw from. Cheers, Colin

7 16

Status Meeting (April 2017)
by Aleksey Bragin 24 Apr '17

24 Apr '17

Hello, Let me invite you to the monthly status meeting taking place 27th of April, 19:00 UTC. We do it either in #reactos-meeting on Freenode, or on a very own standalone IRC server. In that case your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. And everyone is fine with that. Please send agenda proposals to me before the meeting so we don't waste time trying to setup the agenda directly during the meeting. Regards, Aleksey Bragin

1 0

retiring 'shellext/slayer'
by Mark Jansen 22 Apr '17

22 Apr '17

The shell extension 'slayer' will soon be removed. It has been surpassed by the shell extension 'acppage'. Since neither of the modules is yet active, this should not pose a problem. Related issues: CORE-10375 and CORE-13111 Regards, Mark.

1 0

Test KVM AHK Bot Upgrade
by Sylvain Petreolle 18 Apr '17

18 Apr '17

Hello all, I'm currently upgrading my AHK Testbot to Fedora 25, 24 only receives backports and Fedora 26 is already on the way. I never upgraded it before, so I don't know if it will take one or several hours to be back online. Kind regards, Sylvain Petreolle

1 0

Re: [ros-dev] [ros-diffs] [tfaber] 74305: [NTOS:KE] - Gracefully handle page faults during V86 code execution. This is a bit of a hack because with our limited use of V86 code it is unclear how a page fault can even occur. ...
by Alex Ionescu 14 Apr '17

14 Apr '17

So why implement this code path if we have nothing that hits it? Best regards, Alex Ionescu On Fri, Apr 14, 2017 at 4:18 AM, <tfaber(a)svn.reactos.org> wrote: > Author: tfaber > Date: Fri Apr 14 11:18:22 2017 > New Revision: 74305 > > URL: http://svn.reactos.org/svn/reactos?rev=74305&view=rev > Log: > [NTOS:KE] > - Gracefully handle page faults during V86 code execution. This is a bit > of a hack because with our limited use of V86 code it is unclear how a page > fault can even occur. > CORE-12993 #resolve > > Modified: > trunk/reactos/ntoskrnl/include/internal/i386/ke.h > trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > trunk/reactos/ntoskrnl/vdm/vdmexec.c > > Modified: trunk/reactos/ntoskrnl/include/internal/i386/ke.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ > ntoskrnl/include/internal/i386/ke.h?rev=74305&r1=74304&r2=74305&view=diff > ============================================================ > ================== > --- trunk/reactos/ntoskrnl/include/internal/i386/ke.h [iso-8859-1] > (original) > +++ trunk/reactos/ntoskrnl/include/internal/i386/ke.h [iso-8859-1] Fri > Apr 14 11:18:22 2017 > @@ -478,6 +478,12 @@ > NTAPI > VdmDispatchBop( > IN PKTRAP_FRAME TrapFrame > +); > + > +BOOLEAN > +NTAPI > +VdmDispatchPageFault( > + _In_ PKTRAP_FRAME TrapFrame > ); > > BOOLEAN > > Modified: trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ > ntoskrnl/ke/i386/traphdlr.c?rev=74305&r1=74304&r2=74305&view=diff > ============================================================ > ================== > --- trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] Fri Apr 14 > 11:18:22 2017 > @@ -1304,8 +1304,20 @@ > UNIMPLEMENTED_FATAL(); > } > #endif > + > /* Check for VDM trap */ > - ASSERT((KiVdmTrap(TrapFrame)) == FALSE); > + if (KiVdmTrap(TrapFrame)) > + { > + DPRINT1("VDM PAGE FAULT at %lx:%lx for address %lx\n", > + TrapFrame->SegCs, TrapFrame->Eip, Cr2); > + if (VdmDispatchPageFault(TrapFrame)) > + { > + /* Return and end VDM execution */ > + DPRINT1("VDM page fault with status 0x%lx resolved\n", > Status); > + KiEoiHelper(TrapFrame); > + } > + DPRINT1("VDM page fault with status 0x%lx NOT resolved\n", > Status); > + } > > /* Either kernel or user trap (non VDM) so dispatch exception */ > if (Status == STATUS_ACCESS_VIOLATION) > > Modified: trunk/reactos/ntoskrnl/vdm/vdmexec.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ > ntoskrnl/vdm/vdmexec.c?rev=74305&r1=74304&r2=74305&view=diff > ============================================================ > ================== > --- trunk/reactos/ntoskrnl/vdm/vdmexec.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/vdm/vdmexec.c [iso-8859-1] Fri Apr 14 > 11:18:22 2017 > @@ -239,7 +239,7 @@ > KeLowerIrql(OldIrql); > return STATUS_INVALID_SYSTEM_SERVICE; > } > - > + > /* Now do the VDM Swap */ > VdmSwapContext(VdmFrame, &VdmTib->MonitorContext, &VdmContext); > > @@ -269,7 +269,7 @@ > > /* Make a copy of the monitor context */ > Context = VdmTib->MonitorContext; > - > + > /* Check if V86 mode was enabled or the trap was edited */ > if ((Context.EFlags & EFLAGS_V86_MASK) || (Context.SegCs & > FRAME_EDITED)) > { > @@ -291,7 +291,7 @@ > /* Remove real IF flag */ > VdmTib->VdmContext.EFlags &= ~EFLAGS_INTERRUPT_MASK; > } > - > + > /* Turn off VIP and VIF */ > TrapFrame->EFlags &= ~(EFLAGS_VIP | EFLAGS_VIF); > VdmTib->VdmContext.EFlags &= ~(EFLAGS_VIP | EFLAGS_VIF); > @@ -362,4 +362,45 @@ > return TRUE; > } > > - > +BOOLEAN > +NTAPI > +VdmDispatchPageFault( > + _In_ PKTRAP_FRAME TrapFrame) > +{ > + NTSTATUS Status; > + PVDM_TIB VdmTib; > + > + PAGED_CODE(); > + > + /* Get the VDM TIB so we can terminate V86 execution */ > + Status = VdmpGetVdmTib(&VdmTib); > + if (!NT_SUCCESS(Status)) > + { > + /* Not a proper VDM fault, keep looking */ > + DPRINT1("VdmDispatchPageFault: no VDM TIB, Vdm=%p\n", > NtCurrentTeb()->Vdm); > + return FALSE; > + } > + > + /* Must be coming from V86 code */ > + ASSERT(TrapFrame->EFlags & EFLAGS_V86_MASK); > + > + _SEH2_TRY > + { > + /* Fill out a VDM Event */ > + VdmTib->EventInfo.Event = VdmMemAccess; > + VdmTib->EventInfo.InstructionSize = 0; > + > + /* End VDM Execution */ > + VdmEndExecution(TrapFrame, VdmTib); > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END; > + > + /* Consider the exception handled if we succeeded */ > + DPRINT1("VdmDispatchPageFault EFlags %lx exit with 0x%lx\n", > TrapFrame->EFlags, Status); > + return NT_SUCCESS(Status); > +} > + > > >

2 1

Re: [ros-dev] Definite Decision about ISO lifetimes at iso.reactos.org
by Colin Finck 09 Apr '17

09 Apr '17

Am 16.03.2017 um 00:00 schrieb Giannis Adamopoulos: > I was wondering if it is possible to delete every second iso instead of purging all isos before some time? That's a good idea and makes sense for the bootcd-dbg ISOs. So my final proposal is this one: bootcd-dbg: 5 years (after that every second ISO is purged) bootcd-dbgwin: 0.5 years bootcd-rel: 0.5 years bootcdregtest: 1 week livecd-dbg: 0.5 years livecd-dbgwin: 0.5 years livecd-rel: 0.5 years I'll be away until the beginning of April, so there is enough time for any objections. Otherwise, it will be set up exactly this way when I'm back. - Colin

1 1

Building/Testing infrastructure back on steroids!
by Colin Finck 09 Apr '17

09 Apr '17

Hi all! As of today, our high-performance servers Carrier, Mothership and Testee are finally back in service for building and testing! They take over many tasks from HotelLux, the generously provided server from Aleksey, which had to bear the load of previously 3 separate machines for over a year. You should notice faster builds on the Windows buildslaves, a returned VBox testslave, and more reliable ISO downloads. The VMware testslave is not back yet, but I'll be reinstalling this one as well. In June, we also plan to upgrade our best-performing server even more, using the donated 64GB of RAM and CPU upgrades that are cheaply available these days. This should decrease build times even more! Cheers, Colin

1 0

Vgal USB patches
by Alexander Rechitskiy 05 Apr '17

05 Apr '17

8 13

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev April 2017