The prev-pointers point to the next-pointers of the previous element --
not the ENTRY structure. The next-pointers are stored in the ENTRY
structures first, so the code would already work correctly. Still, it is
more accurate to use the next-fields.
To prevent misuse of __member2struct() in the future, I've got a patch
that requires the pointer to be passed to this macro to be compatible
with the member of the structure. I'll commit this patch after I've
tested it properly.
MFC after: 1 month.
Idle threads are not allowed to acquire any lock but spinlocks.
Deny any attempt to do so by panicing at the locking operation
when INVARIANTS is on. Then, remove the check on blocking on a
turnstile.
The check in sleepqueues is left because they are not allowed to use
tsleep() either which could happen still.
Reviewed by: bde, jhb, kib
MFC after: 1 week
with TDP_NOSLEEPING on.
The current message has no informations on the thread and wchan
involed, which may be useful in case where dumps have mangled dwarf
informations.
Reported by: kib
Reviewed by: bde, jhb, kib
MFC after: 1 week
Regular LISTs have been implemented in such a way that the prev-pointer
does not point to the previous element, but to the next-pointer stored
in the previous element. This is done to simplify LIST_REMOVE(). This
macro can be implemented without knowing the address of the list head.
Unfortunately this makes it harder to implement LIST_PREV(), which is
why this macro was never here. Still, it is possible to implement this
macro. If the prev-pointer points to the list head, we return NULL.
Otherwise we simply subtract the offset of the prev-pointer within the
structure.
It's not as efficient as traversing forward of course, but in practice
it shouldn't be that bad. In almost all use cases, people will want to
compare the value returned by LIST_PREV() against NULL, so an optimizing
compiler will not emit code that does more branching than TAILQs.
While there, make the code a bit more readable by introducing
__member2struct(). This makes STAILQ_LAST() far more readable.
MFC after: 1 month
The ENOTDIR mapping was introduced in r235266 for kern/128933 based on
an interpretation of the somewhat ambiguous language in the POSIX realpath
specification. The interpretation is inconsistent with Solaris and Linux,
a regression from 9.0, and does not appear to be permitted by the
description of ENOTDIR:
20 ENOTDIR Not a directory. A component of the specified pathname
existed, but it was not a directory, when a directory was
expected.
PR: standards/171577
MFC after: 3 days
is something for make(1) to consume. Bmake gives output such as:
"warning: Couldn't read shell's output for "/bin/sh -c true"
Note we parted from traditional Pmake behavior in r18864 / r18255.
with no output. Add "echo" at the end these shell commands whose output is
assigned to a variable's value to ensure there is some output.
Submitted by: John Van Horne <jvanhorne@juniper.net>
When truss is detaching from very active process it is possible to
hang on waitpid(2) in restore_proc() forever, because
ptrace(PT_SYSCALL) must be called before detaching, to allow the
debugging process to continue execution. Also when truss called with
'-c' argument, it does not print anything after detach, because it
immediately exits from restore_proc().
To fix these two problems make detaching deferred, but then it is
impossible to detach from a process which does not do any system call.
To fix this issue use sigaction(2) instead of signal(3) to disable
SA_RESTART flag for waitpid(2) that makes it non-restartable. Remove
global variable child_pid, because now detaching is handled in context
where child's pid is known.
Reported by: mjg
Tested by: mjg, swills
Approved by: kib (mentor)
MFC after: 2 weeks
versions. Instead use Imp's good work on "legacy" and follow the outcome
of the previous TRB discussions on this topic.
Now use the libc getline() if it exists, and only where it doesn't
create a bootstraping version.
of the DWC OTG is very simple in PIO mode, and we need to re-transmit
data when NAK is received among other things. We probably will need
to implement some kind of rate limitation on the NAK-ing.
bytes syncronized.
The rationale behind this is the following: for large disks the
percent synchronisation counter ticks too seldom, and monitoring
software (as well as human operator) can't tell whether
synchronisation goes on or one of disks got stuck. On an idle
server one can look into gstat and see whether synchronisation goes
on or not, but on a busy server that won't work. Also, new value
monitored can be differentiated obtaining the synchronisation speed
quite precisely.
Submitted by: Konstantin Kukushkin <dark ramtel.ru>
Reviewed by: pjd
