Re: IDE disk geometry
On Wed, 2005-09-21 at 00:57, Uwe Bonnes wrote: Our IOCTL handling is a mess. Seems like it has only been needed and implemented for CDs, so far. I had a patch that splitted out IOCTL code handling to separate, loadable dlls, but the patch went by unnoticed. Look for Mail from around July 10 Uniform SYS/VXD Handling x/6 In your case, when you did CreateFile(\\c:\), in file.c it would be noticed that a raw handle on the disk is needed and something like disk.sys would be loaded, where you would implement the needed IOCTL. That sounds great. I wonder why it didn't go through...? But that's a bit too much heavy lifting of the wine goblet for me to undertake! - mo
RE: IDE disk geometry
From: Vitaliy Margolen So all you need to do is to find where this information is stored on windows (it has to be somewhere in registry It's an IOCTL, so it is passed to the disk driver on Windows. Although it is possible that the driver caches the info in the registry, I don't think that's very likely (and it would be driver-dependent). That doesn't mean that Wine can't store the info where it pleases (e.g. in the registry). Ge van Geldorp.
Re: IDE disk geometry
Michael == Michael Ost [EMAIL PROTECTED] writes: Michael On Tue, 2005-09-20 at 18:22, Vitaliy Margolen wrote: Tuesday, September 20, 2005, 6:11:49 PM, Michael Ost wrote: Should I put my code in CDROM_DeviceIoControl? Or handle it in NtDeviceIoControlFile? Should I pass all other IoControlCodes except IOCTL_DISK_DRIVE_GET_GEOMETRY for a verifiable IDE drive on to the CDROM_... function? I don't it make any sense to create the whole new file to parse just one IOCTL. So you might just add it to the cdrom.c I think that might get accepted. Michael I don't think it was clear that the device in question is not a Michael CDROM, but a hard disk. Are IDE hard disks supposed to be Michael lumped in with CDROMs in the code? Our IOCTL handling is a mess. I had a patch that splitted out IOCTL code handling to separate, loadable dlls, but the patch went by unnoticed. Look for Mail from around July 10 Uniform SYS/VXD Handling x/6 In your case, when you did CreateFile(\\c:\), in file.c it would be noticed that a raw handle on the disk is needed and something like disk.sys would be loaded, where you would implement the needed IOCTL. ... Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
IDE disk geometry
Any suggestions for a good wineish way to implement an IOCTL_ call for
an IDE disk?
My winelib app is hosting a Windows DLL that is making an
IOCTL_DISK_DRIVE_GET_GEOMETRY call on an IDE hard disk. ntdll/file.c
NtDeviceIoControlFile is passing this off to ntdll/cdrom.c
CDROM_DeviceIoControl and, of course, since it is not a cdrom disk, that
fails.
I have some code that reads geometry information out of
/proc/ide/hd?/geometry that is working fine. But I am not sure how to
integrate it into ntdll.
Should I put my code in CDROM_DeviceIoControl? Or handle it in
NtDeviceIoControlFile? Should I pass all other IoControlCodes except
IOCTL_DISK_DRIVE_GET_GEOMETRY for a verifiable IDE drive on to the
CDROM_... function?
If anyone has a background in this code, you probably have an idea
straight off how best to fit it in.
Thanks for any help. Patch against wine-20050419 is attached for
illustrative purposes. ... mo
--- dlls/ntdll/file.c.20050419 2005-09-20 09:49:54.0 -0700
+++ dlls/ntdll/file.c 2005-09-20 17:10:17.0 -0700
@@ -790,6 +790,113 @@
return io_status-u.Status;
}
+/***
+ * FILE_IdeDeviceIoControlFile (INTERNAL)
+ *
+ * Handle device IO control for ide disks. Returns TRUE if
+ * DeviceHandle is an IDE disk, else FALSE.
+ */
+static BOOL FILE_IdeDeviceIoControlFile(HANDLE DeviceHandle, HANDLE hEvent,
+PIO_APC_ROUTINE UserApcRoutine,
+PVOID UserApcContext,
+PIO_STATUS_BLOCK IoStatusBlock,
+ULONG IoControlCode,
+PVOID InputBuffer,
+ULONG InputBufferSize,
+PVOID OutputBuffer,
+ULONG OutputBufferSize)
+{
+#if !linux
+ return FALSE;
+#else
+ BOOL releaseFd = FALSE;
+ BOOL isIde = FALSE;
+ NTSTATUS status = STATUS_SUCCESS;
+ DWORD sz = 0;
+
+ int fd;
+ FILE* file;
+ int length;
+ char linkPath[64];
+ char path[MAX_PATH];
+ char letter;
+ struct stat st;
+
+ if ((status = wine_server_handle_to_fd( DeviceHandle, 0, fd, NULL ))
!= STATUS_SUCCESS)
+ goto out;
+ releaseFd = TRUE;
+
+ // does the file descriptor point to an entry in /proc/ide?
+ // todo - isn't there a system call to get a name from a dev_t and
ino_t?
+ snprintf(linkPath, sizeof(linkPath), /proc/%d/fd/%d, getpid(), fd);
+ length = readlink(linkPath, path, sizeof(path));
+ if (length != -1)
+ path[length] = '\0';
+ else {
+ // bad proc format?
+ goto out;
+ }
+
+ // see if the device exists in /proc/ide
+puts(path); //todo
+ if (sscanf(path, /dev/hd%c, letter) != 1)
+ goto out;
+ snprintf(path, sizeof(path), /proc/ide/hd%c, letter);
+ if (stat(path, st) == -1)
+ goto out;
+ isIde = TRUE;
+
+IoStatusBlock-Information = 0;
+ switch (IoControlCode)
+ {
+ case IOCTL_DISK_GET_DRIVE_GEOMETRY:
+ strcat(path, /geometry);
+
+ if (OutputBuffer == 0)
+ IoStatusBlock-u.Status = STATUS_INVALID_PARAMETER;
+ else if (OutputBufferSize sizeof(DISK_GEOMETRY))
+ IoStatusBlock-u.Status = STATUS_BUFFER_TOO_SMALL;
+ else if ((file = fopen(path, r)) != 0) {
+ int cylinders, heads, sectors;
+ if (fscanf(file, physical %d/%d/%d, cylinders,
heads, sectors) == 3) {
+ DISK_GEOMETRY* geometry = (DISK_GEOMETRY*)
OutputBuffer;
+ geometry-Cylinders.QuadPart = cylinders;
+ geometry-MediaType = FixedMedia;
+ geometry-TracksPerCylinder = heads;
+ geometry-SectorsPerTrack = sectors;
+ // todo - is this always 512, or where is it?
+ geometry-BytesPerSector = 512;
+
+ sz = sizeof(DISK_GEOMETRY);
+ IoStatusBlock-u.Status = STATUS_SUCCESS;
+ }
+ else // unknown proc format
+ IoStatusBlock-u.Status =
STATUS_INVALID_PARAMETER;
+
+ fclose(file);
+ }
+ else // unknown proc format
+ IoStatusBlock-u.Status = STATUS_INVALID_PARAMETER;
+ break;
+
+default:
+FIXME(Unsupported IOCTL %lx (type=%lx access=%lx func=%lx
meth=%lx)\n,
+ IoControlCode, IoControlCode 16, (IoControlCode 14) 3,
+ (IoControlCode 2)
Re: IDE disk geometry
Tuesday, September 20, 2005, 6:11:49 PM, Michael Ost wrote: Any suggestions for a good wineish way to implement an IOCTL_ call for an IDE disk? Use SCSI ioctls I think they should work on IDE drives as well. I have some code that reads geometry information out of /proc/ide/hd?/geometry that is working fine. But I am not sure how to integrate it into ntdll. This is not portable. Does it really need to know geometry? Could you just tell it some fake stuff? Should I put my code in CDROM_DeviceIoControl? Or handle it in NtDeviceIoControlFile? Should I pass all other IoControlCodes except IOCTL_DISK_DRIVE_GET_GEOMETRY for a verifiable IDE drive on to the CDROM_... function? I don't it make any sense to create the whole new file to parse just one IOCTL. So you might just add it to the cdrom.c I think that might get accepted. Thanks for any help. Patch against wine-20050419 is attached for illustrative purposes. ... mo No this will not work. You can't add your function at front of what's there. This will slow down and add unnecessary fixmis. For onw IOCTL you might as well put into the cdrom.c But before you go too far, pleas look at kernel/oldconfig.c. It does some parsing of /proc already. So all you need to do is to find where this information is stored on windows (it has to be somewhere in registry) and add to that. Then you don't need to parse /proc all the time but just read info from the registry. One possible option would be to use IOCTL_SCSI_GET_INQUIRY_DATA to get the hdd info. I think it does work on IDE HDDs. And as I remember it has the info you need. And also all that info stored in registry as well. Vitaliy
Re: IDE disk geometry
On Tue, 2005-09-20 at 18:22, Vitaliy Margolen wrote: Tuesday, September 20, 2005, 6:11:49 PM, Michael Ost wrote: Should I put my code in CDROM_DeviceIoControl? Or handle it in NtDeviceIoControlFile? Should I pass all other IoControlCodes except IOCTL_DISK_DRIVE_GET_GEOMETRY for a verifiable IDE drive on to the CDROM_... function? I don't it make any sense to create the whole new file to parse just one IOCTL. So you might just add it to the cdrom.c I think that might get accepted. I don't think it was clear that the device in question is not a CDROM, but a hard disk. Are IDE hard disks supposed to be lumped in with CDROMs in the code? But before you go too far, pleas look at kernel/oldconfig.c. It does some parsing of /proc already. So all you need to do is to find where this information is stored on windows (it has to be somewhere in registry) and add to that. Then you don't need to parse /proc all the time but just read info from the registry. One possible option would be to use IOCTL_SCSI_GET_INQUIRY_DATA to OK. That's a good idea, except that in the Wine version my company is using there is no oldconfig.c. So for our version I guess I would patch dlls/ntdll/cdrom.c by reading out of proc directly. But I would submit a version that stores disk geometry in the registry. I'll look in to that. Thanks for the feedback... mo
