public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Hamish McIntyre-Bhatty <hamishmb@live.co.uk>
To: cygwin@cygwin.com
Subject: Re: Relating device names in /dev/ to drive letters in Windows.
Date: Tue, 28 Jul 2020 22:36:42 +0100	[thread overview]
Message-ID: <AM0PR05MB48988030487030DD0A3BB61AE7730@AM0PR05MB4898.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <mailman.96674.1595867913.8982.cygwin@cygwin.com>


[-- 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 --]

       reply	other threads:[~2020-07-28 21:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.96674.1595867913.8982.cygwin@cygwin.com>
2020-07-28 21:36 ` Hamish McIntyre-Bhatty [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM0PR05MB48988030487030DD0A3BB61AE7730@AM0PR05MB4898.eurprd05.prod.outlook.com \
    --to=hamishmb@live.co.uk \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).