Date: Tue, 23 Apr 2013 05:51:44 -0700 From: Jeremy Chadwick <jdc@koitsu.org> To: Steven Hartland <killing@multiplay.co.uk> Cc: Scott Long <scottl@freebsd.org>, Alexander Motin <mav@FreeBSD.org>, Kenneth Merry <ken@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: ada(4) and ahci(4) quirk printing Message-ID: <20130423125144.GA62949@icarus.home.lan> In-Reply-To: <CC7BB743D5AB4312BB3A0FE37AC1C566@multiplay.co.uk> References: <20130422051452.GA2148@icarus.home.lan> <51763BF9.2000506@FreeBSD.org> <20130423092602.GA58831@icarus.home.lan> <51765466.4040209@FreeBSD.org> <4D28DBAE46424C268AA22FCDD8657946@multiplay.co.uk> <20130423114722.GA61919@icarus.home.lan> <CC7BB743D5AB4312BB3A0FE37AC1C566@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 23, 2013 at 01:20:31PM +0100, Steven Hartland wrote: > ----- Original Message ----- From: "Jeremy Chadwick" > <jdc@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@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130423125144.GA62949>