ada(4) and ahci(4) quirk printing

[Jeremy Chadwick]

On Tue, Apr 23, 2013 at 01:20:31PM +0100, Steven Hartland wrote:
> ----- Original Message ----- From: "Jeremy Chadwick"
> <jdc at koitsu.org>
> >>Wouldn't camcontrol be a better place for this?
> >
> >1) Not possible at this time -- the ADA_Q_* quirks are not exported to
> >userland (i.e. /usr/include), only the kernel.  camcontrol's source only
> >relies on things in userland.
> 
> Thats not an issue which is hard to resolve.

Outside of my interest/care at this point -- camcontrol looking at
include files in kernel space might be a Bad Idea(tm), and I don't know
the implications/concerns of bringing the quirks bits into include/cam.
I'll leave that for you/Alexander/Kenneth to discuss.

> >2) Assuming #1 is addressed: where would it go?  You can't put it under
> >"camcontrol identify" because all (I repeat: ALL) that information comes
> >from ATA IDENTIFY and thus would be extremely misleading.  (Same goes
> >for SCSI's INQUIRY stuff).  Which leads me to...
> 
> A new quirks option makes the most sence which could be used not only by
> disks but other areas too.

Not something I'm willing to write, honestly -- at least not the
camcontrol userland portion.  (The little work/hacking I did on
camcontrol some time ago, as you know, left a somewhat sour taste in my
mouth.  Rather not get into that...)

> >3) I'm never thrilled about adding new commands to camcontrol given
> >how enormous that thing is to begin with.  :-)  I also imagine something
> >like "camcontrol quirks" might lead people to think it lets you adjust
> >quirks in real-time (nope -- read-only, tunable-only).  And that leads
> >me to...
> 
> Again depends how its implemented if we fix / improve the CCB situation
> this could be handled quite elegently with even with the possiblibly of
> changing on the fly. I know scottl has some thoughts on this.
> 
> >4) camcontrol wouldn't address the need/interest for ahci(4) quirks to
> >be made available.
> 
> Why?

Because camcontrol is for CAM.  ahci(4) is not part of CAM.  The last
place I'd look for "poking at AHCI" (as in *actual AHCI*) is camcontrol.

This is one of the reasons sysctl exists -- it's a sort of "covers
everything" tree, on a per-device basis.

> >All of these things combined do lead me to believe sysctl is the better
> >place for this.
> >
> >P.S. -- I just noticed that our USB layer prints device quirks
> >regardless of bootverbose -- instead it's based on kernel option
> >USB_DEBUG, which is enabled in GENERIC.  Hooray for inconsistency.
> 
> Personally while I like a relatively clean output I think its important
> that the information is available when needed, and that shouldn't require
> a reboot.
> 
> So if this info isn't available else where I would say adding to standard
> output (not verbose only)is a good option especially since its often as
> important to know a quirk is in place or for 4K not in place as say
> transfer speed / data spec e.g. SATA 2.x.

I too think it's most useful to have during boot-up, and it's only a
single line shown (and only for devices which have quirks).  Yes, I for
a system with ~30 disks that have quirks there will be 30 extra lines,
but I imagine that system's dmesg is already long anyway -- it's still
going to be shorter than boot -v.  ;-) And I have yet to encounter
anyone in all my years, sans kernel developers, who run their FreeBSD
boxes with boot verbose enabled by default.  (Oh I'm sure there's one of
you lurking in the woodwork, waiting patiently to tear me a new one for
saying that...  :P)

Footnote: the more this conversation bikesheds the less interest I have
in doing any more work on it.  I wrote what I did, it works, if folks
want to take it and run with it + fix it + do it differently, awesome,
I'm all for it.  I'm just trying to provide something that is incredibly
useful, especially with the introduction of 4K sector drives.  I can
only do so much with my (limited) knowledge set.

-- 
| Jeremy Chadwick                                   jdc at koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |