Menu
▾
▴
reactos-kernel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(64) |
Oct
(438) |
Nov
(183) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(132) |
May
(466) |
Jun
(366) |
Jul
(392) |
Aug
(31) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
|
From: Phillip S. <ps...@cf...> - 2001-10-15 19:50:48
|
At 03:50 PM 10/15/2001 +0100, you wrote: >But the existing memory management code doesn't 'do all the work' Yes it does: it handles memory mapped files ( sections ) and working sets. These are all that are needed to implement the cache. >since cached file data and memory mapped files are fundamentally >different things. Most of the time data will either be memory mapped How are they different? They are both just file data in memory. The only difference is semantics: is memory allocated, and then have file data read into it, or is it mapped, and the data is read in on page fault or otherwise locking of the memory. >or the subject of NtReadFile/NtWriteFile and we want the paths for >handling both to be optimized for their specific characteristics not >to kludge one into a special case of the other. What is a kludge here? NtReadFile needs to return some data to the caller, it is already mapped into the kernel address space for caching, just do memcpy(). >Because every time an application uses a part of a cached file >then it calls (via the filesystem) the cache manager so we can record the >LRU information very easily. Only when it uses it via Read/Write calls, not via MMF. > > And how does memory mapped files interact with this cache? > > >My plan was to handle memory mapped data which is also shared >with the cache using the mechanism for paging user data. This is precisely the way that NT does it by utilizing the same section object for both the cache and MMF, and the main reason I like the idea: it uses the same system for cache and MMF, keeping things simple and unified. Am I confused, or are you not planning on using the section object for the cache? If you are not, how is the cache and MMF to share the same pages? It seems to me that your plan calls for section objects and MMF to be totally different than the cache block structure. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jason F. <jas...@ya...> - 2001-10-15 19:14:43
|
I don't think they'll be too quick to do this.. it would give the project a lot of publicity and in their eyes do more harm than good. They'll only worry about us when their marketshare starts being affected. Nevertheless, I have contacted the FSF asking for their advice. - Jason --- Eric <em...@po...> wrote: > Well it's a moot point. I can see we all basically agree on what's > RIGHT > but it all comes down to how much $ M$ wants to spend pursuing a > lawsuit. I > frankly don't see them doing this for reasons already stated. > > What is ROS prepared to do in such an event? Or is it something > you really > aren't concerned with right now? Just curious. > > Eric > > -----Original Message----- > From: Rex Jolliff [mailto:re...@lv...] > Sent: Friday, October 12, 2001 6:46 PM > To: ros...@re... > Subject: [ros-kernel] Re: RE: Re: Legal... > > > At 09:52 AM 10/12/01 -0400, you wrote: > >I'm not a lawyer and don't pretend to be one but I simply fail to > see how > M$ > >have any legal standing. That's like Ford suing Chrysler for > copying the > >automobile. Is it not? > > > >After all, M$ literally copied the Window concept from Xerox and > MS-DOS was > >a derivative of CP/M which they purchased and copied. > > I am sure that Microsoft believes they have hundreds of patents on > technology in the > NT operating system. It does not matter than those patents are > bogus, one > would > have to defend oneself against them all the same and expend scarce > resources doing > so. > > > Rex Jolliff > re...@lv... > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Anjum N. <anj...@ho...> - 2001-10-15 19:12:15
|
although i am not a very good developer yet i am ready to help. i am already working on one but its in very initial stage. >From: "Zeno Kaiser" <Gen...@we...> >Reply-To: <ros...@re...> >To: ros...@re... >Subject: [ros-kernel] shell >Date: Mon, 15 Oct 2001 16:19:33 +0200 > > who will help me to make a shell like windows? >we can use code from litestep and other projects! >i will make a projektpage > >please write to me! > >GenesisXG >_______________________________________________________________________ >1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de >Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de > >==================================================== >= To remove yourself from this mailing list, go to = >= http://www.reactos.com/home/mailing.html = >==================================================== > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Brian P. <br...@sg...> - 2001-10-15 18:53:12
|
I think the only limitation loadros has is that it has to fit everything it loads into the 640k conventional memory. About 'ROSDTECT.COM' -- I think this functionality will be built into FreeLoader if and when it gets implemented. Brian -----Original Message----- From: Thierry Delhaise [mailto:thi...@ma...] Sent: Monday, October 15, 2001 9:27 AM To: Ros-Kernel Subject: [ros-kernel] loadros command line Hi all, I try to test a new drivers chain 'class2, scsiport, atapi, disk, vfat'. I use loadros to boot this new chain and seems that not all modules are load by loadros. One seems to be view as an hive file !? I took a short look at loadros.asm but see nothing about a limitation of the number of modules being able to load by loadros. May be a limitation about the DOS command line ? Can someone could describe me quickly spec of loadros (limitations, situations tested , situations don't tested, etc...). Does the future support of binary compatible 'ROSDETECT.COM' (I think all will be able to understand what I mean, if not tell me !) will be add in this 'COM' (LOADROS) file or in an another way ? Thanks Thierry ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert C. <rob...@it...> - 2001-10-15 17:40:34
|
Further to my last email...
I can see there is multiboot stuff in freeloader already. Doh!
Also, the current make file will fail because mingw gcc is built with
only PE emulation by default, which may be causing problems as you are
trying to link to a 'binary' target - which PE is not supported for.
Now, using grub as further inspiration...
===
# General rule for making a raw binary.
%: %.exec
$(OBJCOPY) -O binary $< $@
===
so for something like freeldr.sys which I'm assuming is actually a raw
binary, all you need is
freeldr.sys: freeldr.exec
../bootsect/stubit ../bootsect/fatstub.bin freeldr.exec freeldr.sys
freeldr.exec: asmcode.a c_code.a \
./bootsect/stubit ../bootsect/fatstub.bin
And that could possibly be simpler if the stub is included in the main
source dir.
Rob
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: Thierry D. <thi...@ma...> - 2001-10-15 17:11:47
|
Hi all, I try to test a new drivers chain 'class2, scsiport, atapi, disk, vfat'. I use loadros to boot this new chain and seems that not all modules are load by loadros. One seems to be view as an hive file !? I took a short look at loadros.asm but see nothing about a limitation of the number of modules being able to load by loadros. May be a limitation about the DOS command line ? Can someone could describe me quickly spec of loadros (limitations, situations tested , situations don't tested, etc...). Does the future support of binary compatible 'ROSDETECT.COM' (I think all will be able to understand what I mean, if not tell me !) will be add in this 'COM' (LOADROS) file or in an another way ? Thanks Thierry ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Zeno K. <Gen...@we...> - 2001-10-15 16:04:30
|
i think we must make a little shell for testing the ReactOS Kernel and GUI! for the beginning it must be only little and later we can begin to make the API and other things like WinCrash! greets to BillGates! GenesisXG <ros...@re...> schrieb am 15.10.01: > Good Evening All, > > I downloaded the TWIN source Steven mentioned and with a bit of coaxing, > got ComCtl32 to compile. TWIN is GPL so I don't see any problem using the > code in ReactOS. I am going to play with some of the TWIN DLLs that are not > yet implemented in ReactOS. If I can get them working, I'll submit them for > your approval. I realize that it is premature to work on GUI code when > there remains much to be done in the kernel, but I have only written a > couple of NT drivers, and don't have the experience to code on that level. > > James > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Michael Z. <mi...@za...> - 2001-10-15 16:01:43
|
> > >>Btw, I guess the M$ developers still have to use VC 1.52 (16 bit) to >> >build > >>the WinXP boot code. ;) >> I wouldn't be surprised if they would use an modified version of for example gcc and etc. They even distribute gcc for an posix extending layer on NT, Interix (i guess it is called like that). Greetz, Michael. |
|
From: Brian P. <br...@sg...> - 2001-10-15 15:50:32
|
Right now FreeLoader is fully gcc+binutils compliant and will build under most x86 gcc dists. It uses AT&T assembly. The real problem with MingW is that it cannot assemble 16-bit code. Every time I use the .code16 directive it complains that it cannot represent reloc type BFD_RELOC_16. For some reason they have the 16-bit code support compiled out of MingW. AFAIK this is the only pending issue that is keeping FreeLoader from compiling. About ReactOS being multiboot compliant -- I don't see how we can accomplish this without an intermediate boot loader. ReactOS will need to have hardware & registry information passed in from the boot loader, and the list of modules to load is specified in the registry. All this doesn't fit very well into the multiboot spec. Brian -----Original Message----- From: Robert Collins [mailto:rob...@it...] Sent: Monday, October 15, 2001 7:36 AM To: ros...@re... Subject: [ros-kernel] Re: Gcc and binutils release ----- Original Message ----- From: "Robert Collins" <rob...@it...> To: <ros...@re...> Sent: Monday, October 15, 2001 9:30 PM Subject: [ros-kernel] Re: Gcc and binutils release > All I know is that on Linux, 16 bit code for bootloaders is generated > and linked by the gcc-gas-ld toolchain. I can look into their makefiles > for you guys ... if you'd like. > Side question: Can someone remind me why making ReactOS multi-boot compliant so that Grub et al can boot it was a bad thing? - Grub should build under cygwin very happily. The makefiles would need a little tweaking for use under mingw without cygwin. --- and now onto the Main issue: generating boot code from gcc + binutils. Grub is built from gcc + binutils. http://savannah.gnu.org/cgi-bin/viewcvs/grub/grub/stage1/ contains the stage1 portion of Grub, which is the assembly code. They simply use -fno-builtin -nostdinc on the commandline to gcc to prevent accidentally pulling in a library header... So I can offer the following: It *is* possible with a standard x86 targeted gcc+recent binutils (all the ReactOS ones are ok) to generate 16 bit assembly suitable for bootstrapping a bootloader. I can see several options: 1) convert freeloader to use standard gcc+binutils as Grub does. 2) make ReactOS multiboot compliant so that it can be used with Grub or other multiboot bootloaders. then phase out freeloader, or make it a multiboot compliant bootloader. 3) Start from scratch under gcc+binutils. I suspect that 1) is actually quite easy and is the way to go... However you'll need to get gcc to support Intel asm memnomics or change to AT&T as it only supports AT&T by default. I'm sure there are patchs out there to give gcc Intel support, this came up somewhere else recently I think... maybe even here:}. Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: <we...@cw...> - 2001-10-15 15:38:52
|
Philip Susi writes > >It is more difficult to create and maintain all of these special code >paths and algorithms for the cache than it would be to simply let the >existing memory management code do all the work for you like in NT. > But the existing memory management code doesn't 'do all the work' since cached file data and memory mapped files are fundamentally different things. Most of the time data will either be memory mapped or the subject of NtReadFile/NtWriteFile and we want the paths for handling both to be optimized for their specific characteristics not to kludge one into a special case of the other. >We do? Where? > Because every time an application uses a part of a cached file then it calls (via the filesystem) the cache manager so we can record the LRU information very easily. > And how does memory mapped files interact with this cache? > My plan was to handle memory mapped data which is also shared with the cache using the mechanism for paging user data. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: <we...@cw...> - 2001-10-15 15:05:36
|
Robert Collins writes > >2) make ReactOS multiboot compliant so that it can be used with Grub or >other multiboot bootloaders. then phase out freeloader, or make it a >multiboot compliant bootloader. > It might not be obvious from the code or the documentation but reactos is mulitboot compliant and it can be booted with grub, this is how I boot reactos exclusively. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Zeno K. <Gen...@we...> - 2001-10-15 15:00:34
|
who will help me to make a shell like windows? we can use code from litestep and other projects! i will make a projektpage please write to me! GenesisXG _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jakov af W. <ja...@vm...> - 2001-10-15 14:52:24
|
On Mon, Oct 15, 2001 at 09:30:13PM +1000, Robert Collins wrote: > > > All I know is that on Linux, 16 bit code for bootloaders is generated > and linked by the gcc-gas-ld toolchain. I can look into their makefiles > for you guys ... if you'd like. > AFAIK the bin86 package is used for that: as86 and ld86. regards, Jakob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-10-15 14:14:57
|
Thanks for the links. I thought that mingw supported stabs as well as coff? Well, I'll play around with this for a bit. We should combine efforts then if you are working on the kernel debugger. Would you like to discuss it sometime on irc or icq? My icq # is 4760754. At 09:55 PM 10/14/2001 -0700, you wrote: >Here's a link for pe and coff: >http://www.microsoft.com/hwdev/download/hardware/PECOFF.pdf > >I couldn't find CV4, however you shouldn't need it since all our files >compile with stabs debug information and I don't think that gcc supports >CV4. A very good reference for stabs can be found here: >http://www.cygwin.com/stabs_toc.html > >I'm starting to work on a slightly more advanced kernel debugger. Maybe we >should combine our efforts. > >ei ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert C. <rob...@it...> - 2001-10-15 14:07:24
|
----- Original Message ----- From: "Robert Collins" <rob...@it...> To: <ros...@re...> Sent: Monday, October 15, 2001 9:30 PM Subject: [ros-kernel] Re: Gcc and binutils release > All I know is that on Linux, 16 bit code for bootloaders is generated > and linked by the gcc-gas-ld toolchain. I can look into their makefiles > for you guys ... if you'd like. > Side question: Can someone remind me why making ReactOS multi-boot compliant so that Grub et al can boot it was a bad thing? - Grub should build under cygwin very happily. The makefiles would need a little tweaking for use under mingw without cygwin. --- and now onto the Main issue: generating boot code from gcc + binutils. Grub is built from gcc + binutils. http://savannah.gnu.org/cgi-bin/viewcvs/grub/grub/stage1/ contains the stage1 portion of Grub, which is the assembly code. They simply use -fno-builtin -nostdinc on the commandline to gcc to prevent accidentally pulling in a library header... So I can offer the following: It *is* possible with a standard x86 targeted gcc+recent binutils (all the ReactOS ones are ok) to generate 16 bit assembly suitable for bootstrapping a bootloader. I can see several options: 1) convert freeloader to use standard gcc+binutils as Grub does. 2) make ReactOS multiboot compliant so that it can be used with Grub or other multiboot bootloaders. then phase out freeloader, or make it a multiboot compliant bootloader. 3) Start from scratch under gcc+binutils. I suspect that 1) is actually quite easy and is the way to go... However you'll need to get gcc to support Intel asm memnomics or change to AT&T as it only supports AT&T by default. I'm sure there are patchs out there to give gcc Intel support, this came up somewhere else recently I think... maybe even here:}. Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Zeno K. <Gen...@we...> - 2001-10-15 14:06:43
|
who will help me to make a shell like windows? we can use code from litestep and other projects! i will make a projektpage please write to me! GenesisXG _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-10-15 14:03:15
|
At 08:17 AM 10/15/2001 +0100, you wrote: > > Currently, trying to copy a file on a machine with 8 megs of ram causes > the > > cache to use all available memory, run out, and then the system locks > > up. This is due to several reasons, the first being that the cache > > does not currently have any mechanism to prevent it from growing > > without bound. > > >Yes, but this shouldn't be very difficult to add. It is more difficult to create and maintain all of these special code paths and algorithms for the cache than it would be to simply let the existing memory management code do all the work for you like in NT. > > The cache needs to map views of the files to be cached into the cache > > working set, and the working set and page fault handling code will keep > > the cache working set from growing without bound, as well as reclaiming > > cache memory. > > >Why? For the cache we have exact LRU information. We do? Where? And how does memory mapped files interact with this cache? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric <em...@po...> - 2001-10-15 13:31:23
|
Well it's a moot point. I can see we all basically agree on what's RIGHT but it all comes down to how much $ M$ wants to spend pursuing a lawsuit. I frankly don't see them doing this for reasons already stated. What is ROS prepared to do in such an event? Or is it something you really aren't concerned with right now? Just curious. Eric -----Original Message----- From: Rex Jolliff [mailto:re...@lv...] Sent: Friday, October 12, 2001 6:46 PM To: ros...@re... Subject: [ros-kernel] Re: RE: Re: Legal... At 09:52 AM 10/12/01 -0400, you wrote: >I'm not a lawyer and don't pretend to be one but I simply fail to see how M$ >have any legal standing. That's like Ford suing Chrysler for copying the >automobile. Is it not? > >After all, M$ literally copied the Window concept from Xerox and MS-DOS was >a derivative of CP/M which they purchased and copied. I am sure that Microsoft believes they have hundreds of patents on technology in the NT operating system. It does not matter than those patents are bogus, one would have to defend oneself against them all the same and expend scarce resources doing so. Rex Jolliff re...@lv... ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Kohn E. D. <em...@cs...> - 2001-10-15 12:50:39
|
On Mon, 15 Oct 2001, Casper Hornstrup wrote: > On Monday 15 October 2001 05:29, Steven Edwards wrote: > > What is the syntax for building a static lib (not a dll) in a reactos > > makefile? > > Is this an .a file? If so, then use target=library, otherwise this is a bug > in the makefile system. How do you build a static library with gcc then? AFAIK in order to build a static library, first you have to separately compile echo source file to object (.o) files, using the -c option of gcc, and after that create a library with the ar command: E.g if you want to create libfoo.a from foo1.c foo2.c gcc -c foo1.c gcc-c foo2.c ar -ru libfoo.a foo1.o foo2.o ... ar comes as component of binutils. Emil > > - Casper > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > > ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert C. <rob...@it...> - 2001-10-15 11:39:38
|
----- Original Message ----- From: "Eric Kohl" <ek...@rz...> To: <ros...@re...> Sent: Monday, October 15, 2001 8:27 PM Subject: [ros-kernel] Re: Gcc and binutils release > > Phillip Susi <ps...@cf...> wrote: > > > > You didn't happen to also fix the bug that prevents it from generating > > binary output so we don't have to have djgpp to compile freeloader did > you? ;) > > > No! And I'm afraid we cannot build a 'merged' toolset that supports mingw > and djgpp. :-( > > I compared the object files generated by mingw and djgpp. They are entirely > different. Mingw generates calls to alloca() in tui.o and djgpp doesn't. So > the problem is not only the linker, it's the compiler too. Just try to build > FreeLoader using mingw and you'll see. Thats probably because (IIRC) alloca is used by a header macro somewhere. > Btw, I guess the M$ developers still have to use VC 1.52 (16 bit) to build > the WinXP boot code. ;) > > - Eric Kohl All I know is that on Linux, 16 bit code for bootloaders is generated and linked by the gcc-gas-ld toolchain. I can look into their makefiles for you guys ... if you'd like. Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-10-15 10:31:19
|
Phillip Susi <ps...@cf...> wrote: > You didn't happen to also fix the bug that prevents it from generating > binary output so we don't have to have djgpp to compile freeloader did you? ;) > No! And I'm afraid we cannot build a 'merged' toolset that supports mingw and djgpp. :-( I compared the object files generated by mingw and djgpp. They are entirely different. Mingw generates calls to alloca() in tui.o and djgpp doesn't. So the problem is not only the linker, it's the compiler too. Just try to build FreeLoader using mingw and you'll see. Btw, I guess the M$ developers still have to use VC 1.52 (16 bit) to build the WinXP boot code. ;) - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Casper H. <ch...@us...> - 2001-10-15 09:44:05
|
On Monday 15 October 2001 05:29, Steven Edwards wrote: > What is the syntax for building a static lib (not a dll) in a reactos > makefile? Is this an .a file? If so, then use target=library, otherwise this is a bug in the makefile system. How do you build a static library with gcc then? - Casper ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: David W. <we...@cw...> - 2001-10-15 07:23:22
|
On Sun, Oct 14, 2001 at 07:05:23PM -0400, Phillip Susi wrote: > Who was it that recently did some work with the cache manager code? Are > you still working on it? The Cc code needs to be reworked to use mapped > section views like NT does instead of CACHE_SEGMENTs. > No, it doesn't. > Currently, trying to copy a file on a machine with 8 megs of ram causes the > cache to use all available memory, run out, and then the system locks > up. This is due to several reasons, the first being that the cache > does not currently have any mechanism to prevent it from growing > without bound. > Yes, but this shouldn't be very difficult to add. > The cache needs to map views of the files to be cached into the cache > working set, and the working set and page fault handling code will keep > the cache working set from growing without bound, as well as reclaiming > cache memory. > Why? For the cache we have exact LRU information. > The other bug in the current code is in cc/view.c in > CcRosGetCacheSegment, which does this: > > Status = MmCreateVirtualMapping(NULL, > current->BaseAddress + (i * PAGESIZE), > PAGE_READWRITE, > (ULONG)MmAllocPage(0)); > > Note that the call to MmAllocPage is not checked for failure. On my test > system, it fails when memory runs out, and returns 0, which then gets > passed to MmCreateVirtualMapping for the physical backing page. If noone > is working on this, I guess I'll go for it, but if someone already is, let > me know. > I'm working on adding support for balancing memory usage including from the cache. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Mark W. <ma...@np...> - 2001-10-15 05:39:15
|
There is a COFF reference on the DJGPP site. http://www.delorie.com/djgpp/doc/coff/ This comes with a header too. AFAIK DJGPP generates MS compatible COFF objects so this should be OK. mingw does not use the same COFF format, be wary. Mark > -----Original Message----- > From: Phillip Susi [mailto:ps...@cf...] > Sent: 15 October 2001 04:48 > To: ros...@re... > Subject: [ros-kernel] Debug format > > > I'm working on getting the kernel debugger to use the COFF or CV4 > debugging > information in the image files instead of loading and parsing text .sym > files. This should make it more useful for debugging. I can't > find where > MS has hidden their documentation on the PE file, COFF, and CV4 formats, > does anyone know where they put it? > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > > ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eugene I. <ge...@ya...> - 2001-10-15 05:15:34
|
Here's a link for pe and coff: http://www.microsoft.com/hwdev/download/hardware/PECOFF.pdf I couldn't find CV4, however you shouldn't need it since all our files compile with stabs debug information and I don't think that gcc supports CV4. A very good reference for stabs can be found here: http://www.cygwin.com/stabs_toc.html I'm starting to work on a slightly more advanced kernel debugger. Maybe we should combine our efforts. ei ----- Original Message ----- From: "Phillip Susi" <ps...@cf...> To: <ros...@re...> Sent: Sunday, October 14, 2001 8:48 PM Subject: [ros-kernel] Debug format > I'm working on getting the kernel debugger to use the COFF or CV4 debugging > information in the image files instead of loading and parsing text .sym > files. This should make it more useful for debugging. I can't find where > MS has hidden their documentation on the PE file, COFF, and CV4 formats, > does anyone know where they put it? > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
8 messages has been excluded from this view by a project administrator.
