Ed, is there any particular reason you didn't go ahead with this?

In D50128#1152638, @kgalazka wrote:

I would assume if you hold the fw semaphore you'd have exclusive access to the adapter..

I don't know how I missed that while reading the datasheets, but there are two registers used for SW/FW synchronization. IXGBE_SWSM is used to ensure that only one SW thread is accessing HW. I'm sorry for misleading you.

We /may/ need to move the child bus attach stuff to a new iflib routine that's documented to being called without the ctx lock held?

Because @kbowling is right about the semaphore I think we don't need to use a iflib CTX lock for MDIO read operation. For writes I think CTX lock is still required. Some operations on PHY use read/modify/write pattern (e.g. ixgbe_init_ext_t_x550em). Without CTX lock write from MDIO bus may get between that read and write.

Regarding E610 - it does have IXGBE_MSCA register, but it's strongly advised to use ACI commands for PHY access instead. It may be better idea to not add independent interface but set phy->ops.read_reg_mdi and phy->ops.write_reg_mdi for X553 backplane and rely on phy.ops.read_reg and phy.ops.write_reg to do the right thing for given HW.

Fix typo in commet

add an rc.d script

improve manpage formatting

Add copyrights.

Thanks. The latest upload fixes those tests for me, all 8 pass.

Fix fork and exec.
Add sysconf() to get max exterr buffer
Provide real exterr format procedure
Fixed flags handling in syscall

LGTM

ping @ngie

In D49993#1152831, @ivy wrote:

i don't want to make significant changes to the existing reviews if possible, so i'll add this as a new review in the stack and tag you as reviewer.

i don't want to make significant changes to the existing reviews if possible, so i'll add this as a new review in the stack and tag you as reviewer.

Thank you for your quick response and working on this awesome feature.

In D49993#1152822, @p.mousavizadeh_protonmail.com wrote:

With your changes, without VLAN filtering, can I assume that all interfaces in a bridge are treated as trunk ports?

I didn't see this review, and I think what I asked in D49993 belongs here.
So I would write my note here again:

With your changes, without VLAN filtering, can I assume that all interfaces in a bridge are treated as trunk ports?

Yes. Thanks. Sorry to be so notpicky...

Fix hand-off from libc to libthr.
Generate SIGSEGV on EFAULT from copyout of the exterr.
Remove getptr.
Report exterr address through kinfo_proc.

In D50483#1152642, @brooks wrote:

Over all this looks great.

I'm on the fence about extending struct pthread on vs adding avoid additional mallocs. It's certainly simplifying, but people might want it off in some cases (e.g., if the kernel doesn't include messages or the developer isn't using APIs they think would benefit from extra explanations.)

In D50267#1147410, @des wrote:

I'd still like someone from tests to weigh in, @ngie perhaps?