Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Apr 1998 11:53:32 -0600 (MDT)
From:      "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
To:        shimon@simon-shapiro.org
Cc:        current@FreeBSD.ORG
Subject:   Re: A CAM of worms
Message-ID:  <199804231753.LAA26658@narnia.plutotech.com>
In-Reply-To: <XFMail.980423065707.shimon@simon-shapiro.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> I am sorry to have joined this discussion so late.  I was on the road and
> no access to the net for all this time.

I hope you have read the full thread and know that this announcement
(which has hence been called off) was as much a surprise for me as it
was for anyone else.

> My exceptions to the proposed plan:
> 
> *  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.

> *  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.

> *  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.

> Simon

--
Justin

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?199804231753.LAA26658>