> >>> ... 05/10/00 11:00AM >>>
>
> > I trust the Linux stack by now has come into compliance
> > here? The class-specific Get Max LUN response has to bless
> > a LUN before it goes to the device in a CBW?
>
> We don't use Get Max LUN, mostly because it's not guaranteed to always be
> available. CBI devices don't have it -- probing is generally considered
> the only reliable way to go.
Probing via bCBWLUN is flatly non compliant for a BBB host,
via "6.2.2 Meaningful CBW" and the second page of "6.4 Device Error Handling".
We're not questioning this claim? Or saying the text is ambiguous?
We're just saying compliance at this level of detail just doesn't matter much?
Or that BBB devices have established a different de facto standard?
Or that CBI/BBB isn't a distinction worth making here?
I've seen people claim that precise interoperability standards are
more holy in Linux culture than in other development cultures
... that I could expect Linux to provoke less "not specified" device
behaviours ... false claim?
> > > I mean, if you want me to reset the device, then don't STALL,
> > > go into indefinite NAK on all bulk endpoints.
> >
> > Eh???
> >
> > The host doesn't understand indefinite NAK until after a timeout.
>
> Why not?
Are my words somehow painfully unclear here?
NAK can't be said to be indefinite until after timeout, can it?
What does "indefinite" mean?
> The host has to time out sometime.
> That's just a practical design consideration.
Aye. To my eye, one of the REALLY irritating things about mass storage
standards is the lack of a place to provide suggested timeouts.
> ... you shouldn't _have_ to reset a device during
> what might be considered normal operation
Agreed.
Except this sounds as if we should consider non-compliant host
behaviour to be normal operation? Am I missing something here?
> Also, reading the nice flowchart in the BBB spec, ...
Do we mean 5.3 figure 2 Status Transport Flow?
That includes a branch from CSW stalled twice to Perform Reset Recovery?
> Also, reading the nice flowchart in the BBB spec, one would
> expect that after I clear the endpoint halt, I _should_ be able
> to get status from the device.
This holds supposing that the host behaves only within
the limits of compliant behaviour?
> ... can't ... perfectly within ... rights as a host to
> declare the device dead.
Not if the host misbehaved first?
> > ... multi LUN ... Zip 250 ... valid. But ... damned rude ...
I said this was rude when first I saw it invented by the bridge vendor.
Can't tell you how pleased I am to have a chance to say "I told you so"
to the people with whom I disagreed. I imagine they'd answer that
they succeeded in forcing a reset to follow non-compliant host behaviour.
I'd answer that forcing people to do things is no way to make friends,
and we'd part still disagreeing.
x4402 Pat LaVarre of iOmega [EMAIL PROTECTED] http://members.aol.com/ppaatt/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
