User Details
- User Since
- Jun 3 2014, 6:27 PM (358 w, 1 d)
Yesterday
Tue, Apr 13
Sun, Apr 11
Sat, Apr 10
Looks good to me.
Fri, Apr 9
My first thought about the high network priority was about serial ports without any hardware buffering and flow control, extremely sensitive to interrupt latency, but uart seems to use TTY priority, at least now. Not sure what else could be so time-critical in networking before, but sure there could be NICs with very few RX buffers. Typical disk hardware though should have much higher latency tolerance, since the amount of traffic is usually predetermined being initiated from the system, that is why I guess its priority was set lower.
Thu, Apr 8
Wed, Apr 7
Tue, Apr 6
Mon, Apr 5
I see in NETWORKING: "# PROVIDE: NETWORKING NETWORK", so it does not look broken to me, but it looks weird.
Wed, Mar 24
Mon, Mar 22
Wed, Mar 17
Mar 15 2021
Mar 11 2021
As me and John just told, the wakeup will not be missed in any case, it can only be duplicated due to the race, since list inserting is done before that under the lock.
I am not getting what is the point of bringing the wakeup() under the lock. Being out of the lock may cause extra wakeups, but they are not critical here.
Mar 10 2021
Mar 9 2021
Mar 8 2021
Still LGTM.
For root on ZFS kernel automatically calls vfs_mountroot_wait() before doing anything. I think it is the only safe way. Attempt to import pool before all disks are detected may end up in importing pool at older transaction group or using old, removed now from pool devices. So I would insert root_hold_wait call at the beginning of zpool_start().
Mar 7 2021
Mar 6 2021
Mar 5 2021
Mar 4 2021
Should probably be merged with D29005.
Mar 3 2021
I like the general direction. I also was thinking about something like this to avoid callout operations on every I/O.
I have no specific objections, but I suppose those were added for something.
Other than the commend above I think it may work.