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=Lj
	6MDcg+Dga0SK9zA+Rhr59ThrljTodW/LWIn9g5aSIkBp/1ccswK/cdnVIZ3iigfz
	eYYsgvhn8KgFpZYXJ9NvEiiSb5nfFGt2Eb6GCZSt/ECJ4xYLkU3zkD3msp9dVwWv
	rpZvpRqbgDW9X4cPpqlrpIiDrl7nBp2kdOcsLzz78=
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=++tJ0JaF
	dJCY86hevfji1V2gIos=; b=t/PPoqTc8+tD9EXkVMqWhELrEL8nwZ4ufTDZ+aUD
	ZRzqJSiJzwPAshjw26fM9O5Urten56HcmOnQOKvVhTjIq/SQHmc0v673hpttQ70K
	8DEfoHuyt3ZJGOzJ8WXFHgSC/DeW0oiO04Wx/7u0Tl9PjaHOL3Sf2ptWiTWRjTpR
	xcQ=
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.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	mail-ig0-f181.google.com
MIME-Version:	1.0
X-Received:	by 10.43.148.72 with SMTP id kf8mr2062276icc.76.1432196736103; Thu, 21 May 2015 01:25:36 -0700 (PDT)
In-Reply-To:	<loom.20150520T030416-888@post.gmane.org>
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> <loom DOT 20150519T094146-560 AT post DOT gmane DOT org> <CACs=mWBEe2CqkN=tizTMcCXLxvbkwNat8Uch_CTPSaDgFCUmYQ AT mail DOT gmail DOT com> <loom DOT 20150520T030416-888 AT post DOT gmane DOT org>
Date:	Thu, 21 May 2015 10:25:36 +0200
Message-ID:	<CACs=mWDbdxH8+pmU3nWUOAKDh1X_SM0C_oKEkXUrarKO8z=20g@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
X-IsSubscribed:	yes

Yes.....it's really a little world :)

I've got the kernelspace part on github (
https://github.com/PicMelter/uniioShd.git ).
It consists of sys (the kernel module), testExe (loads/unloads on the
fly the module
in the kernel) and secondExe that just interact with the first
executable and the kernel
module if it is loaded. With the buildAll.bat if the WDK7.1 is
present, all the applications
are builded automatically.
There is a Cyg.c that represent my effort to connect to the module,
sending an ioctl and doing
an mmap.

I think that, even if it's a semplification of the program I'm
porting, this little project
is very close to what I'm trying to do with the main project.

As I read somewhere else, cygwin doesn't support custom ioctl on
custom modules, have I
understood well? This may explain why I'm never able to send any ioctl
to my module.

For the mmap part, well, I've tried to follow with gdb what Cygwin is
doing but II must admit
that at some point I just lose track of what it's doing.

If it's too messy, I can polish the code a little bit; consider that
it's the environment where I'm
always doing tests so rarely I have the time to clean the code...

   -Alessio

2015-05-20 3:19 GMT+02:00 Mark Geisert <mark AT maxrnd DOT com>:
> Alessio Faina writes:
>> Well.....I wrote and answered myself the question you pointed out that
>> is residing on stackoverflow....
>
> Oh, small world :)
>
>> It was my first option I thought of to pass the pointer to the virtual
>> address to the userland application but
>> I've been asked to mantain the architecture using open(), ioctl(),
>> mmap() etc.... so I don't know, it's a kind of
>> jolly to be played in case I won't be able to use the posix
>> architecture....but reading on forums/mailing lists...
>> I think I will be forced to use the kind of implementation I've
>> described in the SO question.
>> It seems that no-one ever have got the need to do something like I'm
>> trying to do.
>>
>> 2015-05-19 9:52 GMT+02:00 Mark Geisert <XXXX <at> XXXXXX.XXX>:
>> > Does
>> >
> http://stackoverflow.com/questions/29938573/accessing-kernel-memory-from-user-mode-windows
>> > help to answer your question?  If it does, you'll still have to decide
>> > whether to translate the Windows calls there into Cygwin calls or instead
>> > just localize the Windows calls in one user-level module and leave
>> > everything else to Cygwin.
>
> Cygwin is entirely and intentionally in user space.  Most of its users don't
> even need programming access to Windows user space, let alone kernel space.
>  So yes, you're likely to be forging a new path.
>
> If you get it working with toy Windows test programs, we *might* be able to
> tell you how to convert it to Cygwin, if it's possible.  But the actual
> figuring it out for Windows is outside the scope of what Cygwin is intended
> to provide.
>
> ..mark
>
>
> --
> 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
>

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

- Raw text -