Re: Tickets: Milestone vs. Version

2018-08-09 Thread Sebastian Huber 

On 10/08/18 07:38, Chris Johns wrote:

On 10/08/2018 15:03, Sebastian Huber wrote:

we want a ticket for each milestone in which it is resolved. What is now the
meaning of the version field?


A ticket may be assigned to a branch but not a milestone. Milestones lets us
select which tickets we fix on branch. Once all tickets on a milestone are
closed the release can be made.

We do not work that way at the moment. I use the milestones when making releases
to move tickets scheduled for a release that are not closed to the next release.


This doesn't explain the version field. Is version the same as branch 
from your point of view?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Tickets: Milestone vs. Version

2018-08-09 Thread Chris Johns 
On 10/08/2018 15:03, Sebastian Huber wrote:
> 
> we want a ticket for each milestone in which it is resolved. What is now the
> meaning of the version field?
> 

A ticket may be assigned to a branch but not a milestone. Milestones lets us
select which tickets we fix on branch. Once all tickets on a milestone are
closed the release can be made.

We do not work that way at the moment. I use the milestones when making releases
to move tickets scheduled for a release that are not closed to the next release.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] score: Fix ISR enable in _Thread_Dispatch_enable()

2018-08-09 Thread Sebastian Huber 
This bug had probably no effect since the interrupt enable is idempotent
on all CPU ports.

Close #3496.
---
 cpukit/include/rtems/score/threaddispatch.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/cpukit/include/rtems/score/threaddispatch.h 
b/cpukit/include/rtems/score/threaddispatch.h
index 63eb4c6fb4..69696f4044 100644
--- a/cpukit/include/rtems/score/threaddispatch.h
+++ b/cpukit/include/rtems/score/threaddispatch.h
@@ -228,9 +228,8 @@ RTEMS_INLINE_ROUTINE void _Thread_Dispatch_enable( 
Per_CPU_Control *cpu_self )
 } else {
   cpu_self->thread_dispatch_disable_level = 0;
   _Profiling_Thread_dispatch_enable( cpu_self, 0 );
+  _ISR_Local_enable( level );
 }
-
-_ISR_Local_enable( level );
   } else {
 _Assert( disable_level > 0 );
 cpu_self->thread_dispatch_disable_level = disable_level - 1;
-- 
2.13.7

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Tickets: Milestone vs. Version

2018-08-09 Thread Sebastian Huber 

Hello,

we want a ticket for each milestone in which it is resolved. What is now 
the meaning of the version field?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rfs: Remove erroneous call of rtems_disk_release()

2018-08-09 Thread Sebastian Huber 

On 10/08/18 01:44, Chris Johns wrote:

On 07/08/2018 15:33, Chris Johns wrote:

I will ping Amar tomorrow. I do not touch the Trac install.


Amar has installed the clone tool (Thank you). There is now a Clone button on
the tickets besides the Reply and Delete buttons.


Thanks, this makes it easier. I back ported the patch to 4.11 and 4.10.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rfs: Remove erroneous call of rtems_disk_release()

2018-08-09 Thread Chris Johns 
On 07/08/2018 15:33, Chris Johns wrote:
> 
> I will ping Amar tomorrow. I do not touch the Trac install.
> 

Amar has installed the clone tool (Thank you). There is now a Clone button on
the tickets besides the Reply and Delete buttons.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

2018-08-09 Thread Joel Sherrill 
On Thu, Aug 9, 2018 at 1:13 PM, Amaan Cheval  wrote:

> Haha, my tc_frequency was set all wrong, causing the date to be wonky.
>
> The dispatching issue turned out to be a (potential) QEMU bug where
> "decq" wouldn't set the ZF in EFLAGS even if it resulted in a 0 value,
> causing the "jne" to always be taken.
>
> Anyway, here's where we're at now:
>
> Start @ 0x1027f9 ...
> EFI framebuffer information:
> addr, size 0x8000, 0x1d4c00
> dimensions 800 x 600
> stride 800
> masks  0x00ff, 0xff00, 0x00ff, 0xff00
> Filling 512 page tables
> 1gib pages not supported!
> maxphysaddr = 48
> sidt = ff f a8 39 34 0 0 0 0 0
> us_per_tick = 1
> Desired frequency = 100 irqs/sec
> APIC was at fee0
> APIC is now at fee0
> APIC ID at *fee00020=0
> APIC spurious vector register *fee000f0=10f
> APIC spurious vector register *fee000f0=1ff
> CPU frequency: 0x57c60
> APIC ticks/sec: 0x57c6qemu-system-x86_64: warning: I/O thread spun for
> 1000 iterations
>
>
> *** BEGIN OF TEST CLOCK TICK ***
> *** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
> *** TEST STATE: EXPECTED-PASS
> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
> *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
> 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
> TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
> TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
> TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:05   12/31/1988
> TA2  - rtems_clock_get_tod - 09:00:10   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:10   12/31/1988
> TA3  - rtems_clock_get_tod - 09:00:15   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:15   12/31/1988
> TA2  - rtems_clock_get_tod - 09:00:20   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:20   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:25   12/31/1988
> TA3  - rtems_clock_get_tod - 09:00:30   12/31/1988
> TA2  - rtems_clock_get_tod - 09:00:30   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:30   12/31/1988
>
> *** END OF TEST CLOCK TICK ***
>
>
+1

>
> *** FATAL ***
> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> fatal code: 0 (0x)
> RTEMS version: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
> RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB
> 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
> executing thread ID: 0x08a010002
> executing thread name: TA1
> qemu-system-x86_64: terminating on signal 2
>
> -
>
> 2 issues:
> - It isn't reliably this way - sometimes it may start at 9:00:01 (and
> then the rest are 6, 11, etc.). I'm using a very naive timecounter
> (number of IRQs occurred so far) right now - I'll have it account for
> the ticks since the last IRQ too, which I imagine may help with this?
>

