Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Mar 1998 12:07:55 -0800 (PST)
From:      Simon Shapiro <shimon@simon-shapiro.org>
To:        Karl Denninger <karl@mcs.net>
Cc:        scsi@FreeBSD.ORG
Subject:   Re: Any thought given to...
Message-ID:  <XFMail.980316120755.shimon@simon-shapiro.org>
In-Reply-To: <19980316124614.64072@mcs.net>

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

On 16-Mar-98 Karl Denninger wrote:
> On Mon, Mar 16, 1998 at 10:44:07AM -0800, Simon Shapiro wrote:
>> 
>> On 16-Mar-98 Karl Denninger wrote:
>> > Making CAM a conditional extract-and-compile thing (ie: an option to
>> > "make
>> > world")?
>> > 
>> > Is this even reasonable to attempt within the confines of CVS?
>> 
>> Last I checked, CAM still lacked (aside from most SCSI HBA drivers)
>> complete support for tapes, CD, CPU, WORM, etc.,  
> 
> Tapes do in fact work in the default density (which is where most people
> use
> them).  I know 'cause I'm doing it :-)

Good.

> CDs appear to work, including autochangers (!).  So do removable media
> (which is problematic with the existing layer).

Even better.

> There ARE host adapters which are missing - a lot of them.

I know I would like to move the DPT driver to CAM.  Just where is the time?

>> Since it is not possible
>> to have CAM and existing layers co-exist (Is this correct, Justin?),
>> once
>> you switch over, you cannot have a complete, functional system.  This, I
>> think, will inhibit what you are asking for.
>> 
>> Simon
> 
> That's why I suggested making it a compile-time (or even CVS extract
> time)
> option.  Compile time would be even better, but that's admittedly a PITA;
> extract-time might be a lot easier to do.

This is Justin's baby.  He should make the decision.  I'll voite for
compile time option.

> I agree that its not "prime time" at this point.  But it is a major
> improvement in a number of areas over the old drivers, including
> performance levels under real load profiles.

Although I was born in Tiberias and not Missuri, I'd concur with you when I
see it.  I see no under-load failures with the existing code.  The only
thing visible in my corner is dropping interrupts.  This I am sure comes
from elsewhere (fast_intr and such).

Simon


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980316120755.shimon>