Couple of comments:
1) Why implement new, complex features in the kernel instead of
fixing current bugs? I know it's fun to start hacking on new code,
but priorities should be to implement stuff that's required not to
break other apps/add functionality, not internal features which will
take ages to implement (the Ps functions for quota are "easy", it's
the Mm part that's bad).
I had already written all these functions, but deleted them, because
nobody needed them, and the Mm part was too complex to do.
2) Why are you bothering with PspPoolQuotaIndexFromPoolType? In case
you haven't noticed, there's something called pool masks which make
the operation very easy without requiring a function call (such as
POOL_TYPE_MASK or BASE_POOL_MASK, forgot how it's called).
3) INT is not an acceptable kernel type.
4) We don't use "static" in the kernel.
5) Instead of duplicating code, perhaps consider calling a main
worker function such as PspChargeQuota?
6) Consider using an enum instead of magic numbers inside the quota
entries, I believe it's called PS_QUOTA_TYPE.
7) The quota routines require interlocks, otherwise they will not be
thread safe.
8) They also require a global spinlock in the "give back" case.
9) Committing code that won't even build, even with the define on,
isn't very appropriate. Trunk isn't a playground. If someone wants to
actually test this, they won't be able to build it because of things
like "refuse". SVN should contain code that builds at any time. It's
not hard to write /* TODO */..
Just my 2 cents
--
Best regards,
Alex Ionescu
On 23-Oct-07, at 6:05 AM, mnordell(a)svn.reactos.org wrote:
> Author: mnordell
> Date: Tue Oct 23 14:05:40 2007
> New Revision: 29826
>
> URL: http://svn.reactos.org/svn/reactos?rev=29826&view=rev
> Log:
> First small attempt at implementing process memory quota. Currently
> disabled without explicit code modification (enabled by macro) to
> not modify behaviour of trunk.
>
> Modified:
> trunk/reactos/ntoskrnl/ps/quota.c
>
> Modified: trunk/reactos/ntoskrnl/ps/quota.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/
> quota.c?rev=29826&r1=29825&r2=29826&view=diff
> ======================================================================
> ========
> --- trunk/reactos/ntoskrnl/ps/quota.c (original)
> +++ trunk/reactos/ntoskrnl/ps/quota.c Tue Oct 23 14:05:40 2007
> @@ -15,6 +15,12 @@
>
> EPROCESS_QUOTA_BLOCK PspDefaultQuotaBlock;
>
> +
> +/* Define this macro to enable quota code testing. Once quota code
> is */
> +/* stable and verified, remove this macro and checks for it. */
> +/*#define PS_QUOTA_ENABLE_QUOTA_CODE*/
> +
> +
> /* FUNCTIONS
> ***************************************************************/
>
> VOID
> @@ -66,9 +72,29 @@
> {
> /* Don't do anything for the system process */
> if (Process == PsInitialSystemProcess) return STATUS_SUCCESS;
> -
> +
> +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE
> + if (Process)
> + {
> + /* TODO: Check with Process->QuotaBlock if this can be
> satisfied, */
> + /* assuming this indeed is the place to check it. */
> + /* Probably something like:
> + if (Process->QuotaUsage[2] + Amount >
> + Process->QuotaBlock->QuotaEntry[2].Limit)
> + {
> + refuse
> + }
> + */
> + Process->QuotaUsage[2] += Amount;
> + if (Process->QuotaPeak[2] < Process->QuotaUsage[2])
> + {
> + Process->QuotaPeak[2] = Process->QuotaUsage[2];
> + }
> + }
> +#else
> /* Otherwise, not implemented */
> UNIMPLEMENTED;
> +#endif
> return STATUS_SUCCESS;
> }
>
> @@ -115,6 +141,38 @@
> return PsChargeProcessPoolQuota(Process, PagedPool, Amount);
> }
>
> +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE
> +/*
> + * Internal helper function.
> + * Returns the index of the Quota* member in EPROCESS for
> + * a specified pool type, or -1 on failure.
> + */
> +static
> +INT
> +PspPoolQuotaIndexFromPoolType(POOL_TYPE PoolType)
> +{
> + switch (PoolType)
> + {
> + case NonPagedPool:
> + case NonPagedPoolMustSucceed:
> + case NonPagedPoolCacheAligned:
> + case NonPagedPoolCacheAlignedMustS:
> + case NonPagedPoolSession:
> + case NonPagedPoolMustSucceedSession:
> + case NonPagedPoolCacheAlignedSession:
> + case NonPagedPoolCacheAlignedMustSSession:
> + return 1;
> + case PagedPool:
> + case PagedPoolCacheAligned:
> + case PagedPoolSession:
> + case PagedPoolCacheAlignedSession:
> + return 0;
> + default:
> + return -1;
> + }
> +}
> +#endif
> +
> /*
> * @implemented
> */
> @@ -124,10 +182,32 @@
> IN POOL_TYPE PoolType,
> IN ULONG Amount)
> {
> + INT PoolIndex;
> /* Don't do anything for the system process */
> if (Process == PsInitialSystemProcess) return STATUS_SUCCESS;
>
> - UNIMPLEMENTED;
> +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE
> + PoolIndex = PspPoolQuotaIndexFromPoolType(PoolType);
> + if (Process && PoolIndex != -1)
> + {
> + /* TODO: Check with Process->QuotaBlock if this can be
> satisfied, */
> + /* assuming this indeed is the place to check it. */
> + /* Probably something like:
> + if (Process->QuotaUsage[PoolIndex] + Amount >
> + Process->QuotaBlock->QuotaEntry[PoolIndex].Limit)
> + {
> + refuse
> + }
> + */
> + Process->QuotaUsage[PoolIndex] += Amount;
> + if (Process->QuotaPeak[PoolIndex] < Process->QuotaUsage
> [PoolIndex])
> + {
> + Process->QuotaPeak[PoolIndex] = Process->QuotaUsage
> [PoolIndex];
> + }
> + }
> +#else
> + UNIMPLEMENTED;
> +#endif
> return STATUS_SUCCESS;
> }
>
> @@ -140,10 +220,26 @@
> IN POOL_TYPE PoolType,
> IN ULONG_PTR Amount)
> {
> + INT PoolIndex;
> /* Don't do anything for the system process */
> if (Process == PsInitialSystemProcess) return;
>
> - UNIMPLEMENTED;
> +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE
> + PoolIndex = PspPoolQuotaIndexFromPoolType(PoolType);
> + if (Process && PoolIndex != -1)
> + {
> + if (Process->QuotaUsage[PoolIndex] < Amount)
> + {
> + DPRINT1("WARNING: Process->QuotaUsage sanity check
> failed.\n");
> + }
> + else
> + {
> + Process->QuotaUsage[PoolIndex] -= Amount;
> + }
> + }
> +#else
> + UNIMPLEMENTED;
> +#endif
> }
>
> /*
> @@ -157,7 +253,11 @@
> /* Don't do anything for the system process */
> if (Process == PsInitialSystemProcess) return;
>
> - UNIMPLEMENTED;
> +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE
> + PsReturnPoolQuota(Process, NonPagedPool, Amount);
> +#else
> + UNIMPLEMENTED;
> +#endif
> }
>
> /*
> @@ -171,7 +271,11 @@
> /* Don't do anything for the system process */
> if (Process == PsInitialSystemProcess) return;
>
> - UNIMPLEMENTED;
> +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE
> + PsReturnPoolQuota(Process, PagedPool, Amount);
> +#else
> + UNIMPLEMENTED;
> +#endif
> }
>
> NTSTATUS
> @@ -182,8 +286,22 @@
> /* Don't do anything for the system process */
> if (Process == PsInitialSystemProcess) return STATUS_SUCCESS;
>
> +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE
> + if (Process)
> + {
> + if (Process->QuotaUsage[2] < Amount)
> + {
> + DPRINT1("WARNING: Process PageFileQuotaUsage sanity
> check failed.\n");
> + }
> + else
> + {
> + Process->QuotaUsage[2] -= Amount;
> + }
> + }
> +#else
> /* Otherwise, not implemented */
> UNIMPLEMENTED;
> +#endif
> return STATUS_SUCCESS;
> }
>
>
>
Hi!
Good job! But this is all kinds of type of wrong! There are internal calls for win32k dc.c
and dcutils.c in there. What you should have done was move the DC object structure to ntgdihdl.h.
So, please revert or but back dc.h and then move the DC object to ntgdihld.h where it belongs.
Thanks,
James
Hi!
What was the revision for the floppy driver that made it inoperative?
You told me on IRC. I did not take my notes to work.
> Hello,
>
> I think that 0.3.4 should have most hardware regressions (floppy and
> vga) fixed. I know I'm not the one to say this but, we are already
> closer to this goal than we were with 0.3.3. Fixing the floppy
> regression should only involve finding the spot in which floppy is not
> reporting correctly to ntoskrnl. I did some tests on this issue and it
> fails on line 596-598 of ntoskrnl\io\iomgr\volume.c and floppy was never
> mounted as the status reported was STATUS_IO_DEVICE_ERROR from line
> 1017-1021 in drivers\storage\floppy\floppy.c. I don't know much about
> the vga regression but I'd think that it may only require a few days
> work to find and fix the issue. We already have SATA support included
> with trunk (uniata.sys) and SCSI is also working now.
>
> -aicommander
>
Thanks,
James
These resources have been lifted straight out of the Windows dll.
Absolutley no attempt has been made to change anything.
IMO, this should be removed until someone manually implements it.
Ged.
fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Sat Oct 20 21:16:30 2007
> New Revision: 29714
>
> URL: http://svn.reactos.org/svn/reactos?rev=29714&view=rev
> Log:
> Dmitry Chapyshev <lentind(a)yandex.ru>
> - Fully implement tapiui.dll, compatible with Windows.
> - Icons come from SUSE's yast2-industrial; 203,202.ico and 301,302.bmp are done by me based on Tango
>
>
>
Hello,
I think that 0.3.4 should have most hardware regressions (floppy and
vga) fixed. I know I'm not the one to say this but, we are already
closer to this goal than we were with 0.3.3. Fixing the floppy
regression should only involve finding the spot in which floppy is not
reporting correctly to ntoskrnl. I did some tests on this issue and it
fails on line 596-598 of ntoskrnl\io\iomgr\volume.c and floppy was never
mounted as the status reported was STATUS_IO_DEVICE_ERROR from line
1017-1021 in drivers\storage\floppy\floppy.c. I don't know much about
the vga regression but I'd think that it may only require a few days
work to find and fix the issue. We already have SATA support included
with trunk (uniata.sys) and SCSI is also working now.
-aicommander
Hi there,
i am thinking of porting ros to the L4 micro-kernel as topic for my
diploma thesis. The operating systems group in Dresden already ported
Linux to L4 (http://os.inf.tu-dresden.de/L4/LinuxOnL4/) and proofed
that L4 offers all that is needed to run an operating system in
userspace on top of it.
The goal of the work would be to be able to run windows applications
next to miro-kernel applications. And to compare the performance with
that of pure ros, L4Linux/wine and windows. A comparison between the
port and L4Linux could also be part of the work. (mapping processes to
L4 tasks, memory management, interrupt-handling and so on)
I am not very experienced in C or assembler programming but am
motivated to learn. But before i start working on that topic i have
some questions on the portability of ros.
In svn and on the ros website i found that there is a ppc port of ros.
And on irc someone told me that there is ongoing work on a ros usermode
port. I also read about a xen port. But i did not yet find working
copies of the any of that ports. I built ros for i386 on my
machine and was able to boot it in vmware. I also tried building the
latest svn version with ROS_ARCH=powerpc but that did not succeed.
1. Did anyone ever finish a port to another arch?
2. How portable is ros in general? Meaning how much code would have to
be changed. I hope there are abstractions and only 10-15% of the kernel
would have to be changed.
3. Do you believe that one person new to ros can finish that kind of
work in 6 months? I know that might be hard to answer but how long did
any of you need to learn ros in detail?
4. If there are working ports, how long did it take to implement them?
If there are not, what are the reasons they where never finished? I am
thinking of lots of assembler and i386 hacks.
5. Finally, what do think of the idea itself?
I hope you take the time to answer my questions. I am still on the way
to determine whether i really want to do that and whether i can do this
in 6 months.
regards,
Henning Schild
Hello,
after updating to r29681, I cannot compile ROS.
The error is:
[WRC] obj-i386\base\applications\cacls\cacls.coff
output-i386\tools\wrc\wrc.exe: unknown option -- W
output-i386\tools\wrc\wrc.exe: unknown option -- n
output-i386\tools\wrc\wrc.exe: unknown option -- W
output-i386\tools\wrc\wrc.exe: unknown option -- p
Error: Too many output files.
mingw32-make: *** [obj-i386\base\applications\cacls\cacls.coff] Error 2
Sincerely,
Carlo Bramini
Hi Marc,
the patch / bug IS valid, Magnus made a mistake and closed it.
I wanted to do the same, but it's rather timeconsuming, so I
appreciate you took the first steps. Still, some modules may require
setting some specific version - that's allright, we can leave some
exceptions for now, but otherwise, version number should be set
globally, not in every .rbuild file (which is so wrong).
WBR,
Aleksey Bragin.
On Oct 19, 2007, at 2:53 AM, Marc Piulachs wrote:
> Hi,
>
> On the reactos frontpage I see that the project aims to reimplement
> WindowsXP , that is NT 5.2 , but currently most of the modules
> define their
> own target version ranging from NT4 to NT 5.3 (2003) .On recent
> shell32
> commits I have even seen someone introducing Vista-only APIs.
>
> I think an effort has to be done to fix that situation ,IMHO targeting
> multiple windows versions is fine but not a mix of them so I
> recently posted
> a bug report on mozilla to have it present at least.
> http://www.reactos.org/bugzilla/show_bug.cgi?id=2745 but It has
> been marked
> as invalid and I can't understand the reason given, I may be wrong
> about
> that but I'd like to know what I'm missing here, can anyone clarify?
>
> /Marc
Shouldn't it be finally fixed, instead?
I don't know who broke it. Was it Magnus with the "No PNP videocard"
commit?
WBR,
Aleksey Bragin.
On Oct 18, 2007, at 8:01 AM, mnordell(a)svn.reactos.org wrote:
> Author: mnordell
> Date: Thu Oct 18 08:01:53 2007
> New Revision: 29653
>
> URL: http://svn.reactos.org/svn/reactos?rev=29653&view=rev
> Log:
> Patch from aicommander. Actually copy uniata.sys from the
> installation media, and disable VGA resolution selection as VGA is
> broken.
> [Display]
> ;<id> = <user friendly name>,<spare>,<service key
> name>,<hight>,<width>,<bpp>
> -vga = "VGA Display (640x480x4)",,Vga,640,480,4
> +;vga = "VGA Display (640x480x4)",,Vga,640,480,4