Thread: [Ndiswrapper-general] [PATCH] ndiswrapper for kernel 2.6.16 (or current git version)
Status: Beta
Brought to you by:
pgiri
From: Carlo M. A. B. <ca...@sa...> - 2006-01-08 05:31:07
Attachments:
linux-2.6.16-usbnoowner.patch
|
Greetings, while trying to get ndiswrapper compiled with linus' current git kernel repository i found a compile error, because struct usb_driver has been redefined without the owner field. attached patch with a proposed fix for whenever kernel 2.6.16 is released (if the API is changed as observed). the posibility of setting no_dynamic_id to 1 (to prevent the sysfs interface to be created and dynamically added device ids associated with this driver), could be also required as part of this API change, but i think the current implicit set of 0 makes more sense. as i don't have a USB device i couldn't test this change, but the resulting module is currently loaded and working as expected for my broadcom 80211g adapter (64 bit kernel). regards, Carlo PS. modified the kernel definition from my git repository to show as a 2.6.16 kernel for this test, as it is now defined as a 2.6.15 git variant from linus, and therefore is not possible to use the current macro version to identify the changes on the API correctly. |
From: Giridhar P. <gi...@lm...> - 2006-01-08 07:54:09
|
Carlo Marcelo Arenas Belon wrote: > attached patch with a proposed fix for whenever kernel 2.6.16 is releas= ed (if > the API is changed as observed). A similar patch was committed to CVS a few hours ago. The patch was based= on 2.6.15-git3 visually (I didn't compile patch on 2.6.15-git3, but just loo= ked at the git patch). Please get the latest snapshot (anon CVS may take some= time to update) and see if that works. Giri |
From: Carlo M. A. B. <ca...@sa...> - 2006-01-09 10:07:05
|
<SNIP> > at the git patch). Please get the latest snapshot (anon CVS may take some time > to update) and see if that works. thanks Giri, works great with last cvs version (1.8rc1), tested with linus' git4 kernel spapshot. on a related issue, and taking that i couldn't find a clear answer or recommended course of action while googling or asking around. what are you guys doing in order to avoid compile errors based on kernel API changes like this one, while the kernel is in merge mode after a release (2 weeks) and taking that the minor version is not getting updated yet. this patch will be most likely valid whenever 2.6.16-rc1 is released, but meanwhile unless the minor release number is updated manually it just won't work, leading in this case hopefully to a compile error which is easy to track and fix. is it really, like it seems that the kernel release process overlooked updating the minor during this merge period, and that should be fixed (was probably planning on raising it on the LKML), or is there any other explanation? Carlo |