lkml.org 
[lkml]   [2012]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: linux-next: build failure after merge of the scsi tree
    On Wed, Mar 28, 2012 at 01:35:10AM +0300, Alexey Dobriyan wrote:
    > On Tue, Mar 27, 2012 at 03:22:16PM -0700, Greg KH wrote:
    > > On Wed, Mar 28, 2012 at 01:17:21AM +0300, Alexey Dobriyan wrote:
    > > > On Mon, Mar 26, 2012 at 07:07:21AM -0700, Greg KH wrote:
    > > > > On Mon, Mar 26, 2012 at 08:57:21AM +0100, James Bottomley wrote:
    > > > > > On Mon, 2012-03-26 at 12:17 +1100, Stephen Rothwell wrote:
    > > > > > > Hi James,
    > > > > > >
    > > > > > > After merging the scsi tree, today's linux-next build (x86_64 allmodconfig)
    > > > > > > failed like this:
    > > > > > >
    > > > > > > drivers/staging/keucr/scsiglue.c:349:2: error: unknown field 'proc_info' specified in initializer
    > > > > > > drivers/staging/rts_pstor/rtsx.c:258:2: error: unknown field 'proc_info' specified in initializer
    > > > > > > drivers/staging/rts5139/rts51x_scsi.c:2190:2: error: unknown field 'proc_info' specified in initializer
    > > > > > >
    > > > > > > Caused by commit 104c4fe25dc9 ("[SCSI] remove scsi_host_template::proc_info").
    > > > > > >
    > > > > > > Since this is a staging driver, I applied these following patches:
    > > > > >
    > > > > > Yes, that looks about right, thanks. We haven't seen anything about
    > > > > > these drivers on the SCSI list, so I've no idea where they are in
    > > > > > development.
    > > > >
    > > > > Why is new patches going into your tree right now, during the 3.4 merge
    > > > > window? API changes should have happened weeks ago, to let others fix
    > > > > up things like this.
    > > > >
    > > > > As for the "where they are in development", they vary, but, a simple
    > > > > grep should have shown you that these in-kernel drivers should also be
    > > > > fixed up, or at the least, give me the heads up to let me do it for you.
    > > > >
    > > > > Care to send me the patch that causes this problem so I can create a fix
    > > > > for this?
    > > >
    > > > See commits 422f07001d6638fdde28f1909cc9162bc7f571d3..104c4fe25dc9bde823ba4591e910a77071b98ab5
    > > > Especially the first one.

    I don't know where to find these patches, care to send them to me, or
    point me at a link with them?

    > > > Probably the best course of action is to remove proc_info code from
    > > > these drivers because the interface was deprecated for a long time.
    > >
    > > If the interface is depreciated, yes, I can remove it now, just let me
    > > know and I will do so.
    > >
    > > > The amount of code once removed from staging prevented me from doing
    > > > any work on them.
    > > >
    > > > Looking at staging ->read_proc users this is going to be a problem for
    > > > its removal. :-(
    > >
    > > Why?
    >
    > Because if staging does count, I can't remove the interface
    > without breaking allmodconfig and it would take forever to convert
    > staging stuff. I don't have energy to do it anymore.
    > Mainline still have several _hard_ ->read_proc conversions.
    > I've tried several times and failed.
    >
    > If staging doesn't count, I will break allmodconfig and all those nasty
    > emails will show up anyway implying that staging does count.

    I don't understand, if read_proc is depreciated, why can't I just remove
    it from the staging drivers and then all will be fine, right?

    confused,

    greg k-h


    \
     
     \ /
      Last update: 2012-03-29 01:55    [W:0.026 / U:33.200 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site