Hi,
Please think twice before committing to the ReactOS repo.
The most recent example is the format/lang/uk-UA.rc changes that have
absolutely nothing to do with the "Russian translation update by Sergey
Stopkin." commit log.
When you do that, you'll always be committing while being calm and in
control of what you're sending. The svn history is a responsibility
shared between the ReactOS developers.
Regards,
Amine.
Le 06/10/2016 à 21:01, hbelusca(a)svn.reactos.org a écrit :
> Author: hbelusca
> Date: Thu Oct 6 19:01:33 2016
> New Revision: 72922
>
> URL: http://svn.reactos.org/svn/reactos?rev=72922&view=rev
> Log:
> [KD]
> - When enabling or disabling the kernel debugger and setting the KdDebuggerEnabled flag, also update the corresponding user-mode flag in SharedUserData->KdDebuggerEnabled.
> - Turn KdpGetMemorySizeInMBs into a INIT_FUNCTION.
> - Print kernel command line & ARC paths even in debug log file mode.
>
> [KD64]
> WinKD: Also print our nice ReactOS debug header (version, # of processors & memory MB, kernel command line and ARC paths).
>
> Modified:
> trunk/reactos/ntoskrnl/kd/kdinit.c
> trunk/reactos/ntoskrnl/kd/kdio.c
> trunk/reactos/ntoskrnl/kd/kdmain.c
> trunk/reactos/ntoskrnl/kd64/kdapi.c
> trunk/reactos/ntoskrnl/kd64/kdinit.c
>
> Modified: trunk/reactos/ntoskrnl/kd/kdio.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdio.c?rev=729…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] Thu Oct 6 19:01:33 2016
> @@ -240,10 +243,15 @@
> KeInitializeSpinLock(&KdpDebugLogSpinLock);
>
> /* Display separator + ReactOS version at start of the debug log */
> - DPRINT1("---------------------------------------------------------------\n");
> + DPRINT1("-----------------------------------------------------\n");
This specific change has likely broken any testbot running sysreg2 and
vmware or vbox.
Why was this change even needed?
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
On 2016-10-05 11:33, akhaldi(a)svn.reactos.org wrote:
> --- trunk/rostests/apitests/ws2_32/getnameinfo.c (added)
> +++ trunk/rostests/apitests/ws2_32/getnameinfo.c [iso-8859-1] Wed Oct 5 09:33:03 2016
> @@ -0,0 +1,99 @@
> +/*
> + * PROJECT: ReactOS api tests
> + * LICENSE: GPLv2+ - See COPYING in the top level directory
> + * PURPOSE: Test for getaddrinfo
> + * PROGRAMMER: Thomas Faber <thomas.faber(a)reactos.org>
> + */
Thanks for the credit, but I don't think I deserve it ;)
Good afternoon gentlemen...
Seems the list server has gone on a vacation.
Still waiting on the digest where Hermes added to Thomas answer..
Anyway Hermes pasted his answer to my mailbox (thank you) and so..
One more step is required in addition to the answers from Thomas and
Hermes..
A small patch in 'base/setup/usetup/bootsup.c', which contains the code
that writes 'freeldr.ini' to the HD during install. Without patching in
the desired
COM port there, trace is lost after ROS installation reboots from HD.
Perhaps we should have a wiki page to cover this ?
And/or perhaps we should make it easier to make this mod,
by moving the hard coded strings from bootsup.c into
an ini file or whatever ?
Anyway, I got my install trace, and posted a clip concerning
the Gecko breakage to CORE-12011.
Best Regards
L.
Hello,
Let me invite you to the monthly status meeting taking place this
Thursday, 29th of September, 19:00 UTC.
IRC service will only be started shortly before the meeting. 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. Hopefully it's not
much of inconvenience.
Or we'll do it in #reactos-meeting on Freenode, depeonds on our admins.
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
Thanks Thomas,
Yes and No...
I added Options=/DEBUG /DEBUGPORT=COM2 /BAUDRATE=115200 /SOS / KDSERIAL
which ended up on the BootCD all right, but it seems KD is never brought
in, or doesn't
use the settings from freeldr.ini on the BootCD, so no trace :/
(Ok, /SOS was perhaps a bit over the top, but anyway.)
Do you know where the source is for what becomes 'freeldr.ini' on the HD
after installation? If I can modify that, I can at least get a trace on
the later
phases of installation, after ROS boots from HD.
Then I might get a hint on why the Wine Gecko installer is broken.
(It waits forever for whatever it might be.. Lucky it can be canceled.)
Speaking of which, shouldn't the Wine Gecko installer be included
in the RosApps list so one can install it later? ATM it isn't.
Best Regards
L.
On 2016-09-27 19.00, Thomas Faber <thomas.faber(a)reactos.org> wrote:
> You should be able to simply add an
> Options=...
> line to the [Setup] section in boot/bootdata/bootcd.ini to modify
> the setup's freeldr options. That file becomes freeldr.ini in the root
> dir of the BootCD.
>
>
> On 2016-09-27 12:21, Love Nystrom wrote:
>> >Good afternoon gentlemen..
>> >
>> >Can anyone tell me at what point during ROS installation KD becomes
>> >operative?
>> >And if there is a way to change the default KD COM port from COM1 to COM2
>> >in order to trace KD output during installation?
>> >
>> >(I run my ROS tests on VMware with a com0com connection from ReactOS COM2
>> >to my host machine, which works fine after install is complete and I can
>> >edit freeldr.ini,
>> >but I'd like to be able to collect KD output during installation as well.)
>> >
>> >(COM1 is not an option, since it's a physical port on both host and guest.)
>> >
>> >Do I have to patch KD itself ?
>> >
>> >Best Regards
>> >L.
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]
Good afternoon gentlemen..
Can anyone tell me at what point during ROS installation KD becomes
operative?
And if there is a way to change the default KD COM port from COM1 to COM2
in order to trace KD output during installation?
(I run my ROS tests on VMware with a com0com connection from ReactOS COM2
to my host machine, which works fine after install is complete and I can
edit freeldr.ini,
but I'd like to be able to collect KD output during installation as well.)
(COM1 is not an option, since it's a physical port on both host and guest.)
Do I have to patch KD itself ?
Best Regards
L.
Agreed..
When the assignment and assert are separated by a call
of X distance, the assert is certainly warranted.
Just not as it stands in ke_x.h
Perhaps you could factorize as suggested, Dmitri?
Best regards
L.
On 2016-09-26 10.28, ros-dev-request(a)reactos.org wrote:
> Rationale is simple:
>
> The real headers contain a KeEnterCriticalRegionThread function, which
> has this assert, and a KeEnterCriticalRegion function, which calls
> that function with KeGetCurrentThread() at input. This is an
> optimization such that if you already have the current thread of
> interest somewhere, you can call KeEnterCriticalRegionThread and avoid
> reading from FS or GS again. ReactOS combines these two functions in
> one, and as such the ASSERT appears pointless. Factoring the functions
> would've been the correct approach -- not removing the ASSERT.
>
> Best regards,
> Alex Ionescu
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]