In IoWritePartitionTableEx(), don't return STATUS_SUCCESS when we cannot write GPT to higher partitions count than space available; return STATUS_INVALID_PARAMETER.
svn path=/trunk/; revision=73114
For now, disable broken code in FstubReadPartitionTableEFI(). In its current state, it wrongly assumes backup GPT is broken and thus attempts to fix main GPT (?!).
Furthermore, it appears Windows 2K3 doesn't perform such checks, nor such GPT rewritings in FstubReadPartitionTableEFI().
CORE-12261
svn path=/trunk/; revision=73112
- Finally fully implement FstubVerifyPartitionTableEFI(). It is capable of fixing a GPT disk.
- Fix implementation of FstubReadHeaderEFI() (which returns a pointer to the header). Fixed all the other functions accordingly. Note that you have to be careful when using Disk->Buffer. You can easily read a buffer that doesn't contain your data anylonger.
- Fix implementation of FstubReadPartitionTableEFI(). It was improperly dealing with the backup table. Now, it will look for it and replace/recreate it if not found where expected.
- Fix implementation of FstubWriteEntryEFI(). The computation of memory placement was wrong, and thus it was missing partitions and causing corruption. Thank you checksums!
In case you format a disk with GPT using Linux (with GParted, for instance), don't be surprised if once started with ReactOS your GPT is modified, and especially its backup table moved. They don't have the same sector counts.
It was a nice way to tests whether ReactOS properly write GPT. Which it does now :-).
svn path=/trunk/; revision=60811
Fix string size to store GPT GUIDs.
This was causing a buffer overflow (with ending null char) and thus a stack corruption.
The side effect of the stack corruption was that the debug code (display) was looping
forever while attempting to read partition table making ntoskrnl unable to boot with
a machine where there's a GPT disk.
Kernel is now able again to handle GPT disks (and they can be used again in user-land).
This was magically hidding before r59923 or by disabling NDEBUG. Lovely Heisenbugs :-).
svn path=/trunk/; revision=60003
- Make MSVC analyzer happy by initializing the event before calling IoBuildDeviceIoControlRequest. Patch by Ivan Rodionov (overclocker at list dot ru).
CORE-7328 #resolve #comment Committed, thanks.
svn path=/trunk/; revision=59352
- Use tags when allocation and freeing memory and define them in tag.h
- Fix some wrongly used tags when freeing
- Our new memory manager doesn't check tags when ExFreePoolWithTag is used. It will be fixed after testing
svn path=/trunk/; revision=52043
Implemented FstubAdjustPartitionCount(), FstubConvertExtendedToLayout(), FstubCopyEntryEFI(), FstubCreateDiskMBR(), FstubCreateDiskEFI(), FstubCreateDiskRaw(), FstubDbgPrintSetPartitionEx(), FstubReadHeaderEFI(), FstubReadPartitionTableEFI(), FstubSetPartitionInformationEFI(), FstubVerifyPartitionTableEFI(), FstubWriteBootSectorEFI(), FstubWriteEntryEFI(), FstubWriteHeaderEFI(), FstubWritePartitionTableEFI(), FstubWritePartitionTableMBR(), FstubWriteSector()
Implemented IoCreateDisk(), IoGetBootDiskInformation(), IoReadDiskSignature(), IoSetPartitionInformationEx(), IoVerifyPartitionTable(), IoWritePartitionTableEx()
To sum up, this commit finishes FSTUB API implementation in the ReactOS kernel. This means one important thing: now ReactOS kernel knows about a bit about EFI and about GPT. No need to say that it's the first step into EFI support. But a lot more work is needed. Especially since the kernel is the only real entity in ReactOS to handle GPT. All the rest of the OS doesn't know anything about GPT.
A small note about FstubVerifyPartitionTableEFI(). This function is supposed to check whether a disk formated with GPT is valid, and if it's not, to fix it. First step is implemented. Second step isn't yet supported.
A general note about all that stuff: on GPT, backup table isn't properly handled for the moment, as ReactOS is experiencing disk geometry issues. That means it's not having the proper disk sectors count and then, can't find the backup table (which is located on last disk sector).
References:
http://www.intel.com/technology/efi/http://developer.apple.com/library/mac/#technotes/tn2006/tn2166.htmlhttp://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=blob;f=fs/partitions/efi.h;hb=HEADhttp://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=blob;f=fs/partitions/efi.c;hb=HEAD
svn path=/trunk/; revision=49212
Implemented FstubAllocateDiskInformation(), FstubDbgGuidToString(), FstubDbgPrintDriveLayoutEx(), FstubDbgPrintPartitionEx(), FstubDetectPartitionStyle(), FstubFreeDiskInformation(), FstubGetDiskGeometry(), FstubReadPartitionTableMBR(), FstubReadSector()
Stubbed FstubReadPartitionTableEFI()
This leads to a correct & working implementation of IoReadPartitionTableEx(). As this state, it only handles MBR partition tables as EFI/GPT as been stubbed out.
EFI/GPT support will come later.
svn path=/trunk/; revision=49130
- Create new /fstub directory in the kernel tree and move iomgr's xhal functions there.
- Delete disk.c entirely from iomgr.c and spread it across fstub.
- Entirely reimplement from scratch IoWritePartitionTable, IoReadPartitionTable, IoSetPartitionInformation, HalExamineMbr. Lots of bug fixes in terms of wrong assumptions and compatibility with weird partition tables.
- Fix prototype of IoAssignDriveLetters, but for now, keep the old code (xHalIoAssignDriveLetters) because this has not been rewritten yet.
- Move some functions to fstubex.c for future implementation, and some to volume.c. Move the HAL table to halstub.c
- Make use of the hal.h file commited earlier.
- Move IoAssignDriveLetters from halfuncs to iofuncs.h
- Implement missing functions in HAL (IoRead/Write/Set PartitionInfo) and make them call into the ntoskrnl exports.
svn path=/trunk/; revision=24737
