From owner-cvs-all@FreeBSD.ORG Sun Apr 8 01:01:21 2007 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8274A16A405; Sun, 8 Apr 2007 01:01:21 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 45A8F13C465; Sun, 8 Apr 2007 01:01:21 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id l3811CCp072471; Sat, 7 Apr 2007 18:01:20 -0700 (PDT) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id l3811CiQ072468; Sat, 7 Apr 2007 18:01:12 -0700 (PDT) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Sat, 7 Apr 2007 18:01:12 -0700 (PDT) From: mjacob@freebsd.org To: Scott Long In-Reply-To: <46183104.6080904@samsco.org> Message-ID: <20070407175932.A72446@ns1.feral.com> References: <200704071940.l37Jew2t013708@repoman.freebsd.org> <20070407131228.L71232@ns1.feral.com> <46183104.6080904@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Scott Long , mjacob@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_sg.c scsi_sg.h src/sys/modules/cam Makefile src/sys/conf NOTES files src/sys/compat/linux linux_ioctl.c linux_ioctl.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2007 01:01:21 -0000 Oh, agreed that it's unpleasant. Better than Solaris tho. By doing this you may have made FreeBSD a viable choice with respect to storagse. There are a lot of management tools for linux storage that use the sg interfaces. Bravo. > To tell you the truth, the SG device has one of the worst programming > interfaces that I've ever seen. Even the various official docs on it > complain about how bad it is. I've written apps for CAM, including a > swiss-army-knife java-based management app, and CAM is vastly superior. > I tried porting the app to linux and gave up due to how limited and > unpleasant it was. From the kernel side, it's even scarier. > > But beyond that, the work I committed here was about opening up FreeBSD > to more storage management opportunities. So I'm happy with whatever > anyone wants to do with it that furthers that goal. I'd like to see > the native interface be used as a bridge to help introduce programmers > to FreeBSD and CAM; if the sg3_utils package is a step in that > direction or if it provides tools that camcontrol doesn't, then go for > it. > > Scott > > > mjacob@freebsd.org wrote: >> >> Cool- does this mean we should commit sg3_utils to ports then? >> >> On Sat, 7 Apr 2007, Scott Long wrote: >> >>> scottl 2007-04-07 19:40:58 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/modules/cam Makefile >>> sys/conf files NOTES >>> sys/compat/linux linux_ioctl.c linux_ioctl.h >>> Added files: >>> sys/cam/scsi scsi_sg.c scsi_sg.h >>> Log: >>> Add the CAM 'SG' peripheral device. This device implements a subset of >>> the >>> Linux SCSI SG passthrough device API. The intention is to allow for both >>> running of Linux apps that want to talk to /dev/sg* nodes, and to >>> facilitate >>> porting of apps from Linux to FreeBSD. As such, both native and >>> linuxolator >>> entry points and definitions are provided. >>> >>> Caveats: >>> - This does not support the procfs and sysfs nodes that the Linux SG >>> driver provides. Some Linux apps may rely on these for operation, >>> others may only use them for informational purposes. >>> - More ioctls need to be implemented. >>> - Linux uses a naming scheme of "sg[a-z]" for devices, while FreeBSD >>> uses a >>> scheme of "sg[0-9]". Devfs aliasis (symlinks) are automatically >>> created >>> to link the two together. However, tools like camcontrol only see the >>> native names. >>> - Some operations were originally designed to return byte counts or >>> other >>> data directly as the syscall return value. The linuxolator doesn't >>> appear >>> to support this well, so this driver just punts for these cases. >>> >>> Now that the driver is in place, others are welcome to add missing >>> functionality. Thanks to Roman Divacky for pushing this work along. >>> >>> Revision Changes Path >>> 1.1 +987 -0 src/sys/cam/scsi/scsi_sg.c (new) >>> 1.1 +139 -0 src/sys/cam/scsi/scsi_sg.h (new) >>> 1.138 +27 -0 src/sys/compat/linux/linux_ioctl.c >>> 1.25 +34 -0 src/sys/compat/linux/linux_ioctl.h >>> 1.1419 +5 -0 src/sys/conf/NOTES >>> 1.1191 +1 -0 src/sys/conf/files >>> 1.15 +1 -0 src/sys/modules/cam/Makefile >>> > >