Re: RTEMS 5 has branch
Hello Chris, thanks a lot for all your hard and tedious work to prepare the RTEMS 5 release. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS 5 RC1 Available
Hello, RTEMS 5 RC1 is available for testing. You can find the release at: https://ftp.rtems.org/pub/rtems/releases/5/rc/5.1.0-rc1 Please report your successes or problems here. You can also raise a ticket if you prefer. Please select the 5.1 milestone. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS 5 has branch
Hello, The RTEMS release repos have been branched for RTEMS 5. I am preparing RC1 now and I hope it will be available shortly. I will provide a separate announcement for it. The 5.1.0-rc1 release candidate will be very close to the 5.0.0-m2006-2 snapshot. The RC2 candidate will have a cleaned RSB (see #4014). All release branch pushes need a ticket. The master is now open for RTEMS 6 changes. The main focus of RTEMS 6 is a build system change for rtems.git. If you have other items you think should be part of 6 please add them to the releases page in the Trac Wiki [1]. My hope is the turn around for RTEMS 6 is not too long. If a patch is pushed to any of the release repos that changes a version number there needs to be a patch for the engineering manual that documents the change. I would like to collection all the changes that need to be made post branching. I am currently working on updating the release procedure section to provide a suitable location for these additions. Major changes in RTEMS 6 and beyond will need to make sure the release process is updated and working. If your changes effect the release process it needs to be flagged and the release process updated at the time of the merge. Thanks Chris [1] https://devel.rtems.org/wiki/Release/6 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH] posix: Only check shm_unlink obj_err if necessary
Hey Gedare, Setting obj_err to 0 would get the desired outcome, but the logic as it exists now is faulty. Setting obj_err to a value that can't be produced by _POSIX_Shm_Get_by_name would be a better option, but it would still be checking an error value after successful execution. _POSIX_Shm_Get_by_name relies on _Objects_Get_by_name internally which states about obj_err: The error indication in case of failure. If _POSIX_Shm_Get_by_name returns OBJECTS_GET_BY_NAME_NO_OBJECT (which it can), the current logic treats that as a success and operates on a NULL pointer. -Original Message- From: Gedare Bloom Sent: Thursday, June 25, 2020 16:49 To: Kinsey Moore Cc: devel@rtems.org Subject: Re: [PATCH] posix: Only check shm_unlink obj_err if necessary Hi Kinsey, I missed seeing this. Two quick questions for you. 1. does it also work to initialize obj_err to 0? that would be simpler code. 2. I see the error handling logic changes slightly, with OBJECTS_GET_BY_NAME_NO_OBJECT now returning ENOENT. I guess if it works to init obj_err to 0, this case should be merged back to the OBJECTS_GET_BY_NAME_INVALID_NAME case? On Thu, Jun 25, 2020 at 2:21 PM Kinsey Moore wrote: > > Is there anything stopping this from being merged? I just ran into this bug > again on the current project I'm working on. > > Kinsey > > -Original Message- > From: Kinsey Moore > Sent: Tuesday, January 28, 2020 12:37 > To: devel@rtems.org > Cc: Kinsey Moore > Subject: [PATCH] posix: Only check shm_unlink obj_err if necessary > > In the nominal case checked by spsysinit01, obj_err is unmodified if > _POSIX_Shm_Get_by_name returns non-NULL. In the case of shm_unlink, this > means an uninitialized value is passed into the switch and it appears this > test was passing by virtue of the stack having the right value on it in most > cases. This now checks obj_err only if _POSIX_Shm_Get_by_name returns NULL. > --- > cpukit/posix/src/shmunlink.c | 45 > ++-- > 1 file changed, 23 insertions(+), 22 deletions(-) > > diff --git a/cpukit/posix/src/shmunlink.c > b/cpukit/posix/src/shmunlink.c index 00d743ac80..39c2ba0d87 100644 > --- a/cpukit/posix/src/shmunlink.c > +++ b/cpukit/posix/src/shmunlink.c > @@ -29,28 +29,29 @@ int shm_unlink( const char *name ) >_Objects_Allocator_lock(); > >shm = _POSIX_Shm_Get_by_name( name, 0, &obj_err ); > - switch ( obj_err ) { > -case OBJECTS_GET_BY_NAME_INVALID_NAME: > - err = ENOENT; > - break; > - > -case OBJECTS_GET_BY_NAME_NAME_TOO_LONG: > - err = ENAMETOOLONG; > - break; > - > -case OBJECTS_GET_BY_NAME_NO_OBJECT: > -default: > - _Objects_Namespace_remove_string( > -&_POSIX_Shm_Information, > -&shm->Object > - ); > - > - if ( shm->reference_count == 0 ) { > -/* Only remove the shm object if no references exist to it. > Otherwise, > - * the shm object will be freed later in _POSIX_Shm_Attempt_delete */ > -_POSIX_Shm_Free( shm ); > - } > - break; > + if ( shm ) { > +_Objects_Namespace_remove_string( > + &_POSIX_Shm_Information, > + &shm->Object > +); > + > +if ( shm->reference_count == 0 ) { > + /* Only remove the shm object if no references exist to it. Otherwise, > + * the shm object will be freed later in _POSIX_Shm_Attempt_delete */ > + _POSIX_Shm_Free( shm ); > +} > + } else { > +switch ( obj_err ) { > + case OBJECTS_GET_BY_NAME_NAME_TOO_LONG: > +err = ENAMETOOLONG; > +break; > + > + case OBJECTS_GET_BY_NAME_INVALID_NAME: > + case OBJECTS_GET_BY_NAME_NO_OBJECT: > + default: > +err = ENOENT; > +break; > +} >} > >_Objects_Allocator_unlock(); > -- > 2.20.1 > > ___ > 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] posix: Only check shm_unlink obj_err if necessary
Hi Kinsey, I missed seeing this. Two quick questions for you. 1. does it also work to initialize obj_err to 0? that would be simpler code. 2. I see the error handling logic changes slightly, with OBJECTS_GET_BY_NAME_NO_OBJECT now returning ENOENT. I guess if it works to init obj_err to 0, this case should be merged back to the OBJECTS_GET_BY_NAME_INVALID_NAME case? On Thu, Jun 25, 2020 at 2:21 PM Kinsey Moore wrote: > > Is there anything stopping this from being merged? I just ran into this bug > again on the current project I'm working on. > > Kinsey > > -Original Message- > From: Kinsey Moore > Sent: Tuesday, January 28, 2020 12:37 > To: devel@rtems.org > Cc: Kinsey Moore > Subject: [PATCH] posix: Only check shm_unlink obj_err if necessary > > In the nominal case checked by spsysinit01, obj_err is unmodified if > _POSIX_Shm_Get_by_name returns non-NULL. In the case of shm_unlink, this > means an uninitialized value is passed into the switch and it appears this > test was passing by virtue of the stack having the right value on it in most > cases. This now checks obj_err only if _POSIX_Shm_Get_by_name returns NULL. > --- > cpukit/posix/src/shmunlink.c | 45 ++-- > 1 file changed, 23 insertions(+), 22 deletions(-) > > diff --git a/cpukit/posix/src/shmunlink.c b/cpukit/posix/src/shmunlink.c > index 00d743ac80..39c2ba0d87 100644 > --- a/cpukit/posix/src/shmunlink.c > +++ b/cpukit/posix/src/shmunlink.c > @@ -29,28 +29,29 @@ int shm_unlink( const char *name ) >_Objects_Allocator_lock(); > >shm = _POSIX_Shm_Get_by_name( name, 0, &obj_err ); > - switch ( obj_err ) { > -case OBJECTS_GET_BY_NAME_INVALID_NAME: > - err = ENOENT; > - break; > - > -case OBJECTS_GET_BY_NAME_NAME_TOO_LONG: > - err = ENAMETOOLONG; > - break; > - > -case OBJECTS_GET_BY_NAME_NO_OBJECT: > -default: > - _Objects_Namespace_remove_string( > -&_POSIX_Shm_Information, > -&shm->Object > - ); > - > - if ( shm->reference_count == 0 ) { > -/* Only remove the shm object if no references exist to it. > Otherwise, > - * the shm object will be freed later in _POSIX_Shm_Attempt_delete */ > -_POSIX_Shm_Free( shm ); > - } > - break; > + if ( shm ) { > +_Objects_Namespace_remove_string( > + &_POSIX_Shm_Information, > + &shm->Object > +); > + > +if ( shm->reference_count == 0 ) { > + /* Only remove the shm object if no references exist to it. Otherwise, > + * the shm object will be freed later in _POSIX_Shm_Attempt_delete */ > + _POSIX_Shm_Free( shm ); > +} > + } else { > +switch ( obj_err ) { > + case OBJECTS_GET_BY_NAME_NAME_TOO_LONG: > +err = ENAMETOOLONG; > +break; > + > + case OBJECTS_GET_BY_NAME_INVALID_NAME: > + case OBJECTS_GET_BY_NAME_NO_OBJECT: > + default: > +err = ENOENT; > +break; > +} >} > >_Objects_Allocator_unlock(); > -- > 2.20.1 > > ___ > 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] posix: Only check shm_unlink obj_err if necessary
Is there anything stopping this from being merged? I just ran into this bug again on the current project I'm working on. Kinsey -Original Message- From: Kinsey Moore Sent: Tuesday, January 28, 2020 12:37 To: devel@rtems.org Cc: Kinsey Moore Subject: [PATCH] posix: Only check shm_unlink obj_err if necessary In the nominal case checked by spsysinit01, obj_err is unmodified if _POSIX_Shm_Get_by_name returns non-NULL. In the case of shm_unlink, this means an uninitialized value is passed into the switch and it appears this test was passing by virtue of the stack having the right value on it in most cases. This now checks obj_err only if _POSIX_Shm_Get_by_name returns NULL. --- cpukit/posix/src/shmunlink.c | 45 ++-- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/cpukit/posix/src/shmunlink.c b/cpukit/posix/src/shmunlink.c index 00d743ac80..39c2ba0d87 100644 --- a/cpukit/posix/src/shmunlink.c +++ b/cpukit/posix/src/shmunlink.c @@ -29,28 +29,29 @@ int shm_unlink( const char *name ) _Objects_Allocator_lock(); shm = _POSIX_Shm_Get_by_name( name, 0, &obj_err ); - switch ( obj_err ) { -case OBJECTS_GET_BY_NAME_INVALID_NAME: - err = ENOENT; - break; - -case OBJECTS_GET_BY_NAME_NAME_TOO_LONG: - err = ENAMETOOLONG; - break; - -case OBJECTS_GET_BY_NAME_NO_OBJECT: -default: - _Objects_Namespace_remove_string( -&_POSIX_Shm_Information, -&shm->Object - ); - - if ( shm->reference_count == 0 ) { -/* Only remove the shm object if no references exist to it. Otherwise, - * the shm object will be freed later in _POSIX_Shm_Attempt_delete */ -_POSIX_Shm_Free( shm ); - } - break; + if ( shm ) { +_Objects_Namespace_remove_string( + &_POSIX_Shm_Information, + &shm->Object +); + +if ( shm->reference_count == 0 ) { + /* Only remove the shm object if no references exist to it. Otherwise, + * the shm object will be freed later in _POSIX_Shm_Attempt_delete */ + _POSIX_Shm_Free( shm ); +} + } else { +switch ( obj_err ) { + case OBJECTS_GET_BY_NAME_NAME_TOO_LONG: +err = ENAMETOOLONG; +break; + + case OBJECTS_GET_BY_NAME_INVALID_NAME: + case OBJECTS_GET_BY_NAME_NO_OBJECT: + default: +err = ENOENT; +break; +} } _Objects_Allocator_unlock(); -- 2.20.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Command line for Qemu and libbsd for pc386
On 2020-06-24 19:22, Joel Sherrill wrote: Hi Does someone have a qemu command line handy for running libbsd network applications on Qemu? I have lots of notes and old examples but can't seem to trip the right combination today. Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel To boot epics I was setting up DHCP, ntp and nfs on my development host, run this script: [h1@earth utilities (master *+)]$ more setUpNetworkForQemu.py ## @brief This Python file uses the following encoding: utf-8 # Documentation for this module. # # More details. ## Documentation for a function. # import netifaces import subprocess import dns.resolver import subprocess from string import Template brNet = '10.1.0.0' brNetMask = '255.255.255.0' brLeaseRange = '10.1.0.100 10.1.0.120' br0Ip = '10.1.0.1' ethNet = '10.0.0.0' ethNetMask = '255.255.255.0' ethLeaseRange = '10.0.0.100 10.0.0.120' eth0Ip = '10.0.0.1' def setupAndStartDhcpd(): dhcpdConfStr = ('\n' + 'default-lease-time 600;\n' + 'max-lease-time 7200;\n' + 'option ntp-servers $ntpIp;\n' + 'option rtems-cmdline code 129=string;\n' + 'option rtems-cmdline "Ich DIch doch auch";\n' + 'filename "RtemsForever";\n' + 'option domain-name "rtems";\n' + '\n' + 'subnet ' + brNet + ' netmask ' + brNetMask + ' {\n' + 'range ' + brLeaseRange + ';\n' + 'option routers ' + br0Ip + ';\n' + 'option domain-name-servers $dnsIp;\n' + '}\n' + 'subnet ' + ethNet + ' netmask ' + ethNetMask + ' {\n' + 'range ' + ethLeaseRange + ';\n' + 'option routers ' + eth0Ip + ';\n' + 'option domain-name-servers $dnsIp;\n' + '}\n' ) # stop dhcp-server subprocess.run(['/bin/systemctl', 'stop', 'isc-dhcp-server.service']) dnsResolver = dns.resolver.Resolver() print("will setup dhcpd with dhcp-server at : ", dnsResolver.nameservers[0]) s = Template(dhcpdConfStr) txtToFile = s.substitute(dnsIp = dnsResolver.nameservers[0], ntpIp = '10.1.0.1') with open('/etc/dhcp/dhcpd.conf', 'w') as f: print(txtToFile, file=f) f.close() s = 'INTERFACESv4="br0"' with open('/etc/default/isc-dhcp-server', 'w') as f: print(s, file=f) f.close() # start dhcp-server subprocess.run(['/bin/systemctl', 'start', 'isc-dhcp-server.service']) def main(): print("\nWill setup qemu network\n") #setup a bridge subprocess.run(['/sbin/brctl', 'addbr', 'br0']) subprocess.run(['/sbin/ifconfig', 'br0', br0Ip, 'netmask', brNetMask, 'up']) subprocess.run(['/usr/bin/tunctl', '-t', 'tap0']) subprocess.run(['/usr/bin/tunctl', '-t', 'tap1']) subprocess.run(['/sbin/brctl', 'addif', 'br0', 'tap0', 'tap1']) subprocess.run(['/sbin/ifconfig', 'tap0']) subprocess.run(['/sbin/ifconfig', 'tap1']) # check for default gateway and interface used gws = netifaces.gateways() defaultGw = gws['default'][netifaces.AF_INET] gwAddress = defaultGw[0] gwInterface = defaultGw[1] print ("Default gateway : ", gwAddress, " on interface : ", gwInterface) if 'wlan' in gwInterface : print("Wlan interface used!? (", gwInterface, ")\n") print("dummy eth mit ip_forwarding must be put in place") #bridging wlan0 to eth0 s = '1' with open('/proc/sys/net/ipv4/ip_forward', 'w') as f: print(s, file=f) f.close() subprocess.run(['/sbin/iptables', '-t', 'nat', '-A', 'POSTROUTING', '-o', 'wlan0', '-j', 'MASQUERADE']) subprocess.run(['/sbin/brctl', 'addif', 'br0', 'eth0']) subprocess.run(['ifconfig', 'eth0', eth0Ip, 'netmask', ethNetMask, 'up']) setupAndStartDhcpd() subprocess.run(['/sbin/ifconfig', 'tap0', 'up']) print("ready for qemu") main() and then start a exe file with [h1@earth QtC-epics-base (7.0 *)]$ more startQemu #!/bin/bash echo Script name: $0 if [ $# -ne 1 ]; then echo "Please name the exe file" exit 2 fi #-net nic -net tap,ifname=tap1,script=no \ #-net nic,model=cadence_gem -net tap,ifname=tap1,script=no \ # -s -no-reboot sudo qemu-system-aarch64 -s -no-reboot \ -net nic,model=cadence_gem -net tap,ifname=tap0,script=no \ -serial null -serial mon:stdio -nographic -M xilinx-zynq-a9 -m 256M \ -kernel bin/RTEMS-xilinx_zynq_a9_qemu/$1 HTH, Heinz___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems_interrupt_catch()
On Thu, Jun 25, 2020, 12:38 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 25/06/2020 01:36, Chris Johns wrote: > > > On 24/6/20 2:40 am, Sebastian Huber wrote: > >> Hello, > >> > >> I noticed that the rtems_interrupt_catch() directive is only declared > >> and implemented if CPU_SIMPLE_VECTORED_INTERRUPTS == TRUE: > >> > >> #if (CPU_SIMPLE_VECTORED_INTERRUPTS == FALSE) > >> > >> typedef ISR_Handler_entry rtems_isr_entry; > >> > >> #else > >> /** > >> * @brief Interrupt handler type. > >> * > >> * @see rtems_interrupt_catch() > >> */ > >> typedef rtems_isr ( *rtems_isr_entry )( > >> rtems_vector_number > >> ); > >> > >> /** > >> * @brief RTEMS Interrupt Catch > >> * > >> * This directive installs @a new_isr_handler as the RTEMS interrupt > >> service > >> * routine for the interrupt vector with number @a vector. The > >> previous RTEMS > >> * interrupt service routine is returned in @a old_isr_handler. > >> * > >> * @param[in] new_isr_handler is the address of interrupt service > >> routine > >> * @param[in] vector is the interrupt vector number > >> * @param[in] old_isr_handler address at which to store previous ISR > >> address > >> * > >> * @retval RTEMS_SUCCESSFUL and *old_isr_handler filled with > >> previous ISR > >> * address > >> */ > >> rtems_status_code rtems_interrupt_catch( > >>rtems_isr_entry new_isr_handler, > >>rtems_vector_number vector, > >>rtems_isr_entry *old_isr_handler > >> ); > >> #endif > >> > >> This is not mentioned in the documentation: > >> > >> > https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#interrupt-catch-establish-an-isr > >> > >> > >> Should we provide this function also if > >> CPU_SIMPLE_VECTORED_INTERRUPTS == FALSE and for example just return > >> RTEMS_NOT_IMPLEMENTED? > > > > Which archs define CPU_SIMPLE_VECTORED_INTERRUPTS as false? > cpukit/score/cpu/arm/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS FALSE > cpukit/score/cpu/v850/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS FALSE > cpukit/score/cpu/x86_64/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS FALSE > cpukit/score/cpu/i386/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS FALSE > cpukit/score/cpu/powerpc/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS FALSE > cpukit/score/cpu/mips/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS FALSE > > cpukit/score/cpu/m68k/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS TRUE > cpukit/score/cpu/bfin/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS TRUE > cpukit/score/cpu/sparc64/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS TRUE > cpukit/score/cpu/sh/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS TRUE > cpukit/score/cpu/lm32/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS TRUE > cpukit/score/cpu/no_cpu/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS TRUE > cpukit/score/cpu/nios2/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS TRUE > cpukit/score/cpu/sparc/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS TRUE > cpukit/score/cpu/moxie/include/rtems/score/cpu.h:#define > CPU_SIMPLE_VECTORED_INTERRUPTS TRUE > > It seem riscv is missing, so an implicit FALSE. > > Instead of returning RTEMS_NOT_IMPLEMENTED we could also implement it > like this for CPU_SIMPLE_VECTORED_INTERRUPTS == FALSE: > > #if CPU_SIMPLE_VECTORED_INTERRUPTS == TRUE >typedef ISR_Handler_entry rtems_isr_entry; > #else >typedef void ( *rtems_isr_entry )( void * ); >/* Now: typedef void rtems_isr_entry; */ > #endif > > rtems_status_code rtems_interrupt_catch( >rtems_isr_entry new_isr_handler, >rtems_vector_number vector, >rtems_isr_entry *old_isr_handler > ) > { >rtems_status_code sc; > >if ( old_isr_handler == NULL ) { > return RTEMS_INVALID_ADDRESS; >} > >sc = rtems_interrupt_handler_install( > vector, > "Catch", > RTEMS_INTERRUPT_UNIQUE, > new_isr_handler, > NULL >); > >if ( sc == RTEMS_SUCCESSFUL ) { > *old_isr_handler = NULL; >} > >return RTEMS_SUCCESSFUL; > } > I would prefer this and honestly thought we already had this. Maybe it was the other direction. PIC interrupt management on top of simple vectored. Without this, the only acceptable option IMO is compile time failure. This is comparable to the SMP cases where we wanted someone to fix code. Either we make it work for them or we let them know at compile time their driver needs work. --joel > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/list
Re: Documentation of Qualification Toolchain?
On 25/6/20 3:26 pm, Sebastian Huber wrote: On 24/06/2020 02:48, Chris Johns wrote: On 19/6/20 11:38 pm, Sebastian Huber wrote: the qualification toolchain in https://git.rtems.org/sebh/rtems-qual.git/ needs a bit of documentation. For a start, I propose to add it to the RTEMS Software Engineering manual. Does this mean adding references to that repo? Yes, I already added a how-to section for the glossary of terms: https://docs.rtems.org/branches/master/eng/req/howto.html Ah OK. We need to make some choices and get something more formal in place. Stray links to things that will change does not help anyone. I am not comfortable with the name of the repo and documenting a personal repo is something we should avoid. Yes, the name is not great. I think your proposal to name it rtems-central was a bit better. Another option is rtems-spec. Yes rtems-central is nice but is this a place a user will come to and use? I see the name rtems-qual.git as the project or outcome name that is currently undersay and not what it is. If a core developer does not need to use this repo to maintain RTEMS and that work can be qualified what role does it perform? If it is simpler and easier for a core developer to use this repo then this is not about qualification it is about development of RTEMS that can be qualified. I would like to understand the intended workflow for this repo. Is something we should promote as the developer workflow? If so we should consider embracing this. For example the glossary generation. Editing by hand the generated output does not make sense to me. The stuff in this repository is already somewhat useful to maintain RTEMS. You can generate the glossary of terms for individual documents from a shared collection of terms. In the RTEMS Classic API Guide the project-wide glossary is located, other documents only include the terms they use in their glossary. All the application configuration options are available as specification items: https://docs.rtems.org/branches/master/eng/req/items.html#spectypeapplicationconfigurationoptionitemtype All the sections about application configuration options in the RTEMS Classic API Guide are generated from them. With a bit of work, we could also generate pages for the Doxygen documentation. The tool chain supports context-sensitive substitution. In the specification a ${uid:attribute/path} syntax is used. For example: * The ${../attr/multiprocessor-resource-sharing:/name} attribute selects the MrsP locking protocol in SMP configurations, otherwise it selects the priority ceiling protocol. For this locking protocol a priority ceiling shall be specified in ``${.:/params[3]/name}``. This priority is used to set the priority ceiling in all scheduler instances. This can be changed later with the ${set-priority:/name} directive using the returned semaphore identifier. In the Sphinx output this is transformed to: * The RTEMS_MULTIPROCESSOR_RESOURCE_SHARING attribute selects the MrsP locking protocol in SMP configurations, otherwise it selects the priority ceiling protocol. For this locking protocol a priority ceiling shall be specified in ``priority_ceiling``. This priority is used to set the priority ceiling in all scheduler instances. This can be changed later with the :ref:`rtems_semaphore_set_priority() ` directive using the returned semaphore identifier. In the Doxygen output this is transformed to: * * The #RTEMS_MULTIPROCESSOR_RESOURCE_SHARING attribute selects the MrsP * locking protocol in SMP configurations, otherwise it selects the priority * ceiling protocol. For this locking protocol a priority ceiling shall be * specified in ``priority_ceiling``. This priority is used to set the * priority ceiling in all scheduler instances. This can be changed later * with the rtems_semaphore_set_priority() directive using the returned * semaphore identifier. I work currently on a complete specification of the RTEMS Classic API. The tool chain has also support for test plan and code generation. I plan to specify the functionality of the RTEMS directives through so called action requirements: https://docs.rtems.org/branches/master/eng/req/items.html#spectypeactionrequirementitemtype This can be used to generate table based test loops to check all states of pre-conditions and post-conditions (see attached file). Great. I think what you have explained would benefit the development of RTEMS and so I think this is something we should look at promoting as a development tool. I have a concern about the long term maintenance of a git repo of git repos. I know of a project that have developed tools to handle something like this because it is hard to do manually. Maybe we should find out more about this. Which long term maintenance issues do you see? Working with Git submodu
Re: Command line for Qemu and libbsd for pc386
Hi Gabriel, Thanks. Your post reminded me to have a look. This the set up I used a while ago .. qemu-system-arm \ -M xilinx-zynq-a9 -m 256M -no-reboot -serial null \ -serial mon:stdio -nographic -net nic,model=cadence_gem \ -net vde,id=vde0,sock=/tmp/vde1 -kernel $* This use the vdeswitch package. The RSB will build VDE support into qemu if it is installed and available. On FreeBSD I have a bridge with a tap interface. The /etc/rc.conf has ... cloned_interfaces="bridge0 tap0" autobridge_interfaces="bridge0" ifconfig_bridge0="inet 10.1.1.2 netmask 255.255.255.0" autobridge_bridge0="re0 tap0" ifconfig_re0="up" ifconfig_tap0="up" defaultrouter="10.1.1.1" Then run the VDE switch with ... #! /bin/sh # # vdeterm /tmp/mgmt1 # sysctl net.link.tap.user_open=1 sysctl net.link.tap.up_on_open=1 chmod 660 /dev/tap0 vde_switch -d -s /tmp/vde1 -M /tmp/mgmt1 -tap tap0 -m 660 \ --mgmtmode 660 VDE lets me run a number of qemu sessions together and have them see each other without needing to add a bunch of tap interfaces. Chris On 25/6/20 4:12 pm, gabriel.moy...@dlr.de wrote: Hi Joel, Before running qemu, some qtabs should be created. How to do that it is described on file libbsd.txt (line 333). Then I usually run qemu as follows: qemu-system-i386 -append --console=/dev/com1 -no-reboot -serial stdio -monitor none -nographic -netdev tap,ifname=qtap1,script=no,downscript=no,id=n1 –device e1000,netdev=n1,mac=52:55:00:d1:55:01 -kernel path/to/exe/file Please note that if you are running two instances, the second one should have different MAC address and ifname, e.g. mac=52:55:00:d1:55:0*2*and ifname=qtab*2* ** If hope this helps. Cheers, Gabriel *From:*devel [mailto:devel-boun...@rtems.org] *On Behalf Of *Joel Sherrill *Sent:* Mittwoch, 24. Juni 2020 19:23 *To:* rtems-de...@rtems.org *Subject:* Command line for Qemu and libbsd for pc386 Hi Does someone have a qemu command line handy for running libbsd network applications on Qemu? I have lots of notes and old examples but can't seem to trip the right combination today. Thanks. --joel ___ 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