Run GNU/Linux on a smaller computer for drivers and interface it with a FreeBSD system?

M

mavavilj

I have been thinking about the old problem of Linux having more drivers than BSDs. The drivers are, however, locked to the Linux kernel.

Then I thought, has it been explored that one would run GNU/Linux just for the drivers using, for example, something like a Raspberry Pi (specifically, an x86 equivalent), and then pipe this to a FreeBSD system using ethernet for sharing?

One would then want just an application for FreeBSD and an application for Linux that can manage these shared devices.
 
Last edited:
Disclaimer: it's been years since I last touched a Linux system (well, a real one, not talking about Windows sub-systems (wsl.exe)). Thing is... no matter the distribution you could always recompile and thus "trim" the kernel. From what I can tell by a quick Google search this still seems to be the case.

IMO that seems more feasible then trying to somehow combine 2 operating systems.

In fact.. if you want to go this route then I think you're even better off with Windows and then dropping / swapping the GUI for PowerShell; the overhead is gonna be a lot less because Windows provides broader hardware support and basically has embedded Linux support as well.

I mean... the FreeBSD Linux sub-system is impressive, but you can't expect it to run just any kind of Linux device driver either.
 
rootbert said:
well, just install Linux and use KVM to run FreeBSD in a VM.
Click to expand...
I prefer FreeBSD, but this is exactly what I do when I have hardware which FreeBSD does not support well.

Case in point is my Framework Laptop 16, which I use when I am traveling.

I'm sure I could spend ages trying to make it mostly work with FreeBSD. But, these days I have better ways to spend my time.

The Framework Laptop 16 works, and is supported, with Linux.

Hence my basic desktop on the laptop is Linux gnome, but all the important things are done with FreeBSD running under KVM...
 
mavavilj said:
I have been thinking about the old problem of Linux having more drivers than BSDs. The drivers are, however, locked to the Linux kernel.
Click to expand...
Is the absolute number of drivers important? Or the type of driver? What kind of driver are you hinting at? For what sort of device?

mavavilj said:
Then I thought, has it been explored that one would run GNU/Linux just for the drivers using, for example, something like a Raspberry Pi, and then pipe this to a FreeBSD system using ethernet for sharing?
Click to expand...
So wifi? A basic wifi/ethernet bridge is pretty cheap. Works with any OS. Probably works better than wifi on a pi too.
 
mavavilj said:
WSL does not run any native Linux application.
Click to expand...
It does, you'll be surprised.

If you want a small computer with drivers, all you have to do is get a Celeron-powered netbook for that, and let FreeBSD be the cloud that pipes the data to that netbook. In fact, this is how Chromebooks and iPads already work... Just install Linux on a random cheap netbook or a pi, suck the data off an Epyc-based server with FreeBSD, done.

However, if you're looking at a tool to collect data and pipe it to a FreeBSD-based machine for analysis (Like a water meter or electricity meter), you might be better off looking for a specialized device that can export data over wifi or Bluetooth or ethernet to a remote host. Sometimes, just stating the problem and figuring out which way the data is supposed to flow - that can be enough to figure out the problem. Now, whether or not that sensor is running embedded Linux or another RTOS - that's a different story. Normally, the priority would be establishing the very fact of collecting the data that gets sent to the cloud.
 
mavavilj said:
Then I thought, has it been explored that one would run GNU/Linux just for the drivers using, for example, something like a Raspberry Pi, and then pipe this to a FreeBSD system using ethernet for sharing?
Click to expand...
I'm thinking something like having the Linux host on a RPi and having the raw data from devices as-is over to FreeBSD would be way-higher bandwidth than Ethernet could provide (Pi iirc is Gigabit); I'm not too sure if that's possible :p

Remote desktop from the Pi to a different FreeBSD host computer could work.

