Live data from Hacker News

Writing a basic Linux device driver when you know nothing about Linux drivers

crescentro.se

31–40 of 72 posts

Re: Writing a basic Linux device driver when you know nothing about Linux drivers

#31

> I also thought I’d message the vendor and ask them if they could share any specifications or docs regarding their protocol. To my surprise, Nanoleaf tech support responded to me within 4 hours, with a full description of the protocol that’s used both by the Desk Dock as well as their RGB strips. How cool is that? Too many vendors still think that they have valuable intellectual property in such relative trivialitie…

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…

Was it Alpha-ESS? they make it so stupidly hard to get your information outside of their smartphone app.

Re: Writing a basic Linux device driver when you know nothing about Linux drivers

#32
post #13

I wish this was done in C so I didn't have to learn Rust. But maybe it is time to learn Rust.

This is using rusb, a Rust wrapper around libusb. libusb is still written in plain old C: https://libusb.info/

If you don't want to learn a different programming language, you can take the exact same approach in any language you prefer and play along. You may need to turn the more object oriented calls into libusb_* calls, but if you're used to programming in C you probably won't have a problem getting that to work.

Re: Writing a basic Linux device driver when you know nothing about Linux drivers

#33

There 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 libusb, they get this code for free.

Most "real" drivers still run in kernel mode, though, and not even Linux can keep their ABI stable (Windows has to, between releases, with the aid of compatibility wrappers that only work for a certain amount of releases).

It would probably be worth it more forbBespoke operating systems to implement either the Windows API (like ReactOS does) or the Linux API (pick an LTS version) to get existing drivers to work. Unless you pay them, most driver programmers aren't going to bother with anything than Windows, maybe Linux, possibly macOS.

Re: Writing a basic Linux device driver when you know nothing about Linux drivers

#34
post #24

The 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.

Re: Writing a basic Linux device driver when you know nothing about Linux drivers

#35
post #12

The author should probably have implemented support in OpenRGB instead to better benefit others, but this is cool nonetheless.

I think they wrote the code more for the challenge of it than anything else. The final code doesn't seem to do more than the bare basics (which is probably enough for the author).

Plus, to port this to OpenRGB, you'd need to rewrite the code into C++ (ugly, old C-inspired C++, at that: https://github.com/CalcProgrammer1/OpenRGB/blob/master/CONTR...) which would take most of the joy out of it for me at least.

Re: Writing a basic Linux device driver when you know nothing about Linux drivers

#37

Earlier quoted context omitted.

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.

It would be neat to design a whole new contemporary stack from scratch.

It would also be an enormous undertaking, requiring man-centuries of work and has the risk of falling into the 'second systems effect' trap...

Re: Writing a basic Linux device driver when you know nothing about Linux drivers

#38

> I also thought I’d message the vendor and ask them if they could share any specifications or docs regarding their protocol. To my surprise, Nanoleaf tech support responded to me within 4 hours, with a full description of the protocol that’s used both by the Desk Dock as well as their RGB strips. How cool is that? Too many vendors still think that they have valuable intellectual property in such relative trivialitie…

I wish more vendors would put "Linux support" on the package. Or maybe "Unofficially supported in Linux" or "Linux community support" if they don't want to get their fingers burned.

Maybe this kind of thing should be enforced in the GPL (as many devices use Linux under the hood).

Re: Writing a basic Linux device driver when you know nothing about Linux drivers

#40
post #12

The author should probably have implemented support in OpenRGB instead to better benefit others, but this is cool nonetheless.

I think they wrote the code more for the challenge of it than anything else. The final code doesn't seem to do more than the bare basics (which is probably enough for the author). Plus, to port this to OpenRGB, you'd need to rewrite the code into C++ (ugly, old C-inspired C++, at that: https://github.com/CalcProgrammer1/OpenRGB/blob/master/CONTR... ) which would take most of the joy out of it for me at least.

I don't think the style described in that doc is at all ugly. It's practical and simple. I say this as someone who spends a lot of time writing modern c++ and heavily using templates.

I thoroughly enjoy rust, but I doubt not being able to use it should be grounds for avoiding contributing to a project. Unless you are going to write async heavy code, libusb is pretty easy to use in C.

Post reply on HN