[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable

James Bottomley James.Bottomley at HansenPartnership.com
Wed Jun 20 17:56:04 UTC 2012


On Wed, 2012-06-20 at 09:51 -0700, Greg KH wrote:
> On Wed, Jun 20, 2012 at 05:40:25PM +0100, James Bottomley wrote:
> > On Wed, 2012-06-20 at 08:12 -0700, Greg KH wrote:
> > > On Wed, Jun 20, 2012 at 08:32:24AM +0100, James Bottomley wrote:
> > > > Thinking about the problem from my point of view, I think the solution
> > > > might be to break up the staging tree: every participating maintainer
> > > > would have a staging branch for ugly drivers that needed polishing and
> > > > these could be accumulated into the staging tree (which may or may not
> > > > be the upstream kernel tree depending on how we feel).  This would mean
> > > > that at least the subsystem which understood the driver took
> > > > responsibility for it.
> > > 
> > > DRM and video already do this today, both in different ways.  DRM has
> > > the code within their subdirectory, but has the driver depend on
> > > CONFIG_STAGING.  Video has subdirectories in drivers/staging/ that I
> > > know to not touch at all.
> > > 
> > > Either way works just fine for me, if other subsystem maintainers want
> > > to do this, they are more than welcome to (just let me know if I'm not
> > > supposed to touch a subdirectory that they create.)
> > 
> > Either way is fine by me too ... if you want to create staging/scsi and
> > move the SCSI drivers into it, that works for us.
> 
> What scsi drivers should move into it?

I've no idea.  All I know is that when we tried to do an API change for
proc_ops, you said there were breakages in I think three SCSI drivers.
If they all got tossed from staging, I'm happy not to enquire
further ...

James




More information about the Ksummit-2012-discuss mailing list