Re: [PATCH 02/12] random: Implement read_random via getentropy.
Am 01.08.2018 um 16:28 schrieb Gedare Bloom:
> Is this relied on for IPSec? How secure is it?
Hello Gedare,
the IPSec implementation in FreeBSD and therefore in RTEMS too uses that
function. So you are right that it is a critical one for security.
`read_random` is a low-level FreeBSD random number function. From the
man page (see
https://www.freebsd.org/cgi/man.cgi?query=read_random=FreeBSD+11.2-RELEASE+and+Ports):
The read_random() function is used to return entropy directly from
the entropy device if it has been loaded. If the entropy device is
not loaded, then the buffer is ignored and zero is returned. The
buffer is filled with no more than count bytes. It is strongly
advised that read_random() is not used; instead use arc4rand()
unless it is necessary to know that no entropy has been returned.
That's basically the same what our `getentropy` does. Returning entropy
directly from the entropy device if it is available. So it is as close
to the original behavior as we can get.
Of course `getentropy` only returns a good entropy if there is a real
entropy source in the BSP. Currently that is only true for the atsam
BSP. I think there should be a patch for BBB somewhere on the mailing list.
We have a chapter in the BSP guide regarding that:
https://docs.rtems.org/branches/master/bsp-howto/getentropy.html
There is also a hint that a good entropy source is necessary for
cryptographic applications. It would be great if you have a good idea
how to make a user aware of the security problem if he doesn't use a
good crypto source.
Best regards
Christian
>
> On Wed, Aug 1, 2018 at 4:04 AM, Christian Mauderer
> wrote:
>> ---
>> freebsd/sys/sys/random.h | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/freebsd/sys/sys/random.h b/freebsd/sys/sys/random.h
>> index 396ec2b1..996ca5c1 100644
>> --- a/freebsd/sys/sys/random.h
>> +++ b/freebsd/sys/sys/random.h
>> @@ -50,11 +50,21 @@ read_random_uio(void *a __unused, u_int b __unused)
>> {
>> return (0);
>> }
>> +#ifndef __rtems__
>> static __inline u_int
>> read_random(void *a __unused, u_int b __unused)
>> {
>> return (0);
>> }
>> +#else /* __rtems__ */
>> +#include
>> +static __inline u_int
>> +read_random(void *ptr, u_int n)
>> +{
>> + getentropy(ptr, n);
>> + return (n);
>> +}
>> +#endif /* __rtems__ */
>> #endif
>>
>> /*
>> --
>> 2.13.7
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
--
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
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 00/12] Add ipsec to libbsd.
On 02/08/2018 15:09, Christian Mauderer wrote: > Just a note: two of the patches are too big for the mailing list. Yeah, 4986580 + 1207698 bytes. Too big to allow. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Add ipsec to libbsd.
Am 01.08.2018 um 10:04 schrieb Christian Mauderer: > Hello, > > this patch set adds IPSec functionality to libbsds everything build set. > > The first four patches prepare some necessary functionality. Patch 5 and > 6 add the if_ipsec driver. 7 to 9 import ipsec-tools from the FreeBSD > ports. 10 is just some readability improvement for the build set. 11 > adds rc.conf support for ipsec and 12 adds information on how to use > ipsec in libbsd. > > Best regards > > Christian Mauderer > Just a note: two of the patches are too big for the mailing list. If someone is interested: I uploaded the whole patch set to a gist: https://gist.github.com/c-mauderer/4ebb44d0502cc3f8c45a345937677903 -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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] Initial implemantation commit
On Wed, Aug 1, 2018 at 8:56 AM, Gedare Bloom wrote:
> On Tue, Jul 31, 2018 at 11:50 PM, Dannie Huang
> wrote:
> > Hi,
> >
> > This is the initial implementation commit of converting newlib markup to
> > rst, the example .rst file looks like this photo (see attached photo
> > please).
> >
>
> Can we see a side-by-side comparison with how newlib's documentation looks?
>
Sure, see attached photo please. Newlib's documentation is on the left and
the rst output is on the right.
>
> > Code is pushed on my github:
> >
> > https://github.com/dh0072/NewlibMarkup2SphinxConverter
> >
> > Best,
> > Dannie
> >
> > On Tue, Jul 31, 2018 at 10:42 PM, Dannie Huang
> > wrote:
> >>
> >> From: Danxue Huang <36866155+dh0...@users.noreply.github.com>
> >>
> >> ---
> >> .gitignore | 2 +
> >> README.md | 2 +
> >> gen_rst_from_makedoc.py | 125
> >>
> >> rst.py | 104
> >> strcmp.rst | 47 ++
> >> 5 files changed, 280 insertions(+)
> >> create mode 100644 .gitignore
> >> create mode 100644 README.md
> >> create mode 100755 gen_rst_from_makedoc.py
> >> create mode 100644 rst.py
> >> create mode 100644 strcmp.rst
> >>
> >> diff --git a/.gitignore b/.gitignore
> >> new file mode 100644
> >> index 000..9f90354
> >> --- /dev/null
> >> +++ b/.gitignore
> >> @@ -0,0 +1,2 @@
> >> +.idea/*
> >> +__pycache__/*
> >> diff --git a/README.md b/README.md
> >> new file mode 100644
> >> index 000..8ebb224
> >> --- /dev/null
> >> +++ b/README.md
> >> @@ -0,0 +1,2 @@
> >> +# NewlibMarkup2SphinxConvertorPrivate
> >> +(PRIVATE) This repo contains code for
> >> NewlibMarkup2SphinxConvertorPrivate.
> >> diff --git a/gen_rst_from_makedoc.py b/gen_rst_from_makedoc.py
> >> new file mode 100755
> >> index 000..da69c80
> >> --- /dev/null
> >> +++ b/gen_rst_from_makedoc.py
> >> @@ -0,0 +1,125 @@
> >> +#!/usr/bin/env python
> >> +#
> >> +# RTEMS Tools Project (http://www.rtems.org/)
> >> +# Copyright 2018 Danxue Huang (danxue.hu...@gmail.com)
> >> +# All rights reserved.
> >> +#
> >> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> >> +#
> >> +# 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.
> >> +#
> >> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT HOLDER 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.
> >> +#
> >> +
> >> +
> >> +import argparse
> >> +import re
> >> +import rst
> >> +
> >> +
> >> +def is_command(s):
> >> +"""
> >> +A command is a single word of at least 3 characters, all uppercase
> >> +:param s: input string
> >> +:return: True if s is a single command, otherwise False
> >> +"""
> >> +return True if re.match('^[A-Z_]{3,}\s*$', s) else False
> >> +
> >> +
> >> +def extract_comments(content):
> >> +"""
> >> +Extract content inside of /* */
> >> +:param content: input file content
> >> +:return: extracted comments
> >> +"""
> >> +comments = ''
> >> +comments_match = re.match('/\*(\*(?!/)|[^*])*\*/', content)
> >> +if comments_match:
> >> +wrapped_comments = comments_match.group()
> >> +comments =
> >> wrapped_comments.lstrip('/*').rstrip('*/').lstrip().rstrip()
> >> +return comments
> >> +
> >> +
> >> +def extract_command_and_text(content):
> >> +"""
> >> +Extract command and text from input string content
> >> +:param content: input string containing command and text
> >> +:return: a tuple containing command and text
> >> +"""
> >> +command = ''
> >> +text = ''
> >> +command_text_dict = {}
> >> +for line in content.splitlines():
> >> +if
[PATCH 1/1] Address comments
---
.gitignore | 1 +
gen_rst_from_makedoc.py | 71 ++--
makedoc2rst_converter.py | 85
3 files changed, 96 insertions(+), 61 deletions(-)
create mode 100644 makedoc2rst_converter.py
diff --git a/.gitignore b/.gitignore
index 9f90354..f707fbd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
.idea/*
__pycache__/*
+*.rst
diff --git a/gen_rst_from_makedoc.py b/gen_rst_from_makedoc.py
index da69c80..4100756 100755
--- a/gen_rst_from_makedoc.py
+++ b/gen_rst_from_makedoc.py
@@ -29,60 +29,8 @@
# POSSIBILITY OF SUCH DAMAGE.
#
-
import argparse
-import re
-import rst
-
-
-def is_command(s):
-"""
-A command is a single word of at least 3 characters, all uppercase
-:param s: input string
-:return: True if s is a single command, otherwise False
-"""
-return True if re.match('^[A-Z_]{3,}\s*$', s) else False
-
-
-def extract_comments(content):
-"""
-Extract content inside of /* */
-:param content: input file content
-:return: extracted comments
-"""
-comments = ''
-comments_match = re.match('/\*(\*(?!/)|[^*])*\*/', content)
-if comments_match:
-wrapped_comments = comments_match.group()
-comments = wrapped_comments.lstrip('/*').rstrip('*/').lstrip().rstrip()
-return comments
-
-
-def extract_command_and_text(content):
-"""
-Extract command and text from input string content
-:param content: input string containing command and text
-:return: a tuple containing command and text
-"""
-command = ''
-text = ''
-command_text_dict = {}
-for line in content.splitlines():
-if is_command(line):
-if command and text:
-command_text_dict[command] = text
-command = line.rstrip()
-text = ''
-else:
-text += line + '\n'
-return command_text_dict
-
-
-def generate_rst(command_text_dict):
-rst_str = ''
-for command, text in command_text_dict.items():
-rst_str += rst.get_command_processor(command)(command, text)
-return rst_str
+import makedoc2rst_converter
def get_parser():
@@ -91,15 +39,15 @@ def get_parser():
)
parser.add_argument(
'-s',
-'--source_file_dir',
+'--source_file_path',
type=str,
-help='Source file directory with newlib style comments',
+help='Path of source file with newlib style comments',
)
parser.add_argument(
'-d',
-'--dest_file_dir',
+'--dest_file_path',
type=str,
-help='Destination directory for converted rst markup file',
+help='Path of destination file with rst markup',
)
return parser
@@ -108,18 +56,19 @@ def main(source_file_dir, dest_file_dir):
with open(source_file_dir, 'r') as source_file, open(dest_file_dir, 'w')
as dest_file:
file_content = source_file.read()
+makedoc2rst = makedoc2rst_converter.makedoc2rst_converter()
# Get comments inside of /* */
-comments = extract_comments(file_content)
+comments = makedoc2rst.extract_comments(file_content)
# Parse comments
-command_text_dict = extract_command_and_text(comments)
+command_text_dict = makedoc2rst.extract_command_and_text(comments)
# Process text based on command type
-rst_str = generate_rst(command_text_dict)
+rst_str = makedoc2rst.generate_rst(command_text_dict)
dest_file.write(rst_str)
if __name__ == '__main__':
args = get_parser().parse_args()
-main(args.source_file_dir, args.dest_file_dir)
+main(args.source_file_path, args.dest_file_path)
diff --git a/makedoc2rst_converter.py b/makedoc2rst_converter.py
new file mode 100644
index 000..e4d2d72
--- /dev/null
+++ b/makedoc2rst_converter.py
@@ -0,0 +1,85 @@
+#!/usr/bin/env python
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2018 Danxue Huang (danxue.hu...@gmail.com)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT,
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
I have started to reply twice but you jumped in ahead. :) On Wed, Aug 1, 2018 at 12:12 PM, Amaan Cheval wrote: > If my previous email _is_ in fact correct, could someone confirm? > Because this excerpt in the documentation here seems to contradict it > (which was what lead to the confusion in the first place): > > https://docs.rtems.org/branches/master/c-user/interrupt_manager.html# > establishing-an-isr > > With my emphasis: > > > The rtems_interrupt_catch directive establishes an ISR for the system. > The address of the ISR and its associated CPU vector number are specified > to this directive. This directive installs the **RTEMS interrupt wrapper in > the processor’s Interrupt Vector Table and the address of the user’s ISR in > the RTEMS’ Vector Table**. This directive returns the previous contents of > the specified vector in the RTEMS’ Vector Table. > Almost but Gedare and I left out a detail. rtems_interrupt_catch is ONLY used on pure simple vectored architectures which do not use the bsp_interrupt_* or interfaces. Some embedded MCUs are so simple and have plenty of vectors so you don't need the complexity of supporting a PIC. For example, the m68k family had 256 direct vectors and I don't recall ever seeing a PIC.[1] You should assume that you can ignore rtems_interrupt_catch and simple vectored support for x86_64. See cpukit/rtems/intrcatch.c and I hope you see an ifdef that results in the code disappearing on your port. Simple vectored is FACE is your cpu.h. :) [1] Disclaimer: The support for the interfaces is critical to the libbsd stack. We haven't discussed it but any architecture that is sufficient to run the new stack will have to support this interface. If someone wants the new stack on a 68040 VME board or a Coldfire board, we will have to find the simplest, non-bloated way to support this. When doing the MIPS Malta, we just converted the MIPS architecture away from simple vectored. So support the bsp_interrupt_* infrastructure. :) --joel > > On Wed, Aug 1, 2018 at 10:39 PM, Amaan Cheval > wrote: > > Okay, I think I understand finally. Sorry about the rambling! > > > > When rtems_interrupt_catch is called, that's installing a "raw" ISR by > > modifying the processor specific table itself, so _ISR_Handler is > > never called, but the user ISR is. > > > > When rtems_interrupt_handler_install is called, that's an "RTEMS > > interrupt", and we go through the _ISR_Handler -> dispatch route I > > laid out earlier, leading to eventually the user's ISR. > > > > Thank you for letting me rubber-duck with you, everyone (let me know > > if anything above sounds off, though!) :P > > > > On Wed, Aug 1, 2018 at 10:20 PM, Amaan Cheval > wrote: > >> Thanks for the background! > >> > >> Let's use the gen5200 as the ongoing example - my confusion arises > >> here (correct me if any of the following points is incorrect!). In > >> overly simplified call chains: > >> > >> Register interrupt handler: > >> - bsp_interrupt_facility_initialize() -> ppc_exc_set_handler(vec, > >> C_dispatch_irq_handler) -> ppc_exc_handler_table[vec] = > >> C_dispatch_irq_handler > >> > >> Interrupt handler called: > >> - C_dispatch_irq_handler -> dispatch -> bsp_interrupt_handler_dispatch > >> (irq-generic.h) -> bsp_interrupt_handler_table[index].handler() > >> > >> What I'm confused about is how the bsp_interrupt_handler_table is > >> updated at all - I just haven't found the link between how the entries > >> in the two tables are synchronized, where the tables are: > >> > >> 1) the ppc_exc_handler_table (the processor IDT) and > >> 2) the bsp_interrupt_handler_table (the RTEMS interrupt table) > >> > >> > >> Another similar chain of confusion for i386 is: > >> - rtems_interrupt_catch (intrcatch.c) -> _ISR_Install_vector (isr.h) > >> -> _CPU_ISR_install_vector (i386/idt.c) -> idt_entry_tbl[vector] > >> updated > >> > >> But the i386 dispatch code chain is: > >> - _ISR_Handler (i386/irq_asm.S) -> BSP_dispatch_isr (i386/irq.c) -> > >> bsp_interrupt_handler_dispatch (irq-generic.h) -> > >> bsp_interrupt_handler_table[index].handler() > >> > >> But I don't see any updates to bsp_interrupt_handler_table that would > >> let this work. > >> - > >> > >> Would you happen to know what that "missing link" is? > >> > >> On Wed, Aug 1, 2018 at 9:07 PM, Joel Sherrill wrote: > >>> > >>> > >>> On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom > wrote: > > On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval > wrote: > > That's definitely very illuminating, thank you so much for all the > > details! > > > > A few more questions that have arisen for me. Feel free to skip over > > them (I'll likely figure them out given enough time, so I'm only > > asking in case any of them are obvious to anyone): > > > > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it
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
If my previous email _is_ in fact correct, could someone confirm? Because this excerpt in the documentation here seems to contradict it (which was what lead to the confusion in the first place): https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#establishing-an-isr With my emphasis: > The rtems_interrupt_catch directive establishes an ISR for the system. The > address of the ISR and its associated CPU vector number are specified to this > directive. This directive installs the **RTEMS interrupt wrapper in the > processor’s Interrupt Vector Table and the address of the user’s ISR in the > RTEMS’ Vector Table**. This directive returns the previous contents of the > specified vector in the RTEMS’ Vector Table. On Wed, Aug 1, 2018 at 10:39 PM, Amaan Cheval wrote: > Okay, I think I understand finally. Sorry about the rambling! > > When rtems_interrupt_catch is called, that's installing a "raw" ISR by > modifying the processor specific table itself, so _ISR_Handler is > never called, but the user ISR is. > > When rtems_interrupt_handler_install is called, that's an "RTEMS > interrupt", and we go through the _ISR_Handler -> dispatch route I > laid out earlier, leading to eventually the user's ISR. > > Thank you for letting me rubber-duck with you, everyone (let me know > if anything above sounds off, though!) :P > > On Wed, Aug 1, 2018 at 10:20 PM, Amaan Cheval wrote: >> Thanks for the background! >> >> Let's use the gen5200 as the ongoing example - my confusion arises >> here (correct me if any of the following points is incorrect!). In >> overly simplified call chains: >> >> Register interrupt handler: >> - bsp_interrupt_facility_initialize() -> ppc_exc_set_handler(vec, >> C_dispatch_irq_handler) -> ppc_exc_handler_table[vec] = >> C_dispatch_irq_handler >> >> Interrupt handler called: >> - C_dispatch_irq_handler -> dispatch -> bsp_interrupt_handler_dispatch >> (irq-generic.h) -> bsp_interrupt_handler_table[index].handler() >> >> What I'm confused about is how the bsp_interrupt_handler_table is >> updated at all - I just haven't found the link between how the entries >> in the two tables are synchronized, where the tables are: >> >> 1) the ppc_exc_handler_table (the processor IDT) and >> 2) the bsp_interrupt_handler_table (the RTEMS interrupt table) >> >> >> Another similar chain of confusion for i386 is: >> - rtems_interrupt_catch (intrcatch.c) -> _ISR_Install_vector (isr.h) >> -> _CPU_ISR_install_vector (i386/idt.c) -> idt_entry_tbl[vector] >> updated >> >> But the i386 dispatch code chain is: >> - _ISR_Handler (i386/irq_asm.S) -> BSP_dispatch_isr (i386/irq.c) -> >> bsp_interrupt_handler_dispatch (irq-generic.h) -> >> bsp_interrupt_handler_table[index].handler() >> >> But I don't see any updates to bsp_interrupt_handler_table that would >> let this work. >> - >> >> Would you happen to know what that "missing link" is? >> >> On Wed, Aug 1, 2018 at 9:07 PM, Joel Sherrill wrote: >>> >>> >>> On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom wrote: On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval wrote: > That's definitely very illuminating, thank you so much for all the > details! > > A few more questions that have arisen for me. Feel free to skip over > them (I'll likely figure them out given enough time, so I'm only > asking in case any of them are obvious to anyone): > > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it > stores some of the data onto the stack? > the interrupt frame structure was introduced during 4.11 development. probably i386 never got updated to use a struct to encapsulate the interrupt frame. the interrupt frame should contain the registers that are preserved by the interrupt entry code I believe. >>> >>> >>> +1 >>> >>> Historically, there was no structure to represent the set of >>> registers and information saved on interrupt entry. Over time >>> this has been added. >>> >>> i386 also is missing the SMP synchronization check in the >>> middle of the context which ensures it is safe for a thread to >>> be migrated. >>> > - There used to be defines in cpu.h regarding hardware/software based > interrupt stacks, and how they'd be setup, which were made > superfluous[1] - I'm not quite sure how these are meant to work - I > see references to "stack high" and "stack low" and I'm not quite sure > what the code is referencing when using those. > a hardware interrupt stack is one that the hardware switches to during an interrupt. i think m68k has such. most interrupt stacks in RTEMS are software-managed, meaning that RTEMS explicitly switches the stack region off the task stack and to an interrupt stack region. some stacks start high and grow down, and some stacks start
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
Okay, I think I understand finally. Sorry about the rambling! When rtems_interrupt_catch is called, that's installing a "raw" ISR by modifying the processor specific table itself, so _ISR_Handler is never called, but the user ISR is. When rtems_interrupt_handler_install is called, that's an "RTEMS interrupt", and we go through the _ISR_Handler -> dispatch route I laid out earlier, leading to eventually the user's ISR. Thank you for letting me rubber-duck with you, everyone (let me know if anything above sounds off, though!) :P On Wed, Aug 1, 2018 at 10:20 PM, Amaan Cheval wrote: > Thanks for the background! > > Let's use the gen5200 as the ongoing example - my confusion arises > here (correct me if any of the following points is incorrect!). In > overly simplified call chains: > > Register interrupt handler: > - bsp_interrupt_facility_initialize() -> ppc_exc_set_handler(vec, > C_dispatch_irq_handler) -> ppc_exc_handler_table[vec] = > C_dispatch_irq_handler > > Interrupt handler called: > - C_dispatch_irq_handler -> dispatch -> bsp_interrupt_handler_dispatch > (irq-generic.h) -> bsp_interrupt_handler_table[index].handler() > > What I'm confused about is how the bsp_interrupt_handler_table is > updated at all - I just haven't found the link between how the entries > in the two tables are synchronized, where the tables are: > > 1) the ppc_exc_handler_table (the processor IDT) and > 2) the bsp_interrupt_handler_table (the RTEMS interrupt table) > > > Another similar chain of confusion for i386 is: > - rtems_interrupt_catch (intrcatch.c) -> _ISR_Install_vector (isr.h) > -> _CPU_ISR_install_vector (i386/idt.c) -> idt_entry_tbl[vector] > updated > > But the i386 dispatch code chain is: > - _ISR_Handler (i386/irq_asm.S) -> BSP_dispatch_isr (i386/irq.c) -> > bsp_interrupt_handler_dispatch (irq-generic.h) -> > bsp_interrupt_handler_table[index].handler() > > But I don't see any updates to bsp_interrupt_handler_table that would > let this work. > - > > Would you happen to know what that "missing link" is? > > On Wed, Aug 1, 2018 at 9:07 PM, Joel Sherrill wrote: >> >> >> On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom wrote: >>> >>> On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval >>> wrote: >>> > That's definitely very illuminating, thank you so much for all the >>> > details! >>> > >>> > A few more questions that have arisen for me. Feel free to skip over >>> > them (I'll likely figure them out given enough time, so I'm only >>> > asking in case any of them are obvious to anyone): >>> > >>> > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it >>> > stores some of the data onto the stack? >>> > >>> the interrupt frame structure was introduced during 4.11 development. >>> probably i386 never got updated to use a struct to encapsulate the >>> interrupt frame. the interrupt frame should contain the registers that >>> are preserved by the interrupt entry code I believe. >> >> >> +1 >> >> Historically, there was no structure to represent the set of >> registers and information saved on interrupt entry. Over time >> this has been added. >> >> i386 also is missing the SMP synchronization check in the >> middle of the context which ensures it is safe for a thread to >> be migrated. >> >>> >>> > - There used to be defines in cpu.h regarding hardware/software based >>> > interrupt stacks, and how they'd be setup, which were made >>> > superfluous[1] - I'm not quite sure how these are meant to work - I >>> > see references to "stack high" and "stack low" and I'm not quite sure >>> > what the code is referencing when using those. >>> > >>> >>> a hardware interrupt stack is one that the hardware switches to during >>> an interrupt. i think m68k has such. >>> >>> most interrupt stacks in RTEMS are software-managed, meaning that >>> RTEMS explicitly switches the stack region off the task stack and to >>> an interrupt stack region. >>> >>> some stacks start high and grow down, and some stacks start low and >>> grow up. maybe this is what the "stack high" and "stack low" you >>> mention are in relation to? >> >> >> They are used to denote the top and bottom of the memory reserved >> for the interrupt stack. One important use is in >> cpukit/libmisc/stackchk/check.c >> to report on usage. >> >>> >>> >>> > - c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am doesn't include >>> > irq-sources.am, by the way (this is part of why I used to think a lot >>> > of what your email mentioned was unnecessary, until you...ahem, >>> > pre-empted that line of thought and helped clarify it :P). Should I >>> > add a ticket to update the no_bsp code to be more in line with current >>> > use? >>> > >>> Sure. I don't know that anyone is in particular maintaining >>> no_cpu/no_bsp since we can't compile it, it is basically best effort >>> stuff that sometimes we miss updating. >> >> >> +1 >> >> Also there are variations
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
Thanks for the background! Let's use the gen5200 as the ongoing example - my confusion arises here (correct me if any of the following points is incorrect!). In overly simplified call chains: Register interrupt handler: - bsp_interrupt_facility_initialize() -> ppc_exc_set_handler(vec, C_dispatch_irq_handler) -> ppc_exc_handler_table[vec] = C_dispatch_irq_handler Interrupt handler called: - C_dispatch_irq_handler -> dispatch -> bsp_interrupt_handler_dispatch (irq-generic.h) -> bsp_interrupt_handler_table[index].handler() What I'm confused about is how the bsp_interrupt_handler_table is updated at all - I just haven't found the link between how the entries in the two tables are synchronized, where the tables are: 1) the ppc_exc_handler_table (the processor IDT) and 2) the bsp_interrupt_handler_table (the RTEMS interrupt table) Another similar chain of confusion for i386 is: - rtems_interrupt_catch (intrcatch.c) -> _ISR_Install_vector (isr.h) -> _CPU_ISR_install_vector (i386/idt.c) -> idt_entry_tbl[vector] updated But the i386 dispatch code chain is: - _ISR_Handler (i386/irq_asm.S) -> BSP_dispatch_isr (i386/irq.c) -> bsp_interrupt_handler_dispatch (irq-generic.h) -> bsp_interrupt_handler_table[index].handler() But I don't see any updates to bsp_interrupt_handler_table that would let this work. - Would you happen to know what that "missing link" is? On Wed, Aug 1, 2018 at 9:07 PM, Joel Sherrill wrote: > > > On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom wrote: >> >> On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval >> wrote: >> > That's definitely very illuminating, thank you so much for all the >> > details! >> > >> > A few more questions that have arisen for me. Feel free to skip over >> > them (I'll likely figure them out given enough time, so I'm only >> > asking in case any of them are obvious to anyone): >> > >> > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it >> > stores some of the data onto the stack? >> > >> the interrupt frame structure was introduced during 4.11 development. >> probably i386 never got updated to use a struct to encapsulate the >> interrupt frame. the interrupt frame should contain the registers that >> are preserved by the interrupt entry code I believe. > > > +1 > > Historically, there was no structure to represent the set of > registers and information saved on interrupt entry. Over time > this has been added. > > i386 also is missing the SMP synchronization check in the > middle of the context which ensures it is safe for a thread to > be migrated. > >> >> > - There used to be defines in cpu.h regarding hardware/software based >> > interrupt stacks, and how they'd be setup, which were made >> > superfluous[1] - I'm not quite sure how these are meant to work - I >> > see references to "stack high" and "stack low" and I'm not quite sure >> > what the code is referencing when using those. >> > >> >> a hardware interrupt stack is one that the hardware switches to during >> an interrupt. i think m68k has such. >> >> most interrupt stacks in RTEMS are software-managed, meaning that >> RTEMS explicitly switches the stack region off the task stack and to >> an interrupt stack region. >> >> some stacks start high and grow down, and some stacks start low and >> grow up. maybe this is what the "stack high" and "stack low" you >> mention are in relation to? > > > They are used to denote the top and bottom of the memory reserved > for the interrupt stack. One important use is in > cpukit/libmisc/stackchk/check.c > to report on usage. > >> >> >> > - c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am doesn't include >> > irq-sources.am, by the way (this is part of why I used to think a lot >> > of what your email mentioned was unnecessary, until you...ahem, >> > pre-empted that line of thought and helped clarify it :P). Should I >> > add a ticket to update the no_bsp code to be more in line with current >> > use? >> > >> Sure. I don't know that anyone is in particular maintaining >> no_cpu/no_bsp since we can't compile it, it is basically best effort >> stuff that sometimes we miss updating. > > > +1 > > Also there are variations based on simple vectored and PIC vectored > architectures. > > The architecture is responsible for the managing the minimal actions > based on what the CPU does for an interrupt/exception. Logically > a PIC is part of the BSP even if it comes integrated with the CPU as > is common on x86 and SoCs. The PIC could fairly easily change > and the architecture is harder to change. > >> >> >> > - My understanding of _ISR_Handler is that it'll be the handler for >> > _all_ interrupt vectors by default - it'll then dispatch interrupts to >> > user-handlers (or internal handlers, for the timer, for eg.). Is that >> > right? (I don't quite understand its interaction with the RTEMS >> > interrupt manager yet, but irq-generic's
[PATCH v2] coverage/symbol-sets.ini : Add symbol-sets and paths to respective libraries
--- tester/rtems/testing/coverage/symbol-sets.ini | 48 +-- 1 file changed, 45 insertions(+), 3 deletions(-) diff --git a/tester/rtems/testing/coverage/symbol-sets.ini b/tester/rtems/testing/coverage/symbol-sets.ini index a2ec7bc..aac0b9b 100644 --- a/tester/rtems/testing/coverage/symbol-sets.ini +++ b/tester/rtems/testing/coverage/symbol-sets.ini @@ -29,8 +29,50 @@ # [symbol-sets] -sets = score,rtems +sets = score,rtems,sapi,libdl,posix,libirfs,libdosfs,libdevfs,libimfs,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock [libraries] -score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a -rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a +score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a +rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a +sapi = @BUILD-TARGET@/c/@BSP@/cpukit/sapi/libsapi.a +libdl = @BUILD-TARGET@/c/@BSP@/cpukit/libdl/libdl.a +posix = @BUILD-TARGET@/c/@BSP@/cpukit/posix/libposix.a +libirfs = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/librfs.a +libdosfs = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libdosfs.a +libdevfs = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libdevfs.a +libimfs = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libimfs.a +#libdefaultsfs = @BUiLD-TARGET@/c/@BSP@/cpukit/libfs/libdefaultfs.a +#libjffs2 = @BUILD-TARGET@/c/@BSP@/cpukit/libfs/libjffs2.a +#dtc = @BUILD-TARGET@/c/@BSP@/cpukit/libfdt/libfdt.a +#libdrvmgr = @BUILD-TARGET@/c/@BSP@/cpukit/libdrvmgr/libdrvmgr.a +#libi2c= @BUILD-TARGET@/c/@BSP@/cpukit/libi2c/libi2c.a +libcsupport = @BUILD-TARGET@/c/@BSP@/cpukit/libcsupport/libcsupport.a +libbspcmdline = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libbspcmdline.a +libcpuuse = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libcpuuse.a +libstackchk = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libstackchk.a +libfsmount= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libfsmount.a +libstringto = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libstringto.a +libdevnull= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libdevnull.a +libdumpbuf= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libdumpbuf.a +#libcapture= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libcapture.a +#libdummy = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libdummy.a +#libmonitor= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libmonitor.a +#libmouse = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libmouse.a +#libmw-fb = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libmw-fb.a +#libredirector = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libredirector.a +#librtemsfdt = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/librtemsfdt.a +#libserdbg = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libserdbg.a +#libshell = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libshell.a +#libtestsupport= @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libtestsupport.a +#libuntar = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libuntar.a +#libutf8proc = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libutf8proc.a +#libuuid = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libuuid.a +#libxz = @BUILD-TARGET@/c/@BSP@/cpukit/libmisc/libxz.a +libblock = @BUILD-TARGET@/c/@BSP@/cpukit/libblock/libblock.a +#libpci= @BUILD-TARGET@/c/@BSP@/cpukit/libpci/libpci.a +#librpc= @BUILD-TARGET@/c/@BSP@/cpukit/librpc/librpc.a +#libxdr= @BUILD-TARGET@/c/@BSP@/cpukit/librpc/libxdr.a +#libcrypt = @BUILD-TARGET@/c/@BSP@/cpukit/libcrypt/libcrypt.a +#libmd = @BUILD-TARGET@/c/@BSP@/cpukit/libmd/libmd.a +#libstdthreads = @BUILD-TARGET@/c/@BSP@/cpukit/libstdthreads/libstdthreads.a +#zlib = @BUILD-TARGET@/c/@BSP@/cpukit/zlib/libz.a -- 2.14.4 ___ 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
On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom wrote: > On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval > wrote: > > That's definitely very illuminating, thank you so much for all the > details! > > > > A few more questions that have arisen for me. Feel free to skip over > > them (I'll likely figure them out given enough time, so I'm only > > asking in case any of them are obvious to anyone): > > > > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it > > stores some of the data onto the stack? > > > the interrupt frame structure was introduced during 4.11 development. > probably i386 never got updated to use a struct to encapsulate the > interrupt frame. the interrupt frame should contain the registers that > are preserved by the interrupt entry code I believe. > +1 Historically, there was no structure to represent the set of registers and information saved on interrupt entry. Over time this has been added. i386 also is missing the SMP synchronization check in the middle of the context which ensures it is safe for a thread to be migrated. > > - There used to be defines in cpu.h regarding hardware/software based > > interrupt stacks, and how they'd be setup, which were made > > superfluous[1] - I'm not quite sure how these are meant to work - I > > see references to "stack high" and "stack low" and I'm not quite sure > > what the code is referencing when using those. > > > > a hardware interrupt stack is one that the hardware switches to during > an interrupt. i think m68k has such. > > most interrupt stacks in RTEMS are software-managed, meaning that > RTEMS explicitly switches the stack region off the task stack and to > an interrupt stack region. > > some stacks start high and grow down, and some stacks start low and > grow up. maybe this is what the "stack high" and "stack low" you > mention are in relation to? > They are used to denote the top and bottom of the memory reserved for the interrupt stack. One important use is in cpukit/libmisc/stackchk/check.c to report on usage. > > > - c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am doesn't include > > irq-sources.am, by the way (this is part of why I used to think a lot > > of what your email mentioned was unnecessary, until you...ahem, > > pre-empted that line of thought and helped clarify it :P). Should I > > add a ticket to update the no_bsp code to be more in line with current > > use? > > > Sure. I don't know that anyone is in particular maintaining > no_cpu/no_bsp since we can't compile it, it is basically best effort > stuff that sometimes we miss updating. > +1 Also there are variations based on simple vectored and PIC vectored architectures. The architecture is responsible for the managing the minimal actions based on what the CPU does for an interrupt/exception. Logically a PIC is part of the BSP even if it comes integrated with the CPU as is common on x86 and SoCs. The PIC could fairly easily change and the architecture is harder to change. > > > - My understanding of _ISR_Handler is that it'll be the handler for > > _all_ interrupt vectors by default - it'll then dispatch interrupts to > > user-handlers (or internal handlers, for the timer, for eg.). Is that > > right? (I don't quite understand its interaction with the RTEMS > > interrupt manager yet, but irq-generic's "bsp_interrupt_handler_table" > > seems to be the RTEMS equivalent to the processor-specific vector > > table, and "bsp_interrupt_handler_dispatch" seems to call the actual > > handler within that table as appropriate. Accurate? (I just haven't > > found how that table actually gets its handlers setup besides during > > initialization, since rtems_interrupt_catch just calls > > _CPU_install_vector, which updates the processor vector table, not the > > RTEMS interrupt manager vector table.) > > > > You have discovered a couple of different but related interrupt > processing code bases. I can see why you get confused. > > Basically, a CPU port should support two kinds of interrupts that may > be installed, "RTEMS" and "Raw" interrupts. The "Raw" interrupts are > installed directly in the processor's vector table. For processors > that use simple vectored interrupts, the "RTEMS" interrupts install a > call to the _ISR_Handler() function in the processor's vector table, > and will put the user's isr function pointer in the > _ISR_Vector_table(), which is the RTEMS Interrupt Manager's vector > table. > > I'm not really familiar with the processors that use a different model > for interrupt handling besides simple vectored. Probably, you will > have to study one of them. > > This irq-generic bsp_interrupt_* code is used by the "IRQ Server" that > builds from the CPU port capabilities to allow for some advanced > features like chaining multiple isrs from the same source. I don't > think you want to be focusing on those right now, but I could be > mistaken. I haven't spent much time looking at the IRQ Server > codebase. > For the most part, the
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
On Wed, Aug 1, 2018 at 11:11 AM, Gedare Bloom wrote: > On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval wrote: >> That's definitely very illuminating, thank you so much for all the details! >> >> A few more questions that have arisen for me. Feel free to skip over >> them (I'll likely figure them out given enough time, so I'm only >> asking in case any of them are obvious to anyone): >> >> - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it >> stores some of the data onto the stack? >> > the interrupt frame structure was introduced during 4.11 development. > probably i386 never got updated to use a struct to encapsulate the > interrupt frame. the interrupt frame should contain the registers that > are preserved by the interrupt entry code I believe. > >> - There used to be defines in cpu.h regarding hardware/software based >> interrupt stacks, and how they'd be setup, which were made >> superfluous[1] - I'm not quite sure how these are meant to work - I >> see references to "stack high" and "stack low" and I'm not quite sure >> what the code is referencing when using those. >> > > a hardware interrupt stack is one that the hardware switches to during > an interrupt. i think m68k has such. > > most interrupt stacks in RTEMS are software-managed, meaning that > RTEMS explicitly switches the stack region off the task stack and to > an interrupt stack region. > > some stacks start high and grow down, and some stacks start low and > grow up. maybe this is what the "stack high" and "stack low" you > mention are in relation to? > >> - c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am doesn't include >> irq-sources.am, by the way (this is part of why I used to think a lot >> of what your email mentioned was unnecessary, until you...ahem, >> pre-empted that line of thought and helped clarify it :P). Should I >> add a ticket to update the no_bsp code to be more in line with current >> use? >> > Sure. I don't know that anyone is in particular maintaining > no_cpu/no_bsp since we can't compile it, it is basically best effort > stuff that sometimes we miss updating. > >> - My understanding of _ISR_Handler is that it'll be the handler for >> _all_ interrupt vectors by default - it'll then dispatch interrupts to >> user-handlers (or internal handlers, for the timer, for eg.). Is that >> right? (I don't quite understand its interaction with the RTEMS >> interrupt manager yet, but irq-generic's "bsp_interrupt_handler_table" >> seems to be the RTEMS equivalent to the processor-specific vector >> table, and "bsp_interrupt_handler_dispatch" seems to call the actual >> handler within that table as appropriate. Accurate? (I just haven't >> found how that table actually gets its handlers setup besides during >> initialization, since rtems_interrupt_catch just calls >> _CPU_install_vector, which updates the processor vector table, not the >> RTEMS interrupt manager vector table.) >> > > You have discovered a couple of different but related interrupt > processing code bases. I can see why you get confused. > > Basically, a CPU port should support two kinds of interrupts that may > be installed, "RTEMS" and "Raw" interrupts. The "Raw" interrupts are > installed directly in the processor's vector table. For processors > that use simple vectored interrupts, the "RTEMS" interrupts install a > call to the _ISR_Handler() function in the processor's vector table, > and will put the user's isr function pointer in the > _ISR_Vector_table(), which is the RTEMS Interrupt Manager's vector > table. > > I'm not really familiar with the processors that use a different model > for interrupt handling besides simple vectored. Probably, you will > have to study one of them. > > This irq-generic bsp_interrupt_* code is used by the "IRQ Server" that > builds from the CPU port capabilities to allow for some advanced > features like chaining multiple isrs from the same source. I don't > think you want to be focusing on those right now, but I could be > mistaken. I haven't spent much time looking at the IRQ Server > codebase. > On second thought, it appears that maybe the non-simple vectored processors do use some of this bsp_interrupt stuff. Keep digging. :) > Gedare > >> - My understanding of the interaction between RTEMS' interrupt manager >> (i.e. support for nested interrupts and thread dispatch once an >> interrupt ends) and the BSP's processor-specific interrupt manager >> (code to use the APIC and IDT in my case) is that they're tied >> together through the use of irq-generic.c's "bsp_interrupt_initialize" >> - is that right? (m68k never seems to call it, though, so perhaps >> not?) >> >> Sorry about the rambling! To reiterate, I'll likely figure it out >> given enough time, so if the answers aren't at the top of your head, I >> can figure it out without wasting your time :) >> >> [1] https://devel.rtems.org/ticket/3459#comment:11 >> >> On Wed, Aug 1, 2018 at 3:18 AM, Joel Sherrill wrote: >>> >>> >>> On Tue, Jul 31, 2018 at 3:05 PM,
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
On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval wrote: > That's definitely very illuminating, thank you so much for all the details! > > A few more questions that have arisen for me. Feel free to skip over > them (I'll likely figure them out given enough time, so I'm only > asking in case any of them are obvious to anyone): > > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it > stores some of the data onto the stack? > the interrupt frame structure was introduced during 4.11 development. probably i386 never got updated to use a struct to encapsulate the interrupt frame. the interrupt frame should contain the registers that are preserved by the interrupt entry code I believe. > - There used to be defines in cpu.h regarding hardware/software based > interrupt stacks, and how they'd be setup, which were made > superfluous[1] - I'm not quite sure how these are meant to work - I > see references to "stack high" and "stack low" and I'm not quite sure > what the code is referencing when using those. > a hardware interrupt stack is one that the hardware switches to during an interrupt. i think m68k has such. most interrupt stacks in RTEMS are software-managed, meaning that RTEMS explicitly switches the stack region off the task stack and to an interrupt stack region. some stacks start high and grow down, and some stacks start low and grow up. maybe this is what the "stack high" and "stack low" you mention are in relation to? > - c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am doesn't include > irq-sources.am, by the way (this is part of why I used to think a lot > of what your email mentioned was unnecessary, until you...ahem, > pre-empted that line of thought and helped clarify it :P). Should I > add a ticket to update the no_bsp code to be more in line with current > use? > Sure. I don't know that anyone is in particular maintaining no_cpu/no_bsp since we can't compile it, it is basically best effort stuff that sometimes we miss updating. > - My understanding of _ISR_Handler is that it'll be the handler for > _all_ interrupt vectors by default - it'll then dispatch interrupts to > user-handlers (or internal handlers, for the timer, for eg.). Is that > right? (I don't quite understand its interaction with the RTEMS > interrupt manager yet, but irq-generic's "bsp_interrupt_handler_table" > seems to be the RTEMS equivalent to the processor-specific vector > table, and "bsp_interrupt_handler_dispatch" seems to call the actual > handler within that table as appropriate. Accurate? (I just haven't > found how that table actually gets its handlers setup besides during > initialization, since rtems_interrupt_catch just calls > _CPU_install_vector, which updates the processor vector table, not the > RTEMS interrupt manager vector table.) > You have discovered a couple of different but related interrupt processing code bases. I can see why you get confused. Basically, a CPU port should support two kinds of interrupts that may be installed, "RTEMS" and "Raw" interrupts. The "Raw" interrupts are installed directly in the processor's vector table. For processors that use simple vectored interrupts, the "RTEMS" interrupts install a call to the _ISR_Handler() function in the processor's vector table, and will put the user's isr function pointer in the _ISR_Vector_table(), which is the RTEMS Interrupt Manager's vector table. I'm not really familiar with the processors that use a different model for interrupt handling besides simple vectored. Probably, you will have to study one of them. This irq-generic bsp_interrupt_* code is used by the "IRQ Server" that builds from the CPU port capabilities to allow for some advanced features like chaining multiple isrs from the same source. I don't think you want to be focusing on those right now, but I could be mistaken. I haven't spent much time looking at the IRQ Server codebase. Gedare > - My understanding of the interaction between RTEMS' interrupt manager > (i.e. support for nested interrupts and thread dispatch once an > interrupt ends) and the BSP's processor-specific interrupt manager > (code to use the APIC and IDT in my case) is that they're tied > together through the use of irq-generic.c's "bsp_interrupt_initialize" > - is that right? (m68k never seems to call it, though, so perhaps > not?) > > Sorry about the rambling! To reiterate, I'll likely figure it out > given enough time, so if the answers aren't at the top of your head, I > can figure it out without wasting your time :) > > [1] https://devel.rtems.org/ticket/3459#comment:11 > > On Wed, Aug 1, 2018 at 3:18 AM, Joel Sherrill wrote: >> >> >> On Tue, Jul 31, 2018 at 3:05 PM, Amaan Cheval >> wrote: >>> >>> Hm, I'm not sure what to look for in the other ports specifically, really. >>> The BSP porting documentation doesn't have a section on interrupts, so I'm >>> doing this on more of an "as it comes up" basis. >>> >>> What I've got right now (the interrupt handlers in C) are what I need for >>>
Re: [PATCH 02/12] random: Implement read_random via getentropy.
Is this relied on for IPSec? How secure is it?
On Wed, Aug 1, 2018 at 4:04 AM, Christian Mauderer
wrote:
> ---
> freebsd/sys/sys/random.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/freebsd/sys/sys/random.h b/freebsd/sys/sys/random.h
> index 396ec2b1..996ca5c1 100644
> --- a/freebsd/sys/sys/random.h
> +++ b/freebsd/sys/sys/random.h
> @@ -50,11 +50,21 @@ read_random_uio(void *a __unused, u_int b __unused)
> {
> return (0);
> }
> +#ifndef __rtems__
> static __inline u_int
> read_random(void *a __unused, u_int b __unused)
> {
> return (0);
> }
> +#else /* __rtems__ */
> +#include
> +static __inline u_int
> +read_random(void *ptr, u_int n)
> +{
> + getentropy(ptr, n);
> + return (n);
> +}
> +#endif /* __rtems__ */
> #endif
>
> /*
> --
> 2.13.7
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Initial implemantation commit
On Tue, Jul 31, 2018 at 11:42 PM, Dannie Huang wrote:
> From: Danxue Huang <36866155+dh0...@users.noreply.github.com>
>
> ---
> .gitignore | 2 +
> README.md | 2 +
> gen_rst_from_makedoc.py | 125
>
> rst.py | 104
> strcmp.rst | 47 ++
> 5 files changed, 280 insertions(+)
> create mode 100644 .gitignore
> create mode 100644 README.md
> create mode 100755 gen_rst_from_makedoc.py
> create mode 100644 rst.py
> create mode 100644 strcmp.rst
Don't include the strcmp.rst file.
Does this code have a long-term destination in mind?
>
> diff --git a/.gitignore b/.gitignore
> new file mode 100644
> index 000..9f90354
> --- /dev/null
> +++ b/.gitignore
> @@ -0,0 +1,2 @@
> +.idea/*
> +__pycache__/*
add *.rst maybe
> diff --git a/README.md b/README.md
> new file mode 100644
> index 000..8ebb224
> --- /dev/null
> +++ b/README.md
> @@ -0,0 +1,2 @@
> +# NewlibMarkup2SphinxConvertorPrivate
> +(PRIVATE) This repo contains code for NewlibMarkup2SphinxConvertorPrivate.
> diff --git a/gen_rst_from_makedoc.py b/gen_rst_from_makedoc.py
> new file mode 100755
> index 000..da69c80
> --- /dev/null
> +++ b/gen_rst_from_makedoc.py
> @@ -0,0 +1,125 @@
> +#!/usr/bin/env python
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2018 Danxue Huang (danxue.hu...@gmail.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# 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.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT HOLDER 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.
> +#
> +
> +
> +import argparse
> +import re
> +import rst
> +
> +
> +def is_command(s):
> +"""
> +A command is a single word of at least 3 characters, all uppercase
> +:param s: input string
> +:return: True if s is a single command, otherwise False
> +"""
> +return True if re.match('^[A-Z_]{3,}\s*$', s) else False
> +
I think most of the tools currently use the Python OOP style of
coding. I think this should be made more consistently class-based?
> +
> +def extract_comments(content):
> +"""
> +Extract content inside of /* */
> +:param content: input file content
> +:return: extracted comments
> +"""
> +comments = ''
> +comments_match = re.match('/\*(\*(?!/)|[^*])*\*/', content)
> +if comments_match:
> +wrapped_comments = comments_match.group()
> +comments =
> wrapped_comments.lstrip('/*').rstrip('*/').lstrip().rstrip()
> +return comments
> +
> +
> +def extract_command_and_text(content):
> +"""
> +Extract command and text from input string content
> +:param content: input string containing command and text
> +:return: a tuple containing command and text
> +"""
> +command = ''
> +text = ''
> +command_text_dict = {}
> +for line in content.splitlines():
> +if is_command(line):
> +if command and text:
> +command_text_dict[command] = text
> +command = line.rstrip()
> +text = ''
> +else:
> +text += line + '\n'
> +return command_text_dict
> +
> +
> +def generate_rst(command_text_dict):
> +rst_str = ''
> +for command, text in command_text_dict.items():
> +rst_str += rst.get_command_processor(command)(command, text)
> +return rst_str
> +
> +
> +def get_parser():
> +parser = argparse.ArgumentParser(
> +description='Convert newlib style markup to rst markup'
> +)
> +parser.add_argument(
> +'-s',
> +'--source_file_dir',
> +type=str,
> +help='Source file directory with newlib style comments',
Re: [PATCH] Initial implemantation commit
On Tue, Jul 31, 2018 at 11:50 PM, Dannie Huang wrote:
> Hi,
>
> This is the initial implementation commit of converting newlib markup to
> rst, the example .rst file looks like this photo (see attached photo
> please).
>
Can we see a side-by-side comparison with how newlib's documentation looks?
> Code is pushed on my github:
>
> https://github.com/dh0072/NewlibMarkup2SphinxConverter
>
> Best,
> Dannie
>
> On Tue, Jul 31, 2018 at 10:42 PM, Dannie Huang
> wrote:
>>
>> From: Danxue Huang <36866155+dh0...@users.noreply.github.com>
>>
>> ---
>> .gitignore | 2 +
>> README.md | 2 +
>> gen_rst_from_makedoc.py | 125
>>
>> rst.py | 104
>> strcmp.rst | 47 ++
>> 5 files changed, 280 insertions(+)
>> create mode 100644 .gitignore
>> create mode 100644 README.md
>> create mode 100755 gen_rst_from_makedoc.py
>> create mode 100644 rst.py
>> create mode 100644 strcmp.rst
>>
>> diff --git a/.gitignore b/.gitignore
>> new file mode 100644
>> index 000..9f90354
>> --- /dev/null
>> +++ b/.gitignore
>> @@ -0,0 +1,2 @@
>> +.idea/*
>> +__pycache__/*
>> diff --git a/README.md b/README.md
>> new file mode 100644
>> index 000..8ebb224
>> --- /dev/null
>> +++ b/README.md
>> @@ -0,0 +1,2 @@
>> +# NewlibMarkup2SphinxConvertorPrivate
>> +(PRIVATE) This repo contains code for
>> NewlibMarkup2SphinxConvertorPrivate.
>> diff --git a/gen_rst_from_makedoc.py b/gen_rst_from_makedoc.py
>> new file mode 100755
>> index 000..da69c80
>> --- /dev/null
>> +++ b/gen_rst_from_makedoc.py
>> @@ -0,0 +1,125 @@
>> +#!/usr/bin/env python
>> +#
>> +# RTEMS Tools Project (http://www.rtems.org/)
>> +# Copyright 2018 Danxue Huang (danxue.hu...@gmail.com)
>> +# All rights reserved.
>> +#
>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> +#
>> +# 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.
>> +#
>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS 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 COPYRIGHT HOLDER 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.
>> +#
>> +
>> +
>> +import argparse
>> +import re
>> +import rst
>> +
>> +
>> +def is_command(s):
>> +"""
>> +A command is a single word of at least 3 characters, all uppercase
>> +:param s: input string
>> +:return: True if s is a single command, otherwise False
>> +"""
>> +return True if re.match('^[A-Z_]{3,}\s*$', s) else False
>> +
>> +
>> +def extract_comments(content):
>> +"""
>> +Extract content inside of /* */
>> +:param content: input file content
>> +:return: extracted comments
>> +"""
>> +comments = ''
>> +comments_match = re.match('/\*(\*(?!/)|[^*])*\*/', content)
>> +if comments_match:
>> +wrapped_comments = comments_match.group()
>> +comments =
>> wrapped_comments.lstrip('/*').rstrip('*/').lstrip().rstrip()
>> +return comments
>> +
>> +
>> +def extract_command_and_text(content):
>> +"""
>> +Extract command and text from input string content
>> +:param content: input string containing command and text
>> +:return: a tuple containing command and text
>> +"""
>> +command = ''
>> +text = ''
>> +command_text_dict = {}
>> +for line in content.splitlines():
>> +if is_command(line):
>> +if command and text:
>> +command_text_dict[command] = text
>> +command = line.rstrip()
>> +text = ''
>> +else:
>> +text += line + '\n'
>> +return command_text_dict
>> +
>> +
>> +def generate_rst(command_text_dict):
>> +rst_str = ''
>> +for command, text in command_text_dict.items():
>> +rst_str += rst.get_command_processor(command)(command, text)
>> +
[GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a
That's definitely very illuminating, thank you so much for all the details! A few more questions that have arisen for me. Feel free to skip over them (I'll likely figure them out given enough time, so I'm only asking in case any of them are obvious to anyone): - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it stores some of the data onto the stack? - There used to be defines in cpu.h regarding hardware/software based interrupt stacks, and how they'd be setup, which were made superfluous[1] - I'm not quite sure how these are meant to work - I see references to "stack high" and "stack low" and I'm not quite sure what the code is referencing when using those. - c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am doesn't include irq-sources.am, by the way (this is part of why I used to think a lot of what your email mentioned was unnecessary, until you...ahem, pre-empted that line of thought and helped clarify it :P). Should I add a ticket to update the no_bsp code to be more in line with current use? - My understanding of _ISR_Handler is that it'll be the handler for _all_ interrupt vectors by default - it'll then dispatch interrupts to user-handlers (or internal handlers, for the timer, for eg.). Is that right? (I don't quite understand its interaction with the RTEMS interrupt manager yet, but irq-generic's "bsp_interrupt_handler_table" seems to be the RTEMS equivalent to the processor-specific vector table, and "bsp_interrupt_handler_dispatch" seems to call the actual handler within that table as appropriate. Accurate? (I just haven't found how that table actually gets its handlers setup besides during initialization, since rtems_interrupt_catch just calls _CPU_install_vector, which updates the processor vector table, not the RTEMS interrupt manager vector table.) - My understanding of the interaction between RTEMS' interrupt manager (i.e. support for nested interrupts and thread dispatch once an interrupt ends) and the BSP's processor-specific interrupt manager (code to use the APIC and IDT in my case) is that they're tied together through the use of irq-generic.c's "bsp_interrupt_initialize" - is that right? (m68k never seems to call it, though, so perhaps not?) Sorry about the rambling! To reiterate, I'll likely figure it out given enough time, so if the answers aren't at the top of your head, I can figure it out without wasting your time :) [1] https://devel.rtems.org/ticket/3459#comment:11 On Wed, Aug 1, 2018 at 3:18 AM, Joel Sherrill wrote: > > > On Tue, Jul 31, 2018 at 3:05 PM, Amaan Cheval > wrote: >> >> Hm, I'm not sure what to look for in the other ports specifically, really. >> The BSP porting documentation doesn't have a section on interrupts, so I'm >> doing this on more of an "as it comes up" basis. >> >> What I've got right now (the interrupt handlers in C) are what I need for >> calibrating the APIC timer (through the PIT) - so simply hooking IRQ0 (for >> the timer) and IRQ7 (spurious vector), since those are needed for the timer >> work to continue. >> >> What constitutes as a requirement for basic interrupt support? > > > There used to be a generic porting guide. I can see that this particular > section > has bit rotted some but the interrupt dispatching section. Some of this > will have evolved to support SMP and fine grained locking but the > pseudo-code > here will give you a push toward the right line of thinking: > > https://docs.rtems.org/releases/rtemsdocs-4.10.2/share/rtems/html/porting/porting00034.html > > The idea is that you need to ensure RTEMS knows it is inside an interrupt > and the current locking scheme (old was dispatching, new is ...) is honored. > > The ARM and PowerPC (plus RISCV) are good ports to look at for how SMP > plays into this. But the CPU supplement is thin for their interrupt > processing. > > > This is the CPU Architecture supplement section for the m68k. This is a > relatively simple > architecture to describe. There is also a section for the i386 which reads > similarly. > > https://docs.rtems.org/branches/master/cpu-supplement/m68xxx_and_coldfire.html#interrupt-processing > > Personally, I find the m68k a fairly easy processor to read assembly in. > Look at cpukit/score/cpu/m68k/cpu_asm.S and _ISR_Handler to see what > is done there w/o SMP. On the m68k _ISR_Handler is directly put into the > vector table. But this isn't the most similar example for you. > > For the i386 (better example), it is in bsps/i386/shared/irq/irq_asm.S with > the > same name. There _ISR_Handler is installed via the DISTINCT_INTERRUPT_ENTRY > macros at the bottom of the file where some prologue jumps to the common > _ISR_Handler and then the actions are similar. Usually _ISR_Handler type of > code ends up invoking a PIC decode method in normal C without an > interrupt attribute. > > Long and multi-architecture answer but maybe that makes sense. The goal > in ticker.exe is to take a number of tick interrupts which don't schedule > and > then take one that
[PATCH 04/12] waf: Allow to only generate lex and yacc.
In some applications, it's usefull if the files generated by lex or yacc
are not build automatically. With that it is for example possible to
create a wrapper source file that sets some defines before the generated
code is parsed.
---
builder.py| 12
waf_libbsd.py | 26 ++
2 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/builder.py b/builder.py
index b0d6374e..78f592c7 100755
--- a/builder.py
+++ b/builder.py
@@ -547,15 +547,17 @@ class
RouteKeywordsFragmentComposer(BuildSystemFragmentComposer):
class LexFragmentComposer(BuildSystemFragmentComposer):
-def __init__(self, sym, dep, cflags = None, includes = None):
+def __init__(self, sym, dep, cflags = None, includes = None, build = True):
self.sym = sym
self.dep = dep
self.cflags, self.includes = _cflagsIncludes(cflags, includes)
+self.build = build
def compose(self, path):
d = { 'file': path,
'sym': self.sym,
- 'dep': self.dep }
+ 'dep': self.dep,
+ 'build': self.build }
if None not in self.cflags:
d['cflags'] = self.cflags
if None not in self.includes:
@@ -564,15 +566,17 @@ class LexFragmentComposer(BuildSystemFragmentComposer):
class YaccFragmentComposer(BuildSystemFragmentComposer):
-def __init__(self, sym, header, cflags = None, includes = None):
+def __init__(self, sym, header, cflags = None, includes = None, build =
True):
self.sym = sym
self.header = header
self.cflags, self.includes = _cflagsIncludes(cflags, includes)
+self.build = build
def compose(self, path):
d = { 'file': path,
'sym': self.sym,
- 'header': self.header }
+ 'header': self.header,
+ 'build': self.build }
if None not in self.cflags:
d['cflags'] = self.cflags
if None not in self.includes:
diff --git a/waf_libbsd.py b/waf_libbsd.py
index bbc8b42c..597e882e 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -361,12 +361,13 @@ class Builder(builder.ModuleManager):
bld(target = lex['file'][:-2]+ '.c',
source = lex['file'],
rule = lex_rule)
-bld.objects(target = 'lex_%s' % (lex['sym']),
-features = 'c',
-cflags = cflags,
-includes = lexIncludes + includes,
-defines = defines + lexDefines,
-source = lex['file'][:-2] + '.c')
+if lex['build']:
+bld.objects(target = 'lex_%s' % (lex['sym']),
+features = 'c',
+cflags = cflags,
+includes = lexIncludes + includes,
+defines = defines + lexDefines,
+source = lex['file'][:-2] + '.c')
libbsd_use += ['lex_%s' % (lex['sym'])]
#
@@ -398,12 +399,13 @@ class Builder(builder.ModuleManager):
bld(target = yaccFile[:-2] + '.c',
source = yaccFile,
rule = yacc_rule)
-bld.objects(target = 'yacc_%s' % (yaccSym),
-features = 'c',
-cflags = cflags,
-includes = yaccIncludes + includes,
-defines = defines + yaccDefines,
-source = yaccFile[:-2] + '.c')
+if yacc['build']:
+bld.objects(target = 'yacc_%s' % (yaccSym),
+features = 'c',
+cflags = cflags,
+includes = yaccIncludes + includes,
+defines = defines + yaccDefines,
+source = yaccFile[:-2] + '.c')
libbsd_use += ['yacc_%s' % (yaccSym)]
#
--
2.13.7
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 08/12] ipsec-tools: Apply patches from FreeBSD ports.
Source: https://svnweb.freebsd.org/ports/head/security/ipsec-tools/files/
revision 468617.
---
ipsec-tools/src/libipsec/libpfkey.h | 2 +-
ipsec-tools/src/libipsec/pfkey.c | 33 ---
ipsec-tools/src/racoon/gssapi.c | 5 ++
ipsec-tools/src/racoon/handler.h | 3 +-
ipsec-tools/src/racoon/isakmp.c | 2 +
ipsec-tools/src/racoon/isakmp_cfg.c | 4 ++
ipsec-tools/src/racoon/isakmp_frag.c | 102 +++---
ipsec-tools/src/racoon/isakmp_inf.c | 1 +
ipsec-tools/src/racoon/isakmp_quick.c | 26 +
ipsec-tools/src/racoon/localconf.c| 3 +-
ipsec-tools/src/racoon/nattraversal.c | 5 +-
ipsec-tools/src/racoon/pfkey.c| 6 +-
12 files changed, 141 insertions(+), 51 deletions(-)
diff --git a/ipsec-tools/src/libipsec/libpfkey.h
b/ipsec-tools/src/libipsec/libpfkey.h
index a213aac7..c05285a2 100644
--- a/ipsec-tools/src/libipsec/libpfkey.h
+++ b/ipsec-tools/src/libipsec/libpfkey.h
@@ -85,7 +85,7 @@ struct pfkey_send_sa_args {
u_int32_t seq;
u_int8_tl_natt_type;
u_int16_t l_natt_sport, l_natt_dport;
- struct sockaddr *l_natt_oa;
+ struct sockaddr *l_natt_oai, *l_natt_oar;
u_int16_t l_natt_frag;
u_int8_t ctxdoi, ctxalg;/* Security context DOI and algorithm */
caddr_t ctxstr; /* Security context string */
diff --git a/ipsec-tools/src/libipsec/pfkey.c b/ipsec-tools/src/libipsec/pfkey.c
index 3114229e..554952d7 100644
--- a/ipsec-tools/src/libipsec/pfkey.c
+++ b/ipsec-tools/src/libipsec/pfkey.c
@@ -1335,9 +1335,12 @@ pfkey_send_x1(struct pfkey_send_sa_args *sa_parms)
len += sizeof(struct sadb_x_nat_t_type);
len += sizeof(struct sadb_x_nat_t_port);
len += sizeof(struct sadb_x_nat_t_port);
- if (sa_parms->l_natt_oa)
+ if (sa_parms->l_natt_oai)
len += sizeof(struct sadb_address) +
- PFKEY_ALIGN8(sysdep_sa_len(sa_parms->l_natt_oa));
+ PFKEY_ALIGN8(sysdep_sa_len(sa_parms->l_natt_oai));
+ if (sa_parms->l_natt_oar)
+ len += sizeof(struct sadb_address) +
+ PFKEY_ALIGN8(sysdep_sa_len(sa_parms->l_natt_oar));
#ifdef SADB_X_EXT_NAT_T_FRAG
if (sa_parms->l_natt_frag)
len += sizeof(struct sadb_x_nat_t_frag);
@@ -1452,10 +1455,21 @@ pfkey_send_x1(struct pfkey_send_sa_args *sa_parms)
return -1;
}
- if (sa_parms->l_natt_oa) {
- p = pfkey_setsadbaddr(p, ep, SADB_X_EXT_NAT_T_OA,
- sa_parms->l_natt_oa,
-
(u_int)PFKEY_ALIGN8(sysdep_sa_len(sa_parms->l_natt_oa)),
+ if (sa_parms->l_natt_oai) {
+ p = pfkey_setsadbaddr(p, ep, SADB_X_EXT_NAT_T_OAI,
+ sa_parms->l_natt_oai,
+
(u_int)PFKEY_ALIGN8(sysdep_sa_len(sa_parms->l_natt_oai)),
+ IPSEC_ULPROTO_ANY);
+ if (!p) {
+ free(newmsg);
+ return -1;
+ }
+ }
+
+ if (sa_parms->l_natt_oar) {
+ p = pfkey_setsadbaddr(p, ep, SADB_X_EXT_NAT_T_OAR,
+ sa_parms->l_natt_oar,
+
(u_int)PFKEY_ALIGN8(sysdep_sa_len(sa_parms->l_natt_oar)),
IPSEC_ULPROTO_ANY);
if (!p) {
free(newmsg);
@@ -2034,7 +2048,8 @@ pfkey_align(struct sadb_msg *msg, caddr_t *mhp)
case SADB_X_EXT_NAT_T_TYPE:
case SADB_X_EXT_NAT_T_SPORT:
case SADB_X_EXT_NAT_T_DPORT:
- case SADB_X_EXT_NAT_T_OA:
+ case SADB_X_EXT_NAT_T_OAI:
+ case SADB_X_EXT_NAT_T_OAR:
#endif
#ifdef SADB_X_EXT_TAG
case SADB_X_EXT_TAG:
@@ -2592,7 +2607,7 @@ pfkey_send_update_nat(int so, u_int satype, u_int mode,
struct sockaddr *src,
psaa.l_natt_type = l_natt_type;
psaa.l_natt_sport = l_natt_sport;
psaa.l_natt_dport = l_natt_dport;
- psaa.l_natt_oa = l_natt_oa;
+ psaa.l_natt_oar = l_natt_oa;
psaa.l_natt_frag = l_natt_frag;
return pfkey_send_update2();
@@ -2667,7 +2682,7 @@ pfkey_send_add_nat(int so, u_int satype, u_int mode,
struct sockaddr *src,
psaa.l_natt_type = l_natt_type;
psaa.l_natt_sport = l_natt_sport;
psaa.l_natt_dport = l_natt_dport;
- psaa.l_natt_oa = l_natt_oa;
+ psaa.l_natt_oai = l_natt_oa;
psaa.l_natt_frag = l_natt_frag;
return pfkey_send_add2();
[PATCH 11/12] Add ipsec to rc.conf.
--- libbsd.py | 7 + .../include/machine/rtems-bsd-rc-conf-services.h | 2 + rtemsbsd/include/rtems/ipsec.h | 53 ++ rtemsbsd/rtems/rtems-bsd-racoon.c | 143 ++ rtemsbsd/rtems/rtems-bsd-rc-conf-ipsec.c | 210 + 5 files changed, 415 insertions(+) create mode 100644 rtemsbsd/include/rtems/ipsec.h create mode 100644 rtemsbsd/rtems/rtems-bsd-racoon.c create mode 100644 rtemsbsd/rtems/rtems-bsd-rc-conf-ipsec.c diff --git a/libbsd.py b/libbsd.py index a667923f..d12987ce 100644 --- a/libbsd.py +++ b/libbsd.py @@ -2133,8 +2133,15 @@ class netipsec(builder.Module): 'prsa_par.h', racoon_cflags, build=False))) +self.addRTEMSHeaderFiles( +[ +'rtems/ipsec.h', +] +) self.addRTEMSSourceFiles( [ +'rtems/rtems-bsd-racoon.c', +'rtems/rtems-bsd-rc-conf-ipsec.c', 'rtems/rtems-bsd-shell-racoon.c', 'rtems/rtems-racoon-mutex.c', ], diff --git a/rtemsbsd/include/machine/rtems-bsd-rc-conf-services.h b/rtemsbsd/include/machine/rtems-bsd-rc-conf-services.h index 1d14187a..2797246d 100644 --- a/rtemsbsd/include/machine/rtems-bsd-rc-conf-services.h +++ b/rtemsbsd/include/machine/rtems-bsd-rc-conf-services.h @@ -158,6 +158,8 @@ void rc_conf_net_init(void* arg); /* Installed by default. */ void rc_conf_firewall_pf_init(void* arg); /* pf_enabled="YES" */ void rc_conf_telnetd_init(void* arg); /* telnetd_enabled="YES" */ void rc_conf_ftpd_init(void* arg); /* ftpd_enabled="YES" */ +void rc_conf_ipsec_init(void* arg); /* ipsec_enabled="YES" + and ike_enabled="YES" */ /* * Added services. diff --git a/rtemsbsd/include/rtems/ipsec.h b/rtemsbsd/include/rtems/ipsec.h new file mode 100644 index ..fcb358c7 --- /dev/null +++ b/rtemsbsd/include/rtems/ipsec.h @@ -0,0 +1,53 @@ +/** + * @file + * + * @ingroup rtems_bsd + * + * @brief Functions related to ipsec support in RTEMS. + */ + +/* + * Copyright (c) 2018 embedded brains GmbH. All rights reserved. + * + * embedded brains GmbH + * Dornierstr. 4 + * 82178 Puchheim + * Germany + * + * + * 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. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 AUTHOR 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. + */ + +#ifndef _RTEMS_IPSEC_H_ +#define _RTEMS_IPSEC_H_ + +/** + * @brief Starts the racoon daemon. + * + * @param argc Argument count including a leading "racoon". + * @param argv Program name and parameters. Terminate with NULL. + * @param prio Priority to use for the daemon process. + */ +rtems_status_code rtems_bsd_racoon_daemon(int argc, const char **argv, + rtems_task_priority prio); + +#endif /* _RTEMS_IPSEC_H_ */ diff --git a/rtemsbsd/rtems/rtems-bsd-racoon.c b/rtemsbsd/rtems/rtems-bsd-racoon.c new file mode 100644 index ..c7ea3594 --- /dev/null +++ b/rtemsbsd/rtems/rtems-bsd-racoon.c @@ -0,0 +1,143 @@ +/* + * Copyright (c) 2018 embedded brains GmbH. All rights reserved. + * + * embedded brains GmbH + * Dornierstr. 4 + * 82178 Puchheim + * Germany + * + * + * 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,
[PATCH 10/12] buildset/everything: Add some usefull comments.
--- buildset/everything.ini | 3 +++ 1 file changed, 3 insertions(+) diff --git a/buildset/everything.ini b/buildset/everything.ini index e5593f59..0eee99e7 100644 --- a/buildset/everything.ini +++ b/buildset/everything.ini @@ -8,9 +8,12 @@ name = everything extends = default.ini [modules] +# WiFi dev_usb_wlan = on dev_wlan_rtwn = on net80211 = on user_space_wlanstats = on usr_sbin_wpa_supplicant = on + +# IPSec netipsec = on -- 2.13.7 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 06/12] if_ipsec: Port and add to everything-buildset.
This ports the kernel space parts for ipsec and adds them to the everything-buildset. --- buildset/default.ini | 1 + buildset/everything.ini | 1 + freebsd/sys/net/if_ipsec.c | 4 libbsd.py| 2 ++ rtemsbsd/include/rtems/bsd/local/opt_ipsec.h | 5 + 5 files changed, 13 insertions(+) diff --git a/buildset/default.ini b/buildset/default.ini index a5cbdf9c..881cb048 100644 --- a/buildset/default.ini +++ b/buildset/default.ini @@ -50,6 +50,7 @@ net = on net80211 = off netinet = on netinet6 = on +netipsec = off opencrypto = on pci = on pf = on diff --git a/buildset/everything.ini b/buildset/everything.ini index 0d9cc5fb..e5593f59 100644 --- a/buildset/everything.ini +++ b/buildset/everything.ini @@ -13,3 +13,4 @@ dev_wlan_rtwn = on net80211 = on user_space_wlanstats = on usr_sbin_wpa_supplicant = on +netipsec = on diff --git a/freebsd/sys/net/if_ipsec.c b/freebsd/sys/net/if_ipsec.c index 76eb07d9..13d3f44b 100644 --- a/freebsd/sys/net/if_ipsec.c +++ b/freebsd/sys/net/if_ipsec.c @@ -174,7 +174,11 @@ ipsec_clone_create(struct if_clone *ifc, int unit, caddr_t params) struct ifnet *ifp; sc = malloc(sizeof(*sc), M_IPSEC, M_WAITOK | M_ZERO); +#ifndef __rtems__ sc->fibnum = curthread->td_proc->p_fibnum; +#else /* __rtems__ */ + sc->fibnum = BSD_DEFAULT_FIB; +#endif /* __rtems__ */ sc->ifp = ifp = if_alloc(IFT_TUNNEL); IPSEC_LOCK_INIT(sc); ifp->if_softc = sc; diff --git a/libbsd.py b/libbsd.py index 05e9dd51..b15779bb 100644 --- a/libbsd.py +++ b/libbsd.py @@ -1988,6 +1988,7 @@ class netipsec(builder.Module): mm = self.manager self.addKernelSpaceHeaderFiles( [ +'sys/net/if_ipsec.h', 'sys/netipsec/ah.h', 'sys/netipsec/ah_var.h', 'sys/netipsec/esp.h', @@ -2007,6 +2008,7 @@ class netipsec(builder.Module): ) self.addKernelSpaceSourceFiles( [ +'sys/net/if_ipsec.c', 'sys/netipsec/ipsec.c', 'sys/netipsec/ipsec_input.c', 'sys/netipsec/ipsec_mbuf.c', diff --git a/rtemsbsd/include/rtems/bsd/local/opt_ipsec.h b/rtemsbsd/include/rtems/bsd/local/opt_ipsec.h index e69de29b..ff8e715b 100644 --- a/rtemsbsd/include/rtems/bsd/local/opt_ipsec.h +++ b/rtemsbsd/include/rtems/bsd/local/opt_ipsec.h @@ -0,0 +1,5 @@ +#include +#ifdef RTEMS_BSD_MODULE_NETIPSEC + #define IPSEC 1 + #define TCP_SIGNATURE 1 +#endif -- 2.13.7 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 05/12] if_ipsec: Import from FreeBSD.
---
freebsd/sys/net/if_ipsec.c | 1004
freebsd/sys/net/if_ipsec.h | 39 ++
2 files changed, 1043 insertions(+)
create mode 100644 freebsd/sys/net/if_ipsec.c
create mode 100644 freebsd/sys/net/if_ipsec.h
diff --git a/freebsd/sys/net/if_ipsec.c b/freebsd/sys/net/if_ipsec.c
new file mode 100644
index ..76eb07d9
--- /dev/null
+++ b/freebsd/sys/net/if_ipsec.c
@@ -0,0 +1,1004 @@
+#include
+
+/*-
+ * Copyright (c) 2016 Yandex LLC
+ * Copyright (c) 2016 Andrey V. Elsukov
+ * 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.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 AUTHOR 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.
+ */
+
+#include
+__FBSDID("$FreeBSD$");
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#ifdef INET6
+#include
+#endif
+
+#include
+#include
+
+#include
+
+static MALLOC_DEFINE(M_IPSEC, "ipsec", "IPsec Virtual Tunnel Interface");
+static const char ipsecname[] = "ipsec";
+
+#if defined(INET) && defined(INET6)
+#defineIPSEC_SPCOUNT 4
+#else
+#defineIPSEC_SPCOUNT 2
+#endif
+
+struct ipsec_softc {
+ struct ifnet*ifp;
+
+ struct rmlock lock;
+ struct secpolicy*sp[IPSEC_SPCOUNT];
+
+ uint32_treqid;
+ u_int family;
+ u_int fibnum;
+ LIST_ENTRY(ipsec_softc) chain;
+ LIST_ENTRY(ipsec_softc) hash;
+};
+
+#defineIPSEC_LOCK_INIT(sc) rm_init(&(sc)->lock, "if_ipsec softc")
+#defineIPSEC_LOCK_DESTROY(sc) rm_destroy(&(sc)->lock)
+#defineIPSEC_RLOCK_TRACKER struct rm_priotracker ipsec_tracker
+#defineIPSEC_RLOCK(sc) rm_rlock(&(sc)->lock, _tracker)
+#defineIPSEC_RUNLOCK(sc) rm_runlock(&(sc)->lock, _tracker)
+#defineIPSEC_RLOCK_ASSERT(sc) rm_assert(&(sc)->lock, RA_RLOCKED)
+#defineIPSEC_WLOCK(sc) rm_wlock(&(sc)->lock)
+#defineIPSEC_WUNLOCK(sc) rm_wunlock(&(sc)->lock)
+#defineIPSEC_WLOCK_ASSERT(sc) rm_assert(&(sc)->lock, RA_WLOCKED)
+
+static struct rmlock ipsec_sc_lock;
+RM_SYSINIT(ipsec_sc_lock, _sc_lock, "if_ipsec softc list");
+
+#defineIPSEC_SC_RLOCK_TRACKER struct rm_priotracker ipsec_sc_tracker
+#defineIPSEC_SC_RLOCK()rm_rlock(_sc_lock,
_sc_tracker)
+#defineIPSEC_SC_RUNLOCK() rm_runlock(_sc_lock,
_sc_tracker)
+#defineIPSEC_SC_RLOCK_ASSERT() rm_assert(_sc_lock, RA_RLOCKED)
+#defineIPSEC_SC_WLOCK()rm_wlock(_sc_lock)
+#defineIPSEC_SC_WUNLOCK() rm_wunlock(_sc_lock)
+#defineIPSEC_SC_WLOCK_ASSERT() rm_assert(_sc_lock, RA_WLOCKED)
+
+LIST_HEAD(ipsec_iflist, ipsec_softc);
+static VNET_DEFINE(struct ipsec_iflist, ipsec_sc_list);
+static VNET_DEFINE(struct ipsec_iflist *, ipsec_sc_htbl);
+static VNET_DEFINE(u_long, ipsec_sc_hmask);
+#defineV_ipsec_sc_list VNET(ipsec_sc_list)
+#defineV_ipsec_sc_htbl VNET(ipsec_sc_htbl)
+#defineV_ipsec_sc_hmaskVNET(ipsec_sc_hmask)
+
+static uint32_t
+ipsec_hash(uint32_t id)
+{
+
+ return (fnv_32_buf(, sizeof(id), FNV1_32_INIT));
+}
+
+#defineSCHASH_NHASH_LOG2 5
+#defineSCHASH_NHASH(1 << SCHASH_NHASH_LOG2)
+#defineSCHASH_HASHVAL(id) (ipsec_hash((id)) & V_ipsec_sc_hmask)
+#defineSCHASH_HASH(id) _ipsec_sc_htbl[SCHASH_HASHVAL(id)]
+
+/*
+ * ipsec_ioctl_sx protects from concurrent ioctls.
+ */
[PATCH 00/12] Add ipsec to libbsd.
Hello, this patch set adds IPSec functionality to libbsds everything build set. The first four patches prepare some necessary functionality. Patch 5 and 6 add the if_ipsec driver. 7 to 9 import ipsec-tools from the FreeBSD ports. 10 is just some readability improvement for the build set. 11 adds rc.conf support for ipsec and 12 adds information on how to use ipsec in libbsd. Best regards Christian Mauderer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 03/12] userspace-header-gen: Special case for Yacc / Lex.
Some variables generated by Yacc / Lex need a special treatment. That
had been done by manual editing of the generated headers in the past.
This patch integrate these changes into the generator.
---
userspace-header-gen.py | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/userspace-header-gen.py b/userspace-header-gen.py
index cd50c1ef..f41feb4a 100755
--- a/userspace-header-gen.py
+++ b/userspace-header-gen.py
@@ -81,6 +81,25 @@ class HeaderGenCU:
self._rtems_port_names.append("_Linker_set_bsd_prog_%s_end" % progname)
self._rtems_port_names.append("rtems_bsd_command_%s" % progname)
+self._filter_special_vars = []
+# Take some special care for some yacc variables. This matches the
yyval
+# and yylval. These two always make trouble in the generated headers.
+# yyval is initialized by Yacc generated code so it's not
+# necessary to move them into the copy back region. yylval is used only
+# for transporting a value. It will be set when used.
+self._filter_special_vars.append({
+"re":re.compile('extern YYSTYPE .*val'),
+"reason":"Lex / Yacc variable initialized by generated code",
+"action":"no_section"
+})
+# Lex generates an external variable that shouldn't be extern. Move it
+# to the current data header file.
+self._filter_special_vars.append({
+"re":re.compile('extern yy_size_t .*len'),
+"reason":"Lex adds an extern to this variable that is not
necessary.",
+"action":"ignore_extern"
+})
+
self._err = err
self._verbose = verbose
self._cu = cu
@@ -381,6 +400,17 @@ class HeaderGenCU:
var_with_type = "extern " + var_with_type
outfile = glob_data_out
+for flt in self._filter_special_vars:
+if flt["re"].match(var_with_type) is not None:
+if flt["action"] == "no_section":
+self._err.write('Don\'t put "%s" into section.
Reason: %s.\n' % \
+(var_with_type, flt["reason"]))
+outfile = None
+if flt["action"] == "ignore_extern":
+self._err.write('Ignore extern of variable "%s".
Reason: %s.\n' % \
+(var_with_type, flt["reason"]))
+outfile = data_out
+
# write output
if self._verbose >= VERBOSE_SOME:
if not is_function:
@@ -389,7 +419,7 @@ class HeaderGenCU:
else:
self._err.write('Found a function "%s" at %s (DIE offset
%s); extern: %r\n' % \
(varname, var_decl, child.offset,
is_extern))
-if not is_function:
+if (not is_function) and (outfile is not None):
outfile.write("RTEMS_LINKER_RWSET_CONTENT(bsd_prog_%s, %s);\n"
% \
(self._progname, var_with_type))
if is_extern:
--
2.13.7
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 02/12] random: Implement read_random via getentropy.
---
freebsd/sys/sys/random.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/freebsd/sys/sys/random.h b/freebsd/sys/sys/random.h
index 396ec2b1..996ca5c1 100644
--- a/freebsd/sys/sys/random.h
+++ b/freebsd/sys/sys/random.h
@@ -50,11 +50,21 @@ read_random_uio(void *a __unused, u_int b __unused)
{
return (0);
}
+#ifndef __rtems__
static __inline u_int
read_random(void *a __unused, u_int b __unused)
{
return (0);
}
+#else /* __rtems__ */
+#include
+static __inline u_int
+read_random(void *ptr, u_int n)
+{
+ getentropy(ptr, n);
+ return (n);
+}
+#endif /* __rtems__ */
#endif
/*
--
2.13.7
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 01/12] crypto/sha2: Remove left over file.
This file seems to be imported from a long gone version.
---
freebsd/sys/crypto/sha2/sha2.h | 141 -
1 file changed, 141 deletions(-)
delete mode 100644 freebsd/sys/crypto/sha2/sha2.h
diff --git a/freebsd/sys/crypto/sha2/sha2.h b/freebsd/sys/crypto/sha2/sha2.h
deleted file mode 100644
index 12da95c9..
--- a/freebsd/sys/crypto/sha2/sha2.h
+++ /dev/null
@@ -1,141 +0,0 @@
-/* $FreeBSD$ */
-/* $KAME: sha2.h,v 1.3 2001/03/12 08:27:48 itojun Exp $*/
-
-/*
- * sha2.h
- *
- * Version 1.0.0beta1
- *
- * Written by Aaron D. Gifford
- *
- * Copyright 2000 Aaron D. Gifford. 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 copyright holder nor the names of contributors
- *may be used to endorse or promote products derived from this software
- *without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) AND CONTRIBUTOR(S) ``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 AUTHOR(S) OR CONTRIBUTOR(S) 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.
- *
- */
-
-#ifndef __SHA2_H__
-#define __SHA2_H__
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-
-/*** SHA-256/384/512 Various Length Definitions ***/
-#define SHA256_BLOCK_LENGTH64
-#define SHA256_DIGEST_LENGTH 32
-#define SHA256_DIGEST_STRING_LENGTH(SHA256_DIGEST_LENGTH * 2 + 1)
-#define SHA384_BLOCK_LENGTH128
-#define SHA384_DIGEST_LENGTH 48
-#define SHA384_DIGEST_STRING_LENGTH(SHA384_DIGEST_LENGTH * 2 + 1)
-#define SHA512_BLOCK_LENGTH128
-#define SHA512_DIGEST_LENGTH 64
-#define SHA512_DIGEST_STRING_LENGTH(SHA512_DIGEST_LENGTH * 2 + 1)
-
-
-/*** SHA-256/384/512 Context Structures ***/
-/* NOTE: If your architecture does not define either u_intXX_t types or
- * uintXX_t (from inttypes.h), you may need to define things by hand
- * for your system:
- */
-#if 0
-typedef unsigned char u_int8_t;/* 1-byte (8-bits) */
-typedef unsigned int u_int32_t;/* 4-bytes (32-bits) */
-typedef unsigned long long u_int64_t; /* 8-bytes (64-bits) */
-#endif
-/*
- * Most BSD systems already define u_intXX_t types, as does Linux.
- * Some systems, however, like Compaq's Tru64 Unix instead can use
- * uintXX_t types defined by very recent ANSI C standards and included
- * in the file:
- *
- * #include
- *
- * If you choose to use then please define:
- *
- * #define SHA2_USE_INTTYPES_H
- *
- * Or on the command line during compile:
- *
- * cc -DSHA2_USE_INTTYPES_H ...
- */
-#if 0 /*def SHA2_USE_INTTYPES_H*/
-
-typedef struct _SHA256_CTX {
- uint32_tstate[8];
- uint64_tbitcount;
- uint8_t buffer[SHA256_BLOCK_LENGTH];
-} SHA256_CTX;
-typedef struct _SHA512_CTX {
- uint64_tstate[8];
- uint64_tbitcount[2];
- uint8_t buffer[SHA512_BLOCK_LENGTH];
-} SHA512_CTX;
-
-#else /* SHA2_USE_INTTYPES_H */
-
-typedef struct _SHA256_CTX {
- u_int32_t state[8];
- u_int64_t bitcount;
- u_int8_tbuffer[SHA256_BLOCK_LENGTH];
-} SHA256_CTX;
-typedef struct _SHA512_CTX {
- u_int64_t state[8];
- u_int64_t bitcount[2];
- u_int8_tbuffer[SHA512_BLOCK_LENGTH];
-} SHA512_CTX;
-
-#endif /* SHA2_USE_INTTYPES_H */
-
-typedef SHA512_CTX SHA384_CTX;
-
-
-/*** SHA-256/384/512 Function Prototypes **/
-
-void SHA256_Init(SHA256_CTX *);
-void SHA256_Update(SHA256_CTX*, const u_int8_t*, size_t);
-void SHA256_Final(u_int8_t[SHA256_DIGEST_LENGTH], SHA256_CTX*);
-char* SHA256_End(SHA256_CTX*, char[SHA256_DIGEST_STRING_LENGTH]);
-char* SHA256_Data(const u_int8_t*, size_t, char[SHA256_DIGEST_STRING_LENGTH]);
-
-void SHA384_Init(SHA384_CTX*);
-void SHA384_Update(SHA384_CTX*, const u_int8_t*,
Re: dl06 - tms570 variant failures
On 01/08/2018 15:26, Sebastian Huber wrote: > On 31/07/18 21:17, Joel Sherrill wrote: >> Hi >> >> The build of all BSPs looks a lot better thanks to the patch >> Sebastian pushed. Only the tms570 variants fail to build. >> They end with this: >> >> error: mv -f spqreslib/.deps/spqreslib-init.Tpo >> spqreslib/.deps/spqreslib-init.Po >> elf:check_file: >> /data/home/joel/rtems-work/tools/5/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/lib/libc.a:lib_a-_Exit.o@23794: >> Mixed data types not allowed (LSB/MSB). >> gmake[5]: *** [dl06.rap] Error 10 > > Is this a new error? > #3401 Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
