[Toybox] getprop.c

[enh]

On Wed, Feb 14, 2018 at 8:06 AM, Rob Landley <rob at landley.net> wrote:
> I'm working on release notes and I noticed this is the android toybox repo:
>
>   Author: Tom Cherry <tomcherry at google.com>
>   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 <sys/system_properties.h>
>
>   #include <selinux/android.h>
>
> 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 at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net