* Re: Relating device names in /dev/ to drive letters in Windows. [not found] <mailman.96674.1595867913.8982.cygwin@cygwin.com> @ 2020-07-28 21:36 ` Hamish McIntyre-Bhatty 0 siblings, 0 replies; 8+ messages in thread From: Hamish McIntyre-Bhatty @ 2020-07-28 21:36 UTC (permalink / raw) To: cygwin [-- Attachment #1.1.1: Type: text/plain, Size: 3515 bytes --] Corinna wrote: > In theory, the Cygwin DLL has to provide stuff through ioctl's after > opening the device file. There are already quite a few ioctl's > supported, namely > > HDIO_GETGEO, BLKGETSIZE, BLKGETSIZE64, BLKRRPART, BLKSSZGET, BLKIOMIN, > BLKIOOPT, BLKPBSZGET, BLKALIGNOFF, RDIOCDOP subcommand RDSETBLK, > RDIOCGET. > > Whatever is missing *and* is provided by the WinAPI function > DeviceIoControl (or, actually, any other way) can be added to > Cygwin's ioctl API as you see fit. > > > Corinna Thanks Corinna. That gives me a better understanding of how this works. I'll need to explore the source a bit to see how it fits together but that helps a lot. Brian wrote: Please maintain threading using Reply to List or Reply/All to keep the discussion together in email clients using proper References headers for threads, rather than just Subject, and also please retain some quoted context for your replies. I have now turned off Digest mode so this will be the last reply from me that messes this stuff up for people. > I'd be happy to attempt implementing this, but I'm not sure where to > start. With the information you've given me I should be able to figure > something out, but I'm not sure how this is done in Linux/a POSIX > compliant way. Would be be through a file and directory structure or > through some libraries? See what libraries are used by the package, whether and what system dependencies each has, clone the source repo or download the sources and create a local repo, so you can follow a similar structure with a Cygwin port. Using a (git) repo to track your information, documentation, research, proofs of concept, and changes will make life easier for all. > I know a little bit of C and C++, so if I do have to write a library I > should be able to muddle through, and probably learn quite a lot, but > I'm not sure quite where to start here, with either the Linux side or > the Cygwin side (would this be part of the Cygwin DLL?). First you need to research what information you need to deliver to your client or consumer, based on the system dependencies found above, and how to find that information under Windows. You could make that process into a proof of concept in some interpreted script running under an elevated admin shell to access /proc/..., /proc/registry/..., /proc/sys/... etc. and get at the information you require. Then you could research how you could implement that process with Windows APIs by searching online docs, including e.g. SO: pay attention to supported versions in MS docs. If you isolate system interfaces into independent modules, they could be reimplemented in the DLL if appropriate. > I'm aware this might not be the right mailing list, but would appreciate > if anyone knowledgeable in this area could give me a few pointers to > help me get started - I'd love to contribute more to Cygwin Check out the newlib-cygwin source repo and read the sources (starting with short .cc files under winsup/cygwin/) to see how system interfaces are implemented using Windows APIs. All makes sense,. I'll see what I can do. It might well be that there are some programs/libs I can just add without having to change anything then. Thanks both, I'll get back to you when I have something to report/more questions, Hamish [-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --] [-- Type: application/pgp-keys, Size: 3235 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Relating device names in /dev/ to drive letters in Windows. @ 2020-07-27 11:24 Hamish McIntyre-Bhatty 2020-07-27 12:44 ` Corinna Vinschen 2020-07-27 13:10 ` Brian Inglis 0 siblings, 2 replies; 8+ messages in thread From: Hamish McIntyre-Bhatty @ 2020-07-27 11:24 UTC (permalink / raw) To: Cygwin General Mailing List [-- Attachment #1.1.1: Type: text/plain, Size: 995 bytes --] Thanks Corinna and Brian. smartmontools does help - I can see make and model, which is definitely helpful. Oh, I guess I just didn't have blkid installed then. I'll fix that. Brian, I'd be happy to attempt implementing this, but I'm not sure where to start. With the information you've given me I should be able to figure something out, but I'm not sure how this is done in Linux/a POSIX compliant way. Would be be through a file and directory structure or through some libraries? I know a little bit of C and C++, so if I do have to write a library I should be able to muddle through, and probably learn quite a lot, but I'm not sure quite where to start here, with either the Linux side or the Cygwin side (would this be part of the Cygwin DLL?). I'm aware this might not be the right mailing list, but would appreciate if anyone knowledgeable in this area could give me a few pointers to help me get started - I'd love to contribute more to Cygwin :) Hamish [-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --] [-- Type: application/pgp-keys, Size: 3235 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Relating device names in /dev/ to drive letters in Windows. 2020-07-27 11:24 Hamish McIntyre-Bhatty @ 2020-07-27 12:44 ` Corinna Vinschen 2020-07-27 13:10 ` Brian Inglis 1 sibling, 0 replies; 8+ messages in thread From: Corinna Vinschen @ 2020-07-27 12:44 UTC (permalink / raw) To: cygwin On Jul 27 12:24, Hamish McIntyre-Bhatty via Cygwin wrote: > Thanks Corinna and Brian. > > smartmontools does help - I can see make and model, which is definitely > helpful. > > Oh, I guess I just didn't have blkid installed then. I'll fix that. > > Brian, > > I'd be happy to attempt implementing this, but I'm not sure where to > start. With the information you've given me I should be able to figure > something out, but I'm not sure how this is done in Linux/a POSIX > compliant way. Would be be through a file and directory structure or > through some libraries? In theory, the Cygwin DLL has to provide stuff through ioctl's after opening the device file. There are already quite a few ioctl's supported, namely HDIO_GETGEO, BLKGETSIZE, BLKGETSIZE64, BLKRRPART, BLKSSZGET, BLKIOMIN, BLKIOOPT, BLKPBSZGET, BLKALIGNOFF, RDIOCDOP subcommand RDSETBLK, RDIOCGET. Whatever is missing *and* is provided by the WinAPI function DeviceIoControl (or, actually, any other way) can be added to Cygwin's ioctl API as you see fit. Corinna -- Corinna Vinschen Cygwin Maintainer ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Relating device names in /dev/ to drive letters in Windows. 2020-07-27 11:24 Hamish McIntyre-Bhatty 2020-07-27 12:44 ` Corinna Vinschen @ 2020-07-27 13:10 ` Brian Inglis 1 sibling, 0 replies; 8+ messages in thread From: Brian Inglis @ 2020-07-27 13:10 UTC (permalink / raw) To: cygwin On 2020-07-27 05:24, Hamish McIntyre-Bhatty via Cygwin wrote: Please maintain threading using Reply to List or Reply/All to keep the discussion together in email clients using proper References headers for threads, rather than just Subject, and also please retain some quoted context for your replies. > smartmontools does help - I can see make and model, which is definitely > helpful. > Oh, I guess I just didn't have blkid installed then. I'll fix that. >> $ which blkid >> /sbin/blkid >> $ cygcheck -f /sbin/blkid >> util-linux-2.33.1-2 >> >> Everyone has util-linux installed as it is in the Base category. > I'd be happy to attempt implementing this, but I'm not sure where to > start. With the information you've given me I should be able to figure > something out, but I'm not sure how this is done in Linux/a POSIX > compliant way. Would be be through a file and directory structure or > through some libraries? See what libraries are used by the package, whether and what system dependencies each has, clone the source repo or download the sources and create a local repo, so you can follow a similar structure with a Cygwin port. Using a (git) repo to track your information, documentation, research, proofs of concept, and changes will make life easier for all. > I know a little bit of C and C++, so if I do have to write a library I > should be able to muddle through, and probably learn quite a lot, but > I'm not sure quite where to start here, with either the Linux side or > the Cygwin side (would this be part of the Cygwin DLL?). First you need to research what information you need to deliver to your client or consumer, based on the system dependencies found above, and how to find that information under Windows. You could make that process into a proof of concept in some interpreted script running under an elevated admin shell to access /proc/..., /proc/registry/..., /proc/sys/... etc. and get at the information you require. Then you could research how you could implement that process with Windows APIs by searching online docs, including e.g. SO: pay attention to supported versions in MS docs. If you isolate system interfaces into independent modules, they could be reimplemented in the DLL if appropriate. > I'm aware this might not be the right mailing list, but would appreciate > if anyone knowledgeable in this area could give me a few pointers to > help me get started - I'd love to contribute more to Cygwin :) Check out the newlib-cygwin source repo and read the sources (starting with short .cc files under winsup/cygwin/) to see how system interfaces are implemented using Windows APIs. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Relating device names in /dev/ to drive letters in Windows. @ 2020-07-23 9:36 Hamish McIntyre-Bhatty 2020-07-23 11:29 ` Hamish McIntyre-Bhatty 2020-07-24 16:26 ` Brian Inglis 0 siblings, 2 replies; 8+ messages in thread From: Hamish McIntyre-Bhatty @ 2020-07-23 9:36 UTC (permalink / raw) To: The Cygwin Mailing List [-- Attachment #1.1.1: Type: text/plain, Size: 578 bytes --] Hi all, I have noticed that after plugging in a USB drive, device files appear in /dev that correlate to the partitions on the drive. This is great because it means things like ddrescue can work in Cygwin, but I'm not yet sure how to relate these to the drives Windows sees. None of the standard Linux tools I use to gather system information (lsblk, blkid, lshw) seem to be available on Cygwin. I'm guessing this is because they won't work because there's no kernel or low level hardware access or something like that. Does anyone know how to do this? Hamish [-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --] [-- Type: application/pgp-keys, Size: 3235 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Relating device names in /dev/ to drive letters in Windows. 2020-07-23 9:36 Hamish McIntyre-Bhatty @ 2020-07-23 11:29 ` Hamish McIntyre-Bhatty 2020-07-24 8:45 ` Corinna Vinschen 2020-07-24 16:26 ` Brian Inglis 1 sibling, 1 reply; 8+ messages in thread From: Hamish McIntyre-Bhatty @ 2020-07-23 11:29 UTC (permalink / raw) To: The Cygwin Mailing List [-- Attachment #1.1.1: Type: text/plain, Size: 1217 bytes --] On 23/07/2020 10:36, Hamish McIntyre-Bhatty wrote: > Hi all, > > I have noticed that after plugging in a USB drive, device files appear > in /dev that correlate to the partitions on the drive. > > This is great because it means things like ddrescue can work in Cygwin, > but I'm not yet sure how to relate these to the drives Windows sees. > None of the standard Linux tools I use to gather system information > (lsblk, blkid, lshw) seem to be available on Cygwin. I'm guessing this > is because they won't work because there's no kernel or low level > hardware access or something like that. Does anyone know how to do this? > > Hamish > Just replying to note that I found https://www.cygwin.com/cygwin-ug-net/using-specialnames.html, which covers some of my question. However, some things (like build in CD/DVD drives) don't show up in /proc/partitions, so that's still not ideal. Also is there any way I can get Make/Model and similar information from Cygwin? I know I can use WMIC or PowerShell for this, but I'm assuming having a Cygwin package depending on those is a big no-no, even as an alternate code path if they are detected? Sorry for all the newbie questions! Hamish [-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --] [-- Type: application/pgp-keys, Size: 3235 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Relating device names in /dev/ to drive letters in Windows. 2020-07-23 11:29 ` Hamish McIntyre-Bhatty @ 2020-07-24 8:45 ` Corinna Vinschen 0 siblings, 0 replies; 8+ messages in thread From: Corinna Vinschen @ 2020-07-24 8:45 UTC (permalink / raw) To: cygwin On Jul 23 12:29, Hamish McIntyre-Bhatty via Cygwin wrote: > On 23/07/2020 10:36, Hamish McIntyre-Bhatty wrote: > > Hi all, > > > > I have noticed that after plugging in a USB drive, device files appear > > in /dev that correlate to the partitions on the drive. > > > > This is great because it means things like ddrescue can work in Cygwin, > > but I'm not yet sure how to relate these to the drives Windows sees. > > None of the standard Linux tools I use to gather system information > > (lsblk, blkid, lshw) seem to be available on Cygwin. I'm guessing this > > is because they won't work because there's no kernel or low level > > hardware access or something like that. Does anyone know how to do this? > > > > Hamish > > > Just replying to note that I found > https://www.cygwin.com/cygwin-ug-net/using-specialnames.html, which > covers some of my question. > > However, some things (like build in CD/DVD drives) don't show up in > /proc/partitions, so that's still not ideal. Also is there any way I can > get Make/Model and similar information from Cygwin? The smartmontools package may help you there. Corinna -- Corinna Vinschen Cygwin Maintainer ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Relating device names in /dev/ to drive letters in Windows. 2020-07-23 9:36 Hamish McIntyre-Bhatty 2020-07-23 11:29 ` Hamish McIntyre-Bhatty @ 2020-07-24 16:26 ` Brian Inglis 1 sibling, 0 replies; 8+ messages in thread From: Brian Inglis @ 2020-07-24 16:26 UTC (permalink / raw) To: cygwin On 2020-07-23 03:36, Hamish McIntyre-Bhatty via Cygwin wrote: > I have noticed that after plugging in a USB drive, device files appear > in /dev that correlate to the partitions on the drive. > > This is great because it means things like ddrescue can work in Cygwin, > but I'm not yet sure how to relate these to the drives Windows sees. > None of the standard Linux tools I use to gather system information > (lsblk, blkid, lshw) seem to be available on Cygwin. I'm guessing this > is because they won't work because there's no kernel or low level > hardware access or something like that. Does anyone know how to do this? $ cygcheck -p blkid Found 17 matches for blkid .htaccess - libblkid-devel-2.32.1-1 - libblkid-devel: Block device ID library (development) libblkid-devel-2.33.1-1 - libblkid-devel: Block device ID library (development) libblkid-devel-2.33.1-2 - libblkid-devel: Block device ID library (development) .htaccess - libblkid1-2.32.1-1 - libblkid1: Block device ID library (runtime) libblkid1-2.33.1-1 - libblkid1: Block device ID library (runtime) libblkid1-2.33.1-2 - libblkid1: Block device ID library (runtime) util-linux-debuginfo-2.32.1-1 - util-linux-debuginfo: Debug info for util-linux util-linux-debuginfo-2.33.1-1 - util-linux-debuginfo: Debug info for util-linux util-linux-debuginfo-2.33.1-2 - util-linux-debuginfo: Debug info for util-linux util-linux-2.32.1-1-src - util-linux-src: Collection of basic system utilities (source) util-linux-2.33.1-1-src - util-linux-src: Collection of basic system utilities (source) util-linux-2.33.1-2-src - util-linux-src: Collection of basic system utilities (source) util-linux-2.32.1-1 - util-linux: Collection of basic system utilities util-linux-2.33.1-1 - util-linux: Collection of basic system utilities util-linux-2.33.1-2 - util-linux: Collection of basic system utilities $ which blkid /sbin/blkid $ cygcheck -f /sbin/blkid util-linux-2.33.1-2 Everyone has util-linux installed as it is in the Base category. Someone has to provide the system interfaces in a POSIX compliant manner or at least similar to Linux and BSD to port the libraries. You can find most info under /proc/registry/ (even /proc/registry/HKEY_PERFORMANCE_DATA/{@,Costly,Global}/ - explore with ls and regtool) and there are Windows dynamic system objects under /proc/sys/ e.g. /proc/sys/ Device/ and /proc/sys/DosDevices/Global/ (explore with ls and od/xxd). Note: You need an elevated admin shell to use most device tools and see a lot of /proc/sys/. Hack at it, sir! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-07-28 21:36 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <mailman.96674.1595867913.8982.cygwin@cygwin.com> 2020-07-28 21:36 ` Relating device names in /dev/ to drive letters in Windows Hamish McIntyre-Bhatty 2020-07-27 11:24 Hamish McIntyre-Bhatty 2020-07-27 12:44 ` Corinna Vinschen 2020-07-27 13:10 ` Brian Inglis -- strict thread matches above, loose matches on Subject: below -- 2020-07-23 9:36 Hamish McIntyre-Bhatty 2020-07-23 11:29 ` Hamish McIntyre-Bhatty 2020-07-24 8:45 ` Corinna Vinschen 2020-07-24 16:26 ` Brian Inglis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).