Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] [ros-diffs] [akhaldi] 57313: * Don't use -momit-leaf-frame-pointer in debug gcc builds, it messes up stack traces. * Remove it from the amd64 gcc builds too.
by Timo Kreuzer 17 Sep '12

17 Sep '12

Amd64 doesn't need a frame pointer. Backtraces are made based on unwind tables. At least if GCC conforms to the ABI. Am 16.09.2012 14:57, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Sun Sep 16 12:57:22 2012 > New Revision: 57313 > > URL: http://svn.reactos.org/svn/reactos?rev=57313&view=rev > Log: > * Don't use -momit-leaf-frame-pointer in debug gcc builds, it messes up stack traces. > * Remove it from the amd64 gcc builds too. > > Modified: > trunk/reactos/cmake/gcc.cmake > > Modified: trunk/reactos/cmake/gcc.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/gcc.cmake?rev=57313&… > ============================================================================== > --- trunk/reactos/cmake/gcc.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/gcc.cmake [iso-8859-1] Sun Sep 16 12:57:22 2012 > @@ -83,12 +83,15 @@ > if(ARCH STREQUAL "i386") > add_compile_flags("-mpreferred-stack-boundary=3 -fno-set-stack-executable -fno-optimize-sibling-calls -fno-omit-frame-pointer") > if(OPTIMIZE STREQUAL "1") > - add_compile_flags("-ftracer -momit-leaf-frame-pointer") > + add_compile_flags("-ftracer") > + if(NOT CMAKE_BUILD_TYPE STREQUAL "Debug") > + add_compile_flags("-momit-leaf-frame-pointer") > + endif() > endif() > elseif(ARCH STREQUAL "amd64") > add_compile_flags("-mpreferred-stack-boundary=4") > if(OPTIMIZE STREQUAL "1") > - add_compile_flags("-ftracer -momit-leaf-frame-pointer") > + add_compile_flags("-ftracer") > endif() > elseif(ARCH STREQUAL "arm") > if(OPTIMIZE STREQUAL "1") > > >

2 1

Re: [ros-dev] [ros-diffs] [mnordell] 57288: Add comment explaining initialization.
by Thomas Faber 16 Sep '12

16 Sep '12

On 2012-09-13 02:52, mnordell(a)svn.reactos.org wrote: > --- trunk/reactos/subsystems/csr/csrsrv/process.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/csr/csrsrv/process.c [iso-8859-1] Thu Sep 13 00:52:12 2012 > @@ -1211,7 +1211,7 @@ > BOOLEAN FirstTry; > ULONG i; > PCSR_SERVER_DLL ServerDll; > - ULONG Result = 0; > + ULONG Result = 0; /* Intentionally invalid enumeratee to silence compiler warning */ > > /* Acquire process lock */ > CsrAcquireProcessLock(); Frankly, I still don't understand it :D As I recall, this warning isn't a false positive, is it? Thus one would logically "fix", not "silence" it.

1 0

uLAN driver with ReactOS USB advances and some questions
by Pavel Pisa 16 Sep '12

16 Sep '12

