Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Apr 1998 09:46:09 -0700 (PDT)
From:      Simon Shapiro <shimon@simon-shapiro.org>
To:        "Justin T. Gibbs" <gibbs@narnia.plutotech.com>, scsi@FreeBSD.ORG, current@FreeBSD.ORG
Subject:   Re: A CAM of worms
Message-ID:  <XFMail.980426094351.shimon@simon-shapiro.org>
In-Reply-To: <199804231753.LAA26658@narnia.plutotech.com>

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

On 23-Apr-98 Justin T. Gibbs wrote:
 ...

>> *  No migration path;  The is no mechanism to migrate at all.  We need a
>>    way to have the same system boot either way.  We need a mechanism to
>>    maintain source for the old systems and switch back.
> 
> There is certainly a migration path.  Run a CAM kernel or don't.  Must
> developers I know have plenty of space to store two sys trees.  As I
> have stated to Julian several times, I will not polute the CAM code
> with #ifdefs, or gratuitously rename controller driver file names or
> "config names" just so you can build a kernel both ways.  If you want
> the code to go on a branch first, fine by me, but it is my intention
> to only put the code into CVS at all once the minimum amount of device
> support acceptable to users of current has been developed and tested.

I have no argument here...

>> *  No migration guide; The is no documentation on the new mechanism, its
>>    interfeaces, requirements, etc.  I asked, several times, politely,
>>    and
>>    privately, for at least a list of functions, their intended purpose
>>    and
>>    the entry points into both HBA drivers and personality drivers.  The
>>    ``I
>>    do not have time'' answer is simply not enough.  If there is no time
>>    to
>>    list the API's maybe the code change should be held until there is
>>    time.
> 
> This is in the works and will be available long before any potential flag
> day.

Great!  I really want to move the DPT driver to CAM, but with a new job and
all I want to make sure I do it as intended (by you, in designing CAM) and
not as guessed (by me, reading the driver to one particular HBA or another).

>> *  The idea of overnight obsolesence of all the existing SCSI code is a
>>    bit, shall we say, aggressive.  Although I have all the confidence in
>>    the
>>    world that the CAM code is wonderfully reliable, efficient and great,
>>    sone of us earthly mortals would like to have a chance to compile and
>>    run
>>    the two systems side by side, at least until the porting is done.
> 
> Overnight?  This project has been in the works for several months.  If
> you have concerns about the CAM architecture the code has been available
> for you to run and review for some time.

This is not my issue at all.  I stated before that I trust it is good and
correct.  But my (aparently wrong) impression that the 28th of April
signifis a drop in the support for the (still) current architecture led me
to think that in two days from now All the kernel will support is CAM, and
non-CAM systems are out in the cold.

I am glad to see that I was wrong.

Simon

BTW, Your mail still arrives here with: Nn:Pluto.freebsd.current, and I
still am not allowed to post to that newsgroup :-)

Simon





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



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