Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Dec 2012 21:25:56 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Jeff Roberson <jroberson@jroberson.net>
Cc:        Ian Lepore <freebsd@damnhippie.dyndns.org>, current@freebsd.org
Subject:   Re: Call for testers, users with scsi cards
Message-ID:  <54F59F93-91A1-44B6-93F6-AB94F3BF2CC2@bsdimp.com>
In-Reply-To: <alpine.BSF.2.00.1212041456040.4081@desktop>
References:  <alpine.BSF.2.00.1212041131340.4081@desktop> <C442208D-42DF-4986-A88E-A7E404F3CCA3@bsdimp.com> <1354658563.87661.23.camel@revolution.hippie.lan> <alpine.BSF.2.00.1212041456040.4081@desktop>

next in thread | previous in thread | raw e-mail | index | archive | help

On Dec 4, 2012, at 5:58 PM, Jeff Roberson wrote:

> On Tue, 4 Dec 2012, Ian Lepore wrote:
>=20
>> On Tue, 2012-12-04 at 14:49 -0700, Warner Losh wrote:
>>> On Dec 4, 2012, at 2:36 PM, Jeff Roberson wrote:
>>>=20
>>>> http://people.freebsd.org/~jeff/loadccb.diff
>>>>=20
>>>> This patch consolidates all of the functions that map cam control =
blocks for DMA into one central function.  This change is a precursor to =
adding new features to the I/O stack.  It is mostly mechanical.  If you =
are running current on a raid or scsi card, especially if it is a lesser =
used one, I would really like you to apply this patch and report back =
any problems.  If it works you should notice nothing.  If it doesn't =
work you will probably panic immediately on I/O or otherwise no I/O will =
happen.
>>>=20
>>> I haven't tested it yet.  My only comment from reading it though =
would be to make subr_busdma.c be dependent on cam, since it can only =
used from cam.  We've grown sloppy about noting these dependencies in =
the tree...
>>>=20
>>> Warner
>>=20
>> Hmmm, if it's only used by cam, why isn't it in cam/ rather than =
kern/ ?
>=20
> kib pointed out drivers that use ccbs but do not depend on cam.  I =
also intend to consolidate many of the busdma_load_* functions into this =
subr_busdma.c eventually.  I will add a load_bio and things like =
load_uio and load_mbuf don't need to be re-implemented for every =
machine.  I will define a MD function that allows you to add virtual or =
physical segments piecemeal (as they all currently have) so that =
function may be called for each member in the uio, mbuf, ccb, or bio.

Sounds like a good reason to me...  Look forward to it...

Warner

> Thanks,
> Jeff
>=20
>>=20
>> -- Ian
>>=20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54F59F93-91A1-44B6-93F6-AB94F3BF2CC2>