Tip jar

If you like CaB and wish to support it, you can use PayPal or KoFi. Thank you, and I hope you continue to enjoy the site - Neil.

Buy Me a Coffee at ko-fi.com

Support CaB

Recent

Welcome to Cook'd and Bomb'd. Please login or sign up.

March 28, 2024, 10:14:04 AM

Login with username, password and session length

Are we finally there with Linux?

Started by RenegadeScrew, April 02, 2021, 12:14:03 PM

Previous topic - Next topic

Blumf

Quote from: Zetetic on April 16, 2021, 04:48:58 PM
...if you're interested in doing hardware stuff...

So driver level stuff, which naturally requires low level code. Not really what I'm talking about.

Wait, are you writing device drivers in PowerShell??

Zetetic

Driving GPIO pins from userspace isn't "driver level stuff", and doesn't naturally require low level code.


Zetetic

Those only work for drivers that implement the libgpio interface (which is absolutely not all Southbridge drivers that you might well encounter if you're using a diverse set of hardware over a few years, still).

Blumf


Zetetic

In the sense thar you can cast all kernel API (and associated tooling) issues as "driver issues" if you try hard enough, I guess. There is a tradition of this, I suppose. It doesn't really change the point.

Blumf

Well, put it this way, when you use grep, it's not talking directly to the SATA driver, there's at least the filesystem driver between them, and a unified kernel API on top of all that. You would not write grep to directly talk to either the SATA driver, or the FS driver. And you sure as hell wouldn't run a bash script to read /dev/sda1 directly for that purpose.

It seems, in your case, that the variety of GPIO drivers should be behind a unifying API that would allow general user space tools to talk to them. That there isn't such a thing (yet?) means you are having to do low(-ish, not bare metal) level direct interfacing to the hardware drivers. That's ideally not something that should be done with typical admin tools unless you really need to.

Compare with the variety of fsck tools that wrap the lower level FS driver details behind a (somewhat) unified interface, which means you don't directly need to call the kernel to check a file system.

Zetetic

Quote from: Blumf on April 16, 2021, 06:27:42 PM
It seems, in your case, that the variety of GPIO drivers should be behind a unifying API
Yes, and that's the intention of the libgpio setup. And before that the vfs-based filesystem API.

As that hints at, part of the issue that Linux has in consistently exposing features to users in a usable fashion is a lack of consistent API stability. Which is both a boon (because first goes at APIs are often shit, and notably the pre-4.8 GPIO interface had a bunch of problems) and a pain in the neck.

Noting that this started from the question of being confident that you could accomplish admin stuff from a CLI.

Blumf


Zetetic

Most recently, setting status LEDs.

I think the cgroups and namespaces discussion is a more interesting one, to be honest.

Blumf

Can't say I've played with that stuff, outside of a quick look at Docker, so not directly.