Does this provide protection against opening then device from two processes at the same time?
Does O_EXCL work with linux USB devices?
Writing a basic Linux device driver when you know nothing about Linux drivers
41–50 of 72 posts
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#42Earlier quoted context omitted.
I have a solar inveter from a company, aparticular German brand. I wanted to use home assistant with it so I needed rs232 data.. tried the support and they asked me to sign an NDA. Okay, cool. I did with a fake name, address and everything and they sent a file.. Turns out the file is available online. Facepalm pro Max. So my question is, what kind of "IP" is in a data sheet that needs protection ? And this isnt even…
They have asked to the legal team who basically don't know shit about what us do and who will always take the most conservative approach possible. So you'll get either: no answer, a "NO" answer or an "NDA" answer.
Yup. The default from lawyers will be "No" because why help? The correct way to use lawyers, either in-house counsel or a paid lawyer if you have a specific project is to tell them what you want to happen and then they figure out what the best legal course of action is to closest achieve that. Mundanely this might mean e.g "Fill out form X1234 and then send letters to this politician suggesting they support your X1234 application" but at the extreme it could mean closer to the situation in the UK where a ferry company illegally fired crews with zero notice, and their legal advice had clearly been "Worst case they put one of your executives in prison, probably not even that, but either way you replace union workers with people on slave wages and that means $$$".
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#43This is awesome! But it also makes me a little bit sad. The original parallel port and even ISA interface seemed so simple by comparison, with less layers of abstraction. Just run a wire, and write to a port. I remember when I was a kid, I found a breakout board in an electronics store's random clearance parts bin, with an ISA header on an edge. On a whim I took it home and wire-wrapped a 7-segment LED onto it. Power…
> The original parallel port and even ISA interface seemed so simple by comparison, with less layers of abstraction. Just run a wire, and write to a port.
All those layers of abstraction is likely what allows us to hook up a single wire to our laptops and get multiple very fast ports from the docking station along with power and display output.
You get some, you lose some.
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#44The title was misleading because the author wrote a userspace Rust driver and not a Linux kernel driver in C.
Upon reading the title I thought this was going to be about how easy it is to write or modify a Linux driver when using a LLM even if you know nothing about the subject.
No LLM needed. Kernel driver code for simple things is usually copy-paste-modify. Find something that works with an HID interrupt based device, and modify that. If you want a /sys led, copy from that. It's only if you try to push to mainline you need to worry about understanding it, but they'd probably smell LLM trash from miles away.
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#45There are many innovative OSes that are killed by the lack of Device Drivers. As a community we must find a way for tackling this issue. Micro-Kernels are a solution where one can run different OSes but they will reuse the same device driver servers. But it requires co-ordination and determination. Rust can be a solution for sure.
Any programming language can be a solution, the programming language itself isn't the problem. Convincing device driver programmers around the world to come up with a universal API that includes all the possible features and works on every OS is. In this case, the cross-platform libusb should make this code work on either Linux or Windows (if you install the signed Windows drivers). If other operating systems port li…
On a previous project I spent a lot of time trying to figure out a 'generic device driver'. That is actually a decently hard space to crack. As each device has randomly different ways of talking. Some are serial/local bus. Some are memory space. Some have a combination. Some systems broadcast data, some you have to query it, some you have to query then wait for the next broadcast. Some systems mildly follow the spec, some strictly follow it, some strictly follow their own flavor of the spec or an outdated one, some have their totally made up spec that they may or may not give you. Even from the same company you can have two models that on the outside if you use their stuff looks the same but under the hood is sorta different enough that your driver is garbage. I basically ended up here https://xkcd.com/927/
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#46Given the title, I'm surprised (in a good way) that it's not about AI coding.
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#47There are many innovative OSes that are killed by the lack of Device Drivers. As a community we must find a way for tackling this issue. Micro-Kernels are a solution where one can run different OSes but they will reuse the same device driver servers. But it requires co-ordination and determination. Rust can be a solution for sure.
Neither microkernels nor rust will help if you can't get everybody to agree on an ABI, which is the hard part in the first place.
That said, if you're willing to deal with other people's APIs, NetBSD's rump kernels are good for providing reusable drivers, and some projects have even had luck pulling drivers out of Linux to reuse, though obviously that's a little bit touchier.
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#48I enjoyed this post, but I'm eager to hear what the next step would be for a real "production" userspace driver. Are these typically just daemons that are configured to run at start up? And then some configuration GUI communicates with it over a socket or something?
You could certainly do that, and it would make a ton of sense if there's both no standard software API for communicating with that type of device, and it's important that multiple pieces of software that communicate with the device are able to run at the same time (or you want to avoid repeating work when starting software multiple times). ADB (Android Debug Bridge) takes this approach.
If there is an applicable standard software API (either multiplatform like a filesystem, or a special one exposed by the OS kernel [1] ), the driver probably belongs in the Linux kernel (or in the form of a Windows driver on that platform). My understanding is that GPU APIs are an exception on Linux, and are implemented in userspace by a piece of software called MESA. You could also use the daemon approach in this case if you don't want to bother with getting a driver added to the kernel.
For a more niche device where exclusive access is acceptable and every piece of software would need to add special support for this specific type of device anyway, it's a lot simpler to distribute the driver as a library that software authors can include in their program. If there are several devices that work similarly but communicate differently, you could have one library that either includes multiple drivers, or exposes a common interface that other libraries can implement.
A downside of any approach for USB devices on Linux that isn't a kernel driver is that one or more udev rules will need to be added (as the article described). This also applies when using a device that uses a supported USB protocol, but has different IDs than the ones listed in the kernel driver.
[1] More devices fall into this category than you might expect. For example, Linux has an API for communicating with CAN devices called SocketCAN, so if you're writing a driver for a CAN device that connects via USB and exposes the full CAN bus over USB (maybe something that goes in or connects to a car), you should write a kernel driver that converts data between SocketCAN and whatever USB protocol is being used (assuming one doesn't already exist, a lot of USB CAN devices use protocols that already have drivers in the kernel). SocketCAN only exposes the raw data extracted from the CAN frames, so if you want to expose an easy way to control a particular CAN device, that belongs in a userspace library that uses the SocketCAN API under the hood.
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#49This is awesome! But it also makes me a little bit sad. The original parallel port and even ISA interface seemed so simple by comparison, with less layers of abstraction. Just run a wire, and write to a port. I remember when I was a kid, I found a breakout board in an electronics store's random clearance parts bin, with an ISA header on an edge. On a whim I took it home and wire-wrapped a 7-segment LED onto it. Power…
I sometimes think about this, starting from scratch with a computer hardware and software stack that disallowed all of the layers of abstraction that have built up over the decades. Yeah many of the abstractions help with performance but maybe there's value giving up much of that performance in exchange for simplicity.
For toy tinkering, to replicate something like the old ability to just write a byte to an IO memory location and have it appear on the pins of a parallel port, you could design a simple USB peripheral that did similar. Give it a set of DIP switches to pick a number (4 for 0-f, more would probably be overkill but feel free) and have the driver present something like /proc/simpleio/device/in and /proc/simpleio/device/out/pin for reading & writing¹. If you use the same set of pins for in and out, /proc/simpleio/device/config to state which direction each is expected to work, and perhaps set voltage options (probably per device, per pin sounds overkill for this). Release the full design and let people make their own, sell pre-made boards and cases and/or let others do that (or just the boards and have people 3D-print their own cases). Devices could have as many pins as the maker likes.
That would only cover the real basics: reading/writing the hi/low status of pins. Other things people might want is analogue voltage control/read (for many sensors) or pulse control (for controlling servos and such). Things like that could be mapped into the /proc/simpleio/device/{in|out}/pin files. Perhaps for setting/reading multiple pins at a time perhaps have something like /proc/simpleio/device/{in|out}/allpins. You could expand the feature in many ways, though TBH beyond the simple hi/low thing people are probably better off getting an rPi or microcontroller and using all the available devices and plans there are out there already for their IO pins and using something newer.
--------
[1] Not sure what you'd do for Windows, I'd be inclined to release a Linux driver and let the Windows community worry about one for their platform.
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#50This is awesome! But it also makes me a little bit sad. The original parallel port and even ISA interface seemed so simple by comparison, with less layers of abstraction. Just run a wire, and write to a port. I remember when I was a kid, I found a breakout board in an electronics store's random clearance parts bin, with an ISA header on an edge. On a whim I took it home and wire-wrapped a 7-segment LED onto it. Power…
USB is designed to solve a complex, but necessary problem.
1. Hot-plug.
2. High speeds with long cables of dubious quality.
3. Multiplexing multiple devices on a single wire with hubs.
4. Reliable transmission on lower layer, so higher level protocols don't need to worry about it.
5. Multiple speeds with negotiation.
6. Newer USB standards support multiple power voltages with negotiation.
All that said, old USB protocols like USB 1.1 is not that hard. You don't need those hundreds of pages, only a subset of them. There are some tutorials in the Internets which will help you to understand everything, from wire signalling to application interface. Don't use USB reference as a learning source. These days ChatGPT probably will guide you over every layer. Just stick with old standards, they are simpler and plenty of devices use them.
With enough persistence and some fast enough MCU you should be able to bit-bang USB 1.1 LS (1.5 Mbps) and write some simple USB device. That will require to implement all layers of USB and I'm pretty sure it's not impossible task.