From owner-freebsd-multimedia@FreeBSD.ORG Wed Apr 15 14:31:23 2009 Return-Path: Delivered-To: freebsd-multimedia@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E196D1065672 for ; Wed, 15 Apr 2009 14:31:23 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 58EAD8FC13 for ; Wed, 15 Apr 2009 14:31:22 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA18089; Wed, 15 Apr 2009 17:17:41 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <49E5EC84.1080800@icyb.net.ua> Date: Wed, 15 Apr 2009 17:17:40 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-multimedia@FreeBSD.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: ac97 interface q X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:31:25 -0000 ac97_if.m defines 'read' method to return int and 'write' method to take u_int32_t data and return int. Calls to AC97_READ and AC97_WRITE are present only in ac97.c and from those calls it is evident that the calling code expects u_int16_t from 'read' and it also passes u_int16_t to 'write', return value of 'write' is discarded. Seems like the interface is richer than what its caller actually uses. And it seems that implementations of the interface do not always have the exact signature - they have the same number of parameters, but the types are varying. Some implementations are closer to the interface contract, e.g. returning -1 from 'read' in case of error. Some are closer to the caller's expectations, e.g. having void return type in 'write'. What are your opinions - should the calling code be enhanced to use the interface properly (i.e. attempt to detect error conditions) or should the interface be dumbed down to its caller's expectations? My ultimate goal is to make all implementations have exactly the signature mandated by the interface. -- Andriy Gapon