lkml.org 
[lkml]   [2004]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: ide errors in 7-rc1-mm1 and later
    Date
    On Friday 04 of June 2004 17:23, Jens Axboe wrote:
    > On Fri, Jun 04 2004, Bartlomiej Zolnierkiewicz wrote:
    > > On Friday 04 of June 2004 14:47, Jens Axboe wrote:
    > > > On Fri, Jun 04 2004, Bartlomiej Zolnierkiewicz wrote:
    > > > > Well, thanks but I still think that your patch suits crappy code
    > > > > perfectly (you know all the complains).
    > > >
    > > > I'm not on a crusade to clean up drivers/ide, in fact I could not care
    > > > less it if rots away (thank fully it is doing just that, pata is going
    > > > away). Most of your complaints are not valid in my opinion (->wrq usage
    > >
    > > You are missing two facts:
    > > - I'm on the _crusade_ to clean drivers/ide and merge them with libata
    > > later
    >
    > I'm well aware of that.
    >
    > > - pata is (slowly) going away but support for it is not going _anywhere_
    > > (although some people are smoking 'libata pata' crack)
    > >
    > > > is fine. it's not pretty, but it's not broken as long as you serialize
    > > > access across the hwgroup of course). Like the rest, it's an artifact
    > > > of how messy the code paths are in there. That could be cleaned too
    > > > naturally, but that's someone elses job and I'm not about to increase
    > > > my work load in that area.
    > >
    > > Yep, you prefer to increase my work load instead.
    >
    > If you think that any change to the ide base is increasing your work
    > load, then yes. Otherwise no.

    No, only the messy ones.

    > > > That you need to queue pre/post flushes to support barriers is a
    > > > _driver implementation detail_ in my opinion. You don't want to even
    > > > advertise
    > >
    > > It is implementation braindamage IMO (but I'll buy it if rest is OK).
    >
    > Well feel free to pull a rabbit out of your hat and suggest something
    > else that works for barriers. It's mind boggling that nothing so far has
    > come out of t13 to address this, I guess data integrity isn't high on
    > their list.
    >
    > So in short, either shut up or put up.

    Yeah, this the hardest part. I'll see what can be done.

    > > > that to upper layers. I will move a little of that into the block
    > > > layer, if only because SATA will need it as well.
    > > >
    > > > As for REQ_DRIVE_TASK and ide_get_error_location(), well hell I do take
    > > > patches! If there's something you consider broken, damnit send a patch
    > >
    > > It is _your_ job to do it properly.
    >
    > I _am_ doing it properly. If you think otherwise, then I suggest you
    > show in code what you want changed. If you think it's my job to keep
    > changing the code based on unclear suggestions, then you are sadly
    > mistaken.

    Suggestions were clear, you've chosen to ignore them wishing that
    I will correct the patch or that you will push patch upstream anyway.

    > > There are no double standards, 'IDE crap embargo' holds for everyone.
    >
    > Like it or not, but ide code needs changing to support barriers one way

    Rule is simple "no more crappola in IDE" and I don't care what your
    patch does if this rule is violated.

    > or the other. If there's some part of the implementation you don't like,
    > then I suggest you show why. Since we appear to have reached a

    Damn, I showed it few times. You seem to contradict yourself.

    > discussion dead lock, I suggest you do so by showing a patch changing eg
    > the ide_get_error_location() stuff. Sadly you could have done this
    > roughly 10 times in the same time frame that you have written these
    > emails.

    Are you trying to trick me into doing your task?

    > > > to correct it and I'll surely merge it into the base if I agree it
    > > > makes sense. That's the way to get changes done if you feel something
    > > > should be different, snide remarks with basically zero detail is not.
    > >
    > > I think I provided enough details few times already.
    > > You can always ask in case of problems (keep linux-ide@ cc:-ed).
    > >
    > > [ First thing to do is to use REQ_DRIVE_TASKFILE not REQ_DRIVE_TASK. ]
    >
    > REQ_DRIVE_TASKFILE change I agree with, and yeah you have given enough
    > detail there. And I'll work iget_get_error_location() to fill the holes
    > in case of flush errors. I'll get that change done soonish and post
    > updates for -mm.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:03    [W:0.030 / U:0.308 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site