Re: You WIN ...

Re: You WIN ...

[Willem Riede]

On 2001.12.31 07:58 Jens Axboe wrote:
> 
> (sat on this for a few days not to boil over)
> 
> On Sat, Dec 29 2001, Andre Hedrick wrote:
> > 
> > Jens,
> > 
> > You win -- it is not worth trying to work with you at this time.
> > All you and I have done is become bitter enemies.
> 
I'm not sure that entering this debate is a good idea, but it is 
so sad to see two such valuable contributers to Linux bicker
with each other...

On the infrequent occasion that I had to exchange email with Andre,
I've realized it is very hard to communicate with him (sorry Andre),
so I understand how Jens must be feeling.

On the other hand - and that may just be my problem, as I don't claim 
to have enough expertise - I've read Suparna's and Jens' notes, 
reviewed the code changes and still don't understand where the 
whole ide/scsi/block/char i/o re-design is going. (I can see what has 
been done - that's well documented, but not what's coming or why - a 
discussion of the decomposition in layers, what is each' responsibility
and what's the api between them, simplifications/improvements that
result)

Likewise, I've not been able to discern from Andre's posts what it is
he's trying to do. No idea how that violates what Jens wants.

But Andre is clearly an unrivaled expert in his area, and the recent
results posted to this list are impressive, so I understand that
Andre feels frustrated not to be able to get those improvements into
the kernel.

As a linux user, I certainly want the benefit of what both parties have 
to offer. It would have to satisfy Linus' taste, fit Jens' design, and 
realize Andre's improvements. There ought to be a way for that to happen.

Now, if only I was smart enough to figure that one out :-(

Regards, Willem Riede.
(maintainer of osst tape driver)

Re: You WIN ...

[Jens Axboe]

(sat on this for a few days not to boil over)

On Sat, Dec 29 2001, Andre Hedrick wrote:
> 
> Jens,
> 
> You win -- it is not worth trying to work with you at this time.
> All you and I have done is become bitter enemies.
> 
> Next, I do not know all the details of the kernel, but what I know is
> that neither one of us is willing to listen and learn.  However, I have
> tried to get answers from you public and private, and nothing.  You may

I've answered lots of your mails and inquiries on irc, I frankly cannot
see how I can improve there.

> get your wish granted to replace me in the future, as this has been your
> stated goal from the past to me directly.

I've never stated that I want to replace you. In fact I've stated
several times that I definitely do not want to maintain low level IDE
code (or any other any directly hardware related driver, nothing but
trouble). I stick to core kernel mainly, makes me happy.

> In closing, there were several cases of filesystem corruption based on
> partition offsets and other various items.  This was totally unacceptable
> for the most part.  I truly think that you do not see what the object of

Please -- there was _one_ case of a one-off in partition handling with
an obscure partition format caused by a missing include, *this was not a
bio problem*. Please list the "various other items" for me. Are you
making stuff up again now?

You seem to naively believe that if you driver passed some ata analyzer
tests or follows the specification state diagrams to the letter, that
it's perfect. That is just so obviously wrong. How about timing related
bugs in your driver under different circumstances? SMP (or just irq)
related races?

I have seen data corruption several times while developing bio
(expected, I'm not perfect), however _none_ of these could have been
avoided with using an analyzer. The low level block driver just did what
I/bio asked it to do, regardless of the data contents or data direction
was right or not. Too bad.

We have seen data corruption in stable kernels before after block or IDE
change. The former was due to missing locking lately, or head-active
list corruption. The latter was a plugging bug in IDE. Neither of these
could have been caught with an analyzer.

> "BLOCK" is all about, regardless that you are clever and quick.  You have
> decided that block will define the interface to the drivers and thus the
> drivers can not conform to standards set forth by the people creating the
> physical layer.

Not so, I'm not telling drivers what to do. I'm making the block
interface as flexible as I can for drivers, while also making it easier
to write a block driver and _get it right_.

> Finally, I offer a public apology to you and all who have suffered on LKML.

Thank you

-- 
Jens Axboe

You WIN ...

[Andre Hedrick]

Jens,

You win -- it is not worth trying to work with you at this time.
All you and I have done is become bitter enemies.

Next, I do not know all the details of the kernel, but what I know is
that neither one of us is willing to listen and learn.  However, I have
tried to get answers from you public and private, and nothing.  You may
get your wish granted to replace me in the future, as this has been your
stated goal from the past to me directly.

In closing, there were several cases of filesystem corruption based on
partition offsets and other various items.  This was totally unacceptable
for the most part.  I truly think that you do not see what the object of
"BLOCK" is all about, regardless that you are clever and quick.  You have
decided that block will define the interface to the drivers and thus the
drivers can not conform to standards set forth by the people creating the
physical layer.

Finally, I offer a public apology to you and all who have suffered on LKML.

Respectfully,

Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project