Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Aug 2013 09:40:24 -0600
From:      Will Andrews <will@firepipe.net>
To:        Steven Hartland <killing@multiplay.co.uk>
Cc:        scsi@freebsd.org
Subject:   Re: 8K quirks & making quirk table more structured
Message-ID:  <CADBaqmjYDPRB-d%2BL_jB4LGxXNak7Ptbf_Zb1XBfYZUb4ZYRNPg@mail.gmail.com>
In-Reply-To: <B0201D260A3B424B98AC36C27B8C0A71@multiplay.co.uk>
References:  <CADBaqmibnA95T7x7UKZLYp3xZfgj0pLH00f1f%2BPEwcQbnBagmQ@mail.gmail.com> <B0201D260A3B424B98AC36C27B8C0A71@multiplay.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 24, 2013 at 4:24 PM, Steven Hartland
<killing@multiplay.co.uk> wrote:
> That currently breaks the main reason for the output of
> quirks in xpt_announce_quirks

The main reason for the output of quirks is for those that you can't
find any other way.  Blocksize is something you can obtain from
diskinfo, so what is the point of putting it in quirks?  Just to spam
dmesg?

> Also it appears that the new method of setting lbppbe
> in scsi would make the result dependent on block_len
> which makes it potentially hard to predict the value
> needed to set a drive to 4 etc.

A fair point.  I would prefer to address this issue in a followup
commit, perhaps as part of harmonizing the quirk tables.  See below.

> In ata you use a different method entirely which its
> not good for consistency as ideally we should have just
> one set of quirks which work for scsi and ata.

Yes, but this problem already exists and is not made worse by this
change.  We can debate this issue, but I consider it a separate one
from converting the quirk entry type.

> Also in ata you appear to have lost the output of quirks.

In ata, there aren't any quirks aside from 4K.

--Will.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADBaqmjYDPRB-d%2BL_jB4LGxXNak7Ptbf_Zb1XBfYZUb4ZYRNPg>