Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1721905

Re: linux-next: manual merge of the scsi tree with the staging tree

From "greg@kroah.com" <greg@kroah.com>
Newsgroups linux.kernel
Subject Re: linux-next: manual merge of the scsi tree with the staging tree
Date 2017-08-28 20:50 +0200
Message-ID <ujxgK-Em-21@gated-at.bofh.it> (permalink)
References (2 earlier) <ujusy-7mE-5@gated-at.bofh.it> <ujuLT-7II-9@gated-at.bofh.it> <ujveW-7TT-29@gated-at.bofh.it> <ujvoC-7Xb-19@gated-at.bofh.it> <ujwul-6V-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, Aug 28, 2017 at 06:51:59PM +0100, James Bottomley wrote:
> On Mon, 2017-08-28 at 18:44 +0200, greg@kroah.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@kroah.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.

This driver has been in the tree for almost 2 years now, with no
problems in this area before.  It, and the infrastructure around it, has
needed hundreds, if not thousands, of patches and changes and reworks to
get it to the almost readable state it is in today.

It was anything but a "quick trip through lindent".

And we don't have code in the "real" part of the kernel depend on code
in drivers/staging/, as that would not work.

So let's just keep things as they are here, there's been no issues with
this for 2 years, and for times when there is, great, let me know and we
can work to fix things up.  You are always free to break staging drivers
with api changes, it's up to the owner of the staging driver to fix the
issues in that case.

thanks,

greg k-h

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

linux-next: manual merge of the scsi tree with the staging tree Stephen Rothwell <sfr@canb.auug.org.au> - 2017-08-28 08:50 +0200
  Re: linux-next: manual merge of the scsi tree with the staging tree Greg KH <greg@kroah.com> - 2017-08-28 08:50 +0200
    Re: linux-next: manual merge of the scsi tree with the staging tree Bart Van Assche <Bart.VanAssche@wdc.com> - 2017-08-28 17:50 +0200
      Re: linux-next: manual merge of the scsi tree with the staging tree "greg@kroah.com" <greg@kroah.com> - 2017-08-28 18:10 +0200
        Re: linux-next: manual merge of the scsi tree with the staging tree Bart Van Assche <Bart.VanAssche@wdc.com> - 2017-08-28 18:40 +0200
          Re: linux-next: manual merge of the scsi tree with the staging tree "greg@kroah.com" <greg@kroah.com> - 2017-08-28 18:50 +0200
            RE: linux-next: manual merge of the scsi tree with the staging tree "Wadgaonkar, Sameer Laxmikant" <Sameer.Wadgaonkar@unisys.com> - 2017-08-28 19:10 +0200
            Re: linux-next: manual merge of the scsi tree with the staging tree James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-08-28 20:00 +0200
              Re: linux-next: manual merge of the scsi tree with the staging tree "greg@kroah.com" <greg@kroah.com> - 2017-08-28 20:50 +0200
  Re: linux-next: manual merge of the scsi tree with the staging tree Stephen Rothwell <sfr@canb.auug.org.au> - 2017-09-05 02:20 +0200

csiph-web