X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=Ww
	mWWxCL+o562/I5IUHX5kc4cYahy9SyawpWre0KQy3XqE+73TetoLO0YJu5SvMl9K
	0rNui9xtd0wugwvxhBGxE2lbYV3TGah2Vm0lAAnAfVTFGmY+k1mv3kkJ9RgN2xzN
	O8dKxLd486Ugf5AuIAy7Meshk5Zb13sBShYMB3G7A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; s=default; bh=OHlWGF17
	3TVH4fAHOzh3At0417Q=; b=Z2q2fI/zomhoswldeQWFG7pIbhBb1A/iXX+Xy6N1
	PCthdX4fEbWOSy5lqVmT7CTh10eEE+uNlXiDnkeBHIAUBBgaVZY1b/wyq+lU7Nmo
	rSCkiMqbM+p7vNdEoASOJ8E78lzEAYzmBNXBt8YsM1x6Dk+AyGstdWkKYfHeVFcN
	puc=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-ie0-f173.google.com
MIME-Version: 1.0
X-Received: by 10.50.57.112 with SMTP id h16mr5120596igq.35.1432742216047; Wed, 27 May 2015 08:56:56 -0700 (PDT)
In-Reply-To: <20150527120908.GE16927@calimero.vinschen.de>
References: <CACs=mWDRGh9KZBT45=8yy4J6h62v0RNYxczV91qRhhb8LcfY4Q AT mail DOT gmail DOT com>	<5559FB9E DOT 3040200 AT cygwin DOT com>	<CACs=mWCO8ejvsufP3C_HFAiKDrcsanGZ+J_EuQQGOm+u30T_zg AT mail DOT gmail DOT com>	<20150527120908 DOT GE16927 AT calimero DOT vinschen DOT de>
Date: Wed, 27 May 2015 17:56:55 +0200
Message-ID: <CACs=mWCdm8HV_AUfEbsY97oSXKE=CTWNHbc1AySDkdydnHcPkg@mail.gmail.com>
Subject: Re: File operations on a Windows Driver (character device)
From: Alessio Faina <alessiofaina AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes

Thanks Mark and Corinna.
I'm sorry for the
<https://cygwin.com/acronyms/#TOFU> and
<https://cygwin.com/acronyms/#PCYMTNQREAIYR>.,
I wont make those mistakes in the future, I promise.

Returning on the issue, I've decided to open the device with the
open() provided by Cygwin
and then intercept the IOCTLs and change them with the Win32
DeviceIoControl (using
_get_osfhandle() for the handle of the device).
At this point I can even implement the mmap with an IOCTL without
problems as I explained
in a previous mail.
I cannot use the read/write calls because I need to access the kernel
memory directly with
the mmap; in this way I can get better performances.

The last (and main) problem I'm facing is the poll()/select(); I've
seen that doing a poll() on
this kind of device always returns "1" because in
select.cc->select_stuff::poll() the function
pointer s->peek is NULL and in that way the counter "n" is always increased.

What I need to do is something that can be compiled under VS2013 and
under Cygwin
for compatibility with applications already written for linux OS; I
was thinking to open a
WSK socket and associate it with every new "open" made from userspace so that a
userspace program can use the poll indifferently if compiled under Cygwin or
under a native environment.
What I don't know is if this way is a smart one or if there is a
clever way to do this:
have you got something to suggest?

Thanks very much everyone for the help

         -Alessio Faina


2015-05-27 14:09 GMT+02:00 Corinna Vinschen <xxx AT cygwin DOT com>:
> On May 18 17:33, Alessio Faina wrote:
>> Ok thanks, I've been able to find the character device under
>> "/proc/sys/DosDevices/Global/deviceName"; now I'm stuck with the mmap
>> implementation; when I do mmap in the userland program it returns me
>> errno 19 (#define ENODEV      19  /* No such device */) obviously because
>> I haven't set anything in the kernel module; there's a way to make visible a
>> portion of memory to be used by the mmap in the kernel? The memory is Non Paged
>> and allocated with a ExAllocatePoolWithTag in 'win terms'.
>
> The problem is that the /proc/sys interface is only implemented for
> very basic operations.  There's no ioctl and mmap implemented for
> arbitrary devices in Cygwin.
>
> To get your device working, you have to either implement support for it
> in Cygwin, or you have to use native W32 or NT calls to access your
> device.
>
> Alternatively: Since you can open the device, read/write should be
> possible.  If you implement all interaction with your device (send
> comands, request map address, etc) in the driver as specially crafted
> read/write calls, you should be able to communicate with it from Cygwin
> applications without having to implement a Cygwin file handler.
>
>
> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple