Date: Sun, 21 Jun 1998 19:15:33 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: ken@plutotech.com (Kenneth D. Merry) Cc: dufault@hda.com, ken@plutotech.com, darrylo@sr.hp.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? Message-ID: <199806212315.TAA28473@hda.hda.com> In-Reply-To: <199806212227.QAA24363@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 21, 98 04:27:00 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. It is at least in my home directory on freefall, and is someplace else. I've lost track of what the incoming elves do to files uploaded to incoming. I poked around on the FreeBSD home page and didn't find out. If you don't see it I can upload another copy. > 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) Good - then you may like the newer stuff. I didn't incorporate it into scsi(8) because I didn't want an sbin binary to grow. I don't know what your plans are for camcontrol, however, you'll probably want to keep the sbin-ness in mind. The server ability would be good even for a program in sbin to support remote support on some sort of embedded scsi device. > 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. I don't like this - this boils down to "scsi_tur" versus "scsi tur". > > 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. Yes, there is always a baseline that should be at least designed as if it is in a library that a command will be based on, and that should be formally placed in a library. Since you have less control over what people do with your library and pretty much full control over the interface to your program, and because a programs interface is typically higher level and easier to change, I'm a bigger fan of a program interface than a library interface. Porting scsi programs over is the only place I see a library useful. The notion behind scsinew is you prototype using the command interface and that have it spit out code if you need it. Just to show I'm not a stickler about high level interfaces, I think that in addition to preserving the current ioctl interface (which I think should be done) it would be good to support the Linux SCSI interface thus extending the Linux binary support. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval 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?199806212315.TAA28473>