From owner-freebsd-arch@FreeBSD.ORG Fri Aug 15 18:30:50 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4977B46; Fri, 15 Aug 2014 18:30:49 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8580427A5; Fri, 15 Aug 2014 18:30:49 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id wp18so2271265obc.20 for ; Fri, 15 Aug 2014 11:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qipc5u84yHxJ7u7jQDcPxvvIexmFYvWzbku14PimcjA=; b=MVGW5tD8mfq4nhulIxayIopxufaMlSvqXR6ao5/Ym42urop3vF+WdW5DanRTwXh7Ya VD+a3gldabD9wa94qcqX2JaoupYsJuerbPEvTVxOslbYKl4TtfIOk3RkhMJerVo1fEla JKSSJooQI79dsUFzfGMuO+CfVKEY+qYPE2u3iq+dLVxqrwpkjPlHXE3OtVuSYaWFHxbK HZY7h+NBqiw6BYw7r5HdtlnDbZqXaF7LpLF8/rvCsEFXnenAusg6bLonEiqega2HK26Q 1KzWVh+rxj+aeUDNMZHry+quG7IN3xIZZvPO1Vg4GbPHphSf2VP/en/D0stU3dB7W7nd dcYA== MIME-Version: 1.0 X-Received: by 10.182.60.4 with SMTP id d4mr22202771obr.4.1408127448848; Fri, 15 Aug 2014 11:30:48 -0700 (PDT) Received: by 10.182.216.200 with HTTP; Fri, 15 Aug 2014 11:30:48 -0700 (PDT) In-Reply-To: <94A47A7D-89C9-4504-B669-2A5EDA80373B@bsdimp.com> References: <20140814052648.GM2737@kib.kiev.ua> <201408140606.s7E66XXA091972@idle.juniper.net> <20140814085257.GN2737@kib.kiev.ua> <201408140847.00573.jhb@freebsd.org> <94A47A7D-89C9-4504-B669-2A5EDA80373B@bsdimp.com> Date: Fri, 15 Aug 2014 20:30:48 +0200 Message-ID: Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML From: Oliver Pinter To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 15 Aug 2014 18:52:46 +0000 Cc: Marcel Moolenaar , Phil Shafer , John-Mark Gurney , "Simon J. Gerraty" , arch@freebsd.org, Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 18:30:50 -0000 On 8/14/14, Warner Losh wrote: > > On Aug 14, 2014, at 6:47 AM, John Baldwin wrote: > >>>> Marking the binary with a libxo-specific note tells the caller that >>>> the binary is capable of rendering its output in a non-traditional >>>> style and gives the caller a means of triggering those styles of >>>> output. In the libxo-enabled world, I see this as vital information >>>> the caller needs to initialize the environment in which the command >>>> will be run. Isn't this exactly the sort of information ELF targets >>>> for note sections? >>> >>> How binary format has any relevance for an application level feature ? >>> What would you do with the binaries which permissions are 'r-s--x--x', >>> which is not unexpected for the tools which gather system information >>> and have to access things like /dev/mem ? >>> >>> You removed and did not answered a crusial question, which is a litmus >>> test for your proposal. Namely, how presence of the proposed note in >>> the binary is different from DT_NEEDED tag for your library ? >> >> Yes, checking DT_NEEDED for libxo.so is the first thing I thought of as >> well. >> It is equivalent to 'ldd foo | grep libxo'. > > Doesn't work for static binaries, nor for cases where libxo is linked in by > a > library indirectly, nor for when the command is a shell script that may > invoke a command that supports this output, nor for a python script that > implements this output, etc. > > My question for people advocating this method: Why not require all commands > that generate this kind of output to support a standard command line option > that causes the command to print nothing and return 0 if it supports > reporting, > or anything else if it doesn't (return 0 with output, or return non-zero > with or without > output). This would handle the more complicated implementation issues with > using > DT_NEEDED and/or the ELF note, be more in line with how things are > traditionally > done, and offer greater flexibility of implementation. > > Warner What's about extending standard file descriptors? Example by: 0: stdin 1: stdout 2: stderr N: extended stdin N+1: extended stdout N+2: extended stderr If the program can not open fd [0-2], then in fallback case can try to open fd [N-N+2]. >