Some of the simulators are odd this way. But I would expect this to
behave better. It is probably a calibration issue. There should be more
than enough time to do the prints and handle the tick ISRs. On some
simulators, it isn't that way.

The initialization should program it to get an interrupt based on the
configured microseconds per tick. You need the calibration or truth
speed to do this. I assume that calibration that would work on real
HW would work on qemu.


> - It is much slower than IRL time - I'm not sure if this is just due
> to QEMU or perhaps from ISRs piling over each other due to the handler
> taking too long. I'm not quite sure how to find out either.
>

This is expected. I recall it is ~2x IRL time for pc386 ticker.


>
> Let me know if you have any suggestions!
>
> Patches incoming soon too, so I'd appreciate reviews! :)
>

Nearly working is a great sign!


>
> On Thu, Aug 9, 2018 at 8:12 PM, Joel Sherrill  wrote:
> >
> >
> > On Thu, Aug 9, 2018 at 7:43 AM, Amaan Cheval 
> wrote:
> >>
> >> Addition to status: it doesn't seem like the RTEMS Interrupt's call to
> >> _Thread_Dispatch functions either - ticker.exe has outputs like the
> >> following (yeah, the counter is running too quickly right now):
> >>
> >> *** BEGIN OF TEST CLOCK TICK ***
> >> *** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb
> 93a425fc83-modified
> >> *** TEST STATE: EXPECTED-PASS
> >> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
> >> *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
> >> 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
> >> TA1  - rtems_clock_get_tod - 11:34:12   05/12/1990
> >> TA2  - rtems_clock_get_tod - 11:34:12   05/12/1990
> >> TA3  - rtems_clock_get_tod - 11:34:12   05/12/1990
> >
> >
> > Congratulations! But why is the date 5/12/1990? I think it is supposed
> > to be 12/31/1989. :)
> >>
> >>
> >> (And then the _Thread_Idle_body is never preempted due to the
> >> interrupt dispatching a new thread - not sure if it just thinks it's
> >> "too late" to even bother or if simply never even tries. I'll keep
> >> investigating.)
> >
> >
> > This means your "outer" assembly language _ISR_Handler does not
>

Re: Inlined code

2018-08-09 Thread Joel Sherrill 
On Thu, Aug 9, 2018, 11:50 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> - Am 6. Aug 2018 um 21:14 schrieb joel j...@rtems.org:
> [...]
> > We looked at a lot of generated assembly. Sometimes we would see
> > large methods being inlined multiple times. This would increase the
> overall
> > size of an RTEMS application. But size is not the only impact of
> inlining.
> > If an inlined method has one or more if's in it, then the branch paths
> > it includes are introduced EVERYWHERE it is inlined. When we
> > had _Thread_Dispatch_enable, I recall it was used > 100 times and
> > includes a branch in it. There was a build option to not inline this
> > routine to avoid needing to add over 100 test cases.
> [...]
>
> I had a look at the _Thread_Dispatch_enable() code and was a bit surprised
> that GCC generates a stack frame in this function.  This turned out as a
> bug in the function. Do you find it? I will fix it tomorrow.
>

Chris and I were just counting instructions and branch paths. But I do
recall seeing ret and restore. That's a hint it is really too big to inline.

Perhaps the check for yes/no to dispatch should be inlined and the rest in
a method. This is how it was historically.

  If (--dispatch disable level)
Call thread dispatch

But this only avoided the call on non-interrupt cases so not inlining at
all really wasn't a hit. I suspect the same now. Nearly all the time it
calls a subroutine anyway and 3K of code is added uselessly.

Look at it holistically. What is executed when it is a different is not
inlined?


