Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 19281 Build 18893: arc lint + arc unit
Event Timeline
| share/man/man9/dev_refthread.9 | ||
|---|---|---|
| 62 | Perhaps use a term 'thread reference'. There are two references on cdev, one you are explaining there, which guarantees liveness of cdev. Another is the reference on the cdev memory and it only provides that cdev memory is not freed and some devfs internal structures are valid for it. Might be point out that the other refs exist. | |
| 66 | I find it strange (and limiting) to call cdevsw a 'method table'. Informally it is called cdevsw. might be device switch. | |
| 68 | s/full//, s/blocked/postponed/ | |
| 71 | This is not devfs duty to care about the driver implementation, devfs is not really about devices. I would reformulate this sentence in the spirit of my previous sentence in the reply. | |
| 97 | Perhaps note that the caller must guarantee the struct vnode liveness e.g. by holding it, but devvn_refthread(9) handles vnode liveness, i.e. possible parallel revocation. | |
| share/man/man9/dev_refthread.9 | ||
|---|---|---|
| 62 | Will fix. | |
| 66 | For consumers it is pretty much exclusively a method table — a lot like a C++ vtable. It is an object-oriented pattern. I am not strongly attached to the term, but I think device switch is less clear. | |
| 68 | In the context of locking and multiprocessing, blocked means postponed. Will remove full. | |
| 71 | Ok, will rework. | |
| 97 | How does devvn_refthread handle vnode liveness? I don't understand. | |
| 98 | I can remove them. | |
| share/man/man9/dev_refthread.9 | ||
|---|---|---|
| 68 | In FreeBSD, blocked means 'removed from CPU and put on turnstile', basically de-scheduled on non-sleepable lock. | |
| 79 | KPI | |
| 97 | struct vnode memory must be stable during the call, this is the duty of the caller. Reclamation or cdev destruction are handled by devvn_refthread(9). | |
| share/man/man9/dev_refthread.9 | ||
|---|---|---|
| 97 | Still not sure I understand this well enough to document. Is the protection that somehow dev_lock protects the lifetime of vnode's v_rdev? | |
| share/man/man9/dev_refthread.9 | ||
|---|---|---|
| 98 | May be, just say that the function correctly handles possible parallel reclamation of the vnode. | |
Per kib, mention that devvn version of refthread correctly handles parallel
vnode reclamation.