One idea is to have a Linux RPi, powered by a FreeBSD computer's USB, and the Pi connected to a video capture card (they make small USB-C dongles for HDMI 4K@60Hz nowadays). You'd view the capture from a video app on FreeBSD (OBS Studio, VLC, etc), and swap USB keyboard/mouse to it (I'm thinking a KVM would make it easy). No virtualization required and it's a small physical footprint! Maybe with input forwarding(?) from FreeBSD you can skip the physical USB/KVM switch and have input over Ethernet/wifi to the Pi while still having display over the capture card.
 
Espionage724 said:
I'm thinking something like having the Linux host on a RPi and having the raw data from devices as-is over to FreeBSD would be way-higher bandwidth than Ethernet could provide (Pi iirc is Gigabit); I'm not too sure if that's possible
Click to expand...
Really? just how do you think security/snort or /usr/sbin/tcpdump (tcpdump(1)) work? If you wanna sniff packets on your home router, you get the interface on the Linux-based wifi router (with dd-wrt or openwrt) to take a dump of data onto the screen of your FreeBSD laptop... 😲😤 There's your real-world sensor example. Or even the smart water/power meters... If those water/power meters run some kind of embedded Linux (Android is not out of question), that really checks all of OP's boxes.
 
astyle said:
Really? just how do you think security/snort or /usr/sbin/tcpdump (tcpdump(1)) work? If you wanna sniff packets on your home router, you get the interface on the Linux-based wifi router (with dd-wrt or openwrt) to take a dump of data onto the screen of your FreeBSD laptop... 😲😤 There's your real-world sensor example. Or even the smart water/power meters... If those water/power meters run some kind of embedded Linux (Android is not out of question), that really checks all of OP's boxes.
Click to expand...
I was thinking more about video when my Intel iGPU can do 40GB/s peak bandwidth by itself :p USB 2.0 is almost half of 1Gbps for something serious enough to max that.
 
Espionage724 said:
I was thinking more about video when my Intel iGPU can do 40GB/s peak bandwidth by itself :p USB 2.0 is almost half of 1Gbps for something serious enough to max that.
Click to expand...
For video, there's always Reflection X, or, if it's between two hosts that both run Xorg, it's not that hard to set up X forwarding. There's also RDP and Samba/NFS for shared disks. My point is, OP needs to define a task in more detail than what we've seen so far. Otherwise, the solutions are gonna be all over the map, and still check the boxes. Remote X sessions don't send that much data. Hell, even videoconferencing doesn't (unless all of the cams are set to capture at 8k!)

If this conversation continues long enough, you'll learn how to program the PCI-E lanes for video streaming, know which scenarios make it a good idea or a sub-optimal one - and still not know what OP wants.

Espionage724 said:
I'm thinking something like having the Linux host on a RPi and having the raw data from devices as-is over to FreeBSD would be way-higher bandwidth than Ethernet could provide (Pi iirc is Gigabit); I'm not too sure if that's possible
Click to expand...
What you're talking about is called Distributed Computing, or Distributed Control System... I think that OP would benefit from reading up about those topics. It woud kind of help to have an overview of how such systems are put together, and how they work. Yeah, those are possible with FreeBSD or any mix of OSes, frankly. Not impossible to put together a functional system using only the hardware components we know about on the consumer market. But once you put the hardware components together, and install the software, you'll realize that what matters in such systems is very different from what matters in consumer-grade devices. Sometimes, you decide to not send video data at all. Sometimes you decide that yeah, video is needed (like during a sewage pipeline inspection), so you put in effort into optimizing how to handle the video data. And the optimal solution may turn out to be VERY different, depending on the task at hand.
 
mavavilj said:
WSL does not run any native Linux application.
Click to expand...
You're wrong about that one ;)

I have a Debian image running which I got from the app store, and guess where /etc/apt/sources is pointing to? None other than the official Debian repositories. In other words: every program I install using apt is in fact... a native Linux application.

And it gets better before it started, because it even allows me to build my own stuff too. Installing GCC and the right libraries is but one command away, as is grabbing Git.
 
Networked "device drivers" exist, for example there is networked NVMe. Which of course is useless for this as FreeBSD already has NVMe support.

In other examples the network layer is much higher than the kernel driver. For example in audio you have network functionality in jackd. So you can have a soundcard unsupported by FreeBSD in a Linux or Windows machine and use it on FreeBSD as if it is local (except latency of course).

Such efforts for low level drivers will require extensive customizations for each kind of driver.
 
cracauer@ said:
networked NVMe
Click to expand...
What's the diff between that, and say, NFS/Samba/WebDAV ? (aside from the obvious issue of latency that was introduced by the very fact of the NVMe being on a remote host?) You'd have to know how to emulate PCIe lanes over HTTPS, I think.

A quick look on Wikipedia pointed me to NVMe over TCP section... Dunno if FreeBSD even supports that, but I would not dismiss that idea out of hand, and in fact, imagine that to be a very distinct technical possibility. After all, this is how Google rents out web hosts that you can pretend to build like a consumer-grade machine (select processor, SSD capacity, RAM, you name it). Whether or not FreeBSD actually supports that kind of hardware control - finding that out is left as an exercise for the reader.
 
astyle said:
What's the diff between that, and say, NFS/Samba/WebDAV ? (aside from the obvious issue of latency that was introduced by the very fact of the NVMe being on a remote host?) You'd have to know how to emulate PCIe lanes over HTTPS, I think.

A quick look on Wikipedia pointed me to NVMe over TCP section... Dunno if FreeBSD even supports that, but I would not dismiss that idea out of hand, and in fact, imagine that to be a very distinct technical possibility. After all, this is how Google rents out web hosts that you can pretend to build like a consumer-grade machine (select processor, SSD capacity, RAM, you name it). Whether or not FreeBSD actually supports that kind of hardware control - finding that out is left as an exercise for the reader.
Click to expand...

It's in Linux.

It is more comparable to iSCSI in that only a single client can use it, and the filesystems run on the client (it gets a raw block device). Not on the server like with NFS and SMB.

As for finding it in FreeBSD, I guess the pressure isn't very high since you can use iSCSI for almost the same purpose.
 
cracauer@ said:
It's in Linux.

It is more comparable to iSCSI in that only a single client can use it, and the filesystems run on the client (it gets a raw block device). Not on the server like with NFS and SMB.

As for finding it in FreeBSD, I guess the pressure isn't very high since you can use iSCSI for almost the same purpose.
Click to expand...
Well, I did find it :P
1745433639876.png

😤 😏
 
I'm not sure I fully understand what you're trying to achieve OP, but you might be interested in this idea. You can run a full X11 desktop on a remote system over the network using a nested X server, typically Xnest (which is old) or Xephyr (which is a bit more modern and a bit better). This is possible because X11 is a networked window system.

Now, suppose you have your framework laptop running gnome as your desktop, and your have a rpi or some other machine on the network running freebsd. You can do something like this in a terminal on the linux box. You need to have a window manager like fvwm and X11 forwarding enabled for ssh on the freebsd box (man sshd_config).

$ Xephyr -screen 1024x768 -nolisten tcp -reset -terminate :1 2>/dev/null &

This will open a window containing a nested X-server on your gnome desktop (this will only work if you're running X11 underneath gnome, it might not work on wayland, I'm not sure what happens with Xwayland).

Your framework's desktop is X display :0, and the new nested server in the Xephyr window is display :1

Now in your terminal shell you can say

$ export DISPLAY=:1

And then you can run any X client on your remote system (the rpi running freebsd) using ssh, for example to run an xterm on the remote freebsd system and have its window appear within the nested X server on your gnome machine, run

$ ssh -X remotehostname xterm &

You may have to play around with xauth settings, you can temporarily just say 'xhost +' to allow clients from other mahines to attach to try it out. You need to run 'xhost +' before you export DISPLAY=:1.

Now, that's all well and good, but it's not particularly impressive. Much more impressive is to run an entire desktop on the remote system in a fullscreen nested Xephyr session.

For this you will want to replace the -screen argument to Xephyr with '-fullscreen', and then to run a full window manager , like fvwm for example, on the remote system; to do that you would say something like

$ ssh -X remotehostname fvwm &

Which will bring up a full fvwm desktop inside your nested X server that is fully running on the remote freebsd machine.

For bonus points you can start an entire gnome or kde session on the remote machine. If you search the web you will find people have written up full howtos on how to do this, I have just sketched out the steps above.

So you can dedicate one of the virtual desktops on your linux laptop to be a full screen nested X session that is running a full desktop on your remote freebsd box.

This is some of the nice stuff you can do with a networked window system like X11.
 
blackbird9 said:
I'm not sure I fully understand what you're trying to achieve espionage,
Click to expand...
Why espionage? How is the term even relevant here?

Besides, we have yet to see OP's reply since post #3, otherwise it really looks like people who are more knowledgeable about the topic have hijacked the conversation, and everybody but OP wants to get their two cents in. 😩
 
astyle said:
Besides, we have yet to see OP's reply since post #3, otherwise it really looks like people who are more knowledgeable about the topic have hijacked the conversation, and everybody but OP wants to get their two cents in. 😩
Click to expand...
including astyle? :) 🤣

... yeah, I guess I was rabbiting on, as usual...
 
You must log in or register to reply here.
Back
Top