Dear ReactOS developers, I follow ReactOS development for some years. I have successfully tested and reported our uLAN driver with PCI cards on ReactOS two years ago. The latest inclusion of USB VENDOR device requests in ReactOS allowed to finally run driver with our real USB hardware with QEMU KVM USB device pass-through setup. ReactOS tuned version of the uLAN driver installs and is fully functional when tested from CHROMuLAN application. But there are more issues still and I would be happy if somebody can help with these or give me hint about possible incompatibility in our driver. The tests were conducted against ReactOS 57254 build. uLAN driver is from GIT source repository http://ulan.sourceforge.net/ http://ulan.git.sourceforge.net/git/gitweb.cgi?p=ulan/ulan-drv;a=tree;f=ul_… uLAN driver was build by MS WDF VC version 15.00.30729.207 The issues: 1) the first minor one - ReactOS requires minimal transfer size for URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE/USB_CONFIGURATION_DESCRIPTOR_TYPE function (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:244) URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE ulan: _usb_submit_urb : return from IoCallDriver USBD 103 ulan: _usb_submit_urb : URB status = 0 status = 0 irp status 0 uLan: _usb_submit_urb done with status:0x0 uLan: _usb_get_descriptor done with status:0x0 uLan: usb_device_descriptor done with status:0x0 uLan: usb_get_configuration uLan: _usb_get_descriptor (type=0x2,idx=0x0) ulan: _usb_submit_urb : enter (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:244) URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE Assertion 'Urb->UrbControlDescriptorRequest.TransferBufferLength >= sizeof(USB_CONFIGURATION_DESCRIPTOR)' failed at /srv/buildbot_ cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp line 1560 Entered debugger on embedded INT3 at 0x0008:0x80924c3a. Unmodified uLAN driver asks for the first four bytes descriptor bytes firest and after obtaining size of the whole descriptor it prepares full size transfer. ReactOS asserts for this shorted 4 bytes transfer. I have adapted driver to use sizeof(USB_CONFIGURATION_DESCRIPTOR) size for initial probe transfer in USB_CONFIGURATION_DESCRIPTOR_TYPE case. This makes ReactOS happy, but I would like to know which side should be updated in the future. Is there defined in some spec that initial probe for size has to be at least of sizeof(USB_CONFIGURATION_DESCRIPTOR) or the ReactOS is more strict than necessary and assert should be modified to allow truncated probes or at least 4 bytes ones in addition? The full log at http://cmp.felk.cvut.cz/~pisa/ulan/reactos/reactos-ul-win-confdesc.log 2) Driver can be enabled and disabled at runtime but shutdown does not finish, is blocked somehow but system/cursor is responsive http://cmp.felk.cvut.cz/~pisa/ulan/reactos/reactos-ul-enabled-at-runtime.log I have no idea what is the problem. Driver works correctly on Windows from 2k to Win7 and latest version supports even suspend and resume on all these platforms. 3) When driver and device are installed/present from boot time, boot hangs http://cmp.felk.cvut.cz/~pisa/ulan/reactos/reactos-ul-during-boot.log (/srv/buildbot_cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp:313) [USBLIB] SCE Request B027B048 TransferBufferLength 8 Flags 3 MDL 00000000 (/srv/buildbot_cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp:324) [USBLIB] Port 0: Status 103, Change 0 (/srv/buildbot_cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp:324) [USBLIB] Port 1: Status 100, Change 0 (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/pnpmgr/pnpmgr.c:4030) IRP_MN_QUERY_PNP_DEVICE_STATE failed with status 0xc00000bb (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:541) uLan2usb convertor (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:541) uLan2usb convertor (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/pnpmgr/pnpmgr.c:4030) IRP_MN_QUERY_PNP_DEVICE_STATE failed with status 0xc00000bb (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/iorsrce.c:725) Failed opening given symbolic link! (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:174) Loading: \SystemRoot\system32\drivers\pciide.sys at FCBF4000 with 7 pages (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:174) Loading: \SystemRoot\system32\drivers\pciidex.sys at FCBEB000 with 9 pages (/srv/buildbot_cmake/full_cmake/build/drivers/bus/pci/pdo.c:1267) Enabling command flags for PCI device 0x21 on bus 0x0: [Bus master] [I/O space enable] (/srv/buildbot_cmake/full_cmake/build/drivers/storage/ide/pciidex/fdo.c:464) IRP_MJ_PNP / Unknown minor function 0x9 (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:174) Loading: \SystemRoot\system32\drivers\ul_wdm.sys at FCBD9000 with 11 pages Assertion 'IsListEmpty(&Irp->ThreadListEntry)' failed at /srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/irp.c line 1524 Entered debugger on embedded INT3 at 0x0008:0x80924c3a. kdb:> ==================================================================================== Thanks for any hints in advance. I would be happy if the problems are resolved in the future. It could be interresting option to have livecd available with ReactOS, uLAN driver and CHROMuLAN for us one day. We can provide even some small funding for such achievement if it could work reliably on real hardware. Other reason why ReactOS is interresting for us is that it has cached some bugs in our driver (mismatch in memory pools tags which are not reported by Windows release builds). Yet another reasons for ReactOS is to use 64-bit ReactOS build as testbed for uLAN driver Windows 64-bit version debugging. (64-bit Linux x86 version is fully supported now same as MIPS, PPC and ARM). But 64-bit Windows are pain for its signing requirements etc. And after all I do not have any (32/64-bit) Windows installed on our computers at all so ReactOS is great target for our development even if we has to depend on users use and demand for Windows. As for CHROMuLAN and RectOS compatibility, chromatography system is functional under ReactOS except for some problem in the complex calibration files dialog which can hang the application and some harmless exception during analysis files read. Both seems to cause similar problems under Wine as well. In each case, thanks for the big pile of the work invested to the ReactOS project, Pavel Pisa e-mail: pisa(a)cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company: http://www.pikron.com/

