On Wed, Jul 28, 2021 at 5:58 PM Chris Johns wrote:
>
> On 29/7/21 9:42 am, Gedare Bloom wrote:
> > On Wed, Jul 28, 2021 at 5:05 PM Chris Johns wrote:
> >> On 29/7/21 12:03 am, Gedare Bloom wrote:
> >>> On Tue, Jul 27, 2021 at 2:59 AM wrote:
> From: Chris Johns
> +static int
> +lo
On 28/07/2021 09:58, Chris Johns wrote:
+static void
+assert_lockmgr(const struct lock_object *lock, int what)
+{
+ panic("lockmgr locks do not support assertions");
+}
This is neither the RTEMS style nor the FreeBSD style. At some point in time it
would be really nice to have a clang-format fo
On 29/7/21 9:42 am, Gedare Bloom wrote:
> On Wed, Jul 28, 2021 at 5:05 PM Chris Johns wrote:
>> On 29/7/21 12:03 am, Gedare Bloom wrote:
>>> On Tue, Jul 27, 2021 at 2:59 AM wrote:
From: Chris Johns
+static int
+lockmgr_upgrade(struct lock *lk, u_int flags, struct lock_object *ilk,
On Wed, Jul 28, 2021 at 5:05 PM Chris Johns wrote:
>
> On 29/7/21 12:03 am, Gedare Bloom wrote:
> > On Tue, Jul 27, 2021 at 2:59 AM wrote:
> >> From: Chris Johns
> >>
> >> struct lock_object {
> >> -#ifndef __rtems__
> >> const char *lo_name; /* Individual lock name. */
> >>
On 29/7/21 12:03 am, Gedare Bloom wrote:
> On Tue, Jul 27, 2021 at 2:59 AM wrote:
>> From: Chris Johns
>>
>> struct lock_object {
>> -#ifndef __rtems__
>> const char *lo_name; /* Individual lock name. */
>> u_int lo_flags;
>> u_int lo_data;/
On Wed, Jul 28, 2021 at 8:03 AM Gedare Bloom wrote:
>
> On Tue, Jul 27, 2021 at 2:59 AM wrote:
> >
> > From: Chris Johns
> >
> > - See `man lockmgr`
> >
> > - Implement the lock_object and move the RTEMS mutex to that object
> >
> > - Add debug support to track the locks with gdb
> >
> > Update
On Tue, Jul 27, 2021 at 2:59 AM wrote:
>
> From: Chris Johns
>
> - See `man lockmgr`
>
> - Implement the lock_object and move the RTEMS mutex to that object
>
> - Add debug support to track the locks with gdb
>
> Update #4475
> ---
> freebsd/sys/sys/_lock.h | 10 +-
> free
On 28/07/2021 09:58, Chris Johns wrote:
Why do we need the lo_name?
I suspect this could be conditional. It is useful when debugging the locks so
being able to get the name in the trace is a good thing.
The thread queues have already a name.
Does this mean referencing the internals of the RTE
On 28/07/2021 09:58, Chris Johns wrote:
For what do we need lo_data?
This field is used in various places for different type of locks so it needs to
stay.
It seems this is only used to indicate if a lock recursed:
sys/sys/_lock.h:u_int lo_data;/* General class
spec
On 28/7/21 4:23 pm, Sebastian Huber wrote:
> On 27/07/2021 10:58, chr...@rtems.org wrote:
>> From: Chris Johns
>>
>> - See `man lockmgr`
>>
>> - Implement the lock_object and move the RTEMS mutex to that object
>>
>> - Add debug support to track the locks with gdb
>>
>> Update #4475
>> ---
>> fr
On 27/07/2021 10:58, chr...@rtems.org wrote:
From: Chris Johns
- See `man lockmgr`
- Implement the lock_object and move the RTEMS mutex to that object
- Add debug support to track the locks with gdb
Update #4475
---
freebsd/sys/sys/_lock.h | 10 +-
freebsd/sys/sys
11 matches
Mail list logo
