From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 14A2F20D4FC for ; Fri, 20 Feb 2026 15:33:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771601584; cv=none; b=MFiTOAcPxIPAY3/TavZiXxBIsI8xBczfTijSh8QGtHJsuKM/1qPfgzlqKIONY+k/LpRUpN6sRWxpZ6pYN08UTJ8cDaRjQzWYrJr6EkfAVmRnFfFGPZy4qKcQXyDwMEGQzGn5ZAs2zfhM2ZUtwubpxvgwHZ63SZI+3t51aT4O07I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771601584; c=relaxed/simple; bh=rPrCqKQfd65vBz0CDw0Q8VmlKfdGGhQiBVfZu4gF4T8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LsOsu7IUeWBHC8dJsay98ULl0Kjyhp7ITzUyv3mMltah65DL+YhDv/b7nMlzRNkJGSuJrQmKNLYMdfl0WL9TDUZwx0O2X7pc7c0ncxTikAj6+JBc9atkLeOGlBoktrxhojWi9TSWVwOUbQpq9qxTS3QJ0Kq3bY/aVFWf5FjS84k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nJLLBW4e; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nJLLBW4e" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5BAB4C116C6; Fri, 20 Feb 2026 15:33:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771601583; bh=rPrCqKQfd65vBz0CDw0Q8VmlKfdGGhQiBVfZu4gF4T8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=nJLLBW4eMj0ahh879CKdyAWC+84abKHQgH7vHP38RDo+TbQIPxEG+AJVlU2lI6wcs NtXA2jYzkjh5M4ZL0U1EJld3yqJ+I31vY6KyBJ5Zx8zT8caRWWUMKLK652m8wdly5e gr+BZPIbZ5sIJfvkyPOx00E2FE6ena6K2OmaaXhUcUQG1xXeOigLHBR5asT92hkhFZ 2SynCYe2dK4dhbTTS6F/wgNc+ZX5PrMQjLJAkqTM0UnD5OzvJOFuxSZERBW+Z0AHU7 l2wYm+6lITKy6d4rqto2D5Tn9zttE8PdIiRxP5iu255JUiuZyT96xApu8ulDMQ5vZ0 f2iNSJ1jJ4eXg== Message-ID: <2ee59b89-2766-47e7-8527-3541b5549c05@kernel.org> Date: Fri, 20 Feb 2026 08:33:01 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: perf-trace: improving ioctl details Content-Language: en-US To: Namhyung Kim , Arnaldo Melo Cc: Arnaldo Carvalho de Melo , LKML , Jiri Olsa References: <4babff5e-5a27-4e3b-b9c6-16fd2781af35@kernel.org> From: David Ahern In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sorry for the delayed response; my time seems to evaporate these days. On 2/19/26 11:49 AM, Namhyung Kim wrote: >>> Questions for you: >>> 1. is such an open ended design acceptable for perf-trace? >> >> Is it lazy, i.e. only when needed this cache/table gets loaded? > > I think it's ok. But I'm curious what's the actual usecases.. do you > want it for testing kernels and drivers? I guess we can have a default > table for regular users and provide the option for kernel developers. The idea is that ioctl is a very open ended and overloaded uapi, and I wanted better granularity on how that time was spent. The breakdown by filename and NR is one level; improving human readability of the NR is another. For the latter, if you look at tools/perf/trace/beauty/ioctl.c, you can see how human readability for NRs has been improved for specific subsystems tty, drm, pcm, kvm, ... (the table in ioctl__scnprintf_cmd), but that design is not going to scale for all of the devices and drivers, especially those with dynamic major numbers. Allowing runtime loading of files seemed like an easy way to accommodate the range of ioctl users in a flexible way. (though it too has limitations given the multiplexing on specific NRs) > >> >>> >>> 2. if yes, is there any preference on file format (json, yaml, >>> key-value, ...)? >> >> We already have JSON parsing infra, so probably that is better? json is used for the PMU files, but it seems to be used only for code generation (pmu-events/pmu-events.c) at build time, not run time loading which I was targeting. Hence the question on format. > > JSON should be fine, although it's a bit verbose. I'm fine with plain > KEY=VALUE format too if it's really a simple mapping. key=value format is what I have now. The only awkwardness is a header to declare the filename it corresponds to and then a further complication is the need for a wildcard format as there are examples that have multiple instances (e.g., /dev/infiniband/uverbs*). > >> >> Great to see you contributing to perf again! > > +1 > Thanks. perf-trace code has changed quite a bit over the past 10 years.