5 6

Affects Version field
by Timo Kreuzer 13 Sep '12

13 Sep '12

Can we rename the "Affects Version" field to "Affected Revision"? Noone cares for 0.3.11 bugs and TRUNK ins meaningless. Also: is it possible to automaticcally translate to the current head revision number, when TRUNK or rather HEAD is selected? Maybe when we have FishEye? Regards, Timo

2 2

Component list rewrite
by caemyr＠myopera.com 13 Sep '12

13 Sep '12

3 6

Fwd: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test
by caemyr＠myopera.com 13 Sep '12

13 Sep '12

Test run failed due to exceeding the maximum number of restarts, Problem started with unexpected crash: Running Wine Test, Module: pdh, Test: pdh Assertion 'KiTimerTableListHead[Index].Time.QuadPart <= Timer->DueTime.QuadPart' failed at ../../ntoskrnl/ke/dpc.c line 252 [7h Entered debugger on embedded INT3 at 0x0008:0x809257d2. kdb:> bt Eip: <NTOSKRNL.EXE:1257d3 (../../lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))> Frames: <NTOSKRNL.EXE:82a22 (../../ntoskrnl/ke/dpc.c:251 (KiTimerExpiration@16))> <NTOSKRNL.EXE:82c20 (../../ntoskrnl/ke/dpc.c:576 (@KiRetireDpcList@4))> <NTOSKRNL.EXE:10a2fa (../../ntoskrnl/ke/i386/ctxswitch.S:78 (KiRetireDpcListInDpcStack))> <HAL.DLL:a71b (../../hal/halx86/up/pic.c:1323 (@HalpDispatchInterrupt2ndEntry@4))> <HAL.DLL:a684 (../../hal/halx86/up/pic.c:1243 (HalEndSystemInterrupt@8))> <NTOSKRNL.EXE:89dbf (../../ntoskrnl/include/internal/arch/../i386/ke.h:829 (@KeUpdateSystemTime@12))> <HAL.DLL:9b6b (../../hal/halx86/generic/timer.c:172 (@HalpClockInterruptHandler@4))> <HAL.DLL:9f52 (../../hal/halx86/generic/trap.S:0 (_HalpClockInterrupt))> <rosautotest.exe:67cb> <rosautotest.exe:703d> The subsequent reboots have been asserting at startup: Boot took 33308394332 cycles! Interrupts: 1838 System Calls: 15454 Context Switches: 1688 (../../ntoskrnl/se/semgr.c:646) HACK: Should deny access for caller: granted 0x90003, desired 0x190003 (generic mapping B12893B0). (../../base/services/eventlog/eventlog.c:296) RegQueryValueEx failed: 126 (../../base/services/eventlog/eventlog.c:393) Failed to load Wine (../../base/services/wlansvc/wlansvc.c:145) wlansvc: main() started (../../base/services/wlansvc/wlansvc.c:96) ServiceMain() called (../../base/services/wlansvc/wlansvc.c:130) ServiceMain() done (../../base/system/services/rpcserver.c:1716) RNotifyBootConfigStatus(00000000 1) called Assertion 'CellBlock < RegistryHive->Storage[CellType].Length' failed at ../../lib/cmlib/hivecell.c line 32 [7h Entered debugger on embedded INT3 at 0x0008:0x809257d2. kdb:> bt Eip: <NTOSKRNL.EXE:1257d3 (../../lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))> Frames: <NTOSKRNL.EXE:124087 (../../lib/cmlib/hivecell.c:32 (HvpGetCellHeader@8))> <NTOSKRNL.EXE:124119 (../../lib/cmlib/hivecell.c:74 (HvGetCell@8))> <NTOSKRNL.EXE:125318 (../../lib/cmlib/cminit.c:97 (CmpPrepareIndexOfKeys@8))> <NTOSKRNL.EXE:125407 (../../lib/cmlib/cminit.c:124 (CmpPrepareKey@8))> <NTOSKRNL.EXE:125435 (../../lib/cmlib/cminit.c:135 (CmPrepareHive@4))> <NTOSKRNL.EXE:12528e (../../lib/cmlib/hiveinit.c:506 (HvInitialize@52))> <NTOSKRNL.EXE:1dca5 (../../ntoskrnl/config/cminit.c:177 (CmpInitializeHive@40))> <NTOSKRNL.EXE:26132 (../../ntoskrnl/config/cmsysini.c:287 (CmpInitHiveFromFile@20))> <NTOSKRNL.EXE:2060d (../../ntoskrnl/config/cmlazy.c:259 (CmpCmdHiveOpen@20))> <NTOSKRNL.EXE:1548d (../../ntoskrnl/config/cmapi.c:1713 (CmLoadKey@16))> <NTOSKRNL.EXE:2928e (../../ntoskrnl/config/ntapi.c:843 (NtLoadKeyEx@16))> <NTOSKRNL.EXE:29356 (../../ntoskrnl/config/ntapi.c:791 (NtLoadKey@8))> <NTOSKRNL.EXE:110fb2 (../../ntoskrnl/ke/i386/traphdlr.c:1629 (@KiFastCallEntryHandler@8))> <NTOSKRNL.EXE:10eba1 (../../ntoskrnl/ke/i386/trap.s:150 (_KiFastCallEntry))> <ntdll.dll:b009> <userenv.dll:62a4> <winlogon.exe:2317> <winlogon.exe:3023> <user32.dll:4bb39> <user32.dll:4c188>--- Press q to abort, any other key to continue --- <user32.dll:4d37b> <winlogon.exe:4b00> ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Subject: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test Date: Thu, 13 Sep 2012 01:14:24 +0000 The Buildbot has finished a build on builder Windows_AMD64_1 VBox-Test while building ReactOS. Full details are available at: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/6579 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_2 Build Reason: Triggerable(Windows_AMD64_1 VBox-Test Trigger) Build Source Stamp: 57288 Blamelist: mnordell BUILD FAILED: failed test sincerely, -The Buildbot -- With best regards Caemyr

