Support for this target OS is not implemented yet!.

[anoduck]

Attempted to install starship for zsh on OpenBSD-CURRENT, and received the following error message: Support for this target OS is not implemented yet!.

Why is it not allowing me to build? OpenBSD runs rust too.

[davidkna]

This crate interfaces with the operating system and needs to be explicitly extended to work with every OS including OpenBSD. Nevertheless, allowing other targets to build with a dummy implementation, by moving errors to the runtime, could be an improvement.

[sharunkumar]

I am getting the same thing when running on termux in android

cargo install bottom

I guess since this repo is a dependency, it led me here

[anoduck]

This crate interfaces with the operating system and needs to be explicitly extended to work with every OS including OpenBSD. Nevertheless, allowing other targets to build with a dummy implementation, by moving errors to the runtime, could be an improvement.

Just saying…
The later solution would be more efficient use of resources. To my understanding and to my experience, OpenBSD is more likely to be run on a desktop than a laptop. This is often due to hardware compatibility issues (or was in the past), and the desire to prioritize speed and usability over security and… whatever…
This is just IMHO. Take it for what it is worth.

[naguam]

I am getting the same thing when running on termux in android

cargo install bottom

I guess since this repo is a dependency, it led me here

I think that now rust-battery is an optional dependency of bottom.

I tried to run bottom on NetBSD though and even if it build well it seems its not the only thing missing to make it work.

Bottom needs full porting at least on NetBSD (I don't know for OpenBSD but this might be similar, just try)

[ahaoboy]

Disabling the default feature installed successfully

cargo install --no-default-features starship

cargo install --no-default-features bottom

[anoduck]

@sharunkumar Termux is not containerized or virtualized. Meaning, Termux is still dependent on the sub-framework of android. While this normally would not cause an issue, in the case of accessing device peripherals, this would cause difficulties. As the two are differently structured and use different labeling schemes.

@naguam Yeah, same here. Bottom looks awesome, but does not finish building without error. NetBSD is a beautiful OS. Enjoy it.

[naguam]

#69

Here it comes for NetBSD :)

[chilledfrogs]

So I'm trying to look into this for OpenBSD, thus far it seems to be implemented by 2 possible mechanisms:

1. the APM_IOC_GETPOWER ioctl (see apm(4))
2. the hw.sensors.acpibat* sysctl (see acpibat(4))

However, I noticed, from what I can tell given that I have never written Rust before, that calculations in order to obtain the battery percentage instead of direct voltage values seem to be implemented by the battery crate itself, and the first interface on OpenBSD, which seems to be the recommended one, reports a battery percentage directly. Therefore, is one preferable over the other?

[anoduck]

@chilledfrogs Just making sure I understand the question correctly:

• acpibat is a c-lib which makes up part of OpenBSD's source code for the OpenBSD kernel. Which is located at /usr/share/compile/GENERIC.MP/acpibat.o.

• apm is the client for apmd. "Apmd" being the advanced power management daemon, which has to be enabled and run as a system service.

If all of this is correct, and my understanding of what libraries are used to compile c programs, then you really only have apm as an option.

[davidkna]

@anoduck I assume that any sysctls that can be queried in the usual manner.

@chilledfrogs I would be fine either way if the API can be covered reasonably. That said, an additional percent-based API might be useful for also fixing #34.
Furthermore, on NetBSD the ACPI battery API used in this crate only covers ACPI batteries and not other less common options, so apm may offer better coverage.

[naguam]

NetBSD's APM and OpenBSD APM are probably different and not forcibly compatible.

On NetBSD APMd is deprecated and supports no more than the sysmon envsys subsystem.
Therefore supporting APM on NetBSD does not bring more coverage at all.
The new subsystem is meant to replace it.

The NetBSD sysmon envsys subsystem is a NetBSD only interface.

The envsys interface can cover other types of batteries but I only implemented acpibat batteries because Rust mostly targets works on amd64 and arm64 anyway on this OS at this time which mostly only use acpibat batteries.

If the plist (xml) exposed via envsys follows the same format as acpibat for other kinds of batteries, there is possibility to bring support for other types of batteries by just changing one line, but as of now, it is not relevant.

The OpenBSD method to get acpi batteries is the syscl.

I started working on it and then gave up because rust-analyzer was crashing on OpenBSD and trashing my editor.
I also had file sync problems when saving files and losing work.

And I did not want to have to bother with that.
Maybe the situation improved since but yes....

[chilledfrogs]

@anoduck I am talking about the APM ioctl, not the command, hence section 4 of the manual which I mentioned, and I am also talking about the C sysctl call, not the command

[naguam]

Maybe I explained badly, but the new system is not using the apm ioctl, but the envsys subsystem has its own ioctl.
The whole APM subsystem is deprecated on NetBSD and not just the daemon or command.

https://man.netbsd.org/apmd.8

The apmd is largely deprecated. Modern systems supporting ACPI should
rely on acpi(4), powerd(8), and the envsys(4) framework instead.

It is deprecated in the same sense FreeBSD deprecated it (implementation of FreeBSD in this project is using sysctl, OpenBSD has sysctl for acpi batteries as well).

https://github.com/starship/rust-battery/blob/main/src/platform/netbsd/sysmon.rs

It is BSD, system utilities (within the base) and kernel subsystems are developed together.

Saying it is only or not about the userspace tools is not so much relevant.

OpenBsd having sysctl for batteries and FreeBSD using such a method, inspiration can be taken on that side.
Or use APM.

I just think it does not make sense to expect to try to unify with NetBSD. These are different OS after all despite shared roots that now have diverged for a very long time.