[Toybox] getprop.c

[Rob Landley]

I'm working on release notes and I noticed this is the android toybox repo:

  Author: Tom Cherry 
  Date:   Thu Jan 4 10:13:59 2018 -0800

  Reland: Stop building getprop

  We've replaced this with our own C++ version to support the new
  property info parsing.

  Bug: 36001741
  Test: Compared getprop results with toybox getprop
  Change-Id: I022e1ee63635547e2705d43c818579a68f01b872

But this is how toys/android/getprop.c starts:

  /* getprop.c - Get an Android system property
   *
   * Copyright 2015 The Android Open Source Project

  USE_GETPROP(NEWTOY(getprop, ">2Z", TOYFLAG_USR|TOYFLAG_SBIN))

  config GETPROP
bool "getprop"
default y
depends on TOYBOX_ON_ANDROID && TOYBOX_SELINUX
help
  usage: getprop [NAME [DEFAULT]]

  Gets an Android system property, or lists them all.
  */

  #define FOR_getprop
  #include "toys.h"

  #include 

  #include 

I.E. it "depends on" android, it's in the android directory, the help text says
it's for android, and i'm pretty sure non-android systems haven't got
selinux/android.h. There can be no non-android use of this command.

Shouldn't we remove this command from toybox if you've decided to use a
different version than the one you yourselves wrote and submitted to toybox...?

Confused,

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] getprop.c

[enh]

On Wed, Feb 14, 2018 at 8:06 AM, Rob Landley  wrote:
> I'm working on release notes and I noticed this is the android toybox repo:
>
>   Author: Tom Cherry 
>   Date:   Thu Jan 4 10:13:59 2018 -0800
>
>   Reland: Stop building getprop
>
>   We've replaced this with our own C++ version to support the new
>   property info parsing.
>
>   Bug: 36001741
>   Test: Compared getprop results with toybox getprop
>   Change-Id: I022e1ee63635547e2705d43c818579a68f01b872
>
> But this is how toys/android/getprop.c starts:
>
>   /* getprop.c - Get an Android system property
>*
>* Copyright 2015 The Android Open Source Project
>
>   USE_GETPROP(NEWTOY(getprop, ">2Z", TOYFLAG_USR|TOYFLAG_SBIN))
>
>   config GETPROP
> bool "getprop"
> default y
> depends on TOYBOX_ON_ANDROID && TOYBOX_SELINUX
> help
>   usage: getprop [NAME [DEFAULT]]
>
>   Gets an Android system property, or lists them all.
>   */
>
>   #define FOR_getprop
>   #include "toys.h"
>
>   #include 
>
>   #include 
>
> I.E. it "depends on" android, it's in the android directory, the help text 
> says
> it's for android, and i'm pretty sure non-android systems haven't got
> selinux/android.h. There can be no non-android use of this command.
>
> Shouldn't we remove this command from toybox if you've decided to use a
> different version than the one you yourselves wrote and submitted to 
> toybox...?
>
> Confused,

gah, i thought i'd sent mail about this, but gmail search says i'm
going senile...

from our perspective, yes, this can be deleted. you might choose not
to delete it depending on the extent to which you also aim to be
pushable to old OS releases and take over all the functionality there.
but part of the problem with getprop/setprop is that -- because
SELinux heavily restricts what an app can do, and because system
properties were never considered "API" (even though in many cases,
often for lack of a real API, they got used as such) -- there's been
little attention to backwards compatibility there.

actually, this might be where i stalled last time i was going to write
this mail: i remember trying to draw up a list of what works where.
but i think i decided "unlike the rest of toybox, with getprop/setprop
you're probably best just keeping the ones already on the system". in
particular, any improvements we've made to the tools have actually
required a new OS to go along with them. even if you build toybox
against a libc.a new enough to contain the new APIs (coming soon in
NDK r17), the daemon on the device won't know what you're asking it.
there's really nothing except source and binary incompatibilities to
gain. (which was why, rather than write a C wrapper for the new C++
property APIs we just wrote a C++ getprop instead. although i'm hoping
that we can at least go a _few_ years this time without another change
to this stuff...)

note that we haven't replaced setprop and have no reason to do so yet,
so the other oddity is that it makes sense to remove toybox getprop
but keep toybox setprop!

> Rob
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] getprop.c

[scsijon]