1 0

Jira search
by Timo Kreuzer 13 Sep '12

13 Sep '12

Hi, Does anyone know how to search for issues older than 1 year or something like that? According to https://jira.atlassian.com/browse/JRA-1983 it should be possible, but Icouldn't figure out how to. Timo

3 2

Re: [ros-dev] [ros-diffs] [ion] 57284: [NTOSKRNL]: Use the token lock acquire/release macros that were already written instead of manually doing it. Also fix the macros since they didn't work in GCC. No functional change, j...
by Timo Kreuzer 12 Sep '12

12 Sep '12

What was the problem with the old macros? The new ones are error-prone. if (NeedLock) SepAcquireTokenLockExclusive(Token); // <= fail! WBR, Timo Am 12.09.2012 18:29, schrieb ion(a)svn.reactos.org: > Author: ion > Date: Wed Sep 12 16:29:28 2012 > New Revision: 57284 > > URL: http://svn.reactos.org/svn/reactos?rev=57284&view=rev > Log: > [NTOSKRNL]: Use the token lock acquire/release macros that were already written instead of manually doing it. Also fix the macros since they didn't work in GCC. > No functional change, just code cleanup. > > Modified: > trunk/reactos/ntoskrnl/include/internal/se.h > trunk/reactos/ntoskrnl/se/access.c > trunk/reactos/ntoskrnl/se/semgr.c > > Modified: trunk/reactos/ntoskrnl/include/internal/se.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/se.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/se.h [iso-8859-1] Wed Sep 12 16:29:28 2012 > @@ -1,4 +1,28 @@ > #pragma once > + > +typedef struct _KNOWN_ACE > +{ > + ACE_HEADER Header; > + ACCESS_MASK Mask; > + ULONG SidStart; > +} KNOWN_ACE, *PKNOWN_ACE; > + > +typedef struct _KNOWN_OBJECT_ACE > +{ > + ACE_HEADER Header; > + ACCESS_MASK Mask; > + ULONG Flags; > + ULONG SidStart; > +} KNOWN_OBJECT_ACE, *PKNOWN_OBJECT_ACE; > + > +typedef struct _KNOWN_COMPOUND_ACE > +{ > + ACE_HEADER Header; > + ACCESS_MASK Mask; > + USHORT CompoundAceType; > + USHORT Reserved; > + ULONG SidStart; > +} KNOWN_COMPOUND_ACE, *PKNOWN_COMPOUND_ACE; > > PSID > FORCEINLINE > @@ -75,6 +99,8 @@ > return Descriptor->Sacl; > } > } > + > +#ifndef RTL_H > > /* SID Authorities */ > extern SID_IDENTIFIER_AUTHORITY SeNullSidAuthority; > @@ -156,6 +182,19 @@ > extern PSECURITY_DESCRIPTOR SeSystemDefaultSd; > extern PSECURITY_DESCRIPTOR SeUnrestrictedSd; > > + > +#define SepAcquireTokenLockExclusive(Token) \ > + KeEnterCriticalRegion(); \ > + ExAcquireResourceExclusive(((PTOKEN)Token)->TokenLock, TRUE); \ > + > +#define SepAcquireTokenLockShared(Token) \ > + KeEnterCriticalRegion(); \ > + ExAcquireResourceShared(((PTOKEN)Token)->TokenLock, TRUE); \ > + > +#define SepReleaseTokenLock(Token) \ > + ExReleaseResource(((PTOKEN)Token)->TokenLock); \ > + KeLeaveCriticalRegion(); \ > + > // > // Token Functions > // > @@ -434,24 +473,6 @@ > OUT PACCESS_TOKEN* NewToken > ); > > -#define SepAcquireTokenLockExclusive(Token) \ > - do { \ > - KeEnterCriticalRegion(); \ > - ExAcquireResourceExclusive(((PTOKEN)Token)->TokenLock, TRUE); \ > - while(0) > - > -#define SepAcquireTokenLockShared(Token) \ > - do { \ > - KeEnterCriticalRegion(); \ > - ExAcquireResourceShared(((PTOKEN)Token)->TokenLock, TRUE); \ > - while(0) > - > -#define SepReleaseTokenLock(Token) \ > - do { \ > - ExReleaseResource(((PTOKEN)Token)->TokenLock); \ > - KeLeaveCriticalRegion(); \ > - while(0) > - > VOID NTAPI > SeQuerySecurityAccessMask(IN SECURITY_INFORMATION SecurityInformation, > OUT PACCESS_MASK DesiredAccess); > @@ -460,4 +481,6 @@ > SeSetSecurityAccessMask(IN SECURITY_INFORMATION SecurityInformation, > OUT PACCESS_MASK DesiredAccess); > > +#endif > + > /* EOF */ > > Modified: trunk/reactos/ntoskrnl/se/access.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/se/access.c?rev=5… > ============================================================================== > --- trunk/reactos/ntoskrnl/se/access.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/se/access.c [iso-8859-1] Wed Sep 12 16:29:28 2012 > @@ -130,11 +130,7 @@ > ASSERT(Sid != NULL); > > /* Lock the token if needed */ > - if (!TokenLocked) > - { > - KeEnterCriticalRegion(); > - ExAcquireResourceSharedLite(Token->TokenLock, TRUE); > - } > + if (!TokenLocked) SepAcquireTokenLockShared(Token); > > /* Check if the owner SID is found, handling restricted case as well */ > Result = SepSidInToken(Token, Sid); > @@ -144,11 +140,7 @@ > } > > /* Release the lock if we had acquired it */ > - if (!TokenLocked) > - { > - ExReleaseResourceLite(Token->TokenLock); > - KeLeaveCriticalRegion(); > - } > + if (!TokenLocked) SepReleaseTokenLock(Token); > > /* Return the result */ > return Result; > @@ -168,15 +160,13 @@ > TokenControl->TokenSource = Token->TokenSource; > > /* Lock the token */ > - KeEnterCriticalRegion(); > - ExAcquireResourceSharedLite(Token->TokenLock, TRUE); > + SepAcquireTokenLockShared(Token); > > /* Capture the modified it */ > TokenControl->ModifiedId = Token->ModifiedId; > > /* Unlock it */ > - ExReleaseResourceLite(Token->TokenLock); > - KeLeaveCriticalRegion(); > + SepReleaseTokenLock(Token); > } > > NTSTATUS > @@ -327,13 +317,11 @@ > ClientToken = SubjectContext->ClientToken; > > /* Always lock the primary */ > - KeEnterCriticalRegion(); > - ExAcquireResourceSharedLite(PrimaryToken->TokenLock, TRUE); > + SepAcquireTokenLockShared(PrimaryToken); > > /* Lock the impersonation one if it's there */ > if (!ClientToken) return; > - KeEnterCriticalRegion(); > - ExAcquireResourceSharedLite(ClientToken->TokenLock, TRUE); > + SepAcquireTokenLockShared(ClientToken); > } > > /* > @@ -351,13 +339,11 @@ > ClientToken = SubjectContext->ClientToken; > > /* Always unlock the primary one */ > - ExReleaseResourceLite(PrimaryToken->TokenLock); > - KeLeaveCriticalRegion(); > + SepReleaseTokenLock(PrimaryToken); > > /* Unlock the impersonation one if it's there */ > if (!ClientToken) return; > - ExReleaseResourceLite(ClientToken->TokenLock); > - KeLeaveCriticalRegion(); > + SepReleaseTokenLock(ClientToken); > } > > /* > > Modified: trunk/reactos/ntoskrnl/se/semgr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/se/semgr.c?rev=57… > ============================================================================== > --- trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] Wed Sep 12 16:29:28 2012 > @@ -952,8 +952,7 @@ > SeCaptureSubjectContext(&SubjectSecurityContext); > > /* Lock the token */ > - KeEnterCriticalRegion(); > - ExAcquireResourceSharedLite(Token->TokenLock, TRUE); > + SepAcquireTokenLockShared(Token); > > /* Check if the token is the owner and grant WRITE_DAC and READ_CONTROL rights */ > if (DesiredAccess & (WRITE_DAC | READ_CONTROL | MAXIMUM_ALLOWED)) > @@ -990,8 +989,7 @@ > > /* Release subject context and unlock the token */ > SeReleaseSubjectContext(&SubjectSecurityContext); > - ExReleaseResourceLite(Token->TokenLock); > - KeLeaveCriticalRegion(); > + SepReleaseTokenLock(Token); > > /* Release the captured security descriptor */ > SeReleaseSecurityDescriptor(CapturedSecurityDescriptor, > > >

