Eric C. Taylor wrote:
>> Feedback appreciated. I still hope to get this started as a PSARC case
>> *really* soon.
>>
>
> What's the rush? 8-)
>
This is a dependency for the SDcard work, and I'm hoping to get
everything submitted soon, as the development effort is nearing completion.
This case was already submitted as PSARC 2007/654, though I had made
some edits before submitting it based on feedback I received from other
people.
> It seems like the block device driver (the nvflash driver or its
> equivalent -- there should probably be some sort of catchy acronym
> for this) would want to register the maximum number of commands
> it can handle at one time, so that the framework can handle the
> queuing.
>
> If the block device driver sets B2S_TARGET_FLAG_HOTPLUGGABLE
> and a new device gets plugged in, somehow it needs to call
> b2s_alloc_target() and b2s_register_target(). How does it do
> that?
>
> How does blk2scsa timeout or cancel submitted commands?
>
It can't/doesn't. There is no provision for it right now. Probably I
should add a B2S_ETIMEDOUT, so that target devices can indicate that the
request timed out. (At the moment, my own sdcard driver just uses the
generic B2S_EIO if some error occurs. Its kind of lame, but good enough
to keep sd(7d) happy, I hope.)
> Does the FORMAT command allow a certain blocksize to be
> specified?
>
No. Its really primitive, and frankly, I only intend it to be used for
erasing or preparing an entire device.
It is my intent that someday this framework could evolve to support
other kinds of formatting operations with additional parameter lists...
I just don't need that today, I don't want to mis-specify something
today based on what "might" occur tomorrow.
(When that day comes, I'll probably add a request flag to indicate
additional data or options are present in the request.)
> It seems like the framework could keep track of the fact that
> a FORMAT command is outstanding so that the reserve/release
> pseudo-commands aren't needed. If that's true, it would also
> remove the need for the B2S_EFORMATTING return code.
>
Yes, I've done that already in the spec I submitted to PSARC. Although
B2S_EFORMATTING still exists for internal use.
Actually, I decided to be really, really lazy, and just always return
true for any well-formed SCMD_RESERVE and SCMD_RELEASE, and ignore
reservations in SCMD_FORMAT. This is not quite compliant with the
specification, but I think it is highly unlikely to cause anyone any
problems.
I can go back and put in the tracking in the framework if it proves
useful or necessary.
> Same goes for the START/STOP unit command and B2S_ESTOPPED/
> B2S_ESTARTING.
>
No, here is where it gets interesting. Some device might actually have
a delayed spin-up time. So I want to allow devices to get START and
STOP and do whatever is required to start them up. I'm also relying,
for the moment, on this as a way to assist with book-keeping against
media change events. (In my memory card driver, I keep track of a
started flag, and when the media is changed, I clear that flag. I use
that to report B2S_EMEDIACHG or B2S_STOPPED when appropriate.)
This also allows for interaction with power management, I believe.
> The name B2S_EBADMSG may be confused with a parallel SCSI error.
>
Its used internally only. Right now I only use it if the target driver
(sd) sends down a request with in insufficient buf. Specifically, a
format command with the FmtData bit set, but a buf that doesn't contain
at least 4 bytes.
> When would a block driver return B2S_EPARM vs B2S_EINVAL? You
> mean "b2s request" rather than "SCSI packet," right?
>
They don't. Its framework internal, and its used when parsing the SCSI
packet. EINVAL is returned when the CDB has garbage in it, and EPARAM
is returned when the data in the attached buf_t (the parameter list, in
SCSI paralance) is screwed up.
Target devices don't touch either of these, which is why they are marked
"Internal Only".
-- Garrett
