Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Fuchsia's target_family should be None, not "unix" #58590
Currently, the Fuchsia target is part of the unix target_family. I'd like to suggest that this should not be the case, and that
First, I want to capture what I think the opposite case is. Fuchsia does support some amount of posix functionality. That subset is currently informal and pragmatic. It has made starting to port exist software a certain amount easier.
"unix" connotes a lot of things. I've singled out some big ones that do not apply to Fuchsia. I think that in aggregate, these outweigh the benefits mentioned above.
Process model: Fuchsia does not have fork and exec, and does not have a process hierarchy. There's no
Signals: Fuchsia does not have unix signals.
Filesystems and users: Fuchsia does not have unix users or groups, and does not implement unix filesystem permissions. Fuchsia does not have a global filesystem.
FDs: Files and file descriptors are central, primitive concepts for unix: "everything is a file". In Fuchsia, they are an abstraction built out of other primitives, and working with those primitives directly is often preferred.
C and ABI: Unix system ABIs are typically deeply intertwined with its C standard library, and C is a de facto standard for specifying ABIs (witness
IO: Portable unix IO boils down to synchronous read(2) and write(2). Abstractions for event-driven programming exist, but are not portable. Fuchsia has limited emulation for some of them, preferring instead to use native constructs more directly.
In aggregate, I think defining
I'd love for rust programs, existing or not, to be as good as possible as easily as possible when built for Fuchsia. I think not setting
For some background: I work on Fuchsia. Among other things, I am one of the maintainers for our libc.
#[cfg(unix)] was historically defined as
While the name is misnomer, making Fuchsia neither
That approach would seem limiting. For example, Rust might want to support a future operating system that is quite different from both Unix and Windows some day.
hm ok no one wants to address the elephant in the room?
i will surely get some details wrong, so feel free to correct. firstly, both
while you may be able to convince some people (myself included), that Fuchsia is
and see this (emphasis mine):
why should rust bless an OS thats in its infancy with its own family? because of
this one has bitten code I've written, as sled tests used to gate some libc calls (fork + kill 9 for crash testing) on