3 3

12 Sep '12

Why the removal of the do/while loop? This breaks the macro when used without braces : +#define SepReleaseTokenLock(Token) \ + ExReleaseResource(((PTOKEN)Token)->TokenLock); \ + KeLeaveCriticalRegion(); \ + <snip> -#define SepReleaseTokenLock(Token) \ - do { \ - ExReleaseResource(((PTOKEN)Token)->TokenLock); \ - KeLeaveCriticalRegion(); \ - while(0) <snip> /* Release the lock if we had acquired it */ + if (!TokenLocked) SepReleaseTokenLock(Token);

1 0

Jira Planning
by Timo Kreuzer 12 Sep '12

12 Sep '12

Hi, I'd like to invite every developer to make use of the Jira planning feature. For those, who are not yet familiar with it here's a an explantion. In the blue Jira menu bar you'll find an item called "Agile". Click on that to get to the planning boards. First time users will be asked to either choose between Scrum or Kanban. Select Scrum. Then you will be asked to select a dashboard or create one. You can simply choose "Scrum Board" from the dropdown list, this one should be fine. You can later create your own board, if you like. Now you will see 3 buttons on the right-hand side below the menu bar: "plan", "work" and "report" First select "plan" On the top you can see the current "sprint", which is the next planned period. We currently have one sprint for September. We can create multiple sprints and periods are as we want them. I think one month is reasonable. Under the sprint you can see the issues that are selected for this sprint, i.e. supposed to be tackled in that period. Currently only project administrators can create sprints, but every developer can move items there. To remove an item from the sprint, you need to click on it, so it gets highlited, then open the menu with the gear wheel icon in the issue description on the right and select "Remove from sprint". Below you see the backlog (all open issues). Since the list is quite huge, you can limit it to your own issues, by pressing the "Only my issues" filter button. (Note this one works like a pushbutton, click it once to enable, again to disable. Maybe Amine can make them look more like that by adding a highlite color) On the righ-hand side, you see a box that shows the currently selected issue. Now you can drag and drop issues from the backlog into one of the sprints. So if you plan to work on a specific issue in September, just drag it into sprint 1. Now select "work" Here you can see the so called "swim lanes". In the default Scrum Board they are configured per Developer. So you see every developer that has active issues in the current sprint(s). You can open and close the swim lanes to see the issues. And you can again select "Only my issues". The board has 3 columns: "To do", "In Progress", "Done". All issues that you selected for the current sprint will initially be in the "To do" column. When you work on an issue, simply drag it over to the "In Progress" column. When you fixed it, drag it to "Done". When dragging them the target column will be highlited in green. The "Done" column will show you 2 fields when dragging an item there: one for resolve, one for close. When you dragged them to close, you'll see a confirmation dialog, where you can enter additional stuff and then confirm it. Have fun Timo

1 0

Jump to page:

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