From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D385C18FDC8 for ; Mon, 20 Jan 2025 10:25:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737368744; cv=none; b=n1aIJlLDRo/1iBHWFv6Q+lXpoZ5B04ZEzo/BCZnENXF1gCtMRyrJWYDqkHQQAVPj0eMgNmYErH3DfFjfYbm9eJYFIq0p5HGW9vXuPbm2MhXbHwGAq9VX1e7Sh2kzzUg1pFwEQBinwJlVtHcSjfpGv1SHH3d751JCk1i3R2fWUCE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737368744; c=relaxed/simple; bh=LD8OuVw8n3F+UjqdO0zdMsAuE9OqG7caHsIEKdL9ptU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bGHBJTS0G2xq0tcTtaxwK6esVGsEMBN1byydTqddjPBw/IpBD+StPAcI7TTqpY++1zTB2KLeeV0gp7F2MJeLlWjNQzPys7H1RYl7tasPkutAiBrtoHMeOay/oTSiH7o1ZkNVT3ATkJqHCq1/RabchryCGlDsklw8MlVu6hzUdbc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=YpvcVHqe; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="YpvcVHqe" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-385ef8b64b3so3796363f8f.0 for ; Mon, 20 Jan 2025 02:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1737368741; x=1737973541; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/plAlONRzFatYjUDsmYEo6CR3UeB2Jc5rLAfXDiJdtk=; b=YpvcVHqegktJxV4UHAHBIF5jDE0UA2mPIOI6a63q5OgN5gXz8ilwzncOp3w/+0Ziup KYbBoojJXW9i5R3ATcUtmDDxwq0MN7rgROtmBBb2bWNgK7R9fN+dUjHity0pg07Lf7pe LkEmYqW6iMZr4URw50Udj53PMaW60NaQ27+wJlE418k6uInmiz9AA6P1vIB81u70Cg01 RV8pNmngzTfXyABf4NtOjnNWSVJHDUZTyl74f2omyxNRF1f/ZHsQAE2w/y2/oIJPQ9yP IeT6khiuzZNYlQGP+gSDm1dWOIcsQro57Sqqhq9JH94JPo3ON3V93gIDe9x22i41b/TA Y1BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737368741; x=1737973541; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/plAlONRzFatYjUDsmYEo6CR3UeB2Jc5rLAfXDiJdtk=; b=RM/a9OfQPjHxgqrIUajLUQG7z95BKnS1jeYlqLEGIN9cHtAOh8Ye14r7jT9ugtsK0d 2cWAJg/2jm9ikXgh1B0elw8WqFIg/bUlfiRxFMnIrL5Ena5mQYICHGm4XJJXnO5b8rmr t9jpYoNOpCu/LBiRPLkcf7S5XCucrxULMPjC66ixWN0F4q2MO3VE8UtAOSOvyDaJcvjr 4F4mHiDHVLR1HN7txbr21OXr3tKr+npeV+PO/dEpDayYjP8Of2pBhUODydwLQDKFW3Q+ E9MS0pAKmzSbg5S+XJPmQc2hmnlB8/Qk7fvaVLV+alPCR3UF5k8NZVYzVEhbV2PRDgo1 jbRg== X-Forwarded-Encrypted: i=1; AJvYcCXFJ1o+WpZbtT+VuoOlVYfZSmug/ju2VkS6mpIWF9rnqvnimLW5AqnIBjs2Bzj4glw7j8W50lo/VgYKyMw=@vger.kernel.org X-Gm-Message-State: AOJu0YxADde7u3GgL+WViwlcsa0Z7W7knJpr8vs+eD1w+xGLb2mtIiNJ guA7bZI65fzuxfHQ+cLzTlQDe3g9NTXUu9YzquGufyW4dyCK3IjHV8ihwvIUHII= X-Gm-Gg: ASbGnctKzzhVWKRPhTjSb/+kiR7Ul1gaTccYMKTwzjO+iVF3XlECljg+2QG9h3lDyuh TSJbpSFelEvi8yxulGbBByrlqoJ69B+qIKGBQk57BRFihwbxpVE02qPNsCZlA5YUtFwCR09je61 hW3eMn9B+wz+yxL5NMz8Q8TtA6ivxOJUyEZCs95m7X46reG6TOYQidv5S7ESuH30OQ1YBu/uOeA OqAsiri8NsSw1AW+WcQ5xm9YVH4bziJNO39YLJv7ZRRQEYQ06n/0aFGrTttar84M4jdhPY= X-Google-Smtp-Source: AGHT+IGuenfcVRf8Q07QNfEdMYeTuOKNmKjxeSjYso288tHkR+4lZp1kulMIxxTWOTGhuEhOwe35wQ== X-Received: by 2002:a05:6000:b10:b0:382:5141:f631 with SMTP id ffacd0b85a97d-38bf56740b4mr8607242f8f.29.1737368741058; Mon, 20 Jan 2025 02:25:41 -0800 (PST) Received: from pathway.suse.cz ([176.114.240.50]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38bf3221be1sm10086350f8f.31.2025.01.20.02.25.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jan 2025 02:25:40 -0800 (PST) Date: Mon, 20 Jan 2025 11:25:38 +0100 From: Petr Mladek To: Miquel Raynal Cc: David Laight , Andy Shevchenko , Steven Rostedt , Rasmus Villemoes , Sergey Senozhatsky , Jonathan Corbet , John Ogness , Andrew Morton , Thomas Petazzoni , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] hexdump: Allow skipping identical lines Message-ID: References: <20250110-perso-hexdump-v2-0-7f9a6a799170@bootlin.com> <20250110-perso-hexdump-v2-2-7f9a6a799170@bootlin.com> <20250117192522.0b2e7c65@pumpkin> <87wmepvnns.fsf@bootlin.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wmepvnns.fsf@bootlin.com> On Mon 2025-01-20 10:29:27, Miquel Raynal wrote: > Hello David & Petr, > > On 17/01/2025 at 19:25:22 GMT, David Laight wrote: > > > On Fri, 17 Jan 2025 17:27:26 +0100 > > Petr Mladek wrote: > > > > ... > >> IMHO, it is perfectly fine to add support for skipping identical lines > >> only to print_hex_dump(). And I would go even further and replace > >> > >> void print_hex_dump(const char *level, const char *prefix_str, int prefix_type, > >> int rowsize, int groupsize, > >> const void *buf, size_t len, bool ascii) > >> > >> with > >> > >> void print_hex_dump(const char *level, const char *prefix_str, > >> enum hex_dump_type, > >> int rowsize, int groupsize, > >> const void *buf, size_t len) > >> > >> and combine all the flags into the one enum: > >> > >> enum hex_dump_type { > >> DUMP_HEX_ONLY = 0, > >> DUMP_HEX_AND_ASCII = BIT(1), > >> DUMP_PREFIX_ADDRESS = BIT(2), > >> DUMP_PREFIX_OFFSET = BIT(3), > >> DUMP_SKIP_IDENTICAL_LINES = BIT(4), > >> }; > > Would a single enum (in the prototype of the function) work? I like the > idea but we need some kind of OR combination to be supported, typically: > > DUMP_HEX_AND_ASCII | DUMP_PREFIX_OFFSET | DUMP_SKIP_IDENTICAL_LINES > > Maybe something like: > > void print_hex(const char *level, const char *prefix_str, > int rowsize, int groupsize, > const void *buf, size_t len, > unsigned int dump_flags) // flags instead of enum? Yes, the parameter would need to be an unsigned int or unsigned long type so that we could use the logical OR operation. We could also define the bits without the enum type because the enum type won't be used anywhere. I just thought that you wanted to have it "enum". AFAIK, workqueues code uses enum because it allows to use the names of the bits in crash/gdb. The enum will cause that the names of the values will appear in the debug info... > enum hex_dump_flags { > // I'm not sure what to do with the default value? I would define DUMP_HEX_ONLY = 0, or DUMP_HEX_DATA = 0, It would be used only when the caller wants only the plain hex data. > DUMP_ASCII = BIT(0), // renamed? You are right that DUMP_ASCII might be enough. The names of the flags would mean what the caller wants on top of the plain hex data. > DUMP_PREFIX_ADDRESS = BIT(1), > DUMP_PREFIX_OFFSET = BIT(2), > DUMP_SKIP_IDENTICAL_LINES = BIT(3), > }; > >> How does that sound, please? > > > > Rename it as (say) print_hex() and add wrappers for the existing callers? > > That would avoid the treewide changes, so yes I can try that, definitely. I am fine with it. But a treewide clean up (2 parameters -> one flags) would be better from my POV. Best Regards, Petr