> Before we start to turn inline functions into non-inline functions we
> should create a benchmark program (or more). We should look at the overall
> code size changes and the local code changes.
>

We were relying on checking size and our benchmarks before.

One metric was the size of the code we were analysing for coverage. That's
directly in the coverage reports.

Another metric when a lot of branch paths have been inlined is the number
of uncovered ranges. When you investigate and realize they are from an
inlineethod used in N places, it is clearly something to.look at.

>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: gcov questions

2018-08-09 Thread Joel Sherrill 
Thought this was interesting. At least this info is now in the RTEMS
archives.

-- Forwarded message -
From: Jim Wilson 
Date: Thu, Aug 9, 2018, 1:26 PM
Subject: Re: gcov questions
To: daro...@o2.pl , g...@gcc.gnu.org 


On 08/09/2018 02:38 AM, daro...@o2.pl wrote:
> Hello,   I wanted to ask what model for
> branch coverage does gcov use?

There is a comment at the start of gcc/profile.c that gives some details
on how it works.  It is computing execution counts for edges in the
control flow graph.  As for which edges get instrumented, basically, you
construct a control flow graph, create a minimal spanning tree to cover
the graph, and then you only need to instrument the edges not on the
spanning tree, plus the function entry point.  You can compute the rest
of the edge counts from that.  Then there are some tricks to improve
efficiency by putting frequently executed edges on the minimal spanning
tree, so that infrequently edges get instrumented.

Gcov was originally written in 1990, based on an idea that came from
Knuth's Art of Computer Programming.  Ball & Larus wrote a nice paper in
1994 that does a good job of covering the methods used, though they may
not have been aware of gcov at the time as it hadn't been accepted into
GCC yet.  This is "Optimally Profiling and Tracing Programs" TOPLAS July
1994.  I don't know if there are free copies of that available.  There
may be better references available now, as these techniques are pretty
widely known nowadays

Jim
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

2018-08-09 Thread Amaan Cheval 
Haha, my tc_frequency was set all wrong, causing the date to be wonky.

The dispatching issue turned out to be a (potential) QEMU bug where
"decq" wouldn't set the ZF in EFLAGS even if it resulted in a 0 value,
causing the "jne" to always be taken.

Anyway, here's where we're at now:

Start @ 0x1027f9 ...
EFI framebuffer information:
addr, size 0x8000, 0x1d4c00
dimensions 800 x 600
stride 800
masks  0x00ff, 0xff00, 0x00ff, 0xff00
Filling 512 page tables
1gib pages not supported!
maxphysaddr = 48
sidt = ff f a8 39 34 0 0 0 0 0
us_per_tick = 1
Desired frequency = 100 irqs/sec
APIC was at fee0
APIC is now at fee0
APIC ID at *fee00020=0
APIC spurious vector register *fee000f0=10f
APIC spurious vector register *fee000f0=1ff
CPU frequency: 0x57c60
APIC ticks/sec: 0x57c6qemu-system-x86_64: warning: I/O thread spun for
1000 iterations


*** BEGIN OF TEST CLOCK TICK ***
*** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
*** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:05   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:10   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:10   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:15   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:15   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:20   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:20   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:25   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:30   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:30   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:30   12/31/1988

*** END OF TEST CLOCK TICK ***


*** FATAL ***
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
fatal code: 0 (0x)
RTEMS version: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB
25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
executing thread ID: 0x08a010002
executing thread name: TA1
qemu-system-x86_64: terminating on signal 2

-

2 issues:
- It isn't reliably this way - sometimes it may start at 9:00:01 (and
then the rest are 6, 11, etc.). I'm using a very naive timecounter
(number of IRQs occurred so far) right now - I'll have it account for
the ticks since the last IRQ too, which I imagine may help with this?
- It is much slower than IRL time - I'm not sure if this is just due
to QEMU or perhaps from ISRs piling over each other due to the handler
taking too long. I'm not quite sure how to find out either.

Let me know if you have any suggestions!

Patches incoming soon too, so I'd appreciate reviews! :)

