Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Jun 1998 22:14:25 -0600 (MDT)
From:      "Kenneth D. Merry" <ken@plutotech.com>
To:        jonny@jonny.eng.br (Joao Carlos Mendes Luis)
Cc:        ken@plutotech.com, jonny@jonny.eng.br, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG
Subject:   Re: Rolling CAM in, what is still needed?
Message-ID:  <199806190414.WAA10410@panzer.plutotech.com>
In-Reply-To: <199806190400.BAA25325@roma.coe.ufrj.br> from Joao Carlos Mendes Luis at "Jun 19, 98 01:00:54 am"

next in thread | previous in thread | raw e-mail | index | archive | help
Joao Carlos Mendes Luis wrote...
> #define quoting(Kenneth D. Merry)
> // 	I know that changes in API can be a PITA, I had to port a very
> // large application from the old scsireq/SCIOCCOMMAND system to the new
> // passthrough driver.  We can't keep old API's around forever for no
> // particular reason, so I'd rather go ahead and port things.
> 
> Sorry for my ignorance, but is this interface FreeBSD only ?

	Nope, it's also used in NetBSD and OpenBSD, I think.

> If it's somewhat generic (say, *BSD), I'd prefer to have both,
> and have immediate portability for "future" applications.
> Is there a big advantage on the new scheme ?

	Yeah, it doesn't involve needless translation, and you can send
more than just SCSI commands with it.  You can send any type of CCB using
the standard passthrough ioctl.

> At least, while CAM is in transition mode, being available only
> as patches, the compatibilty API would make easy to choose cam
> or not-cam during boot time (for those interfaces available in
> both modes, of course).  I hope that's what you said above.

	Yeah, you could do it that way I suppose.  But there's more than
just random SCSI utilities that will break if you run a CAM userland with a
regular -current kernel.  The device statistics code is completely
different in CAM, and all the dk* stuff doesn't exist anymore.  i.e.
systat, iostat, vmstat and rpc.rstatd compiled under CAM won't work right
with a regular -current kernel, and vice versa.

> As always, JMHO, and not being an involved programmer, my vote
> is not much here.  :)

	I'm not terribly inclined to do it myself, at the moment I don't
think it's really worth the effort.  If someone else thinks it's important
to have scsireq support, and wants to go through the trouble to do it, I
may be able to fish out my (probably now broken) code to implement the 
SCIOCCOMMAND in the passthrough driver.  You'll still have to point the
applications to /dev/rpassn, though.


Ken
-- 
Kenneth Merry
ken@plutotech.com

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?199806190414.WAA10410>