History log of /fuchsia/zircon/system/ulib/sync/rules.mk
Revision Date Author Comments
# 035548f1 25-Jul-2018 Adam Barth <abarth@chromium.org>

[sync] Build with -fvisibility=hidden

ZX-1895 #comment

Test: No behavior change
Change-Id: Ie0345a54693d703638d3718c62321731a3c1c9c6


# 3319e1a1 25-Jul-2018 Adam Barth <abarth@chromium.org>

[sync] Break sync->fbl dependency

We can just use zx_futex_t instead of defining a new futex_t type.

Test: No behavior change.
Change-Id: I1d3a314af416a6c661f9c493447e7053ab916b00


# aeaa8e2f 23-Oct-2017 George Kulakowski <kulakowski@google.com>

[sync] Allow completion_t to be used from C++

Incidentally this renames the tests, since this thing is no longer part of the DDK.

Change-Id: Ic5e965568ac74fb2e111e5e8eb494d1d626c8124


# f3e2126c 12-Sep-2017 Roland McGrath <mcgrathr@google.com>

[zx] Magenta -> Zircon

The Great Renaming is here!

Change-Id: I3229bdeb2a3d0e40fb4db6fec8ca7d971fbffb94


# 16656ae0 05-Apr-2017 Brian Swetland <swetland@google.com>

[build] flatten the build

Previously we treated kernel/, system/, and third_party/ as
overlays on a shared namespace. This required the concept
of "canonical" module names, and a lot of complexity to ensure
that things didn't collide and the build worked.

This change gets rid of that, no longer passes -I to make,
so that include directives from our *.mk files do not magically
wildcard across various paths, etc.

The most user-visible change is that everywhere where a module
name is specified (MODULE_DEPS, MODULE_LIBS, etc), full module
names like kernel/lib/io or system/ulib/mxio must be used instead
of previously-allowed "short" names like lib/io and ulib/mxio.

The build output still has a similar shape, but the first segment
of the module path (kernel/, system/, or third_party/) is no
longer elided under $(BUILDDIR)

Change-Id: I525aba1da1c86eb7a86007bddc669f7eeebfedd5


# 76c6aea6 21-Feb-2017 Sean Klein <smklein@google.com>

[sync] Export as static library only

MG-511 #in progress

Change-Id: If869d941afd179dffd0546e25ba23a26fa16630b


# 8e9bf06c 17-Feb-2017 Sean Klein <smklein@google.com>

[udev][sync] Move completion to a small synchronization library

'completion.c' does not actually depend on any components in the
driver infrastructure (even though the reverse is generally true).

However, if a non-driver entity wants to use completion.c (and other
interesting synchronization primitives), then the use of these tools
should not necessarily be exclusive to the drivers. ulib/sync could
become the location for other synchronization primitives, such
as reader/writer locks.

MG-511 #in progress

Change-Id: Iaf6ad6b7b3d67c015e5dd9bf6677e5e7de6a8a73