From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76848 invoked by alias); 27 May 2015 15:57:00 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 76836 invoked by uid 89); 27 May 2015 15:56:59 -0000 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 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 27 May 2015 15:56:58 +0000 Received: by iesa3 with SMTP id a3so17018282ies.2 for ; Wed, 27 May 2015 08:56:56 -0700 (PDT) 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) Received: by 10.36.32.139 with HTTP; Wed, 27 May 2015 08:56:55 -0700 (PDT) In-Reply-To: <20150527120908.GE16927@calimero.vinschen.de> References: <5559FB9E.3040200@cygwin.com> <20150527120908.GE16927@calimero.vinschen.de> Date: Wed, 27 May 2015 15:59:00 -0000 Message-ID: Subject: Re: File operations on a Windows Driver (character device) From: Alessio Faina To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00356.txt.bz2 Thanks Mark and Corinna. I'm sorry for the and ., 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 : > 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