From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E4B27D2FFF8 for ; Fri, 18 Oct 2024 11:54:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 888D3605EB; Fri, 18 Oct 2024 11:54:53 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id Bugc4CfyMC_A; Fri, 18 Oct 2024 11:54:52 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.142; helo=lists1.osuosl.org; envelope-from=buildroot-bounces@buildroot.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6851D605F9 Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp3.osuosl.org (Postfix) with ESMTP id 6851D605F9; Fri, 18 Oct 2024 11:54:52 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists1.osuosl.org (Postfix) with ESMTP id A9BA12804 for ; Fri, 18 Oct 2024 11:54:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 8B91480A99 for ; Fri, 18 Oct 2024 11:54:50 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id gauzhZ7XAJLX for ; Fri, 18 Oct 2024 11:54:49 +0000 (UTC) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=198.175.65.16; helo=mgamail.intel.com; envelope-from=andriy.shevchenko@linux.intel.com; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp1.osuosl.org 8731680A98 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8731680A98 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) by smtp1.osuosl.org (Postfix) with ESMTPS id 8731680A98 for ; Fri, 18 Oct 2024 11:54:49 +0000 (UTC) X-CSE-ConnectionGUID: OoGBaC34THG+kLAKRZvWng== X-CSE-MsgGUID: idl5BmoITSOv0QUFyZdw0Q== X-IronPort-AV: E=McAfee;i="6700,10204,11222"; a="28885994" X-IronPort-AV: E=Sophos;i="6.11,199,1725346800"; d="scan'208";a="28885994" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Oct 2024 04:54:49 -0700 X-CSE-ConnectionGUID: C8Op6P1BQfq6IXLRzbmvHQ== X-CSE-MsgGUID: 8fAcYGnJSwKJSjwKeqKwiQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,213,1725346800"; d="scan'208";a="78450996" Received: from smile.fi.intel.com ([10.237.72.154]) by fmviesa006.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Oct 2024 04:54:47 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1t1lZ6-00000004Rv5-38Lj; Fri, 18 Oct 2024 14:54:44 +0300 Date: Fri, 18 Oct 2024 14:54:44 +0300 From: Andy Shevchenko To: Aaron Sierra Cc: Vincent Fazio , Andy Yan , buildroot , Andy Yan Message-ID: References: <1929b27b55e.1242e8abc627480.7414881916261699452@bubbl-tek.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1729252490; x=1760788490; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ycm19sdaqhM9kiiqcjY+PMzzu6NxIxjFRr3UzyioQns=; b=Wlc+dpkzXCtstp5V1JK1wXvf6pkQHRcRSSiI5coWrq0BbSmCJ34p+jjZ MlVU7hsxmIFKLQHem6muuvE0zEy7mXTEz9DXZ5l6sO1CUK+edfxJCSIU5 r/fN7tI2zKKPtMKVnz6d+o67if8t27WCtldepQTzYl36Gn7K1IuLWNX7d TYgHtcQdu7xgMGYOtv+7IAPaaie5kT8kgODTlEC6DELsgD81Qz8q3G1Lj d7Qbjo73E5m4c8B1/vmJQb18k5n6cZN3+4Vvb2sILjnZT+nkjskqiwzZR suaiWKyh+gYyspcWrgQF8sr1HPMFsfG8HxgLuovgf8/8QW55EqL2sytlc g==; X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dmarc=none (p=none dis=none) header.from=linux.intel.com X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=Wlc+dpkz Subject: Re: [Buildroot] [PATCH v2 1/1] package: Add iotools package X-BeenThere: buildroot@buildroot.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Discussion and development of buildroot List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: buildroot-bounces@buildroot.org Sender: "buildroot" On Fri, Oct 18, 2024 at 02:52:20PM +0300, Andy Shevchenko wrote: > On Thu, Oct 17, 2024 at 10:45:23AM -0500, Aaron Sierra wrote: > > > On Mon, Oct 14, 2024 at 05:55:46PM +0000, Vincent Fazio wrote: > > > > Aaron, Andy, > > > > > From: buildroot buildroot-bounces@buildroot.org> On Behalf Of Aaron > > > > > Sierra > > > > > Sent: Monday, October 14, 2024 12:01 PM > > > > > ---- On Mon, 14 Oct 2024 10:38:22 -0500 Andy Shevchenko wrote --- ... > > > > > 2. It would be nice if the package populated command symlinks in the target > > > > > filesystem. That could be done in a number of way, like using an explicit list of > > > > > commands maintained in the package Makefile (iotools.mk) or adding a host- > > > > > build dependency and leveraging the --list-cmds output to get the list of > > > > > embedded commands for linking. > > > > > > > > Caveat lector, I have not reviewed your patch or the sources in a while. > > > > > > > > WRT to this comment, I have this note from when we ported it: > > > > > > > > # we can't run make install because the symlink installation executes the binary > > > > # which isn't guaranteed to work in cross-compile scenarios > > > > define IOTOOLS_INSTALL_TARGET_CMDS > > > > $(INSTALL) -D -m 0755 $(@D)/iotools $(TARGET_DIR)/usr/sbin/ > > > > > > > > for link in $( IOTOOLS_LINKS); do \ > > > > ln -sf iotools $(TARGET_DIR)/usr/sbin/$link; \ > > > > done > > > > endef > > > > > > > > We then earlier in the mk file define the tools per platform, akin to: > > > > > > I deliberately won't populate those links. The naming is so generic > > > that it's a real chance to get a collision with all pain of splitting it > > > in the configuration what links we create and what not and what to do > > > with those that may collide. > > > > > > TL;DR: no, I don't think it's a good idea. > > > > For the benefit of the uninitiated, iotools operates similarly to Busybox, > > expressing behavior either by: > > 1. taking the command name from argv[0] (i.e. symlinks named for internal commands) > > * This is the mechanism encouraged by the project's make install (i.e. > > iotools --make-links) > > 2. taking the command name from argv[1] (i.e. iotools [[command] [arguments]]) > > There is a little nuance between two. When the Busybox is the *main( > shell/coreutils/util-linux/etc provider it must populate the links, many of > them (naming wise) are standardized by POSIX. In full opposition to the iotools > with unpredictable consequences of the potential name clashing (esp. those that > are called or/xor/and/etc.). Worth to add that when Busybox is supplied *in the addition to* the main shell it must NOT populate the links (for the very same reasoning: POSIX standardization). > > I proposed populating the symlinks in the target filesystem to ensure the > > subcommands are ready-to-use for people already familiar with the tool. It sounds > > like you're advocating for #2 ("iotools_fallback") to be the primary mode of > > operation for Buildroot users. > > Yes, I highly suggest not to go this way. > > > Can you point to documentation that Buildroot users can use to _know_ that the > > second mode of operation is available and encouraged? I do not see any in the > > help output or in the project README. Here is the current help output: > > > > $ ./iotools --help > > usage: ./iotools COMMAND > > COMMANDS: > > --make-links > > --clean-links > > --list-cmds > > -v --version > > Is it full output? Because to me it shows two screens of the listed commands. > I do not see an issue here. > > > For the sake of usability, I think it's important to either improve utility and/or > > project documentation or reconsider your stated position on symlink population. > > I am against populating the links. > > > Feel free to ask for help with either direction you choose. -- With Best Regards, Andy Shevchenko _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot