sginsberg(a)svn.reactos.org a écrit :
> Author: sginsberg
> Date: Sun Aug 24 10:48:05 2008
> New Revision: 35600
>
> URL: http://svn.reactos.org/svn/reactos?rev=35600&view=rev
> Log:
> - Remove KEBUGCHECK and KEBUGCHECKEX macros
> - Replace "KeBugCheck(0)" by ASSERT(FALSE)
> - Replace deprecated "CPRINT" by DRINT1
>
You probably understand that KEBUGCHECK(0) is *NOT* the same as
ASSERT(FALSE)
ASSERT(FALSE) is valid only in debug mode, and lets the code continue in
release mode.
KEBUGCHECK stops the execution also in release mode.
For example, in ntoskrnl/dbgk/dbgkobj.c, code now continues even if
DbgkpQueueMessage failed. Are you sure it is safe to continue in that case?
(same question applies for other locations)
Hervé
In the kernel, stdcall IoCallDriver is macroed to the fastcall IofCallDriver. However, for clarification I think that IoCallDriver should be used, and this is what we do everywhere else.
>Why this?
>> ======================================================================
>> --- trunk/reactos/ntoskrnl/io/iomgr/iofunc.c [iso-8859-1] (original)
>> +++ trunk/reactos/ntoskrnl/io/iomgr/iofunc.c [iso-8859-1] Sat Aug 23
>> 11:30:14 2008
>> @@ -682,7 +682,7 @@
>> StackPtr->FileObject = FileObject;
>>
>> /* Call the Driver */
>> - return IofCallDriver(DeviceObject, Irp);
>> + return IoCallDriver(DeviceObject, Irp);
>> }
>>
>> /*
>> @@ -732,7 +732,7 @@
>> StackPtr->FileObject = FileObject;
>>
>> /* Call the Driver */
>> - return IofCallDriver(DeviceObject, Irp);
>> + return IoCallDriver(DeviceObject, Irp);
>> }
>>
>>
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
--- Please, please, don't think I'm trying to say "revert this!" ---
There are dozens (if not more) places in the kernel where such checks
could/should be made. I believe the more correct approach instead of
adding them to every function, is to use a similar framework to
Microsoft's Driver Verifier, where such functions are hooked and
wrapped through similar verifications.
I'm not saying this particular assert should be removed, I'm just
letting people know that if there's going to be major work on this --
there's a better way.
Just my 2c.
On 23-Aug-08, at 4:04 PM, arty(a)svn.reactos.org wrote:
> Author: arty
> Date: Sat Aug 23 18:04:15 2008
> New Revision: 35581
>
> URL: http://svn.reactos.org/svn/reactos?rev=35581&view=rev
> Log:
> Catch failure to release the cancel spinlock. Would've spotted my
> error in
> tcpip.sys.
>
> Modified:
> trunk/reactos/ntoskrnl/io/iomgr/irp.c
>
> Modified: trunk/reactos/ntoskrnl/io/iomgr/irp.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/irp.c?re…
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- trunk/reactos/ntoskrnl/io/iomgr/irp.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/irp.c [iso-8859-1] Sat Aug 23
> 18:04:15 2008
> @@ -970,12 +970,14 @@
> IoCancelIrp(IN PIRP Irp)
> {
> KIRQL OldIrql;
> + KIRQL IrqlAtEntry;
> PDRIVER_CANCEL CancelRoutine;
> IOTRACE(IO_IRP_DEBUG,
> "%s - Canceling IRP %p\n",
> __FUNCTION__,
> Irp);
> ASSERT(Irp->Type == IO_TYPE_IRP);
> + IrqlAtEntry = KeGetCurrentIrql();
>
> /* Acquire the cancel lock and cancel the IRP */
> IoAcquireCancelSpinLock(&OldIrql);
> @@ -999,6 +1001,7 @@
> /* Set the cancel IRQL And call the routine */
> Irp->CancelIrql = OldIrql;
> CancelRoutine(IoGetCurrentIrpStackLocation(Irp)-
> >DeviceObject, Irp);
> + ASSERT(IrqlAtEntry == KeGetCurrentIrql());
> return TRUE;
> }
>
>
Best regards,
Alex Ionescu
Feel free to open a bug.
----- Message d'origine ----
De : Olaf Siejka <caemyr(a)gmail.com>
À : ros-dev(a)reactos.org
Envoyé le : Jeudi, 21 Août 2008, 22h47mn 20s
Objet : Re: [ros-dev] Ros-dev Digest, Vol 48, Issue 14
Not to mention that makex is not 100% functional, for example i cannot perform makex depends or even makex bootcd on a clean tree. I have to first do make depends, then makex bootcd.
2008/8/21 <ros-dev-request(a)reactos.org>
Send Ros-dev mailing list submissions to
ros-dev(a)reactos.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.reactos.org/mailman/listinfo/ros-dev
or, via email, send a message with subject or body 'help' to
ros-dev-request(a)reactos.org
You can reach the person managing the list at
ros-dev-owner(a)reactos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ros-dev digest..."
Today's Topics:
1. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
like makex when there is more then one CPU Core now. makex kept
for now to keep compatible. (gedmurphy)
2. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
like makex when there is more then one CPU Core now. makex kept
for now to keep compatible. (Timo Kreuzer)
3. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
like makex when there is more then one CPU Core now. makex kept
for now to keep compatible. (Colin Finck)
4. Has anyone given any thought to coding so that the OS can use
the GPU (Matthew Therault)
5. Re: Has anyone given any thought to coding so that the OS can
use the GPU (Steven Edwards)
6. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
like makex when there is more then one CPU Core now. makex kept
for now to keep compatible. (Aleksey Bragin)
----------------------------------------------------------------------
Message: 1
Date: Wed, 20 Aug 2008 12:59:42 +0100
From: "gedmurphy" <gedmurphy(a)gmail.com>
Subject: Re: [ros-dev] [ros-diffs] [dreimer] 35473: make automatically
behaves like makex when there is more then one CPU Core now. makex
kept for now to keep compatible.
To: <ros-dev(a)reactos.org>
Message-ID: <000f01c902bc$3ea137f0$bbe3a7d0$@com>
Content-Type: text/plain; charset="utf-8"
I don't want make to consume both CPU's.
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dreimer(a)svn.reactos.org
Sent: 20 August 2008 10:10
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [dreimer] 35473: make automatically behaves like makex when there is more then one CPU Core now. makex kept for now to keep compatible.
Author: dreimer
Date: Wed Aug 20 04:10:07 2008
New Revision: 35473
URL: http://svn.reactos.org/svn/reactos?rev=35473&view=rev
Log:
make automatically behaves like makex when there is more then one CPU Core now. makex kept for now to keep compatible.
Modified:
trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd
trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac
Not to mention that makex is not 100% functional, for example i cannot
perform makex depends or even makex bootcd on a clean tree. I have to first
do make depends, then makex bootcd.
2008/8/21 <ros-dev-request(a)reactos.org>
> Send Ros-dev mailing list submissions to
> ros-dev(a)reactos.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.reactos.org/mailman/listinfo/ros-dev
> or, via email, send a message with subject or body 'help' to
> ros-dev-request(a)reactos.org
>
> You can reach the person managing the list at
> ros-dev-owner(a)reactos.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ros-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
> like makex when there is more then one CPU Core now. makex kept
> for now to keep compatible. (gedmurphy)
> 2. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
> like makex when there is more then one CPU Core now. makex kept
> for now to keep compatible. (Timo Kreuzer)
> 3. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
> like makex when there is more then one CPU Core now. makex kept
> for now to keep compatible. (Colin Finck)
> 4. Has anyone given any thought to coding so that the OS can use
> the GPU (Matthew Therault)
> 5. Re: Has anyone given any thought to coding so that the OS can
> use the GPU (Steven Edwards)
> 6. Re: [ros-diffs] [dreimer] 35473: make automatically behaves
> like makex when there is more then one CPU Core now. makex kept
> for now to keep compatible. (Aleksey Bragin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 20 Aug 2008 12:59:42 +0100
> From: "gedmurphy" <gedmurphy(a)gmail.com>
> Subject: Re: [ros-dev] [ros-diffs] [dreimer] 35473: make automatically
> behaves like makex when there is more then one CPU Core now.
> makex
> kept for now to keep compatible.
> To: <ros-dev(a)reactos.org>
> Message-ID: <000f01c902bc$3ea137f0$bbe3a7d0$@com>
> Content-Type: text/plain; charset="utf-8"
>
> I don't want make to consume both CPU's.
>
> Ged.
>
> -----Original Message-----
> From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org]
> On Behalf Of dreimer(a)svn.reactos.org
> Sent: 20 August 2008 10:10
> To: ros-diffs(a)reactos.org
> Subject: [ros-diffs] [dreimer] 35473: make automatically behaves like makex
> when there is more then one CPU Core now. makex kept for now to keep
> compatible.
>
> Author: dreimer
> Date: Wed Aug 20 04:10:07 2008
> New Revision: 35473
>
> URL: http://svn.reactos.org/svn/reactos?rev=35473&view=rev
> Log:
> make automatically behaves like makex when there is more then one CPU Core
> now. makex kept for now to keep compatible.
>
> Modified:
> trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd
> trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac
I don't want make to consume both CPU's.
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dreimer(a)svn.reactos.org
Sent: 20 August 2008 10:10
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [dreimer] 35473: make automatically behaves like makex when there is more then one CPU Core now. makex kept for now to keep compatible.
Author: dreimer
Date: Wed Aug 20 04:10:07 2008
New Revision: 35473
URL: http://svn.reactos.org/svn/reactos?rev=35473&view=rev
Log:
make automatically behaves like makex when there is more then one CPU Core now. makex kept for now to keep compatible.
Modified:
trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd
trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac
Modified: trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd
URL: http://svn.reactos.org/svn/reactos/trunk/tools/RosBE/RosBE-Windows/Root/Bui…
==============================================================================
--- trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd [iso-8859-1] (original)
+++ trunk/tools/RosBE/RosBE-Windows/Root/Build.cmd [iso-8859-1] Wed Aug 20 04:10:07 2008
@@ -103,11 +103,20 @@
)
::
+:: Get the number of CPUs in the system so we know how many jobs to execute.
+:: To modify the number used alter the options used with cpucount:
+:: No Option - Number of CPUs.
+:: -x1 - Number of CPUs, plus 1.
+:: -x2 - Number of CPUs, doubled.
+:: -a - Determine the cpu count based on the inherited process affinity mask.
+::
+for /f "usebackq" %%i in (`"%_ROSBE_BASEDIR%\Tools\cpucount.exe" -x1`) do set CPUCOUNT=%%i
+::
:: Check if we are using -j or not.
::
-if "%1" == "multi" (
- if not "%2" == "" (
- title 'makex %2' parallel build started: %TIMERAW%
+if %CPUCOUNT% GTR 2 (
+ if not "%1" == "" (
+ title 'makex %1' parallel build started: %TIMERAW%
) else (
title 'makex' parallel build started: %TIMERAW%
)
@@ -139,27 +148,17 @@
goto :EOF
:BUILDMULTI
- ::
- :: Get the number of CPUs in the system so we know how many jobs to execute.
- :: To modify the number used alter the options used with cpucount:
- :: No Option - Number of CPUs.
- :: -x1 - Number of CPUs, plus 1.
- :: -x2 - Number of CPUs, doubled.
- :: -a - Determine the cpu count based on the inherited process affinity mask.
- ::
- for /f "usebackq" %%i in (`"%_ROSBE_BASEDIR%\Tools\cpucount.exe" -x1`) do set CPUCOUNT=%%i
-
if %_ROSBE_SHOWTIME% == 1 (
if %_ROSBE_WRITELOG% == 1 (
- "%_ROSBE_BASEDIR%\Tools\buildtime.exe" "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %2 %3 %4 %5 %6 %7 %8 %9 2>&1 | "%_ROSBE_BASEDIR%\Tools\tee.exe" "%_ROSBE_LOGDIR%\BuildLog-%_ROSBE_GCCVERSION%-%DATENAME%-%TIMENAME%.txt"
+ "%_ROSBE_BASEDIR%\Tools\buildtime.exe" "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %* 2>&1 | "%_ROSBE_BASEDIR%\Tools\tee.exe" "%_ROSBE_LOGDIR%\BuildLog-%_ROSBE_GCCVERSION%-%DATENAME%-%TIMENAME%.txt"
) else (
- "%_ROSBE_BASEDIR%\Tools\buildtime.exe" "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %2 %3 %4 %5 %6 %7 %8 %9
+ "%_ROSBE_BASEDIR%\Tools\buildtime.exe" "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %*
)
) else (
if %_ROSBE_WRITELOG% == 1 (
- "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %2 %3 %4 %5 %6 %7 %8 %9 2>&1 | "%_ROSBE_BASEDIR%\Tools\tee.exe" "%_ROSBE_LOGDIR%\BuildLog-%_ROSBE_GCCVERSION%-%DATENAME%-%TIMENAME%.txt"
+ "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %* 2>&1 | "%_ROSBE_BASEDIR%\Tools\tee.exe" "%_ROSBE_LOGDIR%\BuildLog-%_ROSBE_GCCVERSION%-%DATENAME%-%TIMENAME%.txt"
) else (
- "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %2 %3 %4 %5 %6 %7 %8 %9
+ "%_ROSBE_MINGWMAKE%" -j %CPUCOUNT% %*
)
)
goto :EOF
Modified: trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac
URL: http://svn.reactos.org/svn/reactos/trunk/tools/RosBE/RosBE-Windows/Root/Ros…
==============================================================================
--- trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac [iso-8859-1] (original)
+++ trunk/tools/RosBE/RosBE-Windows/Root/RosBE.mac [iso-8859-1] Wed Aug 20 04:10:07 2008
@@ -7,7 +7,7 @@
ENV = set
HELP = "%_ROSBE_BASEDIR%\Help.cmd" $*
MAKE = "%_ROSBE_BASEDIR%\Build.cmd" $*
-MAKEX = "%_ROSBE_BASEDIR%\Build.cmd" multi $*
+MAKEX = "%_ROSBE_BASEDIR%\Build.cmd" $*
RADDR2LINE = "%_ROSBE_BASEDIR%\reladdr2line.cmd" $*
RENV = for /f "usebackq tokens=*" %i in (`set _ROSBE_`) do @echo %i
SCUT = "%_ROSBE_BASEDIR%\scut.cmd" $*
Just a random thought wondering if anyone else has thought about it. They
are making great strides into how the GPU can now be used as a processor.
--
Two men walk into a bar....... Third one ducks....
Think about it, it will come to you. :P