On Thu, Aug 9, 2018 at 8:12 PM, Joel Sherrill  wrote:
>
>
> On Thu, Aug 9, 2018 at 7:43 AM, Amaan Cheval  wrote:
>>
>> Addition to status: it doesn't seem like the RTEMS Interrupt's call to
>> _Thread_Dispatch functions either - ticker.exe has outputs like the
>> following (yeah, the counter is running too quickly right now):
>>
>> *** BEGIN OF TEST CLOCK TICK ***
>> *** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
>> *** TEST STATE: EXPECTED-PASS
>> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
>> *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
>> 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
>> TA1  - rtems_clock_get_tod - 11:34:12   05/12/1990
>> TA2  - rtems_clock_get_tod - 11:34:12   05/12/1990
>> TA3  - rtems_clock_get_tod - 11:34:12   05/12/1990
>
>
> Congratulations! But why is the date 5/12/1990? I think it is supposed
> to be 12/31/1989. :)
>>
>>
>> (And then the _Thread_Idle_body is never preempted due to the
>> interrupt dispatching a new thread - not sure if it just thinks it's
>> "too late" to even bother or if simply never even tries. I'll keep
>> investigating.)
>
>
> This means your "outer" assembly language _ISR_Handler does not
> yet deal with "needs dispatch". On the 5 second tick, a task is unblocked
> and set up to preempt. The end of the ISR path has to be right to
> make this work.
>
> --joel
>>
>>
>> On Thu, Aug 9, 2018 at 6:03 PM, Amaan Cheval 
>> wrote:
>> > Hi everyone!
>> >
>> > Good news! The APIC timer _does_ work now (after implementing 1GiB
>> > pages)! I see Clock_isr_ticks increasing steadily, though I don't have
>> > tc_get_timecount implemented yet - I've yet to figure out the
>> > specifics of the clock driver (how
>> > rtems_configuration_get_microseconds_per_tick influences the
>> > counter_ticks, specifically).
>> >
>> > I suspect we'll barely just make ticker.exe work by EOD tomorrow,
>> > leaving just the weekend for me to clean the patches up and Monday to
>> > actually merge them.
>> >
>> > Would someone be willing to have a meeting on

Re: Inlined code

2018-08-09 Thread Sebastian Huber 
- Am 6. Aug 2018 um 21:14 schrieb joel j...@rtems.org:
[...]
> We looked at a lot of generated assembly. Sometimes we would see
> large methods being inlined multiple times. This would increase the overall
> size of an RTEMS application. But size is not the only impact of inlining.
> If an inlined method has one or more if's in it, then the branch paths
> it includes are introduced EVERYWHERE it is inlined. When we
> had _Thread_Dispatch_enable, I recall it was used > 100 times and
> includes a branch in it. There was a build option to not inline this
> routine to avoid needing to add over 100 test cases.
[...]

I had a look at the _Thread_Dispatch_enable() code and was a bit surprised that 
GCC generates a stack frame in this function.  This turned out as a bug in the 
function. Do you find it? I will fix it tomorrow.

Before we start to turn inline functions into non-inline functions we should 
create a benchmark program (or more). We should look at the overall code size 
changes and the local code changes.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

2018-08-09 Thread Joel Sherrill 
On Thu, Aug 9, 2018 at 7:43 AM, Amaan Cheval  wrote:

> Addition to status: it doesn't seem like the RTEMS Interrupt's call to
> _Thread_Dispatch functions either - ticker.exe has outputs like the
> following (yeah, the counter is running too quickly right now):
>
> *** BEGIN OF TEST CLOCK TICK ***
> *** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
> *** TEST STATE: EXPECTED-PASS
> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
> *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
> 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
> TA1  - rtems_clock_get_tod - 11:34:12   05/12/1990
> TA2  - rtems_clock_get_tod - 11:34:12   05/12/1990
> TA3  - rtems_clock_get_tod - 11:34:12   05/12/1990
>

Congratulations! But why is the date 5/12/1990? I think it is supposed
to be 12/31/1989. :)

>
> (And then the _Thread_Idle_body is never preempted due to the
> interrupt dispatching a new thread - not sure if it just thinks it's
> "too late" to even bother or if simply never even tries. I'll keep
> investigating.)
>

This means your "outer" assembly language _ISR_Handler does not
yet deal with "needs dispatch". On the 5 second tick, a task is unblocked
and set up to preempt. The end of the ISR path has to be right to
make this work.

--joel

