Date: Fri, 17 Dec 2004 09:53:35 -0700 From: Scott Long <scottl@freebsd.org> To: Matt Rowley <matt@arin.net> Cc: Dan Nelson <dnelson@allantgroup.com> Subject: Re: FreeBSD 5.3 and Adaptec raidutils (again) Message-ID: <41C30F0F.3080302@freebsd.org> In-Reply-To: <22C3670E71A83C719BAC25E9@elric.arin.net> References: <A6125B2CFEDE2BEDF10D9FA6@elric.arin.net> <20041211004038.GC50516@dragon.nuxi.com> <11A4B937C9C745F2DD5B75EC@elric.arin.net> <20041217081458.GB10368@dan.emsphone.com> <41C30321.5060209@freebsd.org> <22C3670E71A83C719BAC25E9@elric.arin.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Rowley wrote: >>> Yes; you can work around it by declaring a temp variable, assigning it >>> the value of attachedTo, making whatever modification is necessary, >>> then assigning attachedTo=temp. Do this every time you get that error. >>> You /might/ also be able to just remove the PACKed attribute from the >>> attachedTo field, but that will cause havoc if the struct is supposed >>> to line up with something generated by the card. >>> >> >> I'd highly recommend against removing the packed attribute. > > > :) It does compile, when you remove packed. After commenting out the > unneeded semaphore union struct in basic.hh, the whole thing compiles. > The resulting raidutil binary spews out the same error as the one from > the current binary port about "Engine connect failed: COMPATIBILITY > number"... but that's to be expected. > > Scott, is Dan's suggestion about using a temp variable and to stop > passing by reference the right way to go? > > --Matt I agree with Dan's temp variable solution. I'm also open to discussion on the compatibility number thing. If you can make it work with the value provided by the current driver, then please do. Otherwise we can discuss reverting the value. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41C30F0F.3080302>