linux-kernel - Re: [PATCH v5 1/1] gpio: add sloppy logic analyzer using polling

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Yb8vJRMEbNjtD3R6@ninjato>
Date:   Sun, 19 Dec 2021 14:09:57 +0100
From:   Wolfram Sang <wsa+renesas@...g-engineering.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Linux Documentation List <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v5 1/1] gpio: add sloppy logic analyzer using polling

Hi Andy,

> I mean that there are similar functionality in different tools and for
> one purpose you need one, for another another and there is no format
> file convertors available (as far as my shallow googling shows).

Yes, this is a truth I can't change. So, I chose the Free Software
solution, so the format is at least documented. Also, you could just try
sigrok and pulseview, it has a nice set of protocol decoders. GTKWave
should be able to use the binary data inside the .sr IIRC. For other
software, you can at least write a converter because the format is open.

> > In your V1 review, you suggested -ENODATA. I will pick yet another one,
> > but it really matters zero in practice.
> 
> Ah, okay, then choose the one you think fits most.

I took -EBADR now.

> > What is the difference? Does it matter here?
> 
> I'm a bit lost in the context here, but the ' > /dev/null 2>&1' means
> to redirect stdout to the /dev/null followed by redirecting stderr to
> stdout (which is redirected to /dev/null). The other construction
> might have side effects IIRC.

Andy, *if* there is a side effect, I will happily fix it. But "it might
have a side effect IIRC" leaves all the detective work to me and I am
not short of other action items. Especially because this is not a
critical path.

> > I read that '-a' and '-o' are deprecated. Dunno where but looking again
> > I found this: https://stackoverflow.com/questions/20449680/boolean-operators-a-o-in-bash
> 
> The SO talks about _bash_, your script is a plain Shell one, right?

It talks about being deprecated in POSIX, so quite the opposite of a
bashism, I'd say.

> > > > +   taskset "$1" echo 1 > "$lasysfsdir"/capture || fail "Capture error! Check kernel log"
> > >
> > > Shouldn't this function setup signal TRAPs?
> >
> > To do what?
> 
> To clean up the garbage it may leave in case of the interrupted run, no?

I don't see any? Which ones do you have in mind?

> > > $@ is better, actually one should never use $*.
> >
> > What difference does it make when expanding into a string?
> 
> The difference is on how the  "foo bar" (with double quotes!) will be
> represented. In your case it will be translated as "foo" and "bar", in
> the case I'm saying it will be "foo bar".

I very well know the difference. I was interested in what difference you
see when they get expanded into a string?

Happy hacking,

   Wolfram


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)