>
> On Thu, Aug 9, 2018 at 6:03 PM, Amaan Cheval 
> wrote:
> > Hi everyone!
> >
> > Good news! The APIC timer _does_ work now (after implementing 1GiB
> > pages)! I see Clock_isr_ticks increasing steadily, though I don't have
> > tc_get_timecount implemented yet - I've yet to figure out the
> > specifics of the clock driver (how
> > rtems_configuration_get_microseconds_per_tick influences the
> > counter_ticks, specifically).
> >
> > I suspect we'll barely just make ticker.exe work by EOD tomorrow,
> > leaving just the weekend for me to clean the patches up and Monday to
> > actually merge them.
> >
> > Would someone be willing to have a meeting on Hangouts (or whatever)
> > with me to speed up the process of (1) upstreaming my patches and (2)
> > checking that my "work package" looks good enough at any convenient
> > time on Monday?
> >
> > (I'm a bit busy on Monday, so I'd really prefer to have this whole
> > thing done by EOD Monday for me.)
> >
> > On Thu, Aug 9, 2018 at 7:03 AM, Gedare Bloom  wrote:
> >> On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval 
> wrote:
> >>> Status update: The code is at a point where the APIC timer _should_
> >>> work, but doesn't (it never starts ticking away, so when calibrating
> >>> with the PIT, and later starting the APIC timer to generate IRQs,
> >>> pretty much nothing happens).
> >>>
> >>> I suspect the cause being the APIC base relocation not working (the
> >>> APIC is located at 0xfee0 in physical memory by default, and in
> >>> the code we write to an MSR to relocate it, because the page-mapping
> >>> scheme FreeBSD setup doesn't let us access such high physical memory -
> >>> only the first 1GiB of physical memory).
> >>>
> >>> On QEMU, the MSR accepts our write for the relocation and happily
> >>> spits it back out when read, but given the unresponsiveness of the
> >>> APIC timer despite enabling all the right bits, I suspect it's just a
> >>> "fake" in that regard (QEMU's "info lapic" doesn't reflect any of our
> >>> changes to the APIC configuration either, supporting this theory).
> >>> QEMU _does_ reflect changes to the APIC by other operating systems
> >>> which don't relocate it, so I don't suspect its emulation being a
> >>> problem.
> >>>
> >>> On VirtualBox, the MSR simply silently swallows the write, and upon a
> >>> read, returns the original 0xfee0 value again. This means that if
> >>> we can't relocate it, we can't access it at the moment either.
> >>>
> >>> The only real way to work around this is to have a paging scheme that
> >>> lets us access physical address 0xfee0 - in that case, we could
> >>> support page-faults and dynamically map pages in, _or_ have static
> >>> pages that are absurdly large (such as 1GiB), letting the virtual
> >>> address do the heavy-lifting in terms of finding the
> >>> virtual-to-physical mapping.
> >>>
> >>
> >> I recommend a few static super pages to get it working. It is simple
> >> and fits the prevailing RTEMS model.
> >>
> >>> Either way, I think this issue this close to the deadline basically
> >>> means the APIC timer won't be functional and make it upstream.
> >>>
> >>> I'll clean things up and send patches tomorrow for everything so far,
> >>> including all the stub-code which will become usable once our paging
> >>> scheme works fine.
> >>>
> >>> If anyone has any last-minute swooping ideas on how to save the APIC
> >>> timer, let me know! (Interrupts aren't masked, and as far as I can
> >>> tell, changing the "-cpu" flag on QEMU doesn't make a difference. I
> >>> don't have any ideas as to what else the problem could be.)
> >>>
> >>> In my final report, I'll make sure I document what's remaining in
> >>> clearer terms than I have in this

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

2018-08-09 Thread Amaan Cheval 
Addition to status: it doesn't seem like the RTEMS Interrupt's call to
_Thread_Dispatch functions either - ticker.exe has outputs like the
following (yeah, the counter is running too quickly right now):

*** BEGIN OF TEST CLOCK TICK ***
*** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
*** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
TA1  - rtems_clock_get_tod - 11:34:12   05/12/1990
TA2  - rtems_clock_get_tod - 11:34:12   05/12/1990
TA3  - rtems_clock_get_tod - 11:34:12   05/12/1990

(And then the _Thread_Idle_body is never preempted due to the
interrupt dispatching a new thread - not sure if it just thinks it's
"too late" to even bother or if simply never even tries. I'll keep
investigating.)

On Thu, Aug 9, 2018 at 6:03 PM, Amaan Cheval  wrote:
> Hi everyone!
>
> Good news! The APIC timer _does_ work now (after implementing 1GiB
> pages)! I see Clock_isr_ticks increasing steadily, though I don't have
> tc_get_timecount implemented yet - I've yet to figure out the
> specifics of the clock driver (how
> rtems_configuration_get_microseconds_per_tick influences the
> counter_ticks, specifically).
>
> I suspect we'll barely just make ticker.exe work by EOD tomorrow,
> leaving just the weekend for me to clean the patches up and Monday to
> actually merge them.
>
> Would someone be willing to have a meeting on Hangouts (or whatever)
> with me to speed up the process of (1) upstreaming my patches and (2)
> checking that my "work package" looks good enough at any convenient
> time on Monday?
>
> (I'm a bit busy on Monday, so I'd really prefer to have this whole
> thing done by EOD Monday for me.)
>
> On Thu, Aug 9, 2018 at 7:03 AM, Gedare Bloom  wrote:
>> On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval  wrote:
>>> Status update: The code is at a point where the APIC timer _should_
>>> work, but doesn't (it never starts ticking away, so when calibrating
>>> with the PIT, and later starting the APIC timer to generate IRQs,
>>> pretty much nothing happens).
>>>
>>> I suspect the cause being the APIC base relocation not working (the
>>> APIC is located at 0xfee0 in physical memory by default, and in
>>> the code we write to an MSR to relocate it, because the page-mapping
>>> scheme FreeBSD setup doesn't let us access such high physical memory -
>>> only the first 1GiB of physical memory).
>>>
>>> On QEMU, the MSR accepts our write for the relocation and happily
>>> spits it back out when read, but given the unresponsiveness of the
>>> APIC timer despite enabling all the right bits, I suspect it's just a
>>> "fake" in that regard (QEMU's "info lapic" doesn't reflect any of our
>>> changes to the APIC configuration either, supporting this theory).
>>> QEMU _does_ reflect changes to the APIC by other operating systems
>>> which don't relocate it, so I don't suspect its emulation being a
>>> problem.
>>>
>>> On VirtualBox, the MSR simply silently swallows the write, and upon a
>>> read, returns the original 0xfee0 value again. This means that if
>>> we can't relocate it, we can't access it at the moment either.
>>>
>>> The only real way to work around this is to have a paging scheme that
>>> lets us access physical address 0xfee0 - in that case, we could
>>> support page-faults and dynamically map pages in, _or_ have static
>>> pages that are absurdly large (such as 1GiB), letting the virtual
>>> address do the heavy-lifting in terms of finding the
>>> virtual-to-physical mapping.
>>>
>>
>> I recommend a few static super pages to get it working. It is simple
>> and fits the prevailing RTEMS model.
>>
>>> Either way, I think this issue this close to the deadline basically
>>> means the APIC timer won't be functional and make it upstream.
>>>
>>> I'll clean things up and send patches tomorrow for everything so far,
>>> including all the stub-code which will become usable once our paging
>>> scheme works fine.
>>>
>>> If anyone has any last-minute swooping ideas on how to save the APIC
>>> timer, let me know! (Interrupts aren't masked, and as far as I can
>>> tell, changing the "-cpu" flag on QEMU doesn't make a difference. I
>>> don't have any ideas as to what else the problem could be.)
>>>
>>> In my final report, I'll make sure I document what's remaining in
>>> clearer terms than I have in this email, so it's easier for other
>>> contributors to pick it up too, if any are interested.
>>>
>>> 
>>>
>>> On Tue, Aug 7, 2018 at 6:03 AM, Chris Johns  wrote:
 On 07/08/2018 09:27, Joel Sherrill wrote:
> On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval  > wrote:
>
> Thanks for all the help! I have a simple test using the RTEMS
> interrupt manager working successfully (tested by calling
> rtems_interrupt_handler_install for vector 0, and then triggering a
> divide-by-0 exception).
>
>

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

2018-08-09 Thread Amaan Cheval 
Hi everyone!

Good news! The APIC timer _does_ work now (after implementing 1GiB
pages)! I see Clock_isr_ticks increasing steadily, though I don't have
tc_get_timecount implemented yet - I've yet to figure out the
specifics of the clock driver (how
rtems_configuration_get_microseconds_per_tick influences the
counter_ticks, specifically).

I suspect we'll barely just make ticker.exe work by EOD tomorrow,
leaving just the weekend for me to clean the patches up and Monday to
actually merge them.

Would someone be willing to have a meeting on Hangouts (or whatever)
with me to speed up the process of (1) upstreaming my patches and (2)
checking that my "work package" looks good enough at any convenient
time on Monday?

(I'm a bit busy on Monday, so I'd really prefer to have this whole
thing done by EOD Monday for me.)

On Thu, Aug 9, 2018 at 7:03 AM, Gedare Bloom  wrote:
> On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval  wrote:
>> Status update: The code is at a point where the APIC timer _should_
>> work, but doesn't (it never starts ticking away, so when calibrating
>> with the PIT, and later starting the APIC timer to generate IRQs,
>> pretty much nothing happens).
>>
>> I suspect the cause being the APIC base relocation not working (the
>> APIC is located at 0xfee0 in physical memory by default, and in
>> the code we write to an MSR to relocate it, because the page-mapping
>> scheme FreeBSD setup doesn't let us access such high physical memory -
>> only the first 1GiB of physical memory).
>>
>> On QEMU, the MSR accepts our write for the relocation and happily
>> spits it back out when read, but given the unresponsiveness of the
>> APIC timer despite enabling all the right bits, I suspect it's just a
>> "fake" in that regard (QEMU's "info lapic" doesn't reflect any of our
>> changes to the APIC configuration either, supporting this theory).
>> QEMU _does_ reflect changes to the APIC by other operating systems
>> which don't relocate it, so I don't suspect its emulation being a
>> problem.
>>
>> On VirtualBox, the MSR simply silently swallows the write, and upon a
>> read, returns the original 0xfee0 value again. This means that if
>> we can't relocate it, we can't access it at the moment either.
>>
>> The only real way to work around this is to have a paging scheme that
>> lets us access physical address 0xfee0 - in that case, we could
>> support page-faults and dynamically map pages in, _or_ have static
>> pages that are absurdly large (such as 1GiB), letting the virtual
>> address do the heavy-lifting in terms of finding the
>> virtual-to-physical mapping.
>>
>
> I recommend a few static super pages to get it working. It is simple
> and fits the prevailing RTEMS model.
>
>> Either way, I think this issue this close to the deadline basically
>> means the APIC timer won't be functional and make it upstream.
>>
>> I'll clean things up and send patches tomorrow for everything so far,
>> including all the stub-code which will become usable once our paging
>> scheme works fine.
>>
>> If anyone has any last-minute swooping ideas on how to save the APIC
>> timer, let me know! (Interrupts aren't masked, and as far as I can
>> tell, changing the "-cpu" flag on QEMU doesn't make a difference. I
>> don't have any ideas as to what else the problem could be.)
>>
>> In my final report, I'll make sure I document what's remaining in
>> clearer terms than I have in this email, so it's easier for other
>> contributors to pick it up too, if any are interested.
>>
>> 
>>
>> On Tue, Aug 7, 2018 at 6:03 AM, Chris Johns  wrote:
>>> On 07/08/2018 09:27, Joel Sherrill wrote:
 On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval >>> > wrote:

 Thanks for all the help! I have a simple test using the RTEMS
 interrupt manager working successfully (tested by calling
 rtems_interrupt_handler_install for vector 0, and then triggering a
 divide-by-0 exception).

 Yeah!

 Could someone shed any light on why the i386 only hooks the first 17
 vectors as "RTEMS interrupts"?

 You are making me feel very old especially since I have the real
 IBM manual in my office which corresponds to the answer.
>>>
>>> Grandchildren, grey hair or Sebastian posting he is feeling old do not make 
>>> you
>>> feel old? Interesting! ;) :)
>>>
> I feel old, too.
>
 It is dated Sept 1985. In fairness, I saved it from the garbage heap
 years later when someone was cleaning out their office. :)
