From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73073C43387 for ; Thu, 17 Jan 2019 00:56:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3B0FF20657 for ; Thu, 17 Jan 2019 00:56:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727130AbfAQA4a (ORCPT ); Wed, 16 Jan 2019 19:56:30 -0500 Received: from smtp.infotech.no ([82.134.31.41]:45648 "EHLO smtp.infotech.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725648AbfAQA43 (ORCPT ); Wed, 16 Jan 2019 19:56:29 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id 84CE6204237; Thu, 17 Jan 2019 01:56:27 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOtBcti-Zl-U; Thu, 17 Jan 2019 01:56:25 +0100 (CET) Received: from [192.168.48.23] (host-192.252-161-233.dyn.295.ca [192.252.161.233]) by smtp.infotech.no (Postfix) with ESMTPA id E1537204144; Thu, 17 Jan 2019 01:56:24 +0100 (CET) Reply-To: dgilbert@interlog.com Subject: Re: [ANNOUNCE] v4 sg driver: ready for testing From: Douglas Gilbert To: SCSI development list , linux-kernel References: <0adbaea3-4110-708c-5ace-ad145f6daad7@interlog.com> Cc: Tony Battersby Message-ID: <03036d97-7316-4a17-4ae5-15d02eb96607@interlog.com> Date: Wed, 16 Jan 2019 19:56:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <0adbaea3-4110-708c-5ace-ad145f6daad7@interlog.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org There is an update to the SCSI Generic (sg) v4 driver adding synchronous and asynchronous bidi command support. Plus lots of fixes and some minor improvements. See: http://sg.danny.cz/sg/sg_v40.html The kernel code is split in two in the tarball below, one targeting lk 5.0 and the other targeting lk 4.20 and earlier ***. Each section contains the 3 files that represent the sg v4 driver plus a meandering 17 part patchset. Those patchsets reflect the driver's rewrite rather than a logical progression. http://sg.danny.cz/sg/p/sgv4_20190116.tgz Plus there are updated testing utilities in sg3_utils-1.45 (beta, revision 807) at the top of this page: http://sg.danny.cz/sg/index.html Doug Gilbert *** the reason for the split is the tree wide change to the access_ok() function. On 2018-12-25 2:39 a.m., Douglas Gilbert wrote: > There is an update to the sg v4 driver with some error fixes, SIGIO and > RT signals work plus single READ, multiple WRITE sharing support. See: >     http://sg.danny.cz/sg/sg_v40.html > > with testing utilities in sg3_utils-1.45 (beta, revision 802) on the main > page: >     http://sg.danny.cz/sg/index.html > > Doug Gilbert > > > On 2018-12-18 6:41 p.m., Douglas Gilbert wrote: >> After an underwhelming response to my intermediate level patchsets to >> modernize the sg driver in October this year (see "[PATCH 0/8] sg: major >> cleanup, remove max_queue limit" followed by v2 and v3 between 20181019 >> and 20181028), I decided to move ahead and add the functionality proposed >> for the version 4 sg driver. That means accepting interface objects of >> type 'struct sg_io_v4' (as found in include/uapi/linux/bsg) plus two new >> ioctls: SG_IOSUBMIT and SG_IORECEIVE as proposed by Linus Torvalds to >> replace the unloved write(2)/read(2) asynchronous interface ****. There >> is a new feature called "sharing" explained in the web page (see below). >> >> Yes, there is a patchset available (14 part and growing) but even without >> explanatory comments at the top of each patch, that patchset is 4 times >> larger than the v4 sg driver (i.e. the finished product) and over 6 >> times larger than the original v3 sg driver! Part of the reason for >> the patchset size is the multiple backtracks and rewrites associated >> with a real development process. The cleanest patchset would have 3 >> parts: >>    1) split the current include/scsi/sg.h into the end product headers: >>       include/uapi/scsi/sg.h and include/scsi/sg.h >>    2) delete drivers/scsi/sg.c >>    3) add the v4 drivers/scsi/sg.c >> >> After part 2) you could build a kernel and I can guarantee that no-one >> will be able to find any sg driver bugs but some users might get upset >> (but not the Linux security folks). >> >> So there is a working v4 sg driver discussed here, with a download: >>      http://sg.danny.cz/sg/sg_v40.html >> >> I will keep that page up to date while the driver is in this phase. >> There is a sg3_utils beta of 1.45 (revision 799) package in the News >> section at the top of the main page: >>      http://sg.danny.cz/sg/index.html >> >> That sg3_utils beta package will use the v4 sg interface via sg devices >> if the v4 driver is detected. There are also three test utilities in >> the 'testing' directory designed to exercise the v4 extensions. >> >> The degree of backward compatibility with the v3 driver should be high >> but there are limits to backward compatibility. As an example, it is >> possible that there are user apps that depend on hitting the 16 >> outstanding command limit (per fd) in the v3 driver and go "wild" >> when v4 removes that ceiling. If so, a "high_v3_compat" driver option >> could be added to put that ceiling back. >> >> The only way to find out is for folks to try and if there is a failure, >> contact me, or send mail to this list. Code reviews welcome as well. >> >> Doug Gilbert >> >> >> **** I felt this was a better use of my time than trying to invent a new >>       debug/trace mechanism for the whole SCSI subsystem. That is what >>       _SCSI_ system maintainers are for, I'll stick to the sg driver (and >>       scsi_debug). Add user space tools and there is more than enough work >>       there ... >> >