Date: Mon, 22 Jun 1998 06:39:32 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: ken@plutotech.com (Kenneth D. Merry) Cc: dufault@hda.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? Message-ID: <199806221039.GAA00170@hda.hda.com> In-Reply-To: <199806220440.WAA25738@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 21, 98 10:40:50 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> I don't have an account on freefall, and I don't see it in the > incoming directory. Could you upload it again? Yes. To compile properly on a recent system you'll have to sprinkle in some includes courtesy of advances in reducing system include nesting. I won't have time to do that so heads up. (...) > > I don't like this - this boils down to "scsi_tur" versus "scsi tur". > > Good point. I guess I could just do it that way. Basically, the > problem I have now is that camcontrol is starting to get optionitis. I can > just continue to use more option letters, or I can try doing something to > make it a little more sane. Here's what the current usage statement looks > like: > > usage: camcontrol <options> [ optional args ] ... (And now I cut out an argument for needing more lines in syscons...) > > Fair number of options, 'eh? Maybe what you're saying would work > better, i.e.: > > camcontrol inquiry -S da0 It is also extensible in the ASCII config file so more creeping options aren't needed and instead of sending magic command lines you can send a config snippet. > (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. > > 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. 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'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. 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?199806221039.GAA00170>