>>>
>>> Ah the good old days before the internet and search engines!!
>>>
 The x86 architecture is really vectored and the original i386
 port actually used simple direct vectoring since the first BSP wasn't
 a PC. Imagine that!  Another board using an i386 which didn't
 look like a PC at all.

 For better or worse, the PC/AT (286) and later used two i8259 PICs
 in a master and slave configuration. The slave PIC cascaded off the

Re: Update of libbsd to close to FreeBSD 12 release planned

2018-08-09 Thread Sebastian Huber 

On 07/08/18 15:23, Sebastian Huber wrote:

Hello,

I started to work on this. Unfortunately, updating FreeBSD requires 
also some update of Newlib header files. I will remove the _KERNEL 
parts of the socket header files and use a kernel space only include. 
For an example see:


https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/sys/rtems/include/sys/cpuset.h;h=a850575a14b50396832149943ed7fe6f7edba515;hb=HEAD#l227 



Once this is done, we need a mandatory Newlib update for libbsd users.



See also:

https://sourceware.org/ml/newlib/2018/msg00666.html

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Add FreeBSD kernel space header files

2018-08-09 Thread Sebastian Huber 
Move the kernel space content of some Newlib provided header files to
RTEMS and libbsd.  This allows to use the Newlib provided header files
with different FreeBSD baselines.

