tsoome: Hi, is it possible to preset default ACPI boot option in loader.conf, for example, to Legacy?

yes. I do suggest to use /boot/conf.d snippets for this purpose like file acpi with content: acpi-user-options=value

value is default,on,off,madt,legacy

Hello, I'm considering working on adding support for the RTL8125 driver. I'm not very experienced in OS developement and this would be my first meaningful contribution to a real OS, so I'm still assessing the viability and breadth of it, considering my abilities. So far my initial doubts are regarding licensing and such.

Can I read and source information from the linux/BSD drivers and then apply it to my code?

Also, I've found a datasheet for the chipset, it's widely available in the internet, but all copies say "not for public release" and "confidential" so eviden

*evidently it's not something Realtek intended to be public. Can I use it?

Also any suggestions regarding the (in)viability of it are also welcome. It may still be out of my league

I'm far from the most experienced with writing low-level code, but I would say that by far the most desirable attribute is tenacity rather than ability

it will be lots of reading and re-reading the datasheet, scratching your head wondering _why_ what you think should be working is not working

and trying to figure out creative ways to get information out of the hardware to figure out what state it is in, as you can't just add some debug printfs

pilonsi: both the datasheet and the other drivers can be useful as sources of information about the likely behavior of the device.

I wouldn't worry too much about the "confidential" marking; avoid copying literal text out of the datasheet (other than unavoidable things like codepoints/register definitions).

Make sure you have an adequate test setup (ideally separate test and build machines; maybe multiple boards using the target chip to ensure the driver can cope with variants and multiple instances properly)

Thank you both for the tips!

sommerfeld: That is nice to know, I was not sure if referencing other code with different licensing, or leaked datasheets like that could have conflicts later with the cddl license

My current plan is to first go through the writing device drivers for illumos book and then get a grasp con the current rge driver

Maybe adding 1gbe support for the rtl8125 as mentioned in the bugtacker, if it's not too convoluted: illumos.org/issues/13729

→ BUG 13729: Driver issue with Realtek RTL8125 (New)

And then get into the actual chipset itself and drivers for other oses for it

I had not thought about having different boards, but definitely will buy different ones once I'm there

So far I have the tp-link tx201 card

For building I'm using an openindiana VM, but will assemble a dedicated x86 host to test it

Can I ask why is it recommended to have 2 machines? In case the driver causes instability, or are there more advantages?

I also have a sun ultra 45 to test in sparc later on

pilonsi: so you can start fixing the bug that caused the last panic before the machine is done rebooting.

pilonsi: plus there is at least the theoretical risk that any kernel bug could cause unrecoverable filesystem damage and permanent data loss. Unlikely with a network driver but it's all one big highly privileged address space.

doing builds in a VM hosted on another machine would be enough separation..

Yeah it would be extremely sad to lose all your work because of a bug in the thing you're working on haha

Probably more immediately critical when working on ZFS, but still

I have written an HBA driver before (you're lucky, I never shared it). The trick is to not have your actual code on the same system until there's at least one more copy.

there's no part of your life DMA can't ruin

yeah

On the plus side, you probably don't need a very expensive computer as a test bed for a 2.5G ethernet card!

ebay has all kinds of off-lease Dell or Lenovo PCs from ~5 years ago that run to like USD $100 and have a PCIe slot or whatever

In many cases having more shitty computers rather than one shiny computer is valuable etc

jclulow: way back when (mid-1980's) I was in the building at MIT Project Athena when a fellow student system programmer created a bug that then destroyed all copies of itself, both source and object, rendering it impossible to root-cause. Also took out a big chunk of the filesystem on our master source machine with it. Don't test stuff as root on the machine with the only copy of the source, folks...

oof

a patch to login which let it create a local temporary home directory when the user's remote homedir wasn't available. it printed something to the effect of "Your home directory is temporary. It will be deleted when you log out" and "home directory not found, setting HOME=/"

the author logged in to test it, then logged out, then realized that something was wrong

I believe there was a frantic dash down the stairs to the machine room to halt the system followed by hours of painstaking reconstruction.

pilonsi - another great bit of advice I got from rmustacc is to put your driver binary in /tmp and just symlink to it from the real directory. Then if it crashes the host due to a bug it doesn't exist after the reboot. Saves having to mess around selecting old boot environments or whatever.