Fuchsia's target_family should be None, not "unix"

[kulakowski]

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 #cfg[unix] should be false for Fuchsia.

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 wait(2) or waitpid(2) on Fuchsia.

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 repr(C)). On Fuchsia, almost all ABIs are specified in a language-agnostic IDL. The biggest exception, the system ABI in, we have been careful to describe in terms of ELF dynamic linkage, rather than C per se.

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 #cfg[unix] to be true for Fuchsia is tempting, yet a trap. An existing small program which just wants to synchronously manipulate stdin and stdout seems to benefit, for example, until they want to handle ^C with their same unix code.

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 #cfg(unix) will help with that.

For some background: I work on Fuchsia. Among other things, I am one of the maintainers for our libc.

cc @cramertj

[nagisa]

#[cfg(unix)] was historically defined as #[cfg(not(windows))] so that having two configurations of #[cfg(windows)] and #[cfg(unix)] would "technically" cover all the targets.

While the name is misnomer, making Fuchsia neither #[cfg(unix)] nor #[cfg(windows)] may cause more harm than good.

[sfackler]

Is Redox a unix? That's the other "weird" OS we support IIRC.

[abarth]

While the name is misnomer, making Fuchsia neither #[cfg(unix)] nor #[cfg(windows)] may cause more harm than good.

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.

[kulakowski]

Redox has no target_family:

rust/src/librustc_target/spec/redox_base.rs

Line 26 in 74e35d2

target_family: None,

[sanxiyn]

I think the case of Redox is a good argument for making Fuchsia "not unix". It apparently works.

How do we proceed now?

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
Unix and Windows are a family of operating systems, Fuchsia is not a family but
a singular OS. secondly, and more importantly, Fuchsia is not popular. no
one would argue the question of whether Unix or Windows are popular. my train
of thought is like this

1. would a single target family work? no, Unix and Windows are too different
2. would 2 families work? so far yes pretty much
3. will 3 families ever be needed? likely yes
4. are 3 families needed right now? likely no

while you may be able to convince some people (myself included), that Fuchsia is
not Unix, thats not really germane to the core issue, which is: is Fuchsia alone
enough to justify a new target family? i say no. you go here:

https://wikipedia.org/wiki/Google_Fuchsia

and see this (emphasis mine):

Fuchsia is a capability-based operating system currently being developed
by Google.

why should rust bless an OS thats in its infancy with its own family? because of
the big G?

[sanxiyn]

I think the proposal is to set Fuchsia's target family to None just like Redox, not to create a new third target family.

[spacejam]

this one has bitten code I've written, as sled tests used to gate some libc calls (fork + kill 9 for crash testing) on cfg(target_family = "unix"), which caused an interesting dive into the fuchsia architecture and rust support when I learned that sled ran on fuchsia but failed to build the tests.

[kulakowski]

My specific suggestion is to change target_family from Some("unix") to None. This is what the redox configuration does as well.

@kulakowski perhaps you could edit the title and/or original post to reflect that?

reading the OP on its own, it just seems like you used this issue as a platform to advertise Fuchsia - you didnt mention the word None in the OP a single time.

[vi]

Meanwhile redox: convert to target_family unix.