Re: Patch that fixes usb4bsd stack build on the recent -CURRENT

2007-07-03 Thread Hans Petter Selasky
Hi Eygene !

Thanks for the patch.

It should be committed now to my SVN repo.

--HPS

On Tuesday 03 July 2007 14:00, Eygene Ryabinkin wrote:
> Hans, good day.
>
> Tried to build the usb4bsd stack on the recent (yesterday's -CURRENT)
> and it failed due to the cam subsystem API changes introduced in
> xpt_bus_register: now it takes three values.
>
> The following patch cures the situation:
> -
> Index: trunk/i4b/src/sys/dev/usb/umass.c
> ===
> --- trunk/i4b/src/sys/dev/usb/umass.c (revision 529)
> +++ trunk/i4b/src/sys/dev/usb/umass.c (working copy)
> @@ -2305,7 +2305,11 @@
>   mtx_lock(&(sc->sc_mtx));
>  #endif
>
> +#if (__FreeBSD_version >= 700048)
> + if(xpt_bus_register(sc->sc_sim, sc->sc_dev, sc->sc_unit) != CAM_SUCCESS)
> { +#else
>   if(xpt_bus_register(sc->sc_sim, sc->sc_unit) != CAM_SUCCESS) {
> +#endif
>  #if (__FreeBSD_version >= 700037)
>   mtx_unlock(&(sc->sc_mtx));
>  #endif
> -
> It was tested on my system: I am writing from the USB keyboard
> and my USB flash is burned by the dd.  My naughty 2Gb Transcend
> flash, as usual, buries the system completely.  So all is going
> as expected ;))
>
> The original umass.c from the fresh -CURRENT uses 'NULL' instead
> of 'sc->sc_dev'.  The commit comment for the cam_xpt.c tells us
> -
> Prepare for future integration between CAM and newbus.  xpt_bus_register
> now takes a device_t to be the parent of the bus that is being created.
> Most SIMs have been updated with a reasonable argument, but a few
> exceptions just pass NULL for now.  This argument isn't used yet and the
> newbus integration likely won't be ready until after 7.0-RELEASE.
> -
> I don't know why umass.c is using NULL, but I had tried both ways
> and there is no difference for my hardware.
>
> I had chosen the check for the __FreeBSD_version of 700048, because
> the cam changes were done at 2007/06/17 05:55:53:
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c?rev=1.189;conte
>nt-type=text%2Fplain and the latest changes in the param.h occured at
> 2007/06/12 16:24:54
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/param.h?rev=1.303;content
>-type=text%2Fplain Users that updated the -CURRENT after June 12th, but
> before June 17th will suffer from the uncompilable stack, but I hope that
> this timeframe is small and -CURRENT users are periodically upgrading the
> sources.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Patch that fixes usb4bsd stack build on the recent -CURRENT

2007-07-03 Thread Eygene Ryabinkin
Hans, good day.

Tried to build the usb4bsd stack on the recent (yesterday's -CURRENT)
and it failed due to the cam subsystem API changes introduced in
xpt_bus_register: now it takes three values.

The following patch cures the situation:
-
Index: trunk/i4b/src/sys/dev/usb/umass.c
===
--- trunk/i4b/src/sys/dev/usb/umass.c   (revision 529)
+++ trunk/i4b/src/sys/dev/usb/umass.c   (working copy)
@@ -2305,7 +2305,11 @@
mtx_lock(&(sc->sc_mtx));
 #endif
 
+#if (__FreeBSD_version >= 700048)
+   if(xpt_bus_register(sc->sc_sim, sc->sc_dev, sc->sc_unit) != 
CAM_SUCCESS) {
+#else
if(xpt_bus_register(sc->sc_sim, sc->sc_unit) != CAM_SUCCESS) {
+#endif
 #if (__FreeBSD_version >= 700037)
mtx_unlock(&(sc->sc_mtx));
 #endif
-
It was tested on my system: I am writing from the USB keyboard
and my USB flash is burned by the dd.  My naughty 2Gb Transcend
flash, as usual, buries the system completely.  So all is going
as expected ;))

The original umass.c from the fresh -CURRENT uses 'NULL' instead
of 'sc->sc_dev'.  The commit comment for the cam_xpt.c tells us
-
Prepare for future integration between CAM and newbus.  xpt_bus_register
now takes a device_t to be the parent of the bus that is being created.
Most SIMs have been updated with a reasonable argument, but a few exceptions
just pass NULL for now.  This argument isn't used yet and the newbus
integration likely won't be ready until after 7.0-RELEASE.
-
I don't know why umass.c is using NULL, but I had tried both ways
and there is no difference for my hardware.

I had chosen the check for the __FreeBSD_version of 700048, because
the cam changes were done at 2007/06/17 05:55:53:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c?rev=1.189;content-type=text%2Fplain
and the latest changes in the param.h occured at 2007/06/12 16:24:54

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/param.h?rev=1.303;content-type=text%2Fplain
Users that updated the -CURRENT after June 12th, but before June 17th
will suffer from the uncompilable stack, but I hope that this timeframe
is small and -CURRENT users are periodically upgrading the sources.
-- 
Eygene
Index: trunk/i4b/src/sys/dev/usb/umass.c
===
--- trunk/i4b/src/sys/dev/usb/umass.c   (revision 529)
+++ trunk/i4b/src/sys/dev/usb/umass.c   (working copy)
@@ -2305,7 +2305,11 @@
mtx_lock(&(sc->sc_mtx));
 #endif
 
+#if (__FreeBSD_version >= 700048)
+   if(xpt_bus_register(sc->sc_sim, sc->sc_dev, sc->sc_unit) != 
CAM_SUCCESS) {
+#else
if(xpt_bus_register(sc->sc_sim, sc->sc_unit) != CAM_SUCCESS) {
+#endif
 #if (__FreeBSD_version >= 700037)
mtx_unlock(&(sc->sc_mtx));
 #endif
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"