Sat, Nov 18
In general, we are getting better and better. Please keep up with that, it is much appreciated!
@remko Thank you for your suggestions.
This is a new diff, which is now based on the last revision of the chapter (50922). This even includes some final modifications I had made before uploading the diff in the bug report, where I had already fixed some typos/errors/bad phrases.
I followed all your advices, except two:
Fri, Nov 17
More updates :) please look into them and poke me whenever I can assist you :)
Mon, Nov 13
When running head at r325049, my home firewall would often hit an LOR in iflib_timer() when it jumped to the hung label. This happened twice a day.
Tue, Oct 31
I think you'll get a lot less pushback if you serialize the multicast stuff in the stack, rather than the driver framework. This will allow you to put warnings / asserts into all the ioctl entry points above the drivers, so as to lock in the "you can't hold a lock while calling into a driver" rule.
OK, let me take a look at creating some in-kernel interface for this.
I think an interface like mjg described is the best approach.
I don't know if I understand. jexec uses exactly the same syscall, jail_attach to achieve the same effect. Putting ifconfig and route inside a jail allows even more actions to be taken by the in-jail admin.
Also, there is no obvious other way to achieve this with current interfaces.
I see two other options: additional interface to manage jails and vnet without attaching process to the jail, or finding a way to avoid duplicated interface names but adding some sort of unique id(?).
jail_attach() is not the correct approach, because it makes the actions of the administrator on the host visible within the jail.
../dev/usb/usb_util.c:usb_pause_mtx(struct mtx *mtx, int timo)
Sun, Oct 29
Guys, since there was a discussion over how the patch does what it does, can I get one more approval before I commit this, Just In Case™?
Sat, Oct 28
Address comments and sync with r325058.
Fri, Oct 27
I'm good with it - I was just waiting for suggested changed to make it in.
Any update on that? Should it be accepted or rejected?
Mon, Oct 23
So let me try to sum up in my own words what's going on here:
Sep 29 2017
Sep 26 2017
Expand a comment explaining code.
Sep 22 2017
PS: Read how to create patches with context for the phabricator. May be it is a problem of phabricator and it modified the diff after you, if I download the raw diff here, there is no even normal diff -p context, which is almost always useful.
While I understand your valid motivation, I can't say that I very much like this in patch for several reasons:
- NGM_ETHER_SET_ENADDR is a control command supposed to be targeted to ng_ether node, not from it, and it is a action request, not notification. I suppose if you connect two ng_ether nodes with lower hooks to create poor mans bridge, this won't work as expected.
- ng_pppoe has method to explicitly set MAC address, and it may get overwritten by this, which may or may not be correct.
- We just fought one locking issue, and here I don't see any hook locks or even references (I understand that your problem is narrower, but still).
Sep 5 2017
Remove extra directory adds
Not sure where those head/* directories came from...
Sep 4 2017
Update my tree before updating revision
incorporate some missing changes from dev branch
Commit was reverted
Aug 30 2017
Aug 29 2017
Aug 26 2017
move more blocking work to deferred context
Aug 25 2017
Yeah, legacy em(4) device on em2:
Huh .... Testing this review by itself this morning. I see the following startup panic:
Aug 24 2017
- Eliminate remaining mutex use in os independent e1000 code.
- Fold in iflib updates.
@jtl any comments?