*BSD support

[mikroskeem]

hopefully pedantic *BSD fans won't kill me now

Perhaps low priority, this is more for fun rather than using in production I guess? Depends how serious this project gets.

My friend came up with a crazy idea to simply replace Debian installation's Linux kernel with FreeBSD's and keep most of the things working (old init scripts seem to be rotting). Having BSD support would make this idea actually doable

[artizirk]

rustysd could provide compatibility layer for Debian GNU/kFreeBSD https://wiki.debian.org/Debian_GNU/kFreeBSD

[KillingSpark]

I seem to remember debian to be somewhat opposed to rusts static compilation implications, but it could be very fun to see

This project is very much about having fun and just seeing where it will lead. Right now it is very much NOT usable in production (assuming you care about keeping your job)

I would love for people to test this on any *BSD they have available and look into any issues they might have, as one of the goals is to be as platform independent as possible (as long as it's unix and has a rust compilation target). I might add some linux specific stuff (cgroups e.g.) but I hope I will be able to make these optional and be hidden behind build feature flags

[KillingSpark]

I noticed that eventfd is actually not unix but linux specific. I provided an implementation using regular pipes that should work on all and hide eventfd behind a feature flag. It should now build (and run) on *BSD as well.

[icefoxen]

If I may poke my nose in, from what I've heard Rust's assumption of all-in-one compilation makes life difficult for distros in general 'cause, well, usually Rust doesn't distribute compiled libraries. Then even when it does, they're usually static-only, and so if you do a bugfix release on a package containing a library then you have to recompile and upgrade everything that depends on it too. It's not necessarily a dealbreaker, there are Rust programs in Debian, but it makes life harder.

Now that I think of it, BSD's might actually have an easier time with that 'cause their ports systems tend to be more source-centric.

[bjorn3]

Then even when it does, they're usually static-only, and so if you do a bugfix release on a package containing a library then you have to recompile and upgrade everything that depends on it too.

The same is true for c++ code which uses templates, as the template implementations must be visible to instantiate templates when they are used.

[icefoxen]

Aha, good point. Hence why Boost upgrades on debian are always such a pain...

[KillingSpark]

I noticed that eventfd is actually not unix but linux specific. I provided an implementation using regular pipes that should work on all and hide eventfd behind a feature flag. It should now build (and run) on *BSD as well.

Tested it on a buddies freebsd system, it works :)

[CameronNemo]

Does any BSD support pidfd's? If I was writing a this-decade service manager I would use pidfds for avoiding races and more ergonomic parallelism.

https://github.com/pop-os/pidfd

[KillingSpark]

It seems like freebsd has something similar (source) but other BSDs dont. Also it's linux 5.4+. I'd like to avoid having too many optional mechanisms so I'm probably not going to be using pidfds for now. But the unsafety of using pids and pgids is something that annoyed me already. So i might do this in the future

[zoujiaqing]

I hope rustysd support freebsd ;)

[KillingSpark]

I hope rustysd support freebsd ;)

It should! If something doesn't work please do report it :)

[zoujiaqing]

I want use rustysd set to init system on FreeBSD!
How to do?

[KillingSpark]

I don't know tbh. I am not very familiar with freebsd. You'd need to examine which services are running now on your freebsd system and probably write unit files for these services, or maybe find unitfiles on some linux distro if the service is available there.

Do not do this on a machine you need in any capacity. I can't guarantee that this will not make your system unbootable.

[valpackett]

procdesc (pidfd) is not exactly the API intended for a supervisor, it offers nothing in terms of tracking escaping children. It's also possible to track processes across forks with an EVFILT_PROC in kqueue but that does nothing in terms of safety. It's procctl(PROC_REAP_*) that you want! I just wrote a demo for this lobste.rs thread. Basically, every child PID of a reaper is automatically an inescapable tracking group that the reaper can reliably signal.

I'm considering using rustysd (instead of reinventing the wheel from scratch) for my custom FreeBSD-derived distribution, so I might look into implementing this functionality here. Though there seems to be a lot of complexity that doesn't match my use case, I'm not sure…

btw as of crates.io libc 0.2.140, eventfd is exposed on FreeBSD 🎉