Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kulakowski opened this Issue Feb 20, 2019 · 10 comments

Comments

Projects
None yet
9 participants
@kulakowski
Copy link
Contributor

kulakowski commented Feb 20, 2019

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

This comment has been minimized.

Copy link
Contributor

nagisa commented Feb 20, 2019

#[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

This comment has been minimized.

Copy link
Member

sfackler commented Feb 20, 2019

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

@abarth

This comment has been minimized.

Copy link

abarth commented Feb 20, 2019

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

This comment has been minimized.

Copy link
Contributor Author

kulakowski commented Feb 20, 2019

Redox has no target_family:

target_family: None,

@sanxiyn

This comment has been minimized.

Copy link
Member

sanxiyn commented Feb 28, 2019

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

How do we proceed now?

@cup

This comment was marked as off-topic.

Copy link

cup commented Feb 28, 2019

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

This comment was marked as resolved.

Copy link
Member

sanxiyn commented Feb 28, 2019

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 comment has been minimized.

Copy link

spacejam commented Feb 28, 2019

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

This comment has been minimized.

Copy link
Contributor Author

kulakowski commented Feb 28, 2019

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

@cup

This comment was marked as resolved.

Copy link

cup commented Feb 28, 2019

@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.

@cramertj cramertj changed the title Fuchsia is not unix Fuchsia's target_family should be None, not "unix" Feb 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.