[illumos-Developer] Webrev for bug 561: Strange characters when executing "format"

[Albert Lee]

On Thu, Jul 21, 2011 at 11:24 AM, Albert Lee <trisk at opensolaris.org> wrote:
> On Thu, Jul 21, 2011 at 10:28 AM, Jason King <jason.brian.king at gmail.com> wrote:
>> LGTM
>>
>> On Thu, Jul 21, 2011 at 8:06 AM, Gary Mills <mills at cc.umanitoba.ca> wrote:
>>>
>>> On Sat, Jul 09, 2011 at 09:13:32PM -0500, Gary Mills wrote:
>>> > >
>>> > > The three values in the inquiry data are space-padded in fixed-length
>>> > > fields, not null terminated.  The code to create a disk name from this
>>> > > data already exists as the get_generic_disk_name() function in the
>>> > > `format' source.  I'll be posting a new webrev soon with this function
>>> > > substituted.  Unfortunately, I can't test it, but it pretty well has
>>> > > to work.
>>> >
>>> > My new webrev is at:
>>> >
>>> >     http://cr.illumos.org/view/4z5nj2vk/illumos561-1/
>>>
>>> Any interest in this one?  I've had no reviews of the revised webrev
>>> so far.
>>>
>>> > It now uses the internal function get_generic_disk_name() to format
>>> > the label for display.  As well, it now only prints the `Inquiry
>>> > failed' message if you supply the `-m' option of the format command.
>>> > This is reasonable because the USCSI ioctl will always fail when the
>>> > disk does not appear as a SCSI disk.  In that case, it will display
>>> > the disk type as `Unknown-Unknown-0001', but `format' will still work
>>> > normally.  From reading the source, I can't tell when, if ever, the
>>> > rest of get_disk_name() will be executed.  That's why I can't test
>>> > that code path,
>>>
>>> --
>>> -Gary Mills-        -Unix Group-        -Computer and Network Services-
>>>
>
> Don't think you actually have to add the #include to the header, since
> the parameters are just struct pointers.
>
> -Albert
>

And thank you for your work on this!

-Albert