lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aHZMG2XnCLoBuf9T@vaman>
Date: Tue, 15 Jul 2025 18:09:55 +0530
From: Vinod Koul <vkoul@...nel.org>
To: Takashi Iwai <tiwai@...e.de>
Cc: Charles Keepax <ckeepax@...nsource.cirrus.com>,
	Joris Verhaegen <verhaegen@...gle.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Richard Fitzgerald <rf@...nsource.cirrus.com>,
	David Rhodes <david.rhodes@...rus.com>,
	Cezary Rojewski <cezary.rojewski@...el.com>,
	Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
	Bard Liao <yung-chuan.liao@...ux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
	Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>,
	Srinivas Kandagatla <srini@...nel.org>,
	Daniel Baluta <daniel.baluta@....com>,
	Orson Zhai <orsonzhai@...il.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Chunyan Zhang <zhang.lyra@...il.com>,
	Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
	Masami Hiramatsu <mhiramat@...nel.org>, kernel-team@...roid.com,
	linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org,
	patches@...nsource.cirrus.com, linux-arm-msm@...r.kernel.org,
	sound-open-firmware@...a-project.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 0/4] ALSA: compress_offload: Add 64-bit safe timestamp
 API

On 11-07-25, 14:41, Takashi Iwai wrote:
> On Fri, 11 Jul 2025 13:56:47 +0200,

> > Would it not be slightly simpler to just update all the in kernel
> > bits to use 64-bit and then only convert to 32-bit for the
> > existing 32-bit IOCTLs? Why do we need 32-bit callbacks into the
> > drivers for example?
> 
> Right, it's a usual pattern to have only the 64bit ops in the kernel
> driver side while providing the 32bit stuff converted in the core
> layer.  Having two different ops are rather confusing and
> superfluous after conversions.
> 
> If there are tons of users for this API, it'd be needed to convert
> gradually, and eventually drop the 32bit ops at the end.  But in this
> case, there doesn't seem so many relevant drivers, hence the
> conversion can be done in a shot as done in your patch 4.

I agree we should do that. Kernel can be 64bit only while we keep
maintaining the 32bit ioctls, cant drop that one

-- 
~Vinod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