51–60 of 65 posts
Really enjoyed that you just run and fun from the browser. Doom wasn't loading for me (Brave browser on Ubuntu without javascript disablers). Very good work. It was fun without doubt.
Earlier quoted context omitted.
I think biggest challenges have to be with reading large specifications. I've never really done that before so it took some time to get used to.
Could you link a random specification you were working against? I'm curious how there are written
NVMe base specification https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-S...
xHCI (USB controller) https://www.intel.com/content/dam/www/public/us/en/documents...
Awesome. I was not expecting something with that feature set. Do you plan on porting more software?
I have some ports locally that are not yet working. I have git, binutils, gcc, make all compiling but they are giving some weird errors. Probably a bug in my libc or syscalls.
This a very cool side project, congratulations! Any tips for anyone that also would like to attempt something similar ? Like where to start or or sources etc
How does one even begin to write drivers for nvme, ata, rtl nics, etc? I know mice and keyboards use HID which is a standard, but are there similar standard protocols for all other devices? Is this how linux manages to avoid needing to "install drivers" in the vast majority of cases? And if there are standard device APIs, why does windows have to go through that whole install driver routine every time I plug somethin…
Yeah basically every commonly used device has its protocol standardized. Although there exist some devices where the manufacturer has to provide the drivers. All of the devices I have written drivers have had their specifications publicly available for free (e.g. NVMe at https://nvmexpress.org/specifications ). I'm not really familiar with how Linux nor Windows handle drivers. While compiling the Linux kernel you spe…
Microsoft, having the resources it does, was able to design and implement a stable driver ABI. In fact, they also have a stable userspace ABI. Both have evolved, but that's not the point.
Linux conversely (whether by design or by limitation) does not have stable ABIs (although userspace compatibility isn't terrible). Even though you can build kernel drivers as modules (and then load/unload), those modules are unique to each specific kernel build.
Remember those guys didn't write the compiler & linker toolchains they were using like Microsoft was able to do.
I will be honest, I understand why Linus & Co. have decided to keep it this way, because it encourages hardware manufacturers to submit either their drivers or their specifications to the upstream kernel, which promotes software freedom. It is a noble goal and has served them well.
BUT - thieir decision has caused me no small amount of consternation over the years as a system administrator. Once you use Linux for something that is not "server software" (be it auth, file sharing, web, etc.), you are generally using it to drive some piece of hardware (CNCs, industrial tools, cough phone systems cough). Vendors, especially those that deal in low-volume / high-margin products, do not want to release their source code. They're allergic to the idea even. So I have gotten stuck in outdated kernel hell on several occasions because the kernel devs have decided to change internal interfaces in a point-point release that my driver software relied upon.
I so wish that Linux would move to a stable driver ABI. It would make administration & upgrades so much easier, especially on the embedded side.
But I also know that it'll never happen.
FWIW, the "no stable kernel ABI" is unique to Linux, although no one really does this like Microsoft (i.e. the BSDs can break between releases, but I do believe NetBSD is superior to FreeBSD in this respect).
It looks like ".." entries don't exist beneath /proc.
Rename the project UHHNIX or OOHNIX. Great work!
Are you trying to start a flame war?? :-D
What do you think it will take to target RISC-V?
A minor bug-report, if you run "cd /proc/3" you cannot "cd .." afterwards. It looks like ".." entries don't exist beneath /proc.