Update #3472.
---
 cpukit/headers.am |   3 +
 cpukit/include/machine/_kernel_in.h   |  60 +
 cpukit/include/machine/_kernel_in6.h  | 181 ++
 cpukit/include/machine/_kernel_uio.h  |  87 +
 cpukit/libnetworking/headers.am   |   2 +
 cpukit/libnetworking/machine/_kernel_if.h |  44 +++
 cpukit/libnetworking/machine/_kernel_socket.h |  83 
 7 files changed, 460 insertions(+)
 create mode 100644 cpukit/include/machine/_kernel_in.h
 create mode 100644 cpukit/include/machine/_kernel_in6.h
 create mode 100644 cpukit/include/machine/_kernel_uio.h
 create mode 100644 cpukit/libnetworking/machine/_kernel_if.h
 create mode 100644 cpukit/libnetworking/machine/_kernel_socket.h

diff --git a/cpukit/headers.am b/cpukit/headers.am
index fb6e1fc009..9c13fefe02 100644
--- a/cpukit/headers.am
+++ b/cpukit/headers.am
@@ -67,9 +67,12 @@ include_linux_spi_HEADERS += include/linux/spi/spidev.h
 include_machinedir = $(includedir)/machine
 include_machine_HEADERS =
 include_machine_HEADERS += include/machine/_kernel_cpuset.h
