Date: Sun, 21 Jun 1998 16:27:00 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: dufault@hda.com (Peter Dufault) Cc: ken@plutotech.com, darrylo@sr.hp.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? Message-ID: <199806212227.QAA24363@panzer.plutotech.com> In-Reply-To: <199806211052.GAA27439@hda.hda.com> from Peter Dufault at "Jun 21, 98 06:52:33 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Dufault wrote... > > Darryl Okahata wrote... > > > "Kenneth D. Merry" <ken@plutotech.com> wrote: > > > > > > > - How many more programs use this (scsireq) interface? > > > > > > Does /sbin/scsi work (or has it been ported)? If so, great. I've > > > got some perl scripts that fdisk/disklabel/newfs arbitrary disks, and > > > they rely upon scsi(8). > > > > Well, scsi(8) has not been ported, it has been replaced by > > camcontrol. camcontrol should be able to do everything that scsi(8) did, > > and more. > > People can also dig up "scsinew.tgz" which is a slicing-dicing version > of scsi(8) that is a superset but can run as a server, generate > Tcl data structures, and has better abilities for command scripts, > can generate code stubs from the ascii CDB description, etc: Hmm, sounds interesting. > This lets scsi(8) recognize commands such as this when set to Tcl > output mode: [ ... ] > Or this for code output: [ ... ] > I don't know where it is archived now. There wasn't much interest > in this the last time I showed it around. Well, I would be interested in taking a look at it. I may be able to incorporate some of the ideas/features into the CAM userland stuff. I've already incorporated the buffer parsing code from libscsi into libcam, and I've put the mode page editing code from scsi(8) into camcontrol. (neither is in the currently released snapshot, but both will be in the next snapshot) One thing I'll probably do is make hardlinks to camcontrol so that there are several different programs you can call, rather than trying to remember command line switches that sometimes don't really resemble the functions they perform. i.e.: scsi_tur, scsi_start, scsi_stop, scsi_read_defects, scsi_inquiry, scsi_cmd, scsi_mode_page, scsi_rescan, and so on. > As I've said in the past, IMHO programs are better than libraries. Well, I think it's a good idea to put code in a library if it could be generally useful. Thus the idea behind libscsi and libcam -- there are some interface routines that more programs than scsi(8) and camcontrol(8) would want to use. 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?199806212227.QAA24363>