Date: Tue, 23 Jun 1998 18:17:24 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: dufault@hda.com (Peter Dufault) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? Message-ID: <199806240017.SAA06568@panzer.plutotech.com> In-Reply-To: <199806221039.GAA00170@hda.hda.com> from Peter Dufault at "Jun 22, 98 06:39:32 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Dufault wrote... > > (I may try putting in support for just specifying devices like that instead > > of -n da -u 0 if I end up re-working the command line options.) A > > complicating factor to all this is all the arguments for the command line > > CDB parsing code. > > Can you provide a look up table for device nicknames between > scsi(8) and camcontrol? The newer one at least knows how to go > from sd0 to /dev/rsd0.ctl. Well, the CAM library can already do that. Basically, cam_open_device() will try to map almost any string you give it to the correct device name and unit number. For instance, if you give it: /dev/rsd0.ctl It will translate that into "da" and 0. Then it asks the kernel for the passthrough device that corresponds to that physical device. There really isn't any way to have a static lookup table, unless the user hardwires passthrough devices in their kernel. Passthrough device unit numbers are assigned (in the non-hardwired case) in the order that devices are found. > > > 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. > > > > That is an option, although I'd have to look at it and see what it > > would entail. Linux binary support is good, since it allows us to run > > commercial applications that haven't been ported to FreeBSD. The question > > is, what sort of application base are we talking about here? Are there > > lots of binary-only Linux applications (or even just one major application) > > that need SCSI passthrough support? > > There are many that already have FreeBSD native interfaces. It is > a question of deciding whether to commit to that part of the Linux > ABI. Right. One thing I'd like to know, though, is are there any Linux programs that are binary-only and do SCSI pass-through? If not, I don't see the point of hacking it in. > It is far more important to support the clean cutover for the > FreeBSD installed base, and time is better spent ensuring that than > any Linux adventure. I think a clean cutover for the FreeBSD installed base can probably be achieved (even without providing the old interface in the kernel) if we: 1. Document the new interface thoroughly. 2. Make sure that all known ports that use SCSI passthrough commands are ported, so that when 3.0 goes out, users can either make the port or install the package and be up and running. Any remaining problems that show up will be a result of one of the following: 1. The user is using a program like xmcd, tosha, etc., and hasn't recompiled it. 2. The user is using some program that does SCSI passthrough that we don't know about. I'm more concerned about #2 than #1. > > I'm still not convinced it's absolutely necessary to support > > even the current ioctl interface, since I haven't really heard of many > > programs that would be affected. The current list is: cd-write, SANE, and > > cdd. (cdrecord, tosha and xmcd have been ported) That certainly isn't an > > insurmountable list, and once those are ported, it'll be a simple matter of > > rebuilding the port once we switch over to CAM. > > You've provided the important one from my point of view which is the > command interface. The point is that in the last few months I've > had three groups contacting me about embedded SCSI in FreeBSD. > Some are going on their own and I've pointed all of them at you folk. > > However, the current CAM versus "classic" and the issue of volatility > for the next two years is a murky one. My opinion is that policy > should be "we shall make it painless until it is a non-issue" and > never "you shall be assimilated" (which snuck out earlier - Hi > Mike). Public statements should be weighed against ensuring > this aspect is a non-issue. Well, how about this: - we provide the SCIOCCOMMAND/scsireq/libscsi interface as a compatibility interface for some period of time, with the (documented in the man pages) understanding that it will eventually go away. - we put a "nag" printf in the kernel that prints out once per boot (whenever someone uses the SCIOCCOMMAND ioctl) to tell the user that they're using a deprecated interface. That should take care of problem users #1 and #2 above, since it would provide binary compatibility. It will also nag them so that they know they're using an outdated interface and they can take steps to port their software to the new interface. I certainly don't want to leave people high and dry when we switch over to CAM. Thus the reason we're waiting on putting it in the tree until more hardware is supported. I'm not averse to providing a compatibility interface, but I'd like to avoid keeping the code in there indefinitely. Comments? 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?199806240017.SAA06568>