May I point out that getprop and setprop are windows, Netware and Mac 
based in the origins of the desktop world, and are used nowadays by the 
like of gnome, java, adobe, steam (games), SAS and a few ... other 
mainline packages.


I'm not sure that android has control rights as they seem to imply they 
have.


Maybe toybox's should just be de-androided instead.

?may be of interest and help,
http://docs.runrev.com/Control-Structure/getProp
http://docs.runrev.com/Control-Structure/setProp
one of my favorite sites.

scsijon
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] getprop.c

[enh]

they're unrelated. (the distinction between native system properties
and Java system properties -- both of which are relevant on Android --
causes a deal of confusion.)

On Wed, Feb 14, 2018 at 3:00 PM, scsijon  wrote:
>
> May I point out that getprop and setprop are windows, Netware and Mac based
> in the origins of the desktop world, and are used nowadays by the like of
> gnome, java, adobe, steam (games), SAS and a few ... other mainline
> packages.
>
> I'm not sure that android has control rights as they seem to imply they
> have.
>
> Maybe toybox's should just be de-androided instead.
>
> ?may be of interest and help,
> http://docs.runrev.com/Control-Structure/getProp
> http://docs.runrev.com/Control-Structure/setProp
> one of my favorite sites.
>
> scsijon
>
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

[Toybox] Init -waitfor?

[scsijon]

BarryK of Puppylinux's origins has been having a problem I think may be 
worth sharing. 
(http://bkhome.org/news/201802/experimenting-with-busybox-runit.html)


It's basically because:

"Neither System V init, daemontools, runit or perp provides any hooks to 
wait for a service to go up or down. runit provides a waiting mechanism, 
but it's based on polling, and the ./check script has to be manually 
written for every service." (https://skarnet.org/software/s6/why.html).


I know he's talking about Busybox's runit in this case, but would it be 
worth adding this facility to toybox?

___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

[Toybox] toys/android/log.c with android NDK?

[Rob Landley]

I grabbed the current ndk (-r16b), make_standalone_toolchain.py'd an --arch
x86_64 --api 26 toolchain, and then built defconfig toybox with it, and at link
time it failed to find:

 '__android_log_write'
 'facilitynames'
 'getgrgid_r'
 'iconv'
 'iconv_open'
 'prioritynames'
 'sethostname'
 'stderr'
 'stdin'
 'stdout'

I've mentioned stdin/stdout/stderr here before. sethostname() is a trivial
syscall wrapper, iconv() and iconv_open() I _know_ bionic has because I
complained about them being implemented in c++, android_log_write() is your own
function (and the double underscore is confusing)...

More to the point all of this _compiled_, meaning it's in the headers. And then
it couldn't find it in the libraries. So there's a consistency issue somewhere.

I can try to fix it up in lib/portability.c...?

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] toys/android/log.c with android NDK?

[enh]

On Wed, Feb 14, 2018 at 3:36 PM, Rob Landley  wrote:
> I grabbed the current ndk (-r16b), make_standalone_toolchain.py'd an --arch
> x86_64 --api 26 toolchain, and then built defconfig toybox with it, and at 
> link
> time it failed to find:
>
>  '__android_log_write'
>  'facilitynames'
>  'getgrgid_r'
>  'iconv'
>  'iconv_open'
>  'prioritynames'
>  'sethostname'
>  'stderr'
>  'stdin'
>  'stdout'
>
> I've mentioned stdin/stdout/stderr here before. sethostname() is a trivial
> syscall wrapper, iconv() and iconv_open() I _know_ bionic has because I
> complained about them being implemented in c++, android_log_write() is your 
> own
> function (and the double underscore is confusing)...
>
> More to the point all of this _compiled_, meaning it's in the headers. And 
> then
> it couldn't find it in the libraries. So there's a consistency issue 
> somewhere.

i suspect you said "--api 26" but then also tried to build a static
binary? in which case you linked against an api 21 libc.a. as i said
(somewhere) earlier today, NDK r17 (and later) will have a modern
libc.a, but for NDK r16 you'll want to either (a) set --api 21 for
static binaries or (b) build a dynamic binary for --api 26.

longer term 
(https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md)
we want to make standalone toolchains obsolete by just teaching the
clang driver everything it needs to know about Android, so hopefully
before the end of the year it's just a matter of `CC=ndk-clang make
defconfig`.

> I can try to fix it up in lib/portability.c...?

the __android_log_write thing might need a fix on your side: i suspect
you're missing a -l for the NDK liblog?

> Rob
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net