ndiswrapper

Yes, I agree with you.

The while divdi3.c is done half-heartedly, as we are still trying to
get realtek driver to work; other drivers don't need 64 bit
arithmetic. We do need to clean it up so it doesn't use gcc headers. 

I have been a bit tied up with work. So if someone can submit a patch,
I will be happy to commit it.

As per regparm changes, it probably will have to wait till after 0.5
is released (unless Pontus wants to commit the changes before). I am
not sure how this regparm will affect any ndis function calls.

-- 
Giri

On Sat, 2004-02-21 at 05:25, Giridhar Pemmasani wrote: 
> Yes, I agree with you.
> 
> The while divdi3.c is done half-heartedly, as we are still trying to
> get realtek driver to work; other drivers don't need 64 bit
> arithmetic. We do need to clean it up so it doesn't use gcc headers. 
> 
> I have been a bit tied up with work. So if someone can submit a patch,
> I will be happy to commit it.

Attached is cvs-fix.diff against yesterday's cvs. It makes divdi3.c
compile cleanly under kbuild, and cleans up a few things in the
ndiswrapper script. (Rather than testing for Debian, it's better to test
whether the particular features are there; that way, SUSE will work as
well.)

> As per regparm changes, it probably will have to wait till after 0.5
> is released (unless Pontus wants to commit the changes before). I am
> not sure how this regparm will affect any ndis function calls.

Concerning CONFIG_REGPARM, note that this will be in stock 2.6.4 so it's
no longer a distribution specific problem. You will at least need
regparm.diff with this option turned on, but something else is still
broken: the last message I got then trying to modprobe was "Calling
startdriver ioctl" (with the DEBUG option off). With regparm=0, the
driver loads fine.

Regards,
-- 
Andreas Gruenbacher <agruen@...>
SUSE Labs, SUSE LINUX AG

Thank you very much for the patches. I will go through the patches
and commit them soon.

Right now I am working on couple of issues. It seems after resume from
S3, ndiswrapper can't initialize the card. I thought I had the
suspend/resume working, but it turned out that it worked only with
swsusp in 2.4 (which is what I was using so far). I haven't figured
out what is causing the problem, but I am working on it. Another thing
is Realtek responded to my request about helping us get this chipset
to work. I haven't looked at it in sometime, so I am trying to see
what exactly the problem with this chipset is. I have also started
working on WPA. Once it works, I will commit the patch and announce
here.

-- 
Giri

I have committed the first two patches (along with necessary change to
driver/Makefile). I haven't committed the last one (regparm patch) as
I am not sure if this affects any ndis calls. I will leave this patch
for Pontus to deal with (I sent separate mail to him about it).

-- 
Giri

On Sun, 2004-02-22 at 05:31, Andreas Gruenbacher wrote:
> Concerning CONFIG_REGPARM, note that this will be in stock 2.6.4 so it's
> no longer a distribution specific problem. You will at least need
> regparm.diff with this option turned on, but something else is still
> broken: the last message I got then trying to modprobe was "Calling
> startdriver ioctl" (with the DEBUG option off). With regparm=3D0, the
> driver loads fine.

Couldn't that be a problem that is module -> ndis driver?=20
And wasn't there something you could do to make the compiler skip it?
like volatile or something? (I remember a mention about asmlinkage or
so)

Anyways, i just got out of bed... so i might be confused =3D)

--=20
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net

> Attached is cvs-fix.diff against yesterday's cvs. It makes divdi3.c
> compile cleanly under kbuild, and cleans up a few things in the
> ndiswrapper script. (Rather than testing for Debian, it's better to test
> whether the particular features are there; that way, SUSE will work as
> well.)

Thanks a lot for these!

> > As per regparm changes, it probably will have to wait till after 0.5
> > is released (unless Pontus wants to commit the changes before). I am
> > not sure how this regparm will affect any ndis function calls.
> 
> Concerning CONFIG_REGPARM, note that this will be in stock 2.6.4 so it's
> no longer a distribution specific problem. You will at least need
> regparm.diff with this option turned on, but something else is still
> broken: the last message I got then trying to modprobe was "Calling
> startdriver ioctl" (with the DEBUG option off). With regparm=0, the
> driver loads fine.

I got the impression that 2.6.4 will have CONFIG_REGPARM but that it
will be set to 0 until 2.7? Or will vendor kernels have this enabled in
2.6 kernels?

Pontus