+include_machine_HEADERS += include/machine/_kernel_in.h
+include_machine_HEADERS += include/machine/_kernel_in6.h
 include_machine_HEADERS += include/machine/_kernel_param.h
 include_machine_HEADERS += include/machine/_kernel_time.h
 include_machine_HEADERS += include/machine/_kernel_types.h
+include_machine_HEADERS += include/machine/_kernel_uio.h
 include_machine_HEADERS += include/machine/_timecounter.h
 
 include_mghttpddir = $(includedir)/mghttpd
diff --git a/cpukit/include/machine/_kernel_in.h 
b/cpukit/include/machine/_kernel_in.h
new file mode 100644
index 00..0dad7f534e
--- /dev/null
+++ b/cpukit/include/machine/_kernel_in.h
@@ -0,0 +1,60 @@
+/*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 1982, 1986, 1990, 1993
+ * The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * @(#)in.h8.3 (Berkeley) 1/3/94
+ * $FreeBSD: head/sys/netinet/in.h 326023 2017-11-20 19:43:44Z pfg $
+ */
+
+#if !defined(_NETINET_IN_H_) || !defined(_KERNEL)
+#error "must be included via  in kernel space"
+#endif
+
+struct ifnet; struct mbuf; /* forward declarations for Standard C */
+struct in_ifaddr;
+
+int in_broadcast(struct in_addr, struct ifnet *);
+int in_ifaddr_broadcast(struct in_addr, struct in_ifaddr *);
+int in_canforward(struct in_addr);
+int in_localaddr(struct in_addr);
+int in_localip(struct in_addr);
+int in_ifhasaddr(struct ifnet *, struct in_addr);
+int inet_aton(const char *, struct in_addr *); /* in libkern */
+char   *inet_ntoa_r(struct in_addr ina, char *buf); /* in libkern */
+char   *inet_ntop(int, const void *, char *, socklen_t); /* in libkern */
+int inet_pton(int af, const char *, void *); /* in libkern */
+voidin_ifdetach(struct ifnet *);
+
+#definein_hosteq(s, t) ((s).s_addr == (t).s_addr)
+#definein_nullhost(x)  ((x).s_addr == INADDR_ANY)
+#definein_allhosts(x)  ((x).s_addr == htonl(INADDR_ALLHOSTS_GROUP))
+
+#definesatosin(sa) ((struct sockaddr_in *)(sa))
+#definesintosa(sin)((struct sockaddr *)(sin))
+#defineifatoia(ifa)((struct in_ifaddr *)(ifa))
diff --git

[PATCH] Add FreeBSD kernel space header files

2018-08-09 Thread Sebastian Huber 
Move the kernel space content of some Newlib provided header files to
RTEMS and libbsd.  This allows to use the Newlib provided header files
with different FreeBSD baselines.

Update #3472.
---
 rtemsbsd/include/machine/_kernel_if.h | 44 
 rtemsbsd/include/machine/_kernel_socket.h | 83 +++
 2 files changed, 127 insertions(+)
 create mode 100644 rtemsbsd/include/machine/_kernel_if.h
 create mode 100644 rtemsbsd/include/machine/_kernel_socket.h

diff --git a/rtemsbsd/include/machine/_kernel_if.h 
b/rtemsbsd/include/machine/_kernel_if.h
new file mode 100644
index 0..b360a41b2
--- /dev/null
+++ b/rtemsbsd/include/machine/_kernel_if.h
@@ -0,0 +1,44 @@
+/*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 1982, 1986, 1989, 1993
+ * The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * @(#)if.h8.1 (Berkeley) 6/10/93
+ * $FreeBSD: head/sys/net/if.h 333502 2018-05-11 20:08:28Z mmacy $
+ */
+
+#if !defined(_NET_IF_H_) || !defined(_KERNEL)
+#error "must be included via  in kernel space"
+#endif
+
+#ifdef MALLOC_DECLARE
+MALLOC_DECLARE(M_IFADDR);
+MALLOC_DECLARE(M_IFMADDR);
+#endif
+
+#defineifr_dataifr_ifru.ifru_data  /* for use by interface 
*/
diff --git a/rtemsbsd/include/machine/_kernel_socket.h 
b/rtemsbsd/include/machine/_kernel_socket.h
new file mode 100644
index 0..e9acc744f
--- /dev/null
+++ b/rtemsbsd/include/machine/_kernel_socket.h
@@ -0,0 +1,83 @@
+/*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 1982, 1985, 1986, 1988, 1993, 1994
+ * The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * @(#)socket.h8.4 (Berkeley) 2/21/94
+ * $FreeBSD: head/sys/sys/socket.h 334719 2018-06-06 15:45:57Z sbruno $
+ */
+
+#if !defined(_SYS_SOCKET_H_) || !defined(_KERNEL)
+#error "must be included via  in kernel space"
+#endif
+
+/*
+ * Flags for accept1(), kern_accept4()