Date: Tue, 23 Apr 2013 13:20:31 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Jeremy Chadwick" <jdc@koitsu.org> Cc: Kenneth Merry <ken@freebsd.org>, Alexander Motin <mav@FreeBSD.org>, Scott Long <scottl@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: ada(4) and ahci(4) quirk printing Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
----- 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.
> 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.
>
> 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?
>
> 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.
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC7BB743D5AB4312BB3A0FE37AC1C566>