Would be great to have JIRA issues associated to such fixes as well as a
test proving the change is correct. For example, are you merely assuming
that you should return "STATUS_NO_MEMORY", or do you know for a fact that
STATUS_CONFLICTING_ADDRESSES is the wrong code here?
Best regards,
Alex Ionescu
On Wed, Oct 8, 2014 at 12:38 AM, <tkreuzer(a)svn.reactos.org> wrote:
> Author: tkreuzer
> Date: Wed Oct 8 07:38:56 2014
> New Revision: 64595
>
> URL: http://svn.reactos.org/svn/reactos?rev=64595&view=rev
> Log:
> [NTOSKRNL]
> Fix a status code
>
> Modified:
> trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c
>
> Modified: trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c…
>
> ==============================================================================
> --- trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] Wed Oct 8
> 07:38:56 2014
> @@ -261,7 +261,7 @@
> {
> DPRINT1("Not enough free space to insert this VAD node!\n");
> KeReleaseGuardedMutex(&CurrentProcess->AddressCreationLock);
> - return STATUS_CONFLICTING_ADDRESSES;
> + return STATUS_NO_MEMORY;
> }
>
> ASSERT(StartingAddress != 0);
>
>
>
Seriously?
Am 11.10.2014 01:07, schrieb aandrejevic(a)svn.reactos.org:
> + /* Count the leading zeros */
> + while (!(Data->Mantissa & (1 << (63 - LeadingZeros)))) LeadingZeros++;
@Timo
Yes of course.. It was a fleeting idea it would be cute to run on a
computer 5x10x1 cm. ;-)
I didn't realize the ARM branch was in poor condition though.
But it stands to reason.. Porting Intel assembly to ARM assembly and
considering all the archiectural differences is/would be a gargantuan job.
Keep up the good work..
Love
On 2014-10-09 19.00, ros-dev-request(a)reactos.org wrote:
> Guys, I don't want to spoil your hopes, but native ARM support is far
> away from being usable. It doesn't even compile. There is no native ARM!
> And there won't be for ages, until we have a really knowledged ARM
> hacker, with the kernel and hardware knowledge of Alex, who would invest
> a huge lot of time into getting it up and running. So unless we want to
> hire someone fulltime for at least half a year, who would probably like
> to be paid a normal software engineer wage, which we cannot afford, we
> won't have ARM support anytime soon.
> x64 is a much more reasonable task, mostly lacking stuff in Mm.
> And that will still require a lot of work.
> And I have more than enough other things to do
On 2014-10-02 09:30, tkreuzer(a)svn.reactos.org wrote:
> -add_executable(dllimport_test
> +add_library(dllimport_test
> dllimport_framedyn.cpp)
Isn't the point of this test to check for linker errors?
A few remarks:
- There should be only one SEH, not for performance, but since the
KeyNameInfo->NameLength = 0; needs to be in SEH as well
- The function duplicates a lot of code from CmpConstructName, possibly
even incomplete
- There was already an implementation in the kernel-fun branch
Unrelated to your code, just something I spotted in that file:
- CmpQueryKeyData cannot be wrapped in SEH (it would cause reference
leaks on exception), but is wrapped in SEH in CmEnumerateKey
- CmpQueryKeyData does not use SEH, but is called with user mode
pointers from CmQueryKey
Timo
Am 29.09.2014 18:27, schrieb jgardou(a)svn.reactos.org:
> Author: jgardou
> Date: Mon Sep 29 16:27:16 2014
> New Revision: 64396
>
> URL: http://svn.reactos.org/svn/reactos?rev=64396&view=rev
> Log:
> [NTOS/CM]
> - Add NtQueryKey(KeyNameInformation) implementation.
> CORE-8581 #resolve
>
>