lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 28 Aug 2017 18:51:59 +0100
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     "greg@...ah.com" <greg@...ah.com>,
        Bart Van Assche <Bart.VanAssche@....com>
Cc:     "sfr@...b.auug.org.au" <sfr@...b.auug.org.au>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "hare@...e.de" <hare@...e.de>,
        "linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "sameer.wadgaonkar@...sys.com" <sameer.wadgaonkar@...sys.com>,
        linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: linux-next: manual merge of the scsi tree with the staging tree

On Mon, 2017-08-28 at 18:44 +0200, greg@...ah.com wrote:
> On Mon, Aug 28, 2017 at 04:36:06PM +0000, Bart Van Assche wrote:
> > 
> > On Mon, 2017-08-28 at 18:05 +0200, greg@...ah.com wrote:
> > > 
> > > On Mon, Aug 28, 2017 at 03:41:28PM +0000, Bart Van Assche wrote:
> > > > 
> > > > * Most SCSI drivers exist under drivers/scsi, including the
> > > > virtio-scsi and   xen-scsifront drivers. So why has the
> > > > visorhba driver been added under unisys/visorhba?
> > > 
> > > That's because right now it's still a staging driver.  Also,
> > > there are other scsi drivers in other portions of the kernel tree
> > > (like the USB driver), so there's no hard rule that all scsi
> > > drivers have to be under drivers/scsi/
> > > 
> > > <snip>
> > > 
> > > Please provide this review to them, on the properly mailing list,
> > > I'm sure they would be glad to get it.
> > 
> > OK, I will do that. BTW, is there a written down version of the
> > rules for adding a driver under drivers/staging available
> > somewhere? 
> 
> The only 2 rules for adding a new drivers/staging driver is:
> 	- has to compile
> 	- correct license
> and sometimes we let code in if the first one isn't true :)
> 
> > 
> > As far as I can see the visorhba driver went in without the linux-
> > scsi mailing list having been CC-ed. See also Benjamin Romer,
> > [PATCH] staging: unisys: Add s-Par visorhba, linux-driver-devel
> > mailing list, July 2015
> > (https://urldefense.proofpoint.com/v2/url?u=https-3A__marc.info_-
> > 3Fl-3Dlinux-2Ddriver-2Ddevel-26m-
> > 3D143681271902628&d=DwIBAg&c=jf_iaSHvJObTbx-
> > siA1ZOg&r=lxuMXTRCffN3cvb-
> > aRKL97jBhWZUIH_7zc3AgXUz9Mw&m=muMI5n73yuzpaRBjZnIrYLfhcO8lIP0JZSjBG
> > D1LC5I&s=76_tO8QEuhUmhJPijDkweBOfh6DLPRILWj9Rhphb8j0&e= ).
> 
> That's totally normal, why would the scsi developers care about a
> staging driver in such a rough state.  Only when it looks "good
> enough" would we ask for a scsi developer review to move it out of
> staging.

I think I've said before, we'd really rather a SCSI driver went via the
SCSI tree because most of what's wrong with it will be the mechanics of
the driver and its interaction with the SCSI and block subsystems which
simply don't get looked at in the staging tree.  The aesthetics and the
formatting issues are mostly fixed by a quick trip through lindent or a
brief education of the submitters on Linux style.

James

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