Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp969221ybl; Fri, 24 Jan 2020 12:55:30 -0800 (PST) X-Google-Smtp-Source: APXvYqzklRRrLtnAs8AB4KuRKiCs3D2sdU+aqEhp5eaQ0nKAauPCFF2sAB9kfCqZx6KdDPbwD9E4 X-Received: by 2002:a05:6808:9a4:: with SMTP id e4mr502287oig.127.1579899330611; Fri, 24 Jan 2020 12:55:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579899330; cv=none; d=google.com; s=arc-20160816; b=z2vA9tz4YlpZFosKgYBySB/xnCm2skg/tcaGxCwhi7DZNcYkQ0i6M0UwXzs4y6XZwk P5TxQ16yoUME0v32YScsR4u5ZRidZglv5jqDRh0KeYoCgx95r4T5+Z0CPZR9f2065zLo kFnDsBCuKIegnBYCGZOm0GMfJ8ofIBEhSNqvnFtOG1HBIHfTw/6uG1UVieNRedNZxRNl jPfJwqclCy8iCtEk7qPvEZJQrDaYnAoNY0gZlgCdNhweNer77hLj9P0hkBeLTDBk9UtN +oObJNPLu6QSvzbbPXni7DELMbx1s88VI+QN45RzARMQ1LAtzDdi1DtBdZ7kc/5afKGo Y+vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=aIKb0sxCFxq6F/tkxcIh+Oz+GSs7skwQOSsBJ3rTtpY=; b=kRZlYlroBRgAHYpH62ugTCgEVtiZh9myXqfDLt6KA+s2KfvoYDao32iYbDzQ59JizP AjjWfBSzcpAvJcvz/ol6JUKuOcjOvnAhCKEqVdB/KwOEHZ01PWIrUAOqSq80Cg2mdYax xEvldt2z4CvrrBFQ9OfNKNxWyjytxpYs6y7OqwUAswVvzNIIvIJHeH86qfhB6aIEoVnS LaEjD++vrMrySRxPLNeBOpy5hH/AnQ9QfZgedLJuPS9zO0J2f/pxMq6saPaSsqLTjo+s E0Vzpj3tdJ9u0etTL3t8RJxjJ4HbNDJ3sVj3kXgXRjHMnIcTfYlMZg9gQl27ipADsvl6 uCEw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f194si330135oig.243.2020.01.24.12.55.09; Fri, 24 Jan 2020 12:55:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728767AbgAXQk5 convert rfc822-to-8bit (ORCPT + 99 others); Fri, 24 Jan 2020 11:40:57 -0500 Received: from coyote.holtmann.net ([212.227.132.17]:50447 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726454AbgAXQk5 (ORCPT ); Fri, 24 Jan 2020 11:40:57 -0500 Received: from marcel-macpro.fritz.box (p4FEFC5A7.dip0.t-ipconnect.de [79.239.197.167]) by mail.holtmann.org (Postfix) with ESMTPSA id C37DACED10; Fri, 24 Jan 2020 17:50:15 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: [PATCH v2] bluetooth: Refactoring mgmt cmd op_code structure From: Marcel Holtmann In-Reply-To: Date: Fri, 24 Jan 2020 17:40:55 +0100 Cc: Alain Michaud , BlueZ Content-Transfer-Encoding: 8BIT Message-Id: <9D8E5673-048E-408C-B55E-37BA60F40B00@holtmann.org> References: <20200118050410.257697-1-alainm@chromium.org> <37FDD376-5D3D-484C-9209-B59FACA22D0A@holtmann.org> <6EF3C3FB-89A6-4B23-A4F5-ADC59FFB9F98@holtmann.org> To: Alain Michaud X-Mailer: Apple Mail (2.3608.40.2.2.4) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Alain, >>> I'll separate the simple one liner into a separate patch then will >>> wait for your suggestion for the rest. Note that with a single jump >>> table as suggested, it will indeed allow us to defunc some op-codes >>> pretty easily. >> >> I have not fully thought this through yet, but here it goes. >> >> The read_version and read_commands are special since they have to be present no matter what. So on purpose we put these two commands first when we designed the API back in the days. We can special handle them and thus also avoid the forward declaration. I am leaning towards this direction since we might want to actually split commands over multiple files to keep this file readable over time. >> >> Now the downside with putting the opcode as a field in the data structure is that we actually have to look through the every field until we find the opcode and can not just jump to the position defined by that opcode. That means actually filling the table with NULL pointers for not supported or disable commands might be better. We could still make the read_commands function map the list of supported commands from that table. > That may be an acceptable compromise. At least there would be exactly > one place to make sure things are aligned. Perhaps we could also > leave the op-codes in place and create a test that ensures that if > !NULL then op_code == index. I don’t understand this? If you would have test cases in mgmt-tester any error would be caught quickly. Regards Marcel