[Toybox] a tizen status

[Rob Landley]

On 10/07/2015 08:38 AM, José Bollo wrote:
> Hello Rob, Hello Hyejin,
> 
> I've just check the differences from toybox mainstream and the toybox
> that is used by Tizen.
> 
> (on my github the tizen version is
> https://github.com/jobol/toybox/tree/tizen and the youngest merge-base
> of it with toybox is https://github.com/jobol/toybox/tree/base)
> 
> Here the summary of the relevant differences (packaging left out)
> 
>  toys/other/stat.c       |  58 ++-
>  toys/pending/syslogd.c  |  30 +-
>  toys/posix/cp.c         |  79 +++-
>  toys/samsung/README     |   3 +
>  toys/samsung/nslookup.c | 181 ++++++++
>  5 files changed, 334 insertions(+), 17 deletions(-)
> 
> (produced using "git diff --stat=40 base tizen -- toys")
> 
> The 2 last lines are the implementation of nslookup. It is new. So here
> the only questions are "why samsung, is it valuable?" and "is nslookup
> wanted in toybox?".

Yes, but host, dig, and nslookup all do approximately the same thing. I
want them to share code. Rich Felker submitted a host implementation way
back that I haven't properly looked at (another of those array of "text
strings associated with magic constants" things). I haven't got a dig
but that's the one I researched and made notes about implementing
myself. I'd happily take nslookup in pending but with the proviso that
I'm likely to merge them together to get a final promoted version.

> So the differences are stat, syslogd and cp. I copy past this
> differences here in plain text post-scriptum.
> 
> Let exam the 3 comands stat, syslogd and cp.

You sent me the fished-out patches earlier, I was partway through
replying to that but I've got a half-dozen email composition windows
open again...

> toys/other/stat.c
> -----------------
> For some reason, the help blocks file/filesystem are swapped. The
> relevant difference is that the Tizen version implements 2 new formats:
> %T for a human readable filesystem type and %C for the security context.

Ah, I'd only noticed one. (Due to the swapping.)

ftype_to_string() seems like it should share code with blkid.c, but
that's on-disk format vs sysinfo format. (And this is not naturally a
function, this is an array checked by a for loop. And why is the
argument uint64_t when every checked constant fits in an int?)

What _is_ smackfs, anyway?

> I think that this command could be picked from Tizen. The commit to
> cherry-pick is ef1d5f3842c30df771a26b77145a3794e1e6031a (but be careful
> because it also pulls toys/posix/cp.c, see below)

Um...

+  else if (CFG_STAT_C && type == 'C') {
+    char *label = NULL;
+       if ((lsm_lget_context(*toys.optargs, (char **)&label) > 0) &&
label) {
+      xprintf("%s", label);
+         free(label);
+       }

Funky indentation aside (the if is 4 spaces in from the variable
declaration, then the xprintf is level with the if despite being in
curly brackets?) I don't understand why you're typecasting &label. It's
a char * declared on the line above, so if you take the address of it
with &label you get a char **, and then you typecast it to that again?

Not _major_ issues, but... why?

> This cherry pick could be amended to swap again the block of help. I
> guess that it is better to present file related help before filesystem
> related help. (well if it is not to tall or that you can scroll ...)

If it's long enough to scroll the screen the one at the end might be
considered more prominent because it stays on the screen, I'm not hugely
tied to either order, but the _churn_ seems unjustified? (It's not that
it was changed, it's that there was no obvious reason to change it and
no explanation given?)

My idea of "cherry pick" is to read an implement the indidivual features
as separate commits. Lemme start with %T...

> Maybe some caution should be taken with the default formating to ensure
> backward compatibility.

Did it change the default output?

Lemme look at the rest of this in a separate email...

Rob

 1444510858.0