sa(4) driver changes available for test

Kenneth D. Merry ken at FreeBSD.ORG
Thu Mar 12 02:16:34 UTC 2015

On Sat, Mar 07, 2015 at 14:30:26 +0100, Harald Schmalzbauer wrote:
>  Bez?glich Kenneth D. Merry's Nachricht vom 19.02.2015 01:13 (localtime):
> > I have updated the patches.
> >
> > I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
> > I committed those separately.
> >
> > I have (hopefully) fixed the build for the stable/10 patches by MFCing
> > dependencies.  (One of them mav did for me, thanks!)
> >
> > Rough draft commit message:
> >
> >
> >
> > The patches against FreeBSD/head as of SVN revision 278975:
> >
> >
> >
> > And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:
> >
> >
> Hello,
> on 26/02/2105, r278964 seems to be part from the sa_changes patchset.
> Do you have a sa_changes.stable_10.20150226 ready?

I haven't done it yet, sorry.

> Or is it just a matter of exluding all parts, comitted with r278964 
> from the patchset?
> I've done so in the mean while:


> Noticed that in sys/dev/mps/mps_sas.c 'cdai.flags' gets conditionally
> (#if __FreeBSD_version >= 1100061) the new "CDAI_FLAG_NONE", while in
> sbin/camcontrol/camcontrol.c, this is unconditionally used. Haven't
> really looked at the code, mostly because my skills wouldN#t allow me to
> answer this qusteion myself, but is that versioncheck in mps_sas.c still
> vaild with the rest of the sa_driver-changes?

Yes, that's intentional.  The mps(4) and mpr(4) drivers are also maintained
outside the tree by LSI/Avago.  I usually try to put version checks in
there, so that things work when they try to compile against earlier
releases.  Otherwise they'd be putting in the same checks themselves.  It
is easier to do them when the changes go in the tree.

camcontrol(8), on the other hand, is only maintained in the FreeBSD tree.
So it only ever needs to build against the FreeBSD branch it is in.

Kenneth Merry
ken at FreeBSD.ORG

More information about the freebsd-current mailing list