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: Jason F. <jas...@ya...> - 2001-09-25 18:29:37
|
Has anyone tested/updated the tree with this update and the latest
one from Jack?
Jack: it seems that most developers prefer that you send them the
"diffs".. but I don't think I have diff installed?..
- Jason
--- "Jack (Butch) Griffin" <bu...@qw...> wrote:
> I have been playing with the ReactOS operating system and trying to
> get a
> console mode app written in vistual C++ to run. The app is your
> basic hello
> world application. I did not really expect that the complete
> infra-structure was in place for this to run, but I figured it
> would point
> out what was missing and give me a starting point for beginning to
> learn
> about the design of this OS.
>
> Anyway I have found a problem and do not know who should get the
> updated
> code. The problem is in MiReadPage() and the updated code is
> below. The
> only change is that STATUS_END_OF_FILE is a legimate return from
> IoPageRead(). It does not mean an error occurred, just that the
> file did
> not contain enough data to fill the page. Function that call
> MiReadPage()
> assume that the data read are OK if the return value is
> STATUS_END_OF_FILE,
> so the update of the Page pointer must be done in this case.
>
> Thanks
> Jack Griffin
>
>
> NTSTATUS
> MiReadPage(PMEMORY_AREA MemoryArea,
> PLARGE_INTEGER Offset,
> PVOID* Page)
> {
> IO_STATUS_BLOCK IoStatus;
> PFILE_OBJECT FileObject;
> PMDL Mdl;
> NTSTATUS Status;
> PREACTOS_COMMON_FCB_HEADER Fcb;
>
> FileObject = MemoryArea->Data.SectionData.Section->FileObject;
> Fcb = (PREACTOS_COMMON_FCB_HEADER)FileObject->FsContext;
>
> if (FileObject->Flags & FO_DIRECT_CACHE_PAGING_READ &&
> (Offset->QuadPart % PAGESIZE) == 0)
> {
> ULONG BaseOffset;
> PVOID BaseAddress;
> BOOLEAN UptoDate;
> PCACHE_SEGMENT CacheSeg;
> LARGE_INTEGER SegOffset;
> PHYSICAL_ADDRESS Addr;
> Status = CcRosGetCacheSegment(Fcb->Bcb,
> (ULONG)Offset->QuadPart,
> &BaseOffset,
> &BaseAddress,
> &UptoDate,
> &CacheSeg);
> if (!NT_SUCCESS(Status))
> {
> return(Status);
> }
> if (!UptoDate)
> {
> Mdl = MmCreateMdl(NULL, BaseAddress,
> Fcb->Bcb->CacheSegmentSize);
> MmBuildMdlForNonPagedPool(Mdl);
> SegOffset.QuadPart = BaseOffset;
> Status = IoPageRead(FileObject,
> Mdl,
> &SegOffset,
> &IoStatus,
> TRUE);
> if (!NT_SUCCESS(Status) && Status != STATUS_END_OF_FILE)
> {
> CcRosReleaseCacheSegment(Fcb->Bcb, CacheSeg, FALSE);
> return(Status);
> }
> }
> Addr = MmGetPhysicalAddress(BaseAddress +
> Offset->QuadPart - BaseOffset);
> (*Page) = (PVOID)(ULONG)Addr.QuadPart;
> MmReferencePage((*Page));
>
> CcRosReleaseCacheSegment(Fcb->Bcb, CacheSeg, TRUE);
> return(STATUS_SUCCESS);
> }
> else
> {
> /*
> * Allocate a page, this is rather complicated by the
> possibility
> * we might have to move other things out of memory
> */
> (*Page) = MmAllocPage(0);
> while ((*Page) == NULL)
> {
> MmWaitForFreePages();
> (*Page) = MmAllocPage(0);
> }
>
> /*
> * Create an mdl to hold the page we are going to read data
> into.
> */
> Mdl = MmCreateMdl(NULL, NULL, PAGESIZE);
> MmBuildMdlFromPages(Mdl, (PULONG)Page);
> /*
> * Call the FSD to read the page
> */
> Status = IoPageRead(FileObject,
> Mdl,
> Offset,
> &IoStatus,
> FALSE);
> return(Status);
> }
> }
>
> ====================================================
> = To remove yourself from this mailing list, go to =
> = http://www.reactos.com/home/mailing.html =
> ====================================================
>
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: KJK::Hyperion <no...@li...> - 2001-09-25 16:56:01
|
At 09.27 24/09/2001 -0700, you wrote: >SGI's XFS filesystem is available as an Open-Source project (GPL) for >Linux. How difficult is it to port a Linux filesystem driver to >ReactOS? > >This filesystem has journaling capabilities, and may be of benefit to >many users. I believe it has ACL support, as well. You'd be disappointed, if you tried. Unix ACLs are very different from NT ACLs: they're just lists of uid + access bitmask pairs in string form. Their difference reflects the huge difference between the two security models. We'd need instead a file system with resource forks/alternate streams ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Frank D. E. Jr. <fd...@ya...> - 2001-09-25 14:13:32
|
It would still be better than FAT, and from a performance standpoint (and the POSIX subsystem whenever that comes around)... --- Phillip Susi <ps...@cf...> wrote: > Any effort to port a unix filesystem to reactos would not fit > semantically > into the OS right. Specifically, even a unix with ACLs does not fit > into > the NT security model. Unix ACLs still only allow specifying > read/write/execute permissions to be set on security entities, and I > doubt > that the security identifier is more than just a 32 bit integer, > which is > not enough to represent an NT SID, which is typically 128 bits ( > though it > can be of any length ). NTFS stores arbitrary security descriptors > which > allows it to hold current and future NT security descriptors. NT > security > descriptors are extensible, and MS has already added capabilities to > specify how a given ACE is to be applied: to the directory, files in > the > directory, children directories, files in those directories, or all > of the > above. In theory it is possible to extend security descriptors to > use > mandatory access control, which is to specify to whom what > permissions may > be granted by those with rights to modify the ACL. An inherited > rights > mask like netware has is also possible. I'd also like to have > deleted file > salvage/purge support like netware. > > In short, a unix filesystem won't port well to reactos due to > differing > semantics. NTFS really is a very powerful and highly extensible > filesystem, whose capabilities are not fully exploited by Microsoft's > > current OSes. I'd like to have reactos exploit more of these > capabilities, > though with win2k it seems that MS is beginning to exploit some of > them > with things like reparse points, which allow EFS and offline files. > Named > data streams are also used to store extra information on the file > properties tab in explorer for the author of the file, subject, etc. > NTFS > can even index files by such extended information instead of just the > name > of the file, as is currently done. NTFS performance could also be > much > better than MIcrosoft's implementations: performance problems ( such > as > being prone to fragmentation ) are due to the driver, not the on disk > > filesystem. > > At 09:27 AM 9/24/2001 -0700, you wrote: > >SGI's XFS filesystem is available as an Open-Source project (GPL) > for > >Linux. How difficult is it to port a Linux filesystem driver to > >ReactOS? > > > >This filesystem has journaling capabilities, and may be of benefit > to > >many users. I believe it has ACL support, as well. > > > >Thus, it may be worth consideration for a future project within > >ReactOS, if it can be ported easily enough. > > > >===== > >======= > >Frank D. Engel, Jr. > >Please note my new address: fd...@ya... > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > ===== ======= Frank D. Engel, Jr. Please note my new address: fd...@ya... __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jason F. <jas...@ya...> - 2001-09-25 08:32:46
|
Quick fix: click on Tools, then on Download (under Nasm on menu). This points to the ftp kernel mirror where its available. - Jason --- Phillip Susi <ps...@cf...> wrote: > The link to nasm on the tools section of www.reactos.com is broken. > > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Mark W. <ma...@np...> - 2001-09-25 02:22:51
|
> > I thought that on NT they were implemented using real threads, and just > play games with the scheduler. I guess I got this idea from seeing a > function called ConvertThreadToFiber() or something. They are pretty much all user mode code. SwitchFiber is a very short function that just saves registers, switches the stack and exception record pointers and then dumps in new ones. It never gets into the kernel, which is one of the reasons that I find fibers so attractive. > I don't see how it is a pain. The difference is having an OOD vs. a > procedural programming model. I prefer the OOP approach, but the > difference at the machine level is that you keep a bit of state > information > in an object on the heap instead of on the stack. Of course, having the > stack for this means you have to reserve one, and even if you > only use say, > an 8kb stack, that's still a fixed 8kb for each connection, instead of > maybe a dozen bytes on the heap. For short lived connections, > this may be > a decent way to do it, but if you have connections that could live for a > good duration, you could easily end up with many 8kb stacks laying around > that aren't being used. Using a heap, you are going to get contention when allocating/freeing memory blocks. If your server is simple enough that all the objects it uses can be created at connection time then you can probably live with this, however if the state sequence it goes through is complicated enough then you won't want those objects to be there all the time. To get around this, you can outfit each connection with its own heap - but then you have to pay for the heap data structure, which is going to allocate at least one page, so we are back to paying the 4-8Kb per connection anyway. > I can see your point, and not having to change existing code is a > powerful > argument, however for new code, I'd prefer to store a function pointer to > the function for handling the next expected state, and each > function is an > easy to understand self contained piece, rather than a large > block of code > that does send/recv over and over. I think that way the code is more > readable. It's a good way of doing it - but I really want to avoid doing the rewriting if possible. Some of the code would be pretty irksome to rewrite in this style - especially since I've got a good chunk of BIND's resolver to cope with! Also I think that keeping the linear path can be more readable. For the SMTP example, then the send/recv calls can all be wrapped up in functions. These functions can just throw exceptions on error, and that way you can keep all of the error handling code in one place. This model just isn't going to work with a chain of functions. > >Just on the subject of IOCP they do seem to be a total hack (`set the low > >bit of the event handle in the overlapped structure to 1 to prevent IOCP > > Huh? > > >notification' is my favourite bit). What is it that means that > threads have > >so much weight in NT anyway? It's from the API docs. My main objection to IOCP is that seems to me that if threads were lighter weight then IOCP would be unnecessary - its just a way of getting around the weight of threads in NT. Of course the OS is far more general purpose than a specific app - there are obviously good reasons for the weight of the threads, and you can't have your cake and eat it (unfortunately!). Putting more of the responsibility on the app is going to yield a more efficient solution, as it knows more about the specifics of the situation, but it also means that the app has more to do. Thanks once again! Mark ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-09-25 01:45:10
|
At 02:20 AM 9/25/2001 +0100, you wrote: >Fibers are just a stack and register context that you can switch out on >demand. They are very lightweight self-scheduled threads. They therefore I thought that on NT they were implemented using real threads, and just play games with the scheduler. I guess I got this idea from seeing a function called ConvertThreadToFiber() or something. >have ideal properties for sitting with IOCP. The OnRecv and OnSend >functions require you to keep track of the current state of a connection, >and make only very light use of the stack. IMO a stack is a pretty >reasonable place to keep all of this data - having to store it yourself in a >connection state structure or class is a pain. Stacks were designed to make I don't see how it is a pain. The difference is having an OOD vs. a procedural programming model. I prefer the OOP approach, but the difference at the machine level is that you keep a bit of state information in an object on the heap instead of on the stack. Of course, having the stack for this means you have to reserve one, and even if you only use say, an 8kb stack, that's still a fixed 8kb for each connection, instead of maybe a dozen bytes on the heap. For short lived connections, this may be a decent way to do it, but if you have connections that could live for a good duration, you could easily end up with many 8kb stacks laying around that aren't being used. >your coding life easier, IOCP basically mean that you can't use them >anywhere near as easily as intended. Keeping the current execution location >also saves you from storing the current state in a variable, and having to >choose the next bit of code to execute based on that. It's not entirely a So instead of having state information in an object on the heap, you have the saved instruction pointer and variables on the stack. Six in one hand, half dozen in the other. >bad way of doing it, but consider an SMTP conversation (outgoing): > > connect > read response > send HELO > read response > send MAIL > read response > send RCPT > ... > >This is basically a linear process. Breaking the code down into little >chunks doesn't make a huge amount of sense. With my method, the code path I can see your point, and not having to change existing code is a powerful argument, however for new code, I'd prefer to store a function pointer to the function for handling the next expected state, and each function is an easy to understand self contained piece, rather than a large block of code that does send/recv over and over. I think that way the code is more readable. >above would be virtually unchanged, all you do is fiddle with `read >response' and `send' to work as listed below and you get IOCP without the >extra coding hassle. The other important driving factor behind this is I >have a fair bit of legacy code that I want to convert to use IOCP. If I >only have to change a few functions, then I'm much happier than if I have to >rework the whole thing! The main other point is that my method, although it >seems a bit of a fiddle at first instance, actually adds no more weight than >keeping track of all this yourself. It's just that the data for the >connection is stored on the stack, not in a class. True... so for ease of porting, this is a clear win, but for readability, I prefer an OOP approach. >Just on the subject of IOCP they do seem to be a total hack (`set the low >bit of the event handle in the overlapped structure to 1 to prevent IOCP Huh? >notification' is my favourite bit). What is it that means that threads have >so much weight in NT anyway? Each thread has a 12kb kernel mode stack, as well as several other structures that the kernel has to keep track of, adding to the memory footprint. Then the user mode stack gets added in. >Nice FTP server by the way! I managed to get the source code out of the >.bz2 file you sent, but not the support libraries - I would definitely be >interested in seeing the whole thing! Thanks. >Thanks, > >Mark ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Mark W. <ma...@np...> - 2001-09-25 01:24:16
|
Fibers are just a stack and register context that you can switch out on
demand. They are very lightweight self-scheduled threads. They therefore
have ideal properties for sitting with IOCP. The OnRecv and OnSend
functions require you to keep track of the current state of a connection,
and make only very light use of the stack. IMO a stack is a pretty
reasonable place to keep all of this data - having to store it yourself in a
connection state structure or class is a pain. Stacks were designed to make
your coding life easier, IOCP basically mean that you can't use them
anywhere near as easily as intended. Keeping the current execution location
also saves you from storing the current state in a variable, and having to
choose the next bit of code to execute based on that. It's not entirely a
bad way of doing it, but consider an SMTP conversation (outgoing):
connect
read response
send HELO
read response
send MAIL
read response
send RCPT
...
This is basically a linear process. Breaking the code down into little
chunks doesn't make a huge amount of sense. With my method, the code path
above would be virtually unchanged, all you do is fiddle with `read
response' and `send' to work as listed below and you get IOCP without the
extra coding hassle. The other important driving factor behind this is I
have a fair bit of legacy code that I want to convert to use IOCP. If I
only have to change a few functions, then I'm much happier than if I have to
rework the whole thing! The main other point is that my method, although it
seems a bit of a fiddle at first instance, actually adds no more weight than
keeping track of all this yourself. It's just that the data for the
connection is stored on the stack, not in a class.
Just on the subject of IOCP they do seem to be a total hack (`set the low
bit of the event handle in the overlapped structure to 1 to prevent IOCP
notification' is my favourite bit). What is it that means that threads have
so much weight in NT anyway?
Nice FTP server by the way! I managed to get the source code out of the
.bz2 file you sent, but not the support libraries - I would definitely be
interested in seeing the whole thing!
Thanks,
Mark
> -----Original Message-----
> From: Phillip Susi [mailto:ps...@cf...]
> Sent: 25 September 2001 01:59
> To: ros...@re...
> Subject: [ros-kernel] Re: IOCP and fibers - not strictly related to ROS
>
>
> I don't know a whole lot about fibers, but I think they are
> implemented on
> top of threads, so you should not be using one per client. If you are
> using IOCPs and a worker thread pool, why do you want to mess with
> fibers? I wrote an ftp server a few years ago using IOCPs that I
> think is
> a good example of how to use them. I'm going to put it on a web site in
> the next few days as I know several others on the list are interested in
> it. Anyhow, why do you want to use fibers? I defined a socket abstract
> base class, and used a pointer to it as the completion key, and derive
> classes from it to handle control and data connections. The GQCS loop
> casts the key to a socket pointer, and calls a virtual OnRecv()
> or OnSend()
> method. I also make use of zero copy overlapped IO requests and memory
> mapped files to reach performance levels of TransmitFile().
> Specifically,
> on a dual PII-233 I was able to saturate 2 ethernet nics, one at 10,000
> KB/s, the other at 5,500 KB/s with around 50% of the cpu.
>
> At 01:44 AM 9/25/2001 +0100, you wrote:
> >Sorry for the OT post, but you guys seem to have a good overall
> sense of the
> >internals of NT and I wondered if you might be able to help with
> development
> >of an idea I've got.
> >
> >My idea, in outline, is to facilate the use of IOCP by combining
> them with
> >fibers. Effectively what you do is this, using a sockets server as an
> >example:
> >
> >* Create a single IOCP and a thread pool as per usual.
> >* For each client, create a fiber. The fiber will run as the client
> >connection, and you can then just treat this as normal piece of
> linear code.
> >If you are reasonably careful then you can get away with a teeny
> stack for
> >this (say a couple of pages). You associate the socket handle
> with the IOCP
> >using the fiber as the key:
> > CreateIoCompletionPort((HANDLE)client_socket, g_CompletionPort,
> >(DWORD)GetCurrentFiber(), NUM_THREADS);
> >
> >* Process the client connection. When you need to do some I/O you do
> >something like:
> >
> > BOOL bRet = ReadFile(...)
> > if (!bRet) {
> > DWORD dwError = GetLastError();
> > if (dwError == ERROR_IO_PENDING) {
> > GetQueuedCompletionStatus(...)
> > SwitchToFiber(CompletionKey);
> > }
> > }
> >
> >OK, so now this *nearly* works. The problem is that after calling
> >ReadFile() I/O can complete immediately. In this case, another
> thread may
> >pick up the completion from GQCS and switch to the fiber BEFORE the first
> >thread has finished executing GetLastError() and SwitchToFiber. In this
> >case, the fiber restart address is bound to wrong. Now I don't
> have an easy
> >solution to this. Then one that I have come up with is somewhat nasty:
> >
> >Before calling ReadFile, "fiddle" the fiber restart address to
> point to just
> >after the !bRet code block and store interesting registers. In
> other words,
> >set the correct fiber state for a restart BEFORE calling
> ReadFile. Now we
> >can't use the stack after calling ReadFile because the fiber
> switch from the
> >completed IO on a different thread will have started to use the
> same stack
> >again. To get around this, immediately after if (!bRet) { we switch to a
> >small, safe stack. You only need one of these stacks per worker
> thread, so
> >this is an acceptable overhead. The stack pointers can be saved
> in TLS. We
> >then continue with the GetLastError(), ... code. We also can't call
> >SwitchToFiber as this will save the current fiber state, destroying the
> >carefully set up restart information. So what we do is just a
> fiber state
> >restore, without a save. So I have split the SwitchToFiber into
> two halves;
> >firstly a save and secondly a restore, with intervening code.
> This neatly
> >sidesteps my restart problem, but is just possibly a bit too low level!
> >
> >I can't see a problem with this method, but it certainly isn't
> supported -
> >this kind of meddling with fibers just isn't catered for in the API.
> >However, looking at the idea and not the implementation, you get the
> >scalability of IOCP without paying any extra from what you would
> have done
> >by writing the code in a stateful sense in the first place.
> Fiber switches
> >don't even involve a kernel call, and end up as being 20-30
> instructions at
> >most. I've already got my own fiber switching code that I wrote a while
> >back (I was doing some work with VenturCom's real-time extensions to NT -
> >they implemented a new subsystem to do this that basically
> schedules its own
> >threads ahead of anyone else's in response to device or timer
> interrupts -
> >I'm not clear on all the details here, but it works very well -
> and for my
> >work, I needed fibers, which weren't implemented in their
> subsystem), so I
> >am planning on using that to handle the switches.
> >
> >My questions are:
> >
> >(1) Can anyone see a problem with this?
> >(2) Is there any *portable* (i.e. API based way) of doing this?
> >(3) If not, is there any portable way of switching
> stacks/exception records
> >in NT other than fibers? Basically that's all I need - a portable way of
> >swapping stacks and exception records around. I can take care of the
> >details of save/restore registers without getting the OS
> involved, as this
> >is just normal application level code.
> >
> >Thanks in advance,
> >
> >Mark
>
> ====================================================
> = 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: Phillip S. <ps...@cf...> - 2001-09-25 01:08:01
|
I don't know a whole lot about fibers, but I think they are implemented on
top of threads, so you should not be using one per client. If you are
using IOCPs and a worker thread pool, why do you want to mess with
fibers? I wrote an ftp server a few years ago using IOCPs that I think is
a good example of how to use them. I'm going to put it on a web site in
the next few days as I know several others on the list are interested in
it. Anyhow, why do you want to use fibers? I defined a socket abstract
base class, and used a pointer to it as the completion key, and derive
classes from it to handle control and data connections. The GQCS loop
casts the key to a socket pointer, and calls a virtual OnRecv() or OnSend()
method. I also make use of zero copy overlapped IO requests and memory
mapped files to reach performance levels of TransmitFile(). Specifically,
on a dual PII-233 I was able to saturate 2 ethernet nics, one at 10,000
KB/s, the other at 5,500 KB/s with around 50% of the cpu.
At 01:44 AM 9/25/2001 +0100, you wrote:
>Sorry for the OT post, but you guys seem to have a good overall sense of the
>internals of NT and I wondered if you might be able to help with development
>of an idea I've got.
>
>My idea, in outline, is to facilate the use of IOCP by combining them with
>fibers. Effectively what you do is this, using a sockets server as an
>example:
>
>* Create a single IOCP and a thread pool as per usual.
>* For each client, create a fiber. The fiber will run as the client
>connection, and you can then just treat this as normal piece of linear code.
>If you are reasonably careful then you can get away with a teeny stack for
>this (say a couple of pages). You associate the socket handle with the IOCP
>using the fiber as the key:
> CreateIoCompletionPort((HANDLE)client_socket, g_CompletionPort,
>(DWORD)GetCurrentFiber(), NUM_THREADS);
>
>* Process the client connection. When you need to do some I/O you do
>something like:
>
> BOOL bRet = ReadFile(...)
> if (!bRet) {
> DWORD dwError = GetLastError();
> if (dwError == ERROR_IO_PENDING) {
> GetQueuedCompletionStatus(...)
> SwitchToFiber(CompletionKey);
> }
> }
>
>OK, so now this *nearly* works. The problem is that after calling
>ReadFile() I/O can complete immediately. In this case, another thread may
>pick up the completion from GQCS and switch to the fiber BEFORE the first
>thread has finished executing GetLastError() and SwitchToFiber. In this
>case, the fiber restart address is bound to wrong. Now I don't have an easy
>solution to this. Then one that I have come up with is somewhat nasty:
>
>Before calling ReadFile, "fiddle" the fiber restart address to point to just
>after the !bRet code block and store interesting registers. In other words,
>set the correct fiber state for a restart BEFORE calling ReadFile. Now we
>can't use the stack after calling ReadFile because the fiber switch from the
>completed IO on a different thread will have started to use the same stack
>again. To get around this, immediately after if (!bRet) { we switch to a
>small, safe stack. You only need one of these stacks per worker thread, so
>this is an acceptable overhead. The stack pointers can be saved in TLS. We
>then continue with the GetLastError(), ... code. We also can't call
>SwitchToFiber as this will save the current fiber state, destroying the
>carefully set up restart information. So what we do is just a fiber state
>restore, without a save. So I have split the SwitchToFiber into two halves;
>firstly a save and secondly a restore, with intervening code. This neatly
>sidesteps my restart problem, but is just possibly a bit too low level!
>
>I can't see a problem with this method, but it certainly isn't supported -
>this kind of meddling with fibers just isn't catered for in the API.
>However, looking at the idea and not the implementation, you get the
>scalability of IOCP without paying any extra from what you would have done
>by writing the code in a stateful sense in the first place. Fiber switches
>don't even involve a kernel call, and end up as being 20-30 instructions at
>most. I've already got my own fiber switching code that I wrote a while
>back (I was doing some work with VenturCom's real-time extensions to NT -
>they implemented a new subsystem to do this that basically schedules its own
>threads ahead of anyone else's in response to device or timer interrupts -
>I'm not clear on all the details here, but it works very well - and for my
>work, I needed fibers, which weren't implemented in their subsystem), so I
>am planning on using that to handle the switches.
>
>My questions are:
>
>(1) Can anyone see a problem with this?
>(2) Is there any *portable* (i.e. API based way) of doing this?
>(3) If not, is there any portable way of switching stacks/exception records
>in NT other than fibers? Basically that's all I need - a portable way of
>swapping stacks and exception records around. I can take care of the
>details of save/restore registers without getting the OS involved, as this
>is just normal application level code.
>
>Thanks in advance,
>
>Mark
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: Mark W. <ma...@np...> - 2001-09-25 00:47:00
|
Sorry for the OT post, but you guys seem to have a good overall sense of the
internals of NT and I wondered if you might be able to help with development
of an idea I've got.
My idea, in outline, is to facilate the use of IOCP by combining them with
fibers. Effectively what you do is this, using a sockets server as an
example:
* Create a single IOCP and a thread pool as per usual.
* For each client, create a fiber. The fiber will run as the client
connection, and you can then just treat this as normal piece of linear code.
If you are reasonably careful then you can get away with a teeny stack for
this (say a couple of pages). You associate the socket handle with the IOCP
using the fiber as the key:
CreateIoCompletionPort((HANDLE)client_socket, g_CompletionPort,
(DWORD)GetCurrentFiber(), NUM_THREADS);
* Process the client connection. When you need to do some I/O you do
something like:
BOOL bRet = ReadFile(...)
if (!bRet) {
DWORD dwError = GetLastError();
if (dwError == ERROR_IO_PENDING) {
GetQueuedCompletionStatus(...)
SwitchToFiber(CompletionKey);
}
}
OK, so now this *nearly* works. The problem is that after calling
ReadFile() I/O can complete immediately. In this case, another thread may
pick up the completion from GQCS and switch to the fiber BEFORE the first
thread has finished executing GetLastError() and SwitchToFiber. In this
case, the fiber restart address is bound to wrong. Now I don't have an easy
solution to this. Then one that I have come up with is somewhat nasty:
Before calling ReadFile, "fiddle" the fiber restart address to point to just
after the !bRet code block and store interesting registers. In other words,
set the correct fiber state for a restart BEFORE calling ReadFile. Now we
can't use the stack after calling ReadFile because the fiber switch from the
completed IO on a different thread will have started to use the same stack
again. To get around this, immediately after if (!bRet) { we switch to a
small, safe stack. You only need one of these stacks per worker thread, so
this is an acceptable overhead. The stack pointers can be saved in TLS. We
then continue with the GetLastError(), ... code. We also can't call
SwitchToFiber as this will save the current fiber state, destroying the
carefully set up restart information. So what we do is just a fiber state
restore, without a save. So I have split the SwitchToFiber into two halves;
firstly a save and secondly a restore, with intervening code. This neatly
sidesteps my restart problem, but is just possibly a bit too low level!
I can't see a problem with this method, but it certainly isn't supported -
this kind of meddling with fibers just isn't catered for in the API.
However, looking at the idea and not the implementation, you get the
scalability of IOCP without paying any extra from what you would have done
by writing the code in a stateful sense in the first place. Fiber switches
don't even involve a kernel call, and end up as being 20-30 instructions at
most. I've already got my own fiber switching code that I wrote a while
back (I was doing some work with VenturCom's real-time extensions to NT -
they implemented a new subsystem to do this that basically schedules its own
threads ahead of anyone else's in response to device or timer interrupts -
I'm not clear on all the details here, but it works very well - and for my
work, I needed fibers, which weren't implemented in their subsystem), so I
am planning on using that to handle the switches.
My questions are:
(1) Can anyone see a problem with this?
(2) Is there any *portable* (i.e. API based way) of doing this?
(3) If not, is there any portable way of switching stacks/exception records
in NT other than fibers? Basically that's all I need - a portable way of
swapping stacks and exception records around. I can take care of the
details of save/restore registers without getting the OS involved, as this
is just normal application level code.
Thanks in advance,
Mark
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: Phillip S. <ps...@cf...> - 2001-09-25 00:27:24
|
The link to nasm on the tools section of www.reactos.com is broken. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-09-25 00:21:53
|
We have our own win32 api headers and libs in reactos, so why do we still use the mingw win32 api? I think we should modify the makefiles to the headers and libs in reactos, instead of the system includes and libs, which requires that the mingw win32 api is installed. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-09-25 00:16:57
|
Could whoever signed up sorgeforge to the list disable moderation? I'm tired of these annoying messages, and I don't think that anyone wants to moderate it anyhow. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-09-25 00:13:34
|
Yes, clean checkout from cvs. I just figured out the problem though: it seems that make tries to run sh as the shell first, and then tries %COMSPEC% only if executing sh fails. I have sh because I have cygwin installed, and sh didn't like the \. This is kind of a problem for me because make requires sh to use the -j switch to spawn multiple processes and take advantage of SMP. Maybe I'll have to talk to the mingw guys about this. At 12:24 PM 9/24/2001 +0200, you wrote: >The commmand line look okay. Is your rules.mak like the current CVS >version? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-09-25 00:04:00
|
Any effort to port a unix filesystem to reactos would not fit semantically into the OS right. Specifically, even a unix with ACLs does not fit into the NT security model. Unix ACLs still only allow specifying read/write/execute permissions to be set on security entities, and I doubt that the security identifier is more than just a 32 bit integer, which is not enough to represent an NT SID, which is typically 128 bits ( though it can be of any length ). NTFS stores arbitrary security descriptors which allows it to hold current and future NT security descriptors. NT security descriptors are extensible, and MS has already added capabilities to specify how a given ACE is to be applied: to the directory, files in the directory, children directories, files in those directories, or all of the above. In theory it is possible to extend security descriptors to use mandatory access control, which is to specify to whom what permissions may be granted by those with rights to modify the ACL. An inherited rights mask like netware has is also possible. I'd also like to have deleted file salvage/purge support like netware. In short, a unix filesystem won't port well to reactos due to differing semantics. NTFS really is a very powerful and highly extensible filesystem, whose capabilities are not fully exploited by Microsoft's current OSes. I'd like to have reactos exploit more of these capabilities, though with win2k it seems that MS is beginning to exploit some of them with things like reparse points, which allow EFS and offline files. Named data streams are also used to store extra information on the file properties tab in explorer for the author of the file, subject, etc. NTFS can even index files by such extended information instead of just the name of the file, as is currently done. NTFS performance could also be much better than MIcrosoft's implementations: performance problems ( such as being prone to fragmentation ) are due to the driver, not the on disk filesystem. At 09:27 AM 9/24/2001 -0700, you wrote: >SGI's XFS filesystem is available as an Open-Source project (GPL) for >Linux. How difficult is it to port a Linux filesystem driver to >ReactOS? > >This filesystem has journaling capabilities, and may be of benefit to >many users. I believe it has ACL support, as well. > >Thus, it may be worth consideration for a future project within >ReactOS, if it can be ported easily enough. > >===== >======= >Frank D. Engel, Jr. >Please note my new address: fd...@ya... ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Frank D. E. Jr. <fd...@ya...> - 2001-09-24 18:12:14
|
NTFS requires these already; the mechanisms should be in place on time for NTFS support, so they could probably be used for XFS as well. --- David Welch <we...@cw...> wrote: > On Mon, Sep 24, 2001 at 06:56:22PM +0200, Casper Hornstrup wrote: > > > > If the file system driver (FSD) is designed properly, it should not > be too > > difficult to port to ReactOS. FSDs can be split in three parts - > the veneer, > > the core, and the disk driver interface layer. The veneer is the > most OS > > specific layer. The core layer can be designed to be mostly OS > independant > > and is typically the largest part of the FSD. The core layer > manages the > > on-disk data structures. The disk driver interface layer interacts > with the > > OS drivers for disk storage and network devices. > > > > In short, if written correctly, only the veneer and the disk driver > interface > > layer would need to be rewritten to port it to ReactOS. > > > If XFS is a journalling filesystem then it may need special > mechanisms to > allow it to specify the order in which filesystem metadata is written > to > disk. > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > ===== ======= Frank D. Engel, Jr. Please note my new address: fd...@ya... __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: David W. <we...@cw...> - 2001-09-24 18:04:49
|
On Mon, Sep 24, 2001 at 06:56:22PM +0200, Casper Hornstrup wrote: > > If the file system driver (FSD) is designed properly, it should not be too > difficult to port to ReactOS. FSDs can be split in three parts - the veneer, > the core, and the disk driver interface layer. The veneer is the most OS > specific layer. The core layer can be designed to be mostly OS independant > and is typically the largest part of the FSD. The core layer manages the > on-disk data structures. The disk driver interface layer interacts with the > OS drivers for disk storage and network devices. > > In short, if written correctly, only the veneer and the disk driver interface > layer would need to be rewritten to port it to ReactOS. > If XFS is a journalling filesystem then it may need special mechanisms to allow it to specify the order in which filesystem metadata is written to disk. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Christopher K. <chr...@ko...> - 2001-09-24 17:12:24
|
> SGI's XFS filesystem is available as an Open-Source project (GPL) for > Linux. How difficult is it to port a Linux filesystem driver to > ReactOS? I've seen some performance test of XFS against FAT, FAT32, ext2, etc. XFS is a very performant filesystem! It rulez! Chris ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Casper H. <ch...@us...> - 2001-09-24 16:59:26
|
On Monday 24 September 2001 18:27, Frank D. Engel, Jr. wrote: > SGI's XFS filesystem is available as an Open-Source project (GPL) for > Linux. How difficult is it to port a Linux filesystem driver to > ReactOS? > > This filesystem has journaling capabilities, and may be of benefit to > many users. I believe it has ACL support, as well. > > Thus, it may be worth consideration for a future project within > ReactOS, if it can be ported easily enough. If the file system driver (FSD) is designed properly, it should not be too difficult to port to ReactOS. FSDs can be split in three parts - the veneer, the core, and the disk driver interface layer. The veneer is the most OS specific layer. The core layer can be designed to be mostly OS independant and is typically the largest part of the FSD. The core layer manages the on-disk data structures. The disk driver interface layer interacts with the OS drivers for disk storage and network devices. In short, if written correctly, only the veneer and the disk driver interface layer would need to be rewritten to port it to ReactOS. - Casper ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Frank D. E. Jr. <fd...@ya...> - 2001-09-24 16:29:24
|
SGI's XFS filesystem is available as an Open-Source project (GPL) for Linux. How difficult is it to port a Linux filesystem driver to ReactOS? This filesystem has journaling capabilities, and may be of benefit to many users. I believe it has ACL support, as well. Thus, it may be worth consideration for a future project within ReactOS, if it can be ported easily enough. ===== ======= Frank D. Engel, Jr. Please note my new address: fd...@ya... __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Casper H. <ch...@us...> - 2001-09-24 10:27:11
|
> -----Original Message----- > From: Guido de Jong [mailto:gui...@ch...] > Sent: 24. september 2001 08:09 > To: ros...@re... > Subject: [ros-kernel] Re: Compile failure > > > On Monday 24 September 2001 04:54, Phillip Susi wrote: > > Building isn't working for me, so I was wondering if/how it > is working > > for everyone else on windows. It looks like the problem is > that the > > path to the depends.exe program uses / as the path > separator instead > > of \, and the / gets thrown out somewhere. I'm using all of the > > utilities from the sourceforge site. Here is the error: > > > > ../tools/depend.mk:10: rtl/.memcmp.d: No such file or directory > > ../tools/depend.mk:10: rtl/.capture.d: No such file or directory > > make[1]: Entering directory `C:/source/reactos/ntoskrnl' > > gcc -I./include -pipe -m386 -I./include -I./include > -D__NTOSKRNL__ -g > > -Wall -We rror -I../include -pipe -m386 -M rtl/capture.c | > > ..\tools\depends.exe rtl rtl/.c > > apture.d > > ..toolsdepends.exe: not found > > \program > files\mingw\bin\..\lib\gcc-lib\i386-mingw32\2.95.3-6\cpp0.exe: I/O > > erro > > r on output > > make[1]: *** [rtl/.capture.d] Error 127 > > make[1]: Leaving directory `C:/source/reactos/ntoskrnl' > > make: *** [ntoskrnl] Error 2 The commmand line look okay. Is your rules.mak like the current CVS version? > > This works fine for me and I use the same version of mingw. > The latest SEH > implemenation will not compile, though: > > except/exhand2.c:4: conflicting types for `ExceptionContinueExecution' > ../../include/ntos/except.h:13: previous declaration of > `ExceptionContinueExecution' > except/exhand2.c:5: conflicting types for `ExceptionContinueSearch' > ../../include/ntos/except.h:14: previous declaration of > `ExceptionContinueSearch' > except/exhand2.c:6: conflicting types for `ExceptionNestedException' > ../../include/ntos/except.h:15: previous declaration of > `ExceptionNestedException' > except/exhand2.c:8: conflicting types for `ExceptionCollidedUnwind' > ../../include/ntos/except.h:16: previous declaration of > `ExceptionCollidedUnwind' > except/exhand2.c:8: redefinition of `EXCEPTION_DISPOSITION' > ../../include/ntos/except.h:18: `EXCEPTION_DISPOSITION' > previously declared > here > make[1]: *** [except/exhand2.o] Error 1 > C:\GCC\BIN\MAKE.EXE: *** [crtdll] Error 2 > > Guido Sorry. A fix is in CVS now. - Casper ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Guido de J. <gui...@ch...> - 2001-09-24 06:06:56
|
On Monday 24 September 2001 04:54, Phillip Susi wrote: > Building isn't working for me, so I was wondering if/how it is working for > everyone else on windows. It looks like the problem is that the path to > the depends.exe program uses / as the path separator instead of \, and the > / gets thrown out somewhere. I'm using all of the utilities from the > sourceforge site. Here is the error: > > ../tools/depend.mk:10: rtl/.memcmp.d: No such file or directory > ../tools/depend.mk:10: rtl/.capture.d: No such file or directory > make[1]: Entering directory `C:/source/reactos/ntoskrnl' > gcc -I./include -pipe -m386 -I./include -I./include -D__NTOSKRNL__ -g > -Wall -We > rror -I../include -pipe -m386 -M rtl/capture.c | ..\tools\depends.exe rtl > rtl/.c > apture.d > ..toolsdepends.exe: not found > \program files\mingw\bin\..\lib\gcc-lib\i386-mingw32\2.95.3-6\cpp0.exe: I/O > erro > r on output > make[1]: *** [rtl/.capture.d] Error 127 > make[1]: Leaving directory `C:/source/reactos/ntoskrnl' > make: *** [ntoskrnl] Error 2 This works fine for me and I use the same version of mingw. The latest SEH implemenation will not compile, though: except/exhand2.c:4: conflicting types for `ExceptionContinueExecution' ../../include/ntos/except.h:13: previous declaration of `ExceptionContinueExecution' except/exhand2.c:5: conflicting types for `ExceptionContinueSearch' ../../include/ntos/except.h:14: previous declaration of `ExceptionContinueSearch' except/exhand2.c:6: conflicting types for `ExceptionNestedException' ../../include/ntos/except.h:15: previous declaration of `ExceptionNestedException' except/exhand2.c:8: conflicting types for `ExceptionCollidedUnwind' ../../include/ntos/except.h:16: previous declaration of `ExceptionCollidedUnwind' except/exhand2.c:8: redefinition of `EXCEPTION_DISPOSITION' ../../include/ntos/except.h:18: `EXCEPTION_DISPOSITION' previously declared here make[1]: *** [except/exhand2.o] Error 1 C:\GCC\BIN\MAKE.EXE: *** [crtdll] Error 2 Guido ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-09-24 02:58:22
|
Building isn't working for me, so I was wondering if/how it is working for everyone else on windows. It looks like the problem is that the path to the depends.exe program uses / as the path separator instead of \, and the / gets thrown out somewhere. I'm using all of the utilities from the sourceforge site. Here is the error: ../tools/depend.mk:10: rtl/.memcmp.d: No such file or directory ../tools/depend.mk:10: rtl/.capture.d: No such file or directory make[1]: Entering directory `C:/source/reactos/ntoskrnl' gcc -I./include -pipe -m386 -I./include -I./include -D__NTOSKRNL__ -g -Wall -We rror -I../include -pipe -m386 -M rtl/capture.c | ..\tools\depends.exe rtl rtl/.c apture.d ..toolsdepends.exe: not found \program files\mingw\bin\..\lib\gcc-lib\i386-mingw32\2.95.3-6\cpp0.exe: I/O erro r on output make[1]: *** [rtl/.capture.d] Error 127 make[1]: Leaving directory `C:/source/reactos/ntoskrnl' make: *** [ntoskrnl] Error 2 ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: David W. <we...@cw...> - 2001-09-23 21:05:53
|
On Sat, Sep 22, 2001 at 05:00:40PM -0700, Jack (Butch) Griffin wrote: > I include a fix for this which I implemented in NtAllocateVirtualMemory(). > If this semantic is not desired in this function, it can be moved back out > to VirtualAllocEx(). > Thanks for your report; could you resend the proposed fix as a patch in -u format, thanks. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jack \(Butch\) G. <bu...@qw...> - 2001-09-23 00:00:24
|
I was playing with virtual alloc today and noticed slightly different
behavior between Windows 2000 and Reactos. Basically if you call
VirtualAlloc() with a NULL pointer and the MEM_COMMIT flag, the function
fails. On windows 2000, this acts just like you had done a MEM_RESERVE to
reserve the memory, followed by a call again with the MEM_COMMIT flag set.
This specific form of the call (e.g. VirtualAlloc(NULL, size, MEM_COMMIT,
PAGE_READWRITE) is used in the microsoft CRT in the functions that implement
malloc(). This can keep Microsoft compiled applications from working in
Reactos. Not sure if this is desired or not.
I include a fix for this which I implemented in NtAllocateVirtualMemory().
If this semantic is not desired in this function, it can be moved back out
to VirtualAllocEx().
Thanks
Jack (Butch) Griffin.
Fix for this ( new version of NtAllocateVirtualMemory)
--------------------------------------------------------
NTSTATUS STDCALL
NtAllocateVirtualMemory(IN HANDLE ProcessHandle,
IN OUT PVOID* UBaseAddress,
IN ULONG ZeroBits,
IN OUT PULONG URegionSize,
IN ULONG AllocationType,
IN ULONG Protect)
/*
* FUNCTION: Allocates a block of virtual memory in the process address
space
* ARGUMENTS:
* ProcessHandle = The handle of the process which owns the virtual
memory
* BaseAddress = A pointer to the virtual memory allocated. If you
* supply a non zero value the system will try to
* allocate the memory at the address supplied. It
round
* it down to a multiple of the page size.
* ZeroBits = (OPTIONAL) You can specify the number of high order bits
* that must be zero, ensuring that the memory will be
* allocated at a address below a certain value.
* RegionSize = The number of bytes to allocate
* AllocationType = Indicates the type of virtual memory you like to
* allocated, can be a combination of MEM_COMMIT,
* MEM_RESERVE, MEM_RESET, MEM_TOP_DOWN.
* Protect = Indicates the protection type of the pages allocated, can
be
* a combination of PAGE_READONLY, PAGE_READWRITE,
* PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, PAGE_GUARD,
* PAGE_NOACCESS
* REMARKS:
* This function maps to the win32 VirtualAllocEx. Virtual memory is
* process based so the protocol starts with a ProcessHandle. I
* splitted the functionality of obtaining the actual address and
* specifying the start address in two parameters ( BaseAddress and
* StartAddress ) The NumberOfBytesAllocated specify the range and the
* AllocationType and ProctectionType map to the other two parameters.
* RETURNS: Status
*/
{
PEPROCESS Process;
MEMORY_AREA* MemoryArea;
ULONG Type;
NTSTATUS Status;
PMADDRESS_SPACE AddressSpace;
PMM_SEGMENT Segment;
PVOID BaseAddress;
ULONG RegionSize;
PVOID PBaseAddress;
ULONG PRegionSize;
DPRINT("NtAllocateVirtualMemory(*UBaseAddress %x, "
"ZeroBits %d, *URegionSize %x, AllocationType %x, Protect %x)\n",
*UBaseAddress,ZeroBits,*URegionSize,AllocationType,
Protect);
/*
* Check the validity of the parameters
*/
if ((Protect & PAGE_FLAGS_VALID_FROM_USER_MODE) != Protect)
{
return(STATUS_INVALID_PAGE_PROTECTION);
}
if ((AllocationType & (MEM_COMMIT | MEM_RESERVE)) == 0)
{
return(STATUS_INVALID_PARAMETER);
}
if (((AllocationType & (MEM_COMMIT | MEM_RESERVE)) == MEM_COMMIT) &&
(*UBaseAddress == 0))
{
NTSTATUS status ;
status = NtAllocateVirtualMemory(ProcessHandle,
UBaseAddress,
ZeroBits,
URegionSize,
MEM_RESERVE,
Protect) ;
if (!NT_SUCCESS(status))
return status;
status = NtAllocateVirtualMemory(ProcessHandle,
UBaseAddress,
ZeroBits,
URegionSize,
MEM_COMMIT,
Protect) ;
if (!NT_SUCCESS(status))
return status ;
return STATUS_SUCCESS ;
}
PBaseAddress = *UBaseAddress;
PRegionSize = *URegionSize;
BaseAddress = (PVOID)PAGE_ROUND_DOWN(PBaseAddress);
RegionSize = PAGE_ROUND_UP(PBaseAddress + PRegionSize) -
PAGE_ROUND_DOWN(PBaseAddress);
Status = ObReferenceObjectByHandle(ProcessHandle,
PROCESS_VM_OPERATION,
NULL,
UserMode,
(PVOID*)(&Process),
NULL);
if (!NT_SUCCESS(Status))
{
DPRINT("NtAllocateVirtualMemory() = %x\n",Status);
return(Status);
}
Type = (AllocationType & MEM_COMMIT) ? MEM_COMMIT : MEM_RESERVE;
DPRINT("Type %x\n", Type);
AddressSpace = &Process->AddressSpace;
MmLockAddressSpace(AddressSpace);
if ((PBaseAddress != 0) &&
((AllocationType & (MEM_COMMIT | MEM_RESERVE)) == MEM_COMMIT))
{
MemoryArea = MmOpenMemoryAreaByAddress(&Process->AddressSpace,
BaseAddress);
if (MemoryArea != NULL &&
MemoryArea->Type == MEMORY_AREA_VIRTUAL_MEMORY &&
MemoryArea->Length >= RegionSize)
{
Status = MmComplexVirtualMemoryOperation(AddressSpace,
MemoryArea,
BaseAddress,
RegionSize,
Type,
Protect);
/* FIXME: Reserve/dereserve swap pages */
MmUnlockAddressSpace(AddressSpace);
ObDereferenceObject(Process);
DPRINT("NtAllocateVirtualMemory() = %x\n",Status);
return(Status);
}
else if (MemoryArea != NULL)
{
MmUnlockAddressSpace(AddressSpace);
ObDereferenceObject(Process);
return(STATUS_UNSUCCESSFUL);
}
}
Segment = ExAllocatePoolWithTag(NonPagedPool,
sizeof(MM_SEGMENT),
TAG_MM_SEGMENT);
if (Segment == NULL)
{
MmUnlockAddressSpace(AddressSpace);
ObDereferenceObject(Process);
return(STATUS_UNSUCCESSFUL);
}
Status = MmCreateMemoryArea(Process,
&Process->AddressSpace,
MEMORY_AREA_VIRTUAL_MEMORY,
&BaseAddress,
RegionSize,
Protect,
&MemoryArea,
PBaseAddress != 0);
if (!NT_SUCCESS(Status))
{
MmUnlockAddressSpace(AddressSpace);
ObDereferenceObject(Process);
DPRINT("NtAllocateVirtualMemory() = %x\n",Status);
return(Status);
}
InitializeListHead(&MemoryArea->Data.VirtualMemoryData.SegmentListHead);
Segment->Type = Type;
Segment->Protect = Protect;
Segment->Length = RegionSize;
InsertTailList(&MemoryArea->Data.VirtualMemoryData.SegmentListHead,
&Segment->SegmentListEntry);
if ((AllocationType & MEM_COMMIT) &&
((Protect & PAGE_READWRITE) ||
(Protect & PAGE_EXECUTE_READWRITE)))
{
MmReserveSwapPages(RegionSize);
}
*UBaseAddress = BaseAddress;
*URegionSize = RegionSize;
DPRINT("*UBaseAddress %x *URegionSize %x\n", BaseAddress, RegionSize);
MmUnlockAddressSpace(AddressSpace);
ObDereferenceObject(Process);
return(STATUS_SUCCESS);
}
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: KJK::Hyperion <no...@li...> - 2001-09-22 23:18:02
|
At 17.08 19/09/2001 -0400, you wrote: >sleep.exe from the mingw sh utils seems to be broken even under windows. try the shell utils from this package: http://unxutils.sourceforge.net/ sleep, in particular, works, at least on Windows NT 5 (tried just yesterday) ==================================================== = 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.
