Building libbsd after installing libbsd
Hi I am not sure if this is avoidable but it is surprising. + build and install rtems to $prefix + build and install libbsd to $prefix + ./waf will then rebuild some files. It appears to be using installed headers + Then ./waf install and it will also rebuild some files before fails. I think there is no way to avoid this and waf for libbsd should detect that it sees headers installed from itself and give an error that you need a clean $prefix to build. Just to make sure there wasn't interference between two different BSPs, I built and installed one followed by a second different one. That went fine. The behavior is bizarre and the weird compilation errors are mysterious until you repeat the steps enough to figure it out. Unless someone knows how the build can avoid this, I think we need an error check early in the configure process. I think it is sufficient to check if machine/rtems-bsd-nexus-bus.h is installed already ad give a nice explanation and failure during configure. Thoughts? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
LIBBSD
For those who run a RTEMS 4.12 single processor application with LIBBSD, what percentage of time does your application spend in the timer server task? My NXP LPC3250 application spends about 13% of the processor time processing the timer server. Most of that time is spent processing LIBBSD's kernel callouts. I am wondering if there is an advantage to only call the FreeBSD's callout_process() function when we know a callout needs to be processed. This would reduce the number of RTEMS timer fires (which currently fire every tick). Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 2/5] libbsd: Index for LibBSD Doc
Add the index file and an empty page for introduction. Signed-off-by: Husni Faiz --- libbsd/index.rst| 23 +++ libbsd/introduction.rst | 8 2 files changed, 31 insertions(+) create mode 100644 libbsd/index.rst create mode 100644 libbsd/introduction.rst diff --git a/libbsd/index.rst b/libbsd/index.rst new file mode 100644 index 000..f790070 --- /dev/null +++ b/libbsd/index.rst @@ -0,0 +1,23 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. include:: ../common/unicode.rst + +.. highlight:: c + +== +RTEMS LibBSD User Manual (|version|). +== + +.. topic:: Copyrights and License + + +.. include:: ../common/license.rst + +.. include:: ../common/header.rst + +.. toctree:: + :maxdepth: 3 + :numbered: + + introduction + quick_start diff --git a/libbsd/introduction.rst b/libbsd/introduction.rst new file mode 100644 index 000..7a37457 --- /dev/null +++ b/libbsd/introduction.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. COMMENT: Written by +.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR) + +Introduction + + -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building libbsd after installing libbsd
On 9/10/20 8:24 am, Joel Sherrill wrote: > Hi > > I am not sure if this is avoidable but it is surprising. > > + build and install rtems to $prefix > > + build and install libbsd to $prefix > > + ./waf will then rebuild some files. It appears to be using installed headers Is this in rtems or libbsd? > + Then ./waf install and it will also rebuild some files before fails. Again which or is it both? > I think there is no way to avoid this and waf for libbsd should detect that it > sees headers installed from itself and give an error that you need a clean > $prefix to build. Waf uses an md5 checksum for dependency checking so replacing a file with the same file should not trigger a rebuild, the contents have to have changed. This is different to make and others that stat a file. > Just to make sure there wasn't interference between two different BSPs, I > built > and installed one followed by a second different one. That went fine. > > The behavior is bizarre and the weird compilation errors are mysterious until > you repeat the steps enough to figure it out. Unless someone knows how the > build > can avoid this, I think we need an error check early in the configure > process. This implies some files in one package are overwriting a file installed by another package. That should not happen. It would be nice to install a manifesto of the files a package installs. I am sure it would aid deployment for those wanting to package and deploy RTEMS with rpm, deb or what ever else. It would help here as the contents of each could be reviewed. > I think it is sufficient to check if machine/rtems-bsd-nexus-bus.h is > installed > already ad give a nice explanation and failure during configure. Adding this would limit those develop and maintaining these packages. > Thoughts? Should we understand the interactions before we decide on a solution? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building libbsd after installing libbsd
On Thu, Oct 8, 2020 at 4:59 PM Chris Johns wrote: > On 9/10/20 8:24 am, Joel Sherrill wrote: > > Hi > > > > I am not sure if this is avoidable but it is surprising. > > > > + build and install rtems to $prefix > > > > + build and install libbsd to $prefix > > > > + ./waf will then rebuild some files. It appears to be using installed > headers > > Is this in rtems or libbsd? > libbsd. RTEMS can be install and then "./waf" does nothing like you would expect. > > > + Then ./waf install and it will also rebuild some files before fails. > > Again which or is it both? > libbsd only > > > I think there is no way to avoid this and waf for libbsd should detect > that it > > sees headers installed from itself and give an error that you need a > clean > > $prefix to build. > > Waf uses an md5 checksum for dependency checking so replacing a file with > the > same file should not trigger a rebuild, the contents have to have changed. > This > is different to make and others that stat a file. > Then something is confusing it. The first build is with the file in the libbsd tree. Running waf again, I think it is using the installed one. > > > Just to make sure there wasn't interference between two different BSPs, > I built > > and installed one followed by a second different one. That went fine. > > > > The behavior is bizarre and the weird compilation errors are mysterious > until > > you repeat the steps enough to figure it out. Unless someone knows how > the build > > can avoid this, I think we need an error check early in the configure > process. > > This implies some files in one package are overwriting a file installed by > another package. That should not happen. > > It would be nice to install a manifesto of the files a package installs. I > am > sure it would aid deployment for those wanting to package and deploy RTEMS > with > rpm, deb or what ever else. It would help here as the contents of each > could be > reviewed. > It would be nice but I don't think that solves this. > > > I think it is sufficient to check if machine/rtems-bsd-nexus-bus.h is > installed > > already ad give a nice explanation and failure during configure. > > Adding this would limit those develop and maintaining these packages. > The behavior now seems to confuse in-tree and installed header files is my guess. > > > Thoughts? > > Should we understand the interactions before we decide on a solution? > Sure. If there really is an avoidable bug. --joel > > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building libbsd after installing libbsd
On 9/10/20 9:13 am, Joel Sherrill wrote: > On Thu, Oct 8, 2020 at 4:59 PM Chris Johns <mailto:chr...@rtems.org>> wrote: > > On 9/10/20 8:24 am, Joel Sherrill wrote: > > Hi > > > > I am not sure if this is avoidable but it is surprising. > > > > + build and install rtems to $prefix > > > > + build and install libbsd to $prefix > > > > + ./waf will then rebuild some files. It appears to be using installed > headers > > Is this in rtems or libbsd? > > libbsd. RTEMS can be install and then "./waf" does nothing like you would > expect. > OK. > > + Then ./waf install and it will also rebuild some files before fails. > > Again which or is it both? > > libbsd only OK > > I think there is no way to avoid this and waf for libbsd should detect > that it > > sees headers installed from itself and give an error that you need a > clean > > $prefix to build. > > Waf uses an md5 checksum for dependency checking so replacing a file with > the > same file should not trigger a rebuild, the contents have to have > changed. This > is different to make and others that stat a file. > > > Then something is confusing it. The first build is with the file in the libbsd > tree. Running waf again, I think it is using the installed one. Oh OK. If the BSP is installed to the same prefix then this is hard to avoid. > > Just to make sure there wasn't interference between two different BSPs, > I > built > > and installed one followed by a second different one. That went fine. > > > > The behavior is bizarre and the weird compilation errors are mysterious > until > > you repeat the steps enough to figure it out. Unless someone knows how > the > build > > can avoid this, I think we need an error check early in the configure > process. > > This implies some files in one package are overwriting a file installed by > another package. That should not happen. > > It would be nice to install a manifesto of the files a package installs. > I am > sure it would aid deployment for those wanting to package and deploy > RTEMS with > rpm, deb or what ever else. It would help here as the contents of each > could be > reviewed. > > It would be nice but I don't think that solves this. Agreed. > > I think it is sufficient to check if machine/rtems-bsd-nexus-bus.h is > installed > > already ad give a nice explanation and failure during configure. > > Adding this would limit those develop and maintaining these packages. > > The behavior now seems to confuse in-tree and installed header files is my > guess. I have not seen this. I am sure it does. > > > > > Thoughts? > > Should we understand the interactions before we decide on a solution? > > > Sure. If there really is an avoidable bug. It should be looked into and resolved. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[libbsd 05/22] CONTRIBUTING.rst: Use LibBSD
--- CONTRIBUTING.rst | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index 8cfec7cd..0ea66946 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -4,16 +4,16 @@ Guidelines for Developing and Contributing Code Introduction -This guide aims to help developing and contributing code to the libbsd. One -goal of the libbsd is to stay in synchronization with FreeBSD. This is only +This guide aims to help developing and contributing code to the LibBSD. One +goal of the LibBSD is to stay in synchronization with FreeBSD. This is only feasible if certain rules are in place. Otherwise, managing more than a thousand imported source files will become too labour intensive eventually. What is in the Git Repository = -The libbsd a self-contained kit with FreeBSD and RTEMS components -pre-merged. The Waf wscript in libbsd automatically generates the build when +The LibBSD a self-contained kit with FreeBSD and RTEMS components +pre-merged. The Waf wscript in LibBSD automatically generates the build when you run waf by reading the modules and module's source, header, defines and special flags from ``libbsd.py``. This is the same module data used to manage the FreeBSD source. @@ -208,7 +208,7 @@ original FreeBSD code. ``rtems_bsd_command_pfctl()`` in `pfctl.c `_. * You probably have to use getopt_r() instead of getopt(). Have a look at `pfctl.c `_. -* Build the libbsd without optimization. +* Build the LibBSD without optimization. * Use the ``userspace-header-gen.py`` to generate some necessary header files. It will generate one ``rtems-bsd-PROGNAME-MODULE-data.h`` per object file, one ``rtems-bsd-PROGNAME-namespace.h`` and one ``rtems-bsd-PROGNAME-data.h``. To call -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 1/5] libbsd: Quick Start Guide for RTEMS LibBSD
This guide has instructions to build the RTESM LibBSD manually for Beagle BSP. Signed-off-by: Husni Faiz --- libbsd/quick_start.rst | 51 ++ 1 file changed, 51 insertions(+) create mode 100644 libbsd/quick_start.rst diff --git a/libbsd/quick_start.rst b/libbsd/quick_start.rst new file mode 100644 index 000..ec8500d --- /dev/null +++ b/libbsd/quick_start.rst @@ -0,0 +1,51 @@ +.. COMMENT: Written by Husni Faiz +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +Quick Start +### + +The LibBSD is a standalone repository and needs to be built +separately. + +The repository can be found here: https://git.rtems.org/rtems-libbsd/ + +Manual LibBSD Build +=== + +Pre-requisites: + +- Built the tool set for your BSP + +- Built and installed RTEMS for your BSP with networking disabled and + POSIX API enabled. + +The following guide uses the Beagle BSP. + +Get the RTEMS LibBSD source + + .. code-block:: shell + +git clone https://git.rtems.org/rtems-libbsd/ +cd rtems-libbsd + +Get the RTEMS Waf build systems + + .. code-block:: shell + +git submodule init +git submodule update rtems_waf + +Configure the build. + + .. code-block:: shell + +./waf configure --prefix=/path/to/rtems/prefix \ +--rtems-bsps=arm/beagleboneblack \ +--buildset=buildset/default.ini + +Build and Install + + .. code-block:: shell + +./waf +./waf install -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[libbsd 2/4] if_lpe.c: Port to LibBSD
---
libbsd.py | 1 +
rtemsbsd/sys/arm/lpc/if_lpe.c | 466 +-
2 files changed, 228 insertions(+), 239 deletions(-)
diff --git a/libbsd.py b/libbsd.py
index de22eaa9..983f41a1 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -235,6 +235,7 @@ class rtems(builder.Module):
'rtems/rtems-legacy-rtrequest.c',
'rtems/rtems-legacy-newproc.c',
'rtems/rtems-legacy-mii.c',
+'sys/arm/lpc/if_lpe.c',
'sys/arm/lpc/lpc_pwr.c',
'sys/dev/atsam/if_atsam.c',
'sys/dev/atsam/if_atsam_media.c',
diff --git a/rtemsbsd/sys/arm/lpc/if_lpe.c b/rtemsbsd/sys/arm/lpc/if_lpe.c
index ccfe1696..247bd486 100755
--- a/rtemsbsd/sys/arm/lpc/if_lpe.c
+++ b/rtemsbsd/sys/arm/lpc/if_lpe.c
@@ -22,28 +22,32 @@
#include
-#include
-#include
-#include
-#include
-#include
-#include
+#include
-#include
-#include
-#include
+#if defined(LIBBSP_ARM_LPC24XX_BSP_H) || defined(LIBBSP_ARM_LPC32XX_BSP_H)
#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
@@ -128,6 +132,10 @@ typedef struct {
uint32_t powerdown;
} lpc_eth_controller;
+#define LPE_LOCK(e) mtx_lock(&(e)->mtx)
+
+#define LPE_UNLOCK(e) mtx_unlock(&(e)->mtx)
+
static volatile lpc_eth_controller *const lpc_eth =
(volatile lpc_eth_controller *) LPC_ETH_CONFIG_REG_BASE;
@@ -300,10 +308,12 @@ typedef enum {
} lpc_eth_state;
typedef struct {
- struct arpcom arpcom;
+ device_t dev;
+ struct ifnet *ifp;
+ struct mtx mtx;
lpc_eth_state state;
- struct rtems_mdio_info mdio;
uint32_t anlpar;
+ struct callout watchdog_callout;
rtems_id receive_task;
rtems_id transmit_task;
unsigned rx_unit_count;
@@ -338,14 +348,18 @@ typedef struct {
int phy;
rtems_vector_number interrupt_number;
rtems_id control_task;
+ int if_flags;
+ struct ifmedia ifmedia;
} lpc_eth_driver_entry;
-static lpc_eth_driver_entry lpc_eth_driver_data;
+static void lpc_eth_interface_watchdog(void *arg);
+
+static void lpc_eth_setup_rxfilter(lpc_eth_driver_entry *e);
static void lpc_eth_control_request_complete(const lpc_eth_driver_entry *e)
{
rtems_status_code sc = rtems_event_transient_send(e->control_task);
- assert(sc == RTEMS_SUCCESSFUL);
+ BSD_ASSERT(sc == RTEMS_SUCCESSFUL);
}
static void lpc_eth_control_request(
@@ -355,17 +369,14 @@ static void lpc_eth_control_request(
)
{
rtems_status_code sc = RTEMS_SUCCESSFUL;
- uint32_t nest_count = 0;
e->control_task = rtems_task_self();
- sc = rtems_bsdnet_event_send(task, event);
- assert(sc == RTEMS_SUCCESSFUL);
+ sc = rtems_event_send(task, event);
+ BSD_ASSERT(sc == RTEMS_SUCCESSFUL);
- nest_count = rtems_bsdnet_semaphore_release_recursive();
sc = rtems_event_transient_receive(RTEMS_WAIT, RTEMS_NO_TIMEOUT);
- assert(sc == RTEMS_SUCCESSFUL);
- rtems_bsdnet_semaphore_obtain_recursive(nest_count);
+ BSD_ASSERT(sc == RTEMS_SUCCESSFUL);
e->control_task = 0;
}
@@ -418,7 +429,7 @@ static void lpc_eth_interrupt_handler(void *arg)
/* Send events to receive task */
if (re != 0) {
++e->receive_interrupts;
-(void) rtems_bsdnet_event_send(e->receive_task, re);
+(void) rtems_event_send(e->receive_task, re);
}
/* Check transmit interrupts */
@@ -433,7 +444,7 @@ static void lpc_eth_interrupt_handler(void *arg)
/* Send events to transmit task */
if (te != 0) {
++e->transmit_interrupts;
-(void) rtems_bsdnet_event_send(e->transmit_task, te);
+(void) rtems_event_send(e->transmit_task, te);
}
LPC_ETH_PRINTK("interrupt: rx = 0x%08x, tx = 0x%08x\n", re, te);
@@ -486,7 +497,7 @@ static void lpc_eth_disable_transmit_interrupts(void)
static struct mbuf *lpc_eth_new_mbuf(struct ifnet *ifp, bool wait)
{
struct mbuf *m = NULL;
- int mw = wait ? M_WAIT : M_DONTWAIT;
+ int mw = wait ? M_WAITOK : M_NOWAIT;
MGETHDR(m, mw, MT_DATA);
if (m != NULL) {
@@ -546,12 +557,12 @@ static bool lpc_eth_add_new_mbuf(
}
}
-static void lpc_eth_receive_task(void *arg)
+static void lpc_eth_receive_task(rtems_task_argument arg)
{
rtems_status_code sc = RTEMS_SUCCESSFUL;
rtems_event_set events = 0;
lpc_eth_driver_entry *const e = (lpc_eth_driver_entry *) arg;
- struct ifnet *const ifp = &e->arpcom.ac_if;
+ struct ifnet *const ifp = e->ifp;
volatile lpc_eth_transfer_descriptor *const desc = e->rx_desc_table;
volatile lpc_eth_receive_status *const status = e->rx_status_table;
struct mbuf **const mbufs = e->rx_mbuf_table;
@@ -564,7 +575,7 @@ static void lpc_eth_receive_task(void *arg)
/* Main event loop */
while (true) {
/* Wait for events */
-sc = rtems_bsdnet_event_receive(
+sc = rtems_event_receive(
LPC_ETH_EVENT_INITIALIZE
Re: LIBBSD
On 29/06/17 20:02, Kirspel, Kevin wrote: For those who run a RTEMS 4.12 single processor application with LIBBSD, what percentage of time does your application spend in the timer server task? My NXP LPC3250 application spends about 13% of the processor time processing the timer server. Most of that time is spent processing LIBBSD’s kernel callouts. I am wondering if there is an advantage to only call the FreeBSD’s callout_process() function when we know a callout needs to be processed. This would reduce the number of RTEMS timer fires (which currently fire every tick). Normally, the timer server should be in the range of 0.x% of CPU time. If you have 13%, then you have a lot of timeout processing. What is the reason for this? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: LIBBSD
I'm not sure but I'll look into it today. I'll need to quantify each callout handler's processing time to see which one is causing the problem. I know the USB and Ethernet stacks/drivers use callouts but maybe there is something else. Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber Sent: Friday, June 30, 2017 1:15 AM To: devel@rtems.org Subject: Re: LIBBSD On 29/06/17 20:02, Kirspel, Kevin wrote: > For those who run a RTEMS 4.12 single processor application with > LIBBSD, what percentage of time does your application spend in the > timer server task? My NXP LPC3250 application spends about 13% of the > processor time processing the timer server. Most of that time is > spent processing LIBBSD's kernel callouts. I am wondering if there is > an advantage to only call the FreeBSD's callout_process() function > when we know a callout needs to be processed. This would reduce the > number of RTEMS timer fires (which currently fire every tick). Normally, the timer server should be in the range of 0.x% of CPU time. If you have 13%, then you have a lot of timeout processing. What is the reason for this? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwIF-g&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=wi6q2gTnD-FidfbEqMhvlESvqYn-Fmg-tXnNg62S3BY&s=8pSzson7fylkfTRzYKIMlQnFgvwpY8lpExFHqEEapbc&e= ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: LIBBSD
Just some quick numbers. LPC3250 running at 208 MHz, 64MB RAM, 512MB FLASH. Case #1: Disable the RTEMS callout timer in LIBBSD (kern_timeout.c) IDLE Task CPUUSE: 99.430% TIME Task CPUUSE: <0.001% Case #2: Enable the RTEMS callout timer but do not call "callout_process()" (the timer service routine just resets the timer and quits) . IDLE Task CPUUSE: 93.144% TIME Task CPUUSE: 6.282% So just processing the 1 tick RTEMS timer in LIBBSD's kern_timeout.c takes up 6% of the CPU processing time. Case #3: Normal callout processing IDLE Task CPUUSE: 87.116% TIME Task CPUUSE: 12.672% Below are the callout functions that are being executed. The number beside each function is the average number of clocks it took to execute (13MHz base clock). ipport_tick - 370/28us pffasttimo - 930/72us pfslowtimo - 5600/431us lpe_tick - 4200/323us _bsd_nd6_timer - 650/50us usb_power_wdog - 1000/80us ohci_rhsc_enable - 400/31us Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber Sent: Friday, June 30, 2017 1:15 AM To: devel@rtems.org Subject: Re: LIBBSD On 29/06/17 20:02, Kirspel, Kevin wrote: > For those who run a RTEMS 4.12 single processor application with > LIBBSD, what percentage of time does your application spend in the > timer server task? My NXP LPC3250 application spends about 13% of the > processor time processing the timer server. Most of that time is > spent processing LIBBSD's kernel callouts. I am wondering if there is > an advantage to only call the FreeBSD's callout_process() function > when we know a callout needs to be processed. This would reduce the > number of RTEMS timer fires (which currently fire every tick). Normally, the timer server should be in the range of 0.x% of CPU time. If you have 13%, then you have a lot of timeout processing. What is the reason for this? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwIF-g&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=wi6q2gTnD-FidfbEqMhvlESvqYn-Fmg-tXnNg62S3BY&s=8pSzson7fylkfTRzYKIMlQnFgvwpY8lpExFHqEEapbc&e= ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
LIBBSD TCPDUMP
I get a crash when running the tcpdump command in LIBBSD. It is due to the
following structure
struct stp_bpdu_ {
u_int8_t protocol_id[2];
u_int8_t protocol_version;
u_int8_t bpdu_type;
u_int8_t flags;
u_int8_t root_id[8];
u_int8_t root_path_cost[4];
u_int8_t bridge_id[8];
u_int8_t port_id[2];
u_int8_t message_age[2];
u_int8_t max_age[2];
u_int8_t hello_time[2];
u_int8_t forward_delay[2];
u_int8_t v1_length;
};
In the code, there is an access to the port_id field as follows:
EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since the
address of "&stp_bpdu->port_id" is at an odd word (16 bit) boundary, an
exception is generated. What is the correct way to fix this? I was going to
update EXTRACT_16BITS to check for an odd boundary and fix it up before calling
ntohs().
Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: LIBBSD
I have rewritten the kern_timeout.c module to use individual RTEMS timers per callout/timeout function. My Idle task CPUUSE is now 99.9%. I still need to validate all the functionality of the kern_timeout.c module with a timeout01 test in the testsuite. I don't think the existing kern_timeout.c module currently supports all the functionality that is used in Freebsd (callouts/timeouts on a particular CPU core). Right now everything is processed on CPU core 0 because of the way the RTEMS timer server works. My version excludes all the SMP stuff and silently places all timeouts on CPU core 0. We could probably support the callouts/timeouts on a particular CPU core if we update the RTEMS timer code but I don't think it is a feature that most people would use. Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Kirspel, Kevin Sent: Friday, June 30, 2017 2:08 PM To: devel@rtems.org Subject: RE: LIBBSD Just some quick numbers. LPC3250 running at 208 MHz, 64MB RAM, 512MB FLASH. Case #1: Disable the RTEMS callout timer in LIBBSD (kern_timeout.c) IDLE Task CPUUSE: 99.430% TIME Task CPUUSE: <0.001% Case #2: Enable the RTEMS callout timer but do not call "callout_process()" (the timer service routine just resets the timer and quits) . IDLE Task CPUUSE: 93.144% TIME Task CPUUSE: 6.282% So just processing the 1 tick RTEMS timer in LIBBSD's kern_timeout.c takes up 6% of the CPU processing time. Case #3: Normal callout processing IDLE Task CPUUSE: 87.116% TIME Task CPUUSE: 12.672% Below are the callout functions that are being executed. The number beside each function is the average number of clocks it took to execute (13MHz base clock). ipport_tick - 370/28us pffasttimo - 930/72us pfslowtimo - 5600/431us lpe_tick - 4200/323us _bsd_nd6_timer - 650/50us usb_power_wdog - 1000/80us ohci_rhsc_enable - 400/31us Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber Sent: Friday, June 30, 2017 1:15 AM To: devel@rtems.org Subject: Re: LIBBSD On 29/06/17 20:02, Kirspel, Kevin wrote: > For those who run a RTEMS 4.12 single processor application with > LIBBSD, what percentage of time does your application spend in the > timer server task? My NXP LPC3250 application spends about 13% of the > processor time processing the timer server. Most of that time is > spent processing LIBBSD's kernel callouts. I am wondering if there is > an advantage to only call the FreeBSD's callout_process() function > when we know a callout needs to be processed. This would reduce the > number of RTEMS timer fires (which currently fire every tick). Normally, the timer server should be in the range of 0.x% of CPU time. If you have 13%, then you have a lot of timeout processing. What is the reason for this? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwIF-g&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=wi6q2gTnD-FidfbEqMhvlESvqYn-Fmg-tXnNg62S3BY&s=8pSzson7fylkfTRzYKIMlQnFgvwpY8lpExFHqEEapbc&e= ___ devel mailing list devel@rtems.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwIFAw&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=RMQjCIXGYJE0sLPFXFT_ff4hxd0Xv4XwddHMeiJ22Dg&s=3xFmeotPlm109pDOuYPFrRHA4IDShM96NNS3CGwextE&e= ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LIBBSD
On 03/07/17 02:03, Kirspel, Kevin wrote: I have rewritten the kern_timeout.c module to use individual RTEMS timers per callout/timeout function. My Idle task CPUUSE is now 99.9%. I still need to validate all the functionality of the kern_timeout.c module with a timeout01 test in the testsuite. I don't think the existing kern_timeout.c module currently supports all the functionality that is used in Freebsd (callouts/timeouts on a particular CPU core). Right now everything is processed on CPU core 0 because of the way the RTEMS timer server works. My version excludes all the SMP stuff and silently places all timeouts on CPU core 0. We could probably support the callouts/timeouts on a particular CPU core if we update the RTEMS timer code but I don't think it is a feature that most people would use. I don't think this is a good idea. For the network stack a fast timer insert/delete is required. This is achieved by the time wheel implementation. The RTEMS timer use a red-black tree to get a more predictable run-time of all operations. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LIBBSD
On 30/06/17 20:08, Kirspel, Kevin wrote: Case #2: Enable the RTEMS callout timer but do not call "callout_process()" (the timer service routine just resets the timer and quits) . IDLE Task CPUUSE: 93.144% TIME Task CPUUSE: 6.282% In this case you have some low-level problem on your target. Is the cache enabled and properly set up in the MMU? How many ticks per second do you use? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: LIBBSD
The MMU is disabled right now because I am tracking down a problem (not related to LIBBSD). I was going to turn it back on after I solve that issue. I'm using a 1ms tick. Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 -Original Message- From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] Sent: Monday, July 03, 2017 1:47 AM To: Kirspel, Kevin ; devel@rtems.org Subject: Re: LIBBSD On 30/06/17 20:08, Kirspel, Kevin wrote: > Case #2: Enable the RTEMS callout timer but do not call "callout_process()" > (the timer service routine just resets the timer and quits) . > IDLE Task CPUUSE: 93.144% > TIME Task CPUUSE: 6.282% In this case you have some low-level problem on your target. Is the cache enabled and properly set up in the MMU? How many ticks per second do you use? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
libbsd updates
Hello, recently an internal discussion about updates in the libbsd started. All who participated in the discussion agreed that we should move the discussion to a public one. Below you can find the mail thread. It's oldest mail first. Mails are split with lines of = signs. I removed some duplicated mail text in case there were no inline comments. The date/time of the mails are in my current locale which is UTC+1. Best regards Christian = On 2023-01-03 16:52, Thomas DOERFLER wrote: Hello, first of all I wish you all a healthy, happy and successful new year. Unfortunately I already have to re-raise an issue: One of our customers has asked us about the RTEMS libbsd update policy. Since we still use a rather old libbsd version, it contains "OpenSSL 1.1.1d-freebsd 10 Sep 2019", there are many openSSL fixes missing when using RTEMS, and this most likely is true for other parts of libbsd. IMHO we should find a way to overcome the current libbsd update blocking points and try to stay close to the FreeBSD code (maybe in a 1-3 month interval). AFAIK the big blocking point are the different views around changes of the file descriptor handling between RTEMS and BSD (this may be a bit off the real topic, I am not yet into the details). In the next week I would like to get things rolling to see the pros and cons of both possible implementations and I would be happy if those closely involved would support this. Apart from the current blocking point, can we agree that staying close the the FreeBSD code (with a 1-3 month update/sync interval) would be desirable? Kind regards to you all, Thomas. = On 2023-01-12 01:24, Gedare Bloom wrote: Hi Thomas, I think the goal you have stated is laudable and fits with the initial design goals of libbsd. I will take a closer look at this topic and report back soon, I hope. I have remained (purposefully) ignorant about libbsd evolution over time, but I guess it is time for me to learn a bit more and catch up. From what I have understood about the current blocking issue, it has to do with the changes that were made to use FreeBSD File Descriptors and the VFS. However, one of the main problems that was noted actually appears to be just related to the size increase caused by the syscall glue implemented in a single .c file. So, I will plan to start my libbsd learning adventure by trying to split that .c file apart into separate build components to see how/if that alleviates the linked image size. If successful, that should get us closer. I think we can then revisit whether or not the FreeBSD File Descriptors themselves are in fact problematic. It would also be helpful to decide if we want to clarify any requirements for libbsd maintenance. So, for example, the ability to keep it updated on a rolling basis would require good automation and validation that changes/updates remain usable. It would appear that there are some minimum resource requirements that some users of libbsd would like to remain under if possible. To ensure that would require establishing what platform(s) have resource requirements for using libbsd, and adding configurations/testing to check for when those resources are exceeded by an update. Because it is entirely plausible that an update pulls in changes from upstream that causes the resources to grow. Gedare = On 2023-01-12 08:46, Sebastian Huber wrote: Hello Gedare, On 12.01.23 01:24, Gedare Bloom wrote: Hi Thomas, I think the goal you have stated is laudable and fits with the initial design goals of libbsd. I will take a closer look at this topic and report back soon, I hope. I have remained (purposefully) ignorant about libbsd evolution over time, but I guess it is time for me to learn a bit more and catch up. yes, one of the goals of libbsd was to follow the FreeBSD upstream, however, I was the only one doing this work in the past and I was busy with other things in the last three years (mainly the RTEMS pre-qualification). We need a more automated way to keep libbsd up to date. My proposal is to focus on the master branch since the FreeBSD EOL is 31. December 2023. We could use FreeBSD 14 for the next production branch. The current libbsd synchronization support was designed to do updates from Subversion. With Git we can do things more efficiently. I would replace the libbsd build system with the one from RTEMS (waf + spec items). With the spec items we can more easily read the data in other scripts. For continuous and automatic updates I would do the following: 1. Check out the FreeBSD X branch. 2. Move all FreeBSD top-level directories under the new "freebsd" directory and merge in all updates from FreeBSD. 3. Gather the set of files imported from FreeBSD. Name the set F. 4. Pick a start FreeBSD c
Re: LIBBSD
On 29/06/17 20:02, Kirspel, Kevin wrote: For those who run a RTEMS 4.12 single processor application with LIBBSD, what percentage of time does your application spend in the timer server task? My NXP LPC3250 application spends about 13% of the processor time processing the timer server. Most of that time is spent processing LIBBSD’s kernel callouts. I am wondering if there is an advantage to only call the FreeBSD’s callout_process() function when we know a callout needs to be processed. This would reduce the number of RTEMS timer fires (which currently fire every tick). I observed a similar problem a 96MHz LPC4088. The main issue is that callout_process() loads a lot of data (64-bit integers). So, on slow memory target, you have a performance issue with 1000 ticks per second. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Libbsd situation.
Hello, if I'm right than RTEMS 6 should be accompanied with libbsd from 6-freebsd-12 branch which should be based on freebsd-12 (stable/12 branch). Please correct me if I'm wrong here. If I'm right above, then there are few things which worries me a bit: (1) FreeBSD's 12 branch is going to be EoLed soon, e.g. December 31, 2023 as claimed on https://www.freebsd.org/security/#sup (2) 6-freebsd-12 branch latest commit in freebsd-org is from Feb 9 22:15:35 2020. Based on that it looks like 6-freebsd-12 branch is >6k commits behind the FreeBSD's stable/12 branch. May this outage be solved by using libbsd master branch? It does not look like as: (i) latest commit in freebsd-org in libbsd master branch is even older than in 6-freebsd-12 and it is from Sep 24 01:58:54 2019. (ii) even if I consider Sebastian's own master-update branch available on his github.com account, it seem this branch synced with what is in 6-freebsd-12 and ends exactly on 2020-02-09. So, it looks like master is also missing few thousands patches from FreeBSD development... Anyway, my biggest worry is that RTEMS 6 libbsd may be based on source code which will lose upstream project support soon after the RTEMS 6 release (assuming RTEMS 6 will happen before Dec 31 2023). So I'm curious if with all those outdatnes it would not be good to jump and update master which would be supported by another 5 years (assuming this is stable/14 branch). E.g. the situation is exactly like with GCC where Sebastian clearly warned about it and project moved from 10 to 12 and now it looks like we will even move to GCC 13 release for RTEMS 6... Except that in case of libbsd it has not happened yet. Am I missing something or is this really a situation with libbsd as of today? Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
The RTEMS LibBSD doesn't have a documentation in the RTEMS Documentation Project. As I'm currently porting USB device drivers to LibBSD I decided to document the drivers I port in the rtems-docs. In this patch set I have added a quick-start guide and the USB template driver documentation. Husni Faiz (5): libbsd: Quick Start Guide for RTEMS LibBSD libbsd: Index for LibBSD Doc libbsd: Add conf.py and wscript for the libbsd doc. wscript: Enable build for LibBSD Doc libbsd: USB Template Driver Documentation libbsd/conf.py | 14 +++++++ libbsd/device_driver.rst | 30 +++++++ libbsd/index.rst | 24 +++++++ libbsd/introduction.rst | 8 +++ libbsd/quick_start.rst | 51 ++++ libbsd/wscript | 7 ++ wscript | 3 ++- 7 files changed, 136 insertions(+), 1 deletion(-) create mode 100644 libbsd/conf.py create mode 100644 libbsd/device_driver.rst create mode 100644 libbsd/index.rst create mode 100644 libbsd/introduction.rst create mode 100644 libbsd/quick_start.rst create mode 100644 libbsd/wscript -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 3/5] libbsd: Add conf.py and wscript for the libbsd doc.
Signed-off-by: Husni Faiz
---
libbsd/conf.py | 14 ++
libbsd/wscript | 7 +++
2 files changed, 21 insertions(+)
create mode 100644 libbsd/conf.py
create mode 100644 libbsd/wscript
diff --git a/libbsd/conf.py b/libbsd/conf.py
new file mode 100644
index 000..3f76889
--- /dev/null
+++ b/libbsd/conf.py
@@ -0,0 +1,14 @@
+import sys, os
+sys.path.insert(0, os.path.abspath('../common/'))
+
+from conf import *
+
+project = "RTEMS LibBSD User Manual"
+
+latex_documents = [
+('index',
+ 'libbsd.tex',
+ u'RTEMS LibBSD User Manual',
+ u'RTEMS Documentation Project',
+ 'manual'),
+]
diff --git a/libbsd/wscript b/libbsd/wscript
new file mode 100644
index 000..4063cd4
--- /dev/null
+++ b/libbsd/wscript
@@ -0,0 +1,7 @@
+from common.waf import cmd_configure as configure
+from common.waf import cmd_build as build
+from common.waf import cmd_options as options
+from common.waf import spell
+from common.waf import cmd_spell
+from common.waf import linkcheck
+from common.waf import cmd_linkcheck
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
Github repo https://github.com/drac98/rtems-docs/commits/libbsd On Mon, Aug 2, 2021 at 12:56 AM Husni Faiz wrote: > The RTEMS LibBSD doesn't have a documentation in the RTEMS Documentation > Project. > As I'm currently porting USB device drivers to LibBSD I decided to > document the drivers I port in the rtems-docs. > > In this patch set I have added a quick-start guide and the USB template > driver documentation. > > Husni Faiz (5): > libbsd: Quick Start Guide for RTEMS LibBSD > libbsd: Index for LibBSD Doc > libbsd: Add conf.py and wscript for the libbsd doc. > wscript: Enable build for LibBSD Doc > libbsd: USB Template Driver Documentation > > libbsd/conf.py | 14 +++ > libbsd/device_driver.rst | 30 +++ > libbsd/index.rst | 24 +++ > libbsd/introduction.rst | 8 +++ > libbsd/quick_start.rst | 51 > libbsd/wscript | 7 ++ > wscript | 3 ++- > 7 files changed, 136 insertions(+), 1 deletion(-) > create mode 100644 libbsd/conf.py > create mode 100644 libbsd/device_driver.rst > create mode 100644 libbsd/index.rst > create mode 100644 libbsd/introduction.rst > create mode 100644 libbsd/quick_start.rst > create mode 100644 libbsd/wscript > > -- > 2.25.1 > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
Hello Husni, thanks for the patches. I'm sure that this will start a discussion about the right place for that documentation. libbsd documentation is a long overdue topic that has been neglected by all of us (including myself) so I think it's good to start that discussion. Best regards Christian Am 01.08.21 um 21:25 schrieb Husni Faiz: The RTEMS LibBSD doesn't have a documentation in the RTEMS Documentation Project. As I'm currently porting USB device drivers to LibBSD I decided to document the drivers I port in the rtems-docs. In this patch set I have added a quick-start guide and the USB template driver documentation. Husni Faiz (5): libbsd: Quick Start Guide for RTEMS LibBSD libbsd: Index for LibBSD Doc libbsd: Add conf.py and wscript for the libbsd doc. wscript: Enable build for LibBSD Doc libbsd: USB Template Driver Documentation libbsd/conf.py | 14 +++ libbsd/device_driver.rst | 30 +++++++ libbsd/index.rst | 24 +++++++ libbsd/introduction.rst | 8 +++ libbsd/quick_start.rst | 51 ++++++++ libbsd/wscript | 7 ++ wscript | 3 ++- 7 files changed, 136 insertions(+), 1 deletion(-) create mode 100644 libbsd/conf.py create mode 100644 libbsd/device_driver.rst create mode 100644 libbsd/index.rst create mode 100644 libbsd/introduction.rst create mode 100644 libbsd/quick_start.rst create mode 100644 libbsd/wscript -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
On 2/8/21 4:58 pm, Christian MAUDERER wrote: > Hello Husni, > > thanks for the patches. I'm sure that this will start a discussion about the > right place for that documentation. libbsd documentation is a long overdue > topic > that has been neglected by all of us (including myself) so I think it's good > to > start that discussion. I suggest the user manual. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
Am 02.08.21 um 10:38 schrieb Chris Johns: On 2/8/21 4:58 pm, Christian MAUDERER wrote: Hello Husni, thanks for the patches. I'm sure that this will start a discussion about the right place for that documentation. libbsd documentation is a long overdue topic that has been neglected by all of us (including myself) so I think it's good to start that discussion. I suggest the user manual. Chris Hello Chris, thanks for the suggestion. So that would be a new libbsd chapter in the user manual and not some extra manual like the "Legacy Networking User Manual"? Sooner or later most of the user facing documentation we already have in libbsd most likely would be moved there too. That would be mainly: https://git.rtems.org/rtems-libbsd/tree/README.md https://git.rtems.org/rtems-libbsd/tree/libbsd.txt The CONTRIBUTING.md is more developer facing. Would we move that in the user manual too or would that be something that should move to either "BSP and Driver Guide" or the "Software Engineering" manual: https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md Note that I don't want to push that work to anyone. I asked Husni that he adds his work to a new manual at the moment so that we have a basis for discussion. The alternative would be to continue adding information like that to the text documents in libbsd. But the text files start to get convoluted and I think a better organized manual is long overdue. I thought that Husnis work would be a great chance to trigger finding the right place so that we can add or move more documentation to that place slowly. I'm sure that I should do quite some of that too because I have added a lot of stuff to libbsd over the time. Best regards Christian -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
On Mon, Aug 2, 2021 at 7:03 AM Christian MAUDERER wrote: > > Am 02.08.21 um 10:38 schrieb Chris Johns: > > On 2/8/21 4:58 pm, Christian MAUDERER wrote: > >> Hello Husni, > >> > >> thanks for the patches. I'm sure that this will start a discussion about > >> the > >> right place for that documentation. libbsd documentation is a long overdue > >> topic > >> that has been neglected by all of us (including myself) so I think it's > >> good to > >> start that discussion. > > > > I suggest the user manual. > > > > Chris > > > > Hello Chris, > > thanks for the suggestion. So that would be a new libbsd chapter in the > user manual and not some extra manual like the "Legacy Networking User > Manual"? > @Vijay Kumar Banerjee would you anticipate a new networking manual, or just a networking subsection in the user manual? Libbsd encompasses more than just networking, so it might be sensible to give libbsd its own entire subsection. Then, lwIP could also get a subsection in the future? > Sooner or later most of the user facing documentation we already have in > libbsd most likely would be moved there too. That would be mainly: > > https://git.rtems.org/rtems-libbsd/tree/README.md > https://git.rtems.org/rtems-libbsd/tree/libbsd.txt > > The CONTRIBUTING.md is more developer facing. Would we move that in the > user manual too or would that be something that should move to either > "BSP and Driver Guide" or the "Software Engineering" manual: > Developer-facing would be moved probably to both BSP and SwE manuals, depending on the content. BSP manual requires a refresh itself, but is the right place to add guidance how to port/implement the libbsd drivers. SwE manual is the right place to document the rules to contribute to libbsd. > https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md > > Note that I don't want to push that work to anyone. I asked Husni that > he adds his work to a new manual at the moment so that we have a basis > for discussion. The alternative would be to continue adding information > like that to the text documents in libbsd. But the text files start to > get convoluted and I think a better organized manual is long overdue. I > thought that Husnis work would be a great chance to trigger finding the > right place so that we can add or move more documentation to that place > slowly. I'm sure that I should do quite some of that too because I have > added a lot of stuff to libbsd over the time. > > Best regards > > Christian > -- > > embedded brains GmbH > Herr Christian MAUDERER > Dornierstr. 4 > 82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > phone: +49-89-18 94 741 - 18 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > ___ > 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 rtems-libbsd 0/5] RTEMS LibBSD Documentation
On Mon, Aug 2, 2021 at 10:11 AM Gedare Bloom wrote: > > On Mon, Aug 2, 2021 at 7:03 AM Christian MAUDERER > wrote: > > > > Am 02.08.21 um 10:38 schrieb Chris Johns: > > > On 2/8/21 4:58 pm, Christian MAUDERER wrote: > > >> Hello Husni, > > >> > > >> thanks for the patches. I'm sure that this will start a discussion about > > >> the > > >> right place for that documentation. libbsd documentation is a long > > >> overdue topic > > >> that has been neglected by all of us (including myself) so I think it's > > >> good to > > >> start that discussion. > > > > > > I suggest the user manual. > > > > > > Chris > > > > > > > Hello Chris, > > > > thanks for the suggestion. So that would be a new libbsd chapter in the > > user manual and not some extra manual like the "Legacy Networking User > > Manual"? > > > @Vijay Kumar Banerjee would you anticipate a new networking manual, or > just a networking subsection in the user manual? Libbsd encompasses > more than just networking, so it might be sensible to give libbsd its > own entire subsection. Then, lwIP could also get a subsection in the > future? > I think there should be a high-level user manual subsection for networking that describes how the selection of the network stack works. We can then add another subsection about lwip since legacy already has one, and libbsd is getting added now. > > Sooner or later most of the user facing documentation we already have in > > libbsd most likely would be moved there too. That would be mainly: > > > > https://git.rtems.org/rtems-libbsd/tree/README.md > > https://git.rtems.org/rtems-libbsd/tree/libbsd.txt > > > > The CONTRIBUTING.md is more developer facing. Would we move that in the > > user manual too or would that be something that should move to either > > "BSP and Driver Guide" or the "Software Engineering" manual: > > > Developer-facing would be moved probably to both BSP and SwE manuals, > depending on the content. BSP manual requires a refresh itself, but is > the right place to add guidance how to port/implement the libbsd > drivers. SwE manual is the right place to document the rules to > contribute to libbsd. > > > https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md > > > > Note that I don't want to push that work to anyone. I asked Husni that > > he adds his work to a new manual at the moment so that we have a basis > > for discussion. The alternative would be to continue adding information > > like that to the text documents in libbsd. But the text files start to > > get convoluted and I think a better organized manual is long overdue. I > > thought that Husnis work would be a great chance to trigger finding the > > right place so that we can add or move more documentation to that place > > slowly. I'm sure that I should do quite some of that too because I have > > added a lot of stuff to libbsd over the time. > > > > Best regards > > > > Christian > > -- > > > > embedded brains GmbH > > Herr Christian MAUDERER > > Dornierstr. 4 > > 82178 Puchheim > > Germany > > email: christian.maude...@embedded-brains.de > > phone: +49-89-18 94 741 - 18 > > fax: +49-89-18 94 741 - 08 > > > > Registergericht: Amtsgericht München > > Registernummer: HRB 157899 > > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > > Unsere Datenschutzerklärung finden Sie hier: > > https://embedded-brains.de/datenschutzerklaerung/ > > ___ > > 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 rtems-libbsd 0/5] RTEMS LibBSD Documentation
On 02/08/2021 18:37, Vijay Kumar Banerjee wrote: I think there should be a high-level user manual subsection for networking that describes how the selection of the network stack works. We can then add another subsection about lwip since legacy already has one, and libbsd is getting added now. This sounds like a good approach. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
On 3/8/21 3:24 am, Sebastian Huber wrote: > On 02/08/2021 18:37, Vijay Kumar Banerjee wrote: >> I think there should be a high-level user manual subsection for >> networking that describes how the selection of the network stack >> works. We can then add another subsection about lwip since legacy >> already has one, and libbsd is getting added now. > > This sounds like a good approach. > I agree. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
Hello, Am 03.08.21 um 04:07 schrieb Chris Johns: On 3/8/21 3:24 am, Sebastian Huber wrote: On 02/08/2021 18:37, Vijay Kumar Banerjee wrote: I think there should be a high-level user manual subsection for networking that describes how the selection of the network stack works. We can then add another subsection about lwip since legacy already has one, and libbsd is getting added now. This sounds like a good approach. I agree. Chris Just so that we are all on the same page: That would be a number of new subsections in https://docs.rtems.org/branches/master/user/index.html: - 15. Selecting a Network Stack - 16. Add-on: libbsd Stack - 17. Add-on: lwIP - 18. Add-on: Legacy Network Stack Or was it meant to be only a section - 15. Selecting a Network Stack in https://docs.rtems.org/branches/master/user/index.html, - a new manual "libbsd" in the top level https://docs.rtems.org/, - a new manual "lwip" in the top level https://docs.rtems.org/ By the way: I think we maybe should keep in mind that there can be more add-on packages added some-when in the future that are not network stacks. We could for example add documentation for a CAN library, a display library or a weather control station. So if we need a top level name for all packages, we maybe should call it "add-on packages" instead of "network libraries". Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
On 3/8/21 5:00 pm, Christian MAUDERER wrote: > Hello, > > Am 03.08.21 um 04:07 schrieb Chris Johns: >> On 3/8/21 3:24 am, Sebastian Huber wrote: >>> On 02/08/2021 18:37, Vijay Kumar Banerjee wrote: >>>> I think there should be a high-level user manual subsection for >>>> networking that describes how the selection of the network stack >>>> works. We can then add another subsection about lwip since legacy >>>> already has one, and libbsd is getting added now. >>> >>> This sounds like a good approach. >>> >> >> I agree. >> >> Chris > > Just so that we are all on the same page: > > That would be a number of new subsections in > https://docs.rtems.org/branches/master/user/index.html: > > - 15. Selecting a Network Stack > - 16. Add-on: libbsd Stack > - 17. Add-on: lwIP > - 18. Add-on: Legacy Network Stack > > Or was it meant to be only a section I think a single section so all things networking are grouped. Chris > > - 15. Selecting a Network Stack > in https://docs.rtems.org/branches/master/user/index.html, > - a new manual "libbsd" in the top level https://docs.rtems.org/, > - a new manual "lwip" in the top level https://docs.rtems.org/ > > By the way: I think we maybe should keep in mind that there can be more add-on > packages added some-when in the future that are not network stacks. We could > for > example add documentation for a CAN library, a display library or a weather > control station. So if we need a top level name for all packages, we maybe > should call it "add-on packages" instead of "network libraries". > > Best regards > > Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
Hello Chris, Am 04.08.21 um 09:28 schrieb Chris Johns: On 3/8/21 5:00 pm, Christian MAUDERER wrote: Hello, Am 03.08.21 um 04:07 schrieb Chris Johns: On 3/8/21 3:24 am, Sebastian Huber wrote: On 02/08/2021 18:37, Vijay Kumar Banerjee wrote: I think there should be a high-level user manual subsection for networking that describes how the selection of the network stack works. We can then add another subsection about lwip since legacy already has one, and libbsd is getting added now. This sounds like a good approach. I agree. Chris Just so that we are all on the same page: That would be a number of new subsections in https://docs.rtems.org/branches/master/user/index.html: - 15. Selecting a Network Stack - 16. Add-on: libbsd Stack - 17. Add-on: lwIP - 18. Add-on: Legacy Network Stack Or was it meant to be only a section I think a single section so all things networking are grouped. That will result in either a deep nesting for the chapters or in very hard to organize information because two levels are used up already. For example the current legacy network manual has a 5.3.1. Additional include files If we make one "networking" group, that would be 15. Networking 15.3 Legacy Network Stack 15.3.5 Using Networking in an RTEMS application 15.3.5.3 Initialization 15.3.5.3.1 Additional include files And please also note: I think we should see libbsd more as an Add-on package and less as a pure network stack. It provides a lot more than just networking. It has USB, it can add HDMI (on beagle for example), it includes an OpenSSL implementation, ... Best regards Christian Chris - 15. Selecting a Network Stack in https://docs.rtems.org/branches/master/user/index.html, - a new manual "libbsd" in the top level https://docs.rtems.org/, - a new manual "lwip" in the top level https://docs.rtems.org/ By the way: I think we maybe should keep in mind that there can be more add-on packages added some-when in the future that are not network stacks. We could for example add documentation for a CAN library, a display library or a weather control station. So if we need a top level name for all packages, we maybe should call it "add-on packages" instead of "network libraries". Best regards Christian -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
On 4/8/21 6:34 pm, Christian MAUDERER wrote: > Hello Chris, > > Am 04.08.21 um 09:28 schrieb Chris Johns: >> On 3/8/21 5:00 pm, Christian MAUDERER wrote: >>> Hello, >>> >>> Am 03.08.21 um 04:07 schrieb Chris Johns: >>>> On 3/8/21 3:24 am, Sebastian Huber wrote: >>>>> On 02/08/2021 18:37, Vijay Kumar Banerjee wrote: >>>>>> I think there should be a high-level user manual subsection for >>>>>> networking that describes how the selection of the network stack >>>>>> works. We can then add another subsection about lwip since legacy >>>>>> already has one, and libbsd is getting added now. >>>>> >>>>> This sounds like a good approach. >>>>> >>>> >>>> I agree. >>>> >>>> Chris >>> >>> Just so that we are all on the same page: >>> >>> That would be a number of new subsections in >>> https://docs.rtems.org/branches/master/user/index.html: >>> >>> - 15. Selecting a Network Stack >>> - 16. Add-on: libbsd Stack >>> - 17. Add-on: lwIP >>> - 18. Add-on: Legacy Network Stack >>> >>> Or was it meant to be only a section >> >> I think a single section so all things networking are grouped. > > That will result in either a deep nesting for the chapters or in very hard to > organize information because two levels are used up already. > > For example the current legacy network manual has a > > 5.3.1. Additional include files > > If we make one "networking" group, that would be > > 15. Networking > 15.3 Legacy Network Stack > 15.3.5 Using Networking in an RTEMS application > 15.3.5.3 Initialization > 15.3.5.3.1 Additional include files > > And please also note: I think we should see libbsd more as an Add-on package > and > less as a pure network stack. Yes this is true and if your top level is LibBSD you do not see networking and then networking becomes confusing if spread out in pieces. What would LibBSD and Legacy Networking mean if you are new RTEMS? Is Legacy networking some form of old embedded realtime protocol we support? :) Maybe Networking is about the history, features and options available in each package (Selection) and the LibBSD part is a link to the networking section of that package? This would mean the lwIP and Legacy network stack is still under Networking. Does "Additional includes" etc need to be a numbered section? Why not just make a heading in the block without it being a section? > It provides a lot more than just networking. It > has USB, it can add HDMI (on beagle for example), it includes an OpenSSL > implementation, ... Yes and if you look at the top level you could see something like: 9 Networking 10 USB 11 Graphics 12 FreeBSD On RTEMS The user manual has clear top level sections and I would like it to stay this way. But yes I understand it is hard to get the breakdown right and it may take a couple more loops until we have something that is clear. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
Hello Chris, Am 04.08.21 um 11:17 schrieb Chris Johns: On 4/8/21 6:34 pm, Christian MAUDERER wrote: Hello Chris, Am 04.08.21 um 09:28 schrieb Chris Johns: On 3/8/21 5:00 pm, Christian MAUDERER wrote: Hello, Am 03.08.21 um 04:07 schrieb Chris Johns: On 3/8/21 3:24 am, Sebastian Huber wrote: On 02/08/2021 18:37, Vijay Kumar Banerjee wrote: I think there should be a high-level user manual subsection for networking that describes how the selection of the network stack works. We can then add another subsection about lwip since legacy already has one, and libbsd is getting added now. This sounds like a good approach. I agree. Chris Just so that we are all on the same page: That would be a number of new subsections in https://docs.rtems.org/branches/master/user/index.html: - 15. Selecting a Network Stack - 16. Add-on: libbsd Stack - 17. Add-on: lwIP - 18. Add-on: Legacy Network Stack Or was it meant to be only a section I think a single section so all things networking are grouped. That will result in either a deep nesting for the chapters or in very hard to organize information because two levels are used up already. For example the current legacy network manual has a 5.3.1. Additional include files If we make one "networking" group, that would be 15. Networking 15.3 Legacy Network Stack 15.3.5 Using Networking in an RTEMS application 15.3.5.3 Initialization 15.3.5.3.1 Additional include files And please also note: I think we should see libbsd more as an Add-on package and less as a pure network stack. Yes this is true and if your top level is LibBSD you do not see networking and then networking becomes confusing if spread out in pieces. What would LibBSD and Legacy Networking mean if you are new RTEMS? Is Legacy networking some form of old embedded realtime protocol we support? :) Maybe Networking is about the history, features and options available in each package (Selection) and the LibBSD part is a link to the networking section of that package? This would mean the lwIP and Legacy network stack is still under Networking. Hm. You are right that we have to somehow make it clear what features can be provided by the libraries. Does "Additional includes" etc need to be a numbered section? Why not just make a heading in the block without it being a section? It was more or less an example that I just took from the current legacy networking manual. I think that manual should be about at the same location and I don't think that anyone wants to do a detailed re-write. So most likely we will just move the levels down. It provides a lot more than just networking. It has USB, it can add HDMI (on beagle for example), it includes an OpenSSL implementation, ... Yes and if you look at the top level you could see something like: 9 Networking 10 USB 11 Graphics 12 FreeBSD On RTEMS The user manual has clear top level sections and I would like it to stay this way. But yes I understand it is hard to get the breakdown right and it may take a couple more loops until we have something that is clear. Hm. That would mean that we split up the libbsd documentation to multiple sections (at least networking and USB). Where can we put common parts like "how to init libbsd"? We also have multiple options in every section. For example OpenSSL can be provided by libbsd or by OpenSSL / LibreSSL / *SSL. Could be difficult for a user to find out how and which libs he can combine to get what he wants. For example some user could start with lwIP for networking and then later wants to add USB and SD/MMC and notes that in that case it would have been a better choice to use libbsd for networking in that case too. We could add a chapter "Selecting Add-Ons" or "Selecting Libraries" with a short description of the libs and when they are alternatives or when they complement each other. Then we can either add the manual of the libs or Add-Ons as subsections (disadvantage: deep nesting) or we can add them with some common prefix so that a user knows that he maybe should first look into the "Selecting ". Best regards Christian Chris -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
On Wed, Aug 4, 2021 at 4:18 AM Christian MAUDERER wrote: > > Hello Chris, > > Am 04.08.21 um 11:17 schrieb Chris Johns: > > > > > > On 4/8/21 6:34 pm, Christian MAUDERER wrote: > >> Hello Chris, > >> > >> Am 04.08.21 um 09:28 schrieb Chris Johns: > >>> On 3/8/21 5:00 pm, Christian MAUDERER wrote: > >>>> Hello, > >>>> > >>>> Am 03.08.21 um 04:07 schrieb Chris Johns: > >>>>> On 3/8/21 3:24 am, Sebastian Huber wrote: > >>>>>> On 02/08/2021 18:37, Vijay Kumar Banerjee wrote: > >>>>>>> I think there should be a high-level user manual subsection for > >>>>>>> networking that describes how the selection of the network stack > >>>>>>> works. We can then add another subsection about lwip since legacy > >>>>>>> already has one, and libbsd is getting added now. > >>>>>> > >>>>>> This sounds like a good approach. > >>>>>> > >>>>> > >>>>> I agree. > >>>>> > >>>>> Chris > >>>> > >>>> Just so that we are all on the same page: > >>>> > >>>> That would be a number of new subsections in > >>>> https://docs.rtems.org/branches/master/user/index.html: > >>>> > >>>> - 15. Selecting a Network Stack > >>>> - 16. Add-on: libbsd Stack > >>>> - 17. Add-on: lwIP > >>>> - 18. Add-on: Legacy Network Stack > >>>> > >>>> Or was it meant to be only a section > >>> > >>> I think a single section so all things networking are grouped. > >> > >> That will result in either a deep nesting for the chapters or in very hard > >> to > >> organize information because two levels are used up already. > >> > >> For example the current legacy network manual has a > >> > >>5.3.1. Additional include files > >> > >> If we make one "networking" group, that would be > >> > >>15. Networking > >>15.3 Legacy Network Stack > >>15.3.5 Using Networking in an RTEMS application > >>15.3.5.3 Initialization > >>15.3.5.3.1 Additional include files > >> > >> And please also note: I think we should see libbsd more as an Add-on > >> package and > >> less as a pure network stack. > > > > Yes this is true and if your top level is LibBSD you do not see networking > > and > > then networking becomes confusing if spread out in pieces. What would > > LibBSD and > > Legacy Networking mean if you are new RTEMS? Is Legacy networking some form > > of > > old embedded realtime protocol we support? :) > > > > Maybe Networking is about the history, features and options available in > > each > > package (Selection) and the LibBSD part is a link to the networking section > > of > > that package? This would mean the lwIP and Legacy network stack is still > > under > > Networking. > > Hm. You are right that we have to somehow make it clear what features > can be provided by the libraries. > > > > > Does "Additional includes" etc need to be a numbered section? Why not just > > make > > a heading in the block without it being a section? > > It was more or less an example that I just took from the current legacy > networking manual. I think that manual should be about at the same > location and I don't think that anyone wants to do a detailed re-write. > So most likely we will just move the levels down. > > > > >> It provides a lot more than just networking. It > >> has USB, it can add HDMI (on beagle for example), it includes an OpenSSL > >> implementation, ... > > > > Yes and if you look at the top level you could see something like: > > > > 9 Networking > > 10 USB > > 11 Graphics > > 12 FreeBSD On RTEMS +1 > > > > The user manual has clear top level sections and I would like it to stay > > this > > way. But yes I understand it is hard to get the breakdown right and it may > > take > > a couple more loops until we have something that is clear. > > Hm. That would mean that we split up the libbsd documentation to > multiple sections (at least networking and USB). Where can we put common > parts like "how to init libbsd"? > > We also have multiple options in every section. For example OpenSSL
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
Hello Gedare, Am 04.08.21 um 16:55 schrieb Gedare Bloom: On Wed, Aug 4, 2021 at 4:18 AM Christian MAUDERER wrote: Hello Chris, Am 04.08.21 um 11:17 schrieb Chris Johns: On 4/8/21 6:34 pm, Christian MAUDERER wrote: Hello Chris, Am 04.08.21 um 09:28 schrieb Chris Johns: On 3/8/21 5:00 pm, Christian MAUDERER wrote: Hello, Am 03.08.21 um 04:07 schrieb Chris Johns: On 3/8/21 3:24 am, Sebastian Huber wrote: On 02/08/2021 18:37, Vijay Kumar Banerjee wrote: I think there should be a high-level user manual subsection for networking that describes how the selection of the network stack works. We can then add another subsection about lwip since legacy already has one, and libbsd is getting added now. This sounds like a good approach. I agree. Chris Just so that we are all on the same page: That would be a number of new subsections in https://docs.rtems.org/branches/master/user/index.html: - 15. Selecting a Network Stack - 16. Add-on: libbsd Stack - 17. Add-on: lwIP - 18. Add-on: Legacy Network Stack Or was it meant to be only a section I think a single section so all things networking are grouped. That will result in either a deep nesting for the chapters or in very hard to organize information because two levels are used up already. For example the current legacy network manual has a 5.3.1. Additional include files If we make one "networking" group, that would be 15. Networking 15.3 Legacy Network Stack 15.3.5 Using Networking in an RTEMS application 15.3.5.3 Initialization 15.3.5.3.1 Additional include files And please also note: I think we should see libbsd more as an Add-on package and less as a pure network stack. Yes this is true and if your top level is LibBSD you do not see networking and then networking becomes confusing if spread out in pieces. What would LibBSD and Legacy Networking mean if you are new RTEMS? Is Legacy networking some form of old embedded realtime protocol we support? :) Maybe Networking is about the history, features and options available in each package (Selection) and the LibBSD part is a link to the networking section of that package? This would mean the lwIP and Legacy network stack is still under Networking. Hm. You are right that we have to somehow make it clear what features can be provided by the libraries. Does "Additional includes" etc need to be a numbered section? Why not just make a heading in the block without it being a section? It was more or less an example that I just took from the current legacy networking manual. I think that manual should be about at the same location and I don't think that anyone wants to do a detailed re-write. So most likely we will just move the levels down. It provides a lot more than just networking. It has USB, it can add HDMI (on beagle for example), it includes an OpenSSL implementation, ... Yes and if you look at the top level you could see something like: 9 Networking 10 USB 11 Graphics 12 FreeBSD On RTEMS +1 The user manual has clear top level sections and I would like it to stay this way. But yes I understand it is hard to get the breakdown right and it may take a couple more loops until we have something that is clear. Hm. That would mean that we split up the libbsd documentation to multiple sections (at least networking and USB). Where can we put common parts like "how to init libbsd"? We also have multiple options in every section. For example OpenSSL can be provided by libbsd or by OpenSSL / LibreSSL / *SSL. Could be difficult for a user to find out how and which libs he can combine to get what he wants. For example some user could start with lwIP for networking and then later wants to add USB and SD/MMC and notes that in that case it would have been a better choice to use libbsd for networking in that case too. We could add a chapter "Selecting Add-Ons" or "Selecting Libraries" with a short description of the libs and when they are alternatives or when I'd like this as well. A library of libraries :) [technically, an index of libraries] they complement each other. Then we can either add the manual of the libs or Add-Ons as subsections (disadvantage: deep nesting) or we can add them with some common prefix so that a user knows that he maybe should first look into the "Selecting ". +1 My preference would be to leave the legacy doc where it is, Just a comment for that point: I know that the doc has been moved around a bit. But I think we should try to get all similar options onto the same "level". Otherwise if a user searches for "How to do networking with RTEMS" and he finds https://docs.rtems.org/ the only manual with "Networking" is the legacy stack. If it is on the same page (level, hirarchie, ...) like the headline "libbsd Networking and other cool stuff" or "lwIP", a user instantly can see that there is mo
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
On Wed, Aug 4, 2021 at 9:05 AM Christian MAUDERER wrote: > > Hello Gedare, > > Am 04.08.21 um 16:55 schrieb Gedare Bloom: > > On Wed, Aug 4, 2021 at 4:18 AM Christian MAUDERER > > wrote: > >> > >> Hello Chris, > >> > >> Am 04.08.21 um 11:17 schrieb Chris Johns: > >>> > >>> > >>> On 4/8/21 6:34 pm, Christian MAUDERER wrote: > >>>> Hello Chris, > >>>> > >>>> Am 04.08.21 um 09:28 schrieb Chris Johns: > >>>>> On 3/8/21 5:00 pm, Christian MAUDERER wrote: > >>>>>> Hello, > >>>>>> > >>>>>> Am 03.08.21 um 04:07 schrieb Chris Johns: > >>>>>>> On 3/8/21 3:24 am, Sebastian Huber wrote: > >>>>>>>> On 02/08/2021 18:37, Vijay Kumar Banerjee wrote: > >>>>>>>>> I think there should be a high-level user manual subsection for > >>>>>>>>> networking that describes how the selection of the network stack > >>>>>>>>> works. We can then add another subsection about lwip since legacy > >>>>>>>>> already has one, and libbsd is getting added now. > >>>>>>>> > >>>>>>>> This sounds like a good approach. > >>>>>>>> > >>>>>>> > >>>>>>> I agree. > >>>>>>> > >>>>>>> Chris > >>>>>> > >>>>>> Just so that we are all on the same page: > >>>>>> > >>>>>> That would be a number of new subsections in > >>>>>> https://docs.rtems.org/branches/master/user/index.html: > >>>>>> > >>>>>> - 15. Selecting a Network Stack > >>>>>> - 16. Add-on: libbsd Stack > >>>>>> - 17. Add-on: lwIP > >>>>>> - 18. Add-on: Legacy Network Stack > >>>>>> > >>>>>> Or was it meant to be only a section > >>>>> > >>>>> I think a single section so all things networking are grouped. > >>>> > >>>> That will result in either a deep nesting for the chapters or in very > >>>> hard to > >>>> organize information because two levels are used up already. > >>>> > >>>> For example the current legacy network manual has a > >>>> > >>>> 5.3.1. Additional include files > >>>> > >>>> If we make one "networking" group, that would be > >>>> > >>>> 15. Networking > >>>> 15.3 Legacy Network Stack > >>>> 15.3.5 Using Networking in an RTEMS application > >>>> 15.3.5.3 Initialization > >>>> 15.3.5.3.1 Additional include files > >>>> > >>>> And please also note: I think we should see libbsd more as an Add-on > >>>> package and > >>>> less as a pure network stack. > >>> > >>> Yes this is true and if your top level is LibBSD you do not see > >>> networking and > >>> then networking becomes confusing if spread out in pieces. What would > >>> LibBSD and > >>> Legacy Networking mean if you are new RTEMS? Is Legacy networking some > >>> form of > >>> old embedded realtime protocol we support? :) > >>> > >>> Maybe Networking is about the history, features and options available in > >>> each > >>> package (Selection) and the LibBSD part is a link to the networking > >>> section of > >>> that package? This would mean the lwIP and Legacy network stack is still > >>> under > >>> Networking. > >> > >> Hm. You are right that we have to somehow make it clear what features > >> can be provided by the libraries. > >> > >>> > >>> Does "Additional includes" etc need to be a numbered section? Why not > >>> just make > >>> a heading in the block without it being a section? > >> > >> It was more or less an example that I just took from the current legacy > >> networking manual. I think that manual should be about at the same > >> location and I don't think that anyone wants to do a detailed re-write. > >> So most likely we will just move the levels down. > >> > >>> > >>>>
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
On 04/08/2021 18:09, Gedare Bloom wrote: On Wed, Aug 4, 2021 at 9:05 AM Christian MAUDERER wrote: Hello Gedare, Am 04.08.21 um 16:55 schrieb Gedare Bloom: On Wed, Aug 4, 2021 at 4:18 AM Christian MAUDERER wrote: Hello Chris, Am 04.08.21 um 11:17 schrieb Chris Johns: On 4/8/21 6:34 pm, Christian MAUDERER wrote: Hello Chris, Am 04.08.21 um 09:28 schrieb Chris Johns: On 3/8/21 5:00 pm, Christian MAUDERER wrote: Hello, Am 03.08.21 um 04:07 schrieb Chris Johns: On 3/8/21 3:24 am, Sebastian Huber wrote: On 02/08/2021 18:37, Vijay Kumar Banerjee wrote: I think there should be a high-level user manual subsection for networking that describes how the selection of the network stack works. We can then add another subsection about lwip since legacy already has one, and libbsd is getting added now. This sounds like a good approach. I agree. Chris Just so that we are all on the same page: That would be a number of new subsections in https://docs.rtems.org/branches/master/user/index.html: - 15. Selecting a Network Stack - 16. Add-on: libbsd Stack - 17. Add-on: lwIP - 18. Add-on: Legacy Network Stack Or was it meant to be only a section I think a single section so all things networking are grouped. That will result in either a deep nesting for the chapters or in very hard to organize information because two levels are used up already. For example the current legacy network manual has a 5.3.1. Additional include files If we make one "networking" group, that would be 15. Networking 15.3 Legacy Network Stack 15.3.5 Using Networking in an RTEMS application 15.3.5.3 Initialization 15.3.5.3.1 Additional include files And please also note: I think we should see libbsd more as an Add-on package and less as a pure network stack. Yes this is true and if your top level is LibBSD you do not see networking and then networking becomes confusing if spread out in pieces. What would LibBSD and Legacy Networking mean if you are new RTEMS? Is Legacy networking some form of old embedded realtime protocol we support? :) Maybe Networking is about the history, features and options available in each package (Selection) and the LibBSD part is a link to the networking section of that package? This would mean the lwIP and Legacy network stack is still under Networking. Hm. You are right that we have to somehow make it clear what features can be provided by the libraries. Does "Additional includes" etc need to be a numbered section? Why not just make a heading in the block without it being a section? It was more or less an example that I just took from the current legacy networking manual. I think that manual should be about at the same location and I don't think that anyone wants to do a detailed re-write. So most likely we will just move the levels down. It provides a lot more than just networking. It has USB, it can add HDMI (on beagle for example), it includes an OpenSSL implementation, ... Yes and if you look at the top level you could see something like: 9 Networking 10 USB 11 Graphics 12 FreeBSD On RTEMS +1 The user manual has clear top level sections and I would like it to stay this way. But yes I understand it is hard to get the breakdown right and it may take a couple more loops until we have something that is clear. Hm. That would mean that we split up the libbsd documentation to multiple sections (at least networking and USB). Where can we put common parts like "how to init libbsd"? We also have multiple options in every section. For example OpenSSL can be provided by libbsd or by OpenSSL / LibreSSL / *SSL. Could be difficult for a user to find out how and which libs he can combine to get what he wants. For example some user could start with lwIP for networking and then later wants to add USB and SD/MMC and notes that in that case it would have been a better choice to use libbsd for networking in that case too. We could add a chapter "Selecting Add-Ons" or "Selecting Libraries" with a short description of the libs and when they are alternatives or when I'd like this as well. A library of libraries :) [technically, an index of libraries] they complement each other. Then we can either add the manual of the libs or Add-Ons as subsections (disadvantage: deep nesting) or we can add them with some common prefix so that a user knows that he maybe should first look into the "Selecting ". +1 My preference would be to leave the legacy doc where it is, Just a comment for that point: I know that the doc has been moved around a bit. But I think we should try to get all similar options onto the same "level". Otherwise if a user searches for "How to do networking with RTEMS" and he finds https://docs.rtems.org/ the only manual with "Networking" is the legacy stack. If it is on the same page (level, hirarchie, ...) like the headline &quo
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
On 5/8/21 2:22 am, Christian Mauderer wrote: > On 04/08/2021 18:09, Gedare Bloom wrote: >> On Wed, Aug 4, 2021 at 9:05 AM Christian MAUDERER >> wrote: >>> Am 04.08.21 um 16:55 schrieb Gedare Bloom: >>>> On Wed, Aug 4, 2021 at 4:18 AM Christian MAUDERER >>>> wrote: >>>> My preference would be to leave the legacy doc where it is, >>> >>> Just a comment for that point: I know that the doc has been moved around >>> a bit. But I think we should try to get all similar options onto the >>> same "level". Otherwise if a user searches for "How to do networking >>> with RTEMS" and he finds https://docs.rtems.org/ the only manual with >>> "Networking" is the legacy stack. If it is on the same page (level, >>> hirarchie, ...) like the headline "libbsd Networking and other cool >>> stuff" or "lwIP", a user instantly can see that there is more than one >>> option. >>> >> >> That's a good point, but I want to keep the legacy stack separate from >> the rest of the documentation to make it simpler to deprecate/obsolete >> it. I don't see value in moving it, just to kill it in the next >> release. AFAIK, we will strongly discourage anyone from using it in >> rtems-6, and I'd like to kill it off moving forward once we feel >> confident that lwIP is feasible for us to maintain. Your point about >> marketing is well-taken though. > > OK. I didn't expect that we are that far that we already plan to (maybe) > remove > it in the next release. In that case I agree: It's not worth the effort to > move it. > Should something be added to the legacy manual indicating it's status? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
> On Aug 4, 2021, at 18:42 , Chris Johns wrote: > > On 5/8/21 2:22 am, Christian Mauderer wrote: >> On 04/08/2021 18:09, Gedare Bloom wrote: >>> On Wed, Aug 4, 2021 at 9:05 AM Christian MAUDERER >>> wrote: >>>> Am 04.08.21 um 16:55 schrieb Gedare Bloom: >>>>> On Wed, Aug 4, 2021 at 4:18 AM Christian MAUDERER >>>>> wrote: >>>>> My preference would be to leave the legacy doc where it is, >>>> >>>> Just a comment for that point: I know that the doc has been moved around >>>> a bit. But I think we should try to get all similar options onto the >>>> same "level". Otherwise if a user searches for "How to do networking >>>> with RTEMS" and he finds https://docs.rtems.org/ the only manual with >>>> "Networking" is the legacy stack. If it is on the same page (level, >>>> hirarchie, ...) like the headline "libbsd Networking and other cool >>>> stuff" or "lwIP", a user instantly can see that there is more than one >>>> option. >>>> >>> >>> That's a good point, but I want to keep the legacy stack separate from >>> the rest of the documentation to make it simpler to deprecate/obsolete >>> it. I don't see value in moving it, just to kill it in the next >>> release. AFAIK, we will strongly discourage anyone from using it in >>> rtems-6, and I'd like to kill it off moving forward once we feel >>> confident that lwIP is feasible for us to maintain. Your point about >>> marketing is well-taken though. >> >> OK. I didn't expect that we are that far that we already plan to (maybe) >> remove >> it in the next release. In that case I agree: It's not worth the effort to >> move it. >> > > Should something be added to the legacy manual indicating it's status? > Is this realistic? I looked at the list of board support packages output by "./rtems-bsps" in RTEMS-6 and there are many old ones (M68K, old VME boards) that I assume use the legacy stack and aren't likely to be updated to use LWIP or "libbsd" and where the old stack works and has a small memory foot print. I understand not adding new drivers to legacy but deprecating the stack requires deprecation and freezing at a given release of those BSPs. That's OK with me, the use of these must be primarily maintenance. I think all these points need to be explained. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Prioritizing and documenting libbsd development goals (was: libbsd updates)
Hello, like suggested earlier in the original discussion I would suggest to prioritize our development goals for libbsd and later evaluate the two problems discussed in the thread based on this. Let's first agree on development goals (that also can be added to the libbsd documentation). From the thread and responses, I currently have collected the following goals / priorities. I replaced my original extensibility and debuggability with Joels transparency because it's a good summary term for these two points. From highest to lowest priority: - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Real time capabilities: No hard real time requirements for libbsd core but we have to make sure that it doesn't have a negative impact on other subsystems. - Performance: Whether libbsd performes well enough in the typical use cases. That means (for example): If it makes the system more maintainable, the performance isn't that important. If it reduces the size, we can trade off some performance or real time capabilities. Would you prioritize different? Did I miss some additional points from the discussion? Best regards Christian On 2023-01-20 08:32, Christian MAUDERER wrote: Hello, recently an internal discussion about updates in the libbsd started. All who participated in the discussion agreed that we should move the discussion to a public one. Below you can find the mail thread. It's oldest mail first. Mails are split with lines of = signs. I removed some duplicated mail text in case there were no inline comments. The date/time of the mails are in my current locale which is UTC+1. Best regards Christian = On 2023-01-03 16:52, Thomas DOERFLER wrote: Hello, first of all I wish you all a healthy, happy and successful new year. Unfortunately I already have to re-raise an issue: One of our customers has asked us about the RTEMS libbsd update policy. Since we still use a rather old libbsd version, it contains "OpenSSL 1.1.1d-freebsd 10 Sep 2019", there are many openSSL fixes missing when using RTEMS, and this most likely is true for other parts of libbsd. IMHO we should find a way to overcome the current libbsd update blocking points and try to stay close to the FreeBSD code (maybe in a 1-3 month interval). AFAIK the big blocking point are the different views around changes of the file descriptor handling between RTEMS and BSD (this may be a bit off the real topic, I am not yet into the details). In the next week I would like to get things rolling to see the pros and cons of both possible implementations and I would be happy if those closely involved would support this. Apart from the current blocking point, can we agree that staying close the the FreeBSD code (with a 1-3 month update/sync interval) would be desirable? Kind regards to you all, Thomas. = On 2023-01-12 01:24, Gedare Bloom wrote: Hi Thomas, I think the goal you have stated is laudable and fits with the initial design goals of libbsd. I will take a closer look at this topic and report back soon, I hope. I have remained (purposefully) ignorant about libbsd evolution over time, but I guess it is time for me to learn a bit more and catch up. From what I have understood about the current blocking issue, it has to do with the changes that were made to use FreeBSD File Descriptors and the VFS. However, one of the main problems that was noted actually appears to be just related to the size increase caused by the syscall glue implemented in a single .c file. So, I will plan to start my libbsd learning adventure by trying to split that .c file apart into separate build components to see how/if that alleviates the linked image size. If successful, that should get us closer. I think we can then revisit whether or not the FreeBSD File Descriptors themselves are in fact problematic. It would also be helpful to decide if we want to clarify any requirements for libbsd maintenance. So, for example, the ability to keep it updated on a rolling basis would require good automation and validation that changes/updates remain usable. It would appear that there are some minimum resource requirements that some users of libbsd would like to remain under if possible. To ensure that would require establishing what platform(s) have resource requirements for using libbsd, and adding configurations/testing to check for when those resources are exceeded b
Multicast in Libbsd
Hi I have an example FACE application I am trying to port to RTEMS. This is a multi-question email: First, it fails with EADDRNOTAVAIL on this call: // Subscribe to multicast group struct ip_mreq mreq; rc = inet_pton(AF_INET, multicastGroup_m, &mreq.imr_multiaddr.s_addr); mreq.imr_interface.s_addr = htonl(INADDR_ANY); rc = setsockopt( new_socket, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq) ); I assume that is because there is no multicast route. On Linux, you have to do an ifconfig and route to have a multicast route, but I haven't been able to find a multicast setup example for FreeBSD. The Linux commands are: ifconfig lo multicast route add -net 224.0.0.0 netmask 240.0.0.0 dev lo I have an mcast listener and writer example from the Net that I am beginning to turn into RTEMS test programs so there will be something less complex than this application to debug and to help everyone in the future. Does anyone have multicast working on libbsd? Know how to set it up on FreeBSD? Advice appreciated. Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
libbsd Makefile issues
Hi
I decided to take a look at this and spotted what I think are at least
two mistakes but when I fixed them, I got a build error.
Help appreciated:
Makefile.diff attached. But it then fails like this:
$ make
i386-rtems4.11-gcc --pipe
-B/home/joel/rtems-4.11-work/bsp-install/i386-rtems4.11/pc386/lib/ -specs bsp_specs
-qrtems -mtune=i386 -Wall -O2 -g -fno-strict-aliasing -ffreestanding
-fno-common -Irtemsbsd/include -Irtemsbsd/i386/include -Ifreebsd/sys
-Ifreebsd/sys/i386/include -Ifreebsd/sys/contrib/altq -Ifreebsd/sys/contrib/pf
-Ifreebsd/include -Ifreebsd/lib/libc/include -Ifreebsd/lib/libc/isc/include
-Ifreebsd/lib/libc/resolv -Ifreebsd/lib/libutil -Ifreebsd/lib/libkvm
-Ifreebsd/lib/libmemstat -Ifreebsd/lib/libipsec -Irtemsbsd/sys -ImDNSResponder/mDNSCore
-ImDNSResponder/mDNSShared -ImDNSResponder/mDNSPosix -Itestsuite/include
-DHAVE_RTEMS_PCI_H=1 -Wall -Wno-format -MT freebsd/contrib/libpcap/scanner.o -MD -MP -MF
freebsd/contrib/libpcap/scanner.d -std=gnu11 -D__FreeBSD__=1 -DBSD=1 -DINET6
-D_U_="__attribute__((unused))" -DHAVE_LIMITS_H=1 -DHAVE_INTTYPES=1
-DHAVE_STDINT=1 -DHAVE_STRERROR=1 -DHAVE_STRLCPY=1 -DHAVE_SNPRINTF=1 -DHAVE_VSNPRINTF=1
-DHAVE_SOCKADDR_SA_LEN=1 -DHAVE
_NET_IF_MEDIA_H=1 -DHAVE_SYS_IOCCOM_H=1 -DNEED_YYPARSE_WRAPPER=1
-Dyylval=pcap_lval -c freebsd/contrib/libpcap/scanner.c -o
freebsd/contrib/libpcap/scanner.o
In file included from ../../freebsd/contrib/libpcap/scanner.l:51:0:
freebsd/contrib/libpcap/pcap-int.h:39:23: fatal error: pcap/pcap.h: No such
file or directory
#include
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
diff --git a/Makefile b/Makefile
index da2a5ef..f6992e6 100644
--- a/Makefile
+++ b/Makefile
@@ -108,10 +108,10 @@ LIB_C_FILES += freebsd/sys/vm/uma_dbg.c
LIB_C_FILES += freebsd/sys/cam/cam.c
LIB_C_FILES += freebsd/sys/cam/scsi/scsi_all.c
LIB_C_FILES += freebsd/contrib/libpcap/scanner.c
-freebsd/contrib/libpcap/scanner.c: freebsd/contrib/libpcap/scanner.l
freebsd/contrib/libpcap/scanner.c
+freebsd/contrib/libpcap/scanner.c: freebsd/contrib/libpcap/scanner.l
${LEX} -P pcap -t $< | sed -e '/YY_BUF_SIZE/s/16384/1024/' > $@
freebsd/contrib/libpcap/scanner.o: freebsd/contrib/libpcap/scanner.c
- $(CC) $(CPPFLAGS) $(CFLAGS) -D__FreeBSD__=1 -DBSD=1 -DINET6
-D_U_=__attribute__((unused)) -DHAVE_LIMITS_H=1 -DHAVE_INTTYPES=1
-DHAVE_STDINT=1 -DHAVE_STRERROR=1 -DHAVE_STRLCPY=1 -DHAVE_SNPRINTF=1
-DHAVE_VSNPRINTF=1 -DHAVE_SOCKADDR_SA_LEN=1 -DHAVE_NET_IF_MEDIA_H=1
-DHAVE_SYS_IOCCOM_H=1 -DNEED_YYPARSE_WRAPPER=1 -Dyylval=pcap_lval -c $< -o $@
+ $(CC) $(CPPFLAGS) $(CFLAGS) -D__FreeBSD__=1 -DBSD=1 -DINET6
-D_U_="__attribute__((unused))" -DHAVE_LIMITS_H=1 -DHAVE_INTTYPES=1
-DHAVE_STDINT=1 -DHAVE_STRERROR=1 -DHAVE_STRLCPY=1 -DHAVE_SNPRINTF=1
-DHAVE_VSNPRINTF=1 -DHAVE_SOCKADDR_SA_LEN=1 -DHAVE_NET_IF_MEDIA_H=1
-DHAVE_SYS_IOCCOM_H=1 -DNEED_YYPARSE_WRAPPER=1 -Dyylval=pcap_lval -c $< -o $@
LIB_C_FILES += freebsd/contrib/libpcap/grammar.c
freebsd/contrib/libpcap/grammar.c: freebsd/contrib/libpcap/grammar.y
yacc -b -b pcap -d -p -b pcap $<
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
LIBBSD Build Error
I have rebased my tools via RSB to the latest and have successfully compiled RTEMS with a custom lpc32xx BSP. When compiling LIBBSD, I am getting the following error when compiling "freebsd/lib/libc/inet/nsap_addr.c " /tmp/ccWucPca.s: Assembler messages: /tmp/ccWucPca.s:474: Error: symbol `inet_nsap_addr' is already defined /tmp/ccWucPca.s:476: Error: symbol `inet_nsap_ntoa' is already defined I assume this is related to pushing network headers into newlib. There are weak aliases in the file as follows: /* * Weak aliases for applications that use certain private entry points, * and fail to include . */ #undef inet_nsap_addr __weak_reference(__inet_nsap_addr, inet_nsap_addr); #undef inet_nsap_ntoa __weak_reference(__inet_nsap_ntoa, inet_nsap_ntoa); Before digging into this, does anyone have an explanation? Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LIBBSD TCPDUMP
On Jul 1, 2017 9:01 AM, "Kirspel, Kevin" wrote:
I get a crash when running the tcpdump command in LIBBSD. It is due to the
following structure
struct stp_bpdu_ {
u_int8_t protocol_id[2];
u_int8_t protocol_version;
u_int8_t bpdu_type;
u_int8_t flags;
u_int8_t root_id[8];
u_int8_t root_path_cost[4];
u_int8_t bridge_id[8];
u_int8_t port_id[2];
u_int8_t message_age[2];
u_int8_t max_age[2];
u_int8_t hello_time[2];
u_int8_t forward_delay[2];
u_int8_t v1_length;
};
In the code, there is an access to the port_id field as follows:
EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since
the address of “&stp_bpdu->port_id” is at an odd word (16 bit) boundary, an
exception is generated. What is the correct way to fix this? I was going
to update EXTRACT_16BITS to check for an odd boundary and fix it up before
calling ntohs().
There should be a bit in cp15 which determines is unaligned accesses are
enabled. Should be examples in other BSPs
--joel
Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642 <(770)%20510->
Direct: (770)-688-1642 <(770)%20688-1642>
Fax: (770)-510-4445 <(770)%20510-4445>
___
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: LIBBSD TCPDUMP
On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin wrote:
> I get a crash when running the tcpdump command in LIBBSD. It is due to the
> following structure
>
>
>
> struct stp_bpdu_ {
>
> u_int8_t protocol_id[2];
>
> u_int8_t protocol_version;
>
> u_int8_t bpdu_type;
>
> u_int8_t flags;
>
> u_int8_t root_id[8];
>
> u_int8_t root_path_cost[4];
>
>u_int8_t bridge_id[8];
>
> u_int8_t port_id[2];
>
> u_int8_t message_age[2];
>
> u_int8_t max_age[2];
>
> u_int8_t hello_time[2];
>
> u_int8_t forward_delay[2];
>
> u_int8_t v1_length;
>
> };
>
>
>
> In the code, there is an access to the port_id field as follows:
> EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since
> the address of “&stp_bpdu->port_id” is at an odd word (16 bit) boundary, an
> exception is generated. What is the correct way to fix this? I was going
> to update EXTRACT_16BITS to check for an odd boundary and fix it up before
> calling ntohs().
>
That would probably be a more portable fix than allowing unaligned
accesses. I think the alignment should be made to the CPU_ALIGNMENT
macro.
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
>
> ___
> 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: LIBBSD TCPDUMP
On Jul 1, 2017 10:34 AM, "Gedare Bloom" wrote:
On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin
wrote:
> I get a crash when running the tcpdump command in LIBBSD. It is due to
the
> following structure
>
>
>
> struct stp_bpdu_ {
>
> u_int8_t protocol_id[2];
>
> u_int8_t protocol_version;
>
> u_int8_t bpdu_type;
>
> u_int8_t flags;
>
> u_int8_t root_id[8];
>
> u_int8_t root_path_cost[4];
>
>u_int8_t bridge_id[8];
>
> u_int8_t port_id[2];
>
> u_int8_t message_age[2];
>
> u_int8_t max_age[2];
>
> u_int8_t hello_time[2];
>
> u_int8_t forward_delay[2];
>
> u_int8_t v1_length;
>
> };
>
>
>
> In the code, there is an access to the port_id field as follows:
> EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since
> the address of “&stp_bpdu->port_id” is at an odd word (16 bit) boundary,
an
> exception is generated. What is the correct way to fix this? I was going
> to update EXTRACT_16BITS to check for an odd boundary and fix it up before
> calling ntohs().
>
That would probably be a more portable fix than allowing unaligned
accesses. I think the alignment should be made to the CPU_ALIGNMENT
macro.
Can't you also just pull it out a byte at a time, form the net version and
then ntohs()?
That's what I coded recently in some marahalling code.
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
>
> ___
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: LIBBSD TCPDUMP
This is how I fixed it. I did similar things for EXTRACT_32BITS and
EXTRACT_64BITS.
static inline u_int16_t
EXTRACT_16BITS(const void *p)
{
#if defined(__arm__) && defined(__rtems__)
if(((uint32_t)p % 2) != 0) {
u_int16_t value;
u_int8_t *ptr = (u_int8_t *)&value;
ptr[0] = ((const u_int8_t *)p)[0];
ptr[1] = ((const u_int8_t *)p)[1];
p = &value;
}
#endif /* __rtems__ */
return ((u_int16_t)ntohs(*(const u_int16_t *)(p)));
}
Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445
From: Joel Sherrill [mailto:j...@rtems.org]
Sent: Saturday, July 01, 2017 11:39 AM
To: Gedare Bloom
Cc: rtems-de...@rtems.org ; Kirspel, Kevin
Subject: Re: LIBBSD TCPDUMP
On Jul 1, 2017 10:34 AM, "Gedare Bloom"
mailto:ged...@rtems.org>> wrote:
On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin
mailto:kevin-kirs...@idexx.com>> wrote:
> I get a crash when running the tcpdump command in LIBBSD. It is due to the
> following structure
>
>
>
> struct stp_bpdu_ {
>
> u_int8_t protocol_id[2];
>
> u_int8_t protocol_version;
>
> u_int8_t bpdu_type;
>
> u_int8_t flags;
>
> u_int8_t root_id[8];
>
> u_int8_t root_path_cost[4];
>
>u_int8_t bridge_id[8];
>
> u_int8_t port_id[2];
>
> u_int8_t message_age[2];
>
> u_int8_t max_age[2];
>
> u_int8_t hello_time[2];
>
> u_int8_t forward_delay[2];
>
> u_int8_t v1_length;
>
> };
>
>
>
> In the code, there is an access to the port_id field as follows:
> EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since
> the address of “&stp_bpdu->port_id” is at an odd word (16 bit) boundary, an
> exception is generated. What is the correct way to fix this? I was going
> to update EXTRACT_16BITS to check for an odd boundary and fix it up before
> calling ntohs().
>
That would probably be a more portable fix than allowing unaligned
accesses. I think the alignment should be made to the CPU_ALIGNMENT
macro.
Can't you also just pull it out a byte at a time, form the net version and then
ntohs()?
That's what I coded recently in some marahalling code.
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
>
> ___
> devel mailing list
> devel@rtems.org<mailto:devel@rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwMFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=DfsZaORruX70gPrZk3-vjldOIsh4IFQ9ZRHVCZMKJ_o&s=Xx_hsbQ3vmD8L038yTJmDbvtePgAQkCJ7YBI_A6FR-Y&e=>
___
devel mailing list
devel@rtems.org<mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwMFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=DfsZaORruX70gPrZk3-vjldOIsh4IFQ9ZRHVCZMKJ_o&s=Xx_hsbQ3vmD8L038yTJmDbvtePgAQkCJ7YBI_A6FR-Y&e=>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: LIBBSD TCPDUMP
On Sat, Jul 1, 2017 at 11:49 AM, Kirspel, Kevin wrote:
> This is how I fixed it. I did similar things for EXTRACT_32BITS and
> EXTRACT_64BITS.
>
>
>
> static inline u_int16_t
>
> EXTRACT_16BITS(const void *p)
>
> {
>
> #if defined(__arm__) && defined(__rtems__)
>
> if(((uint32_t)p % 2) != 0) {
>
> u_int16_t value;
>
> u_int8_t *ptr = (u_int8_t *)&value;
>
> ptr[0] = ((const u_int8_t *)p)[0];
>
> ptr[1] = ((const u_int8_t *)p)[1];
>
> p = &value;
>
Is it correct to assign a pointer to a block-scoped variable here? It
looks suspect to me. I'd at least put the declaration of 'value'
before the block here.
> }
>
> #endif /* __rtems__ */
>
> return ((u_int16_t)ntohs(*(const u_int16_t *)(p)));
>
> }
>
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
> From: Joel Sherrill [mailto:j...@rtems.org]
> Sent: Saturday, July 01, 2017 11:39 AM
> To: Gedare Bloom
> Cc: rtems-de...@rtems.org ; Kirspel, Kevin
>
> Subject: Re: LIBBSD TCPDUMP
>
>
>
>
>
>
>
> On Jul 1, 2017 10:34 AM, "Gedare Bloom" wrote:
>
> On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin
> wrote:
>> I get a crash when running the tcpdump command in LIBBSD. It is due to
>> the
>> following structure
>>
>>
>>
>> struct stp_bpdu_ {
>>
>> u_int8_t protocol_id[2];
>>
>> u_int8_t protocol_version;
>>
>> u_int8_t bpdu_type;
>>
>> u_int8_t flags;
>>
>> u_int8_t root_id[8];
>>
>> u_int8_t root_path_cost[4];
>>
>>u_int8_t bridge_id[8];
>>
>> u_int8_t port_id[2];
>>
>> u_int8_t message_age[2];
>>
>> u_int8_t max_age[2];
>>
>> u_int8_t hello_time[2];
>>
>> u_int8_t forward_delay[2];
>>
>> u_int8_t v1_length;
>>
>> };
>>
>>
>>
>> In the code, there is an access to the port_id field as follows:
>> EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() . Since
>> the address of “&stp_bpdu->port_id” is at an odd word (16 bit) boundary,
>> an
>> exception is generated. What is the correct way to fix this? I was going
>> to update EXTRACT_16BITS to check for an odd boundary and fix it up before
>> calling ntohs().
>>
>
> That would probably be a more portable fix than allowing unaligned
> accesses. I think the alignment should be made to the CPU_ALIGNMENT
> macro.
>
>
>
> Can't you also just pull it out a byte at a time, form the net version and
> then ntohs()?
>
>
>
> That's what I coded recently in some marahalling code.
>
>
>
>
>
>>
>>
>> Kevin Kirspel
>>
>> Electrical Engineer - Sr. Staff
>>
>> Idexx Roswell
>>
>> 235 Hembree Park Drive
>>
>> Roswell GA 30076
>>
>> Tel: (770)-510- ext. 81642
>>
>> Direct: (770)-688-1642
>>
>> Fax: (770)-510-4445
>>
>>
>>
>>
>
>> ___
>> 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
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: LIBBSD TCPDUMP
No. I fixed that after I noticed the data was invalid during testing. I moved
the variable declaration outside of the if statement and now the data is
correct.
Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445
-Original Message-
From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of Gedare
Bloom
Sent: Saturday, July 01, 2017 1:30 PM
To: Kirspel, Kevin
Cc: j...@rtems.org; rtems-de...@rtems.org
Subject: Re: LIBBSD TCPDUMP
On Sat, Jul 1, 2017 at 11:49 AM, Kirspel, Kevin wrote:
> This is how I fixed it. I did similar things for EXTRACT_32BITS and
> EXTRACT_64BITS.
>
>
>
> static inline u_int16_t
>
> EXTRACT_16BITS(const void *p)
>
> {
>
> #if defined(__arm__) && defined(__rtems__)
>
> if(((uint32_t)p % 2) != 0) {
>
> u_int16_t value;
>
> u_int8_t *ptr = (u_int8_t *)&value;
>
> ptr[0] = ((const u_int8_t *)p)[0];
>
> ptr[1] = ((const u_int8_t *)p)[1];
>
> p = &value;
>
Is it correct to assign a pointer to a block-scoped variable here? It looks
suspect to me. I'd at least put the declaration of 'value'
before the block here.
> }
>
> #endif /* __rtems__ */
>
> return ((u_int16_t)ntohs(*(const u_int16_t *)(p)));
>
> }
>
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
> From: Joel Sherrill [mailto:j...@rtems.org]
> Sent: Saturday, July 01, 2017 11:39 AM
> To: Gedare Bloom
> Cc: rtems-de...@rtems.org ; Kirspel, Kevin
>
> Subject: Re: LIBBSD TCPDUMP
>
>
>
>
>
>
>
> On Jul 1, 2017 10:34 AM, "Gedare Bloom" wrote:
>
> On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin
>
> wrote:
>> I get a crash when running the tcpdump command in LIBBSD. It is due
>> to the following structure
>>
>>
>>
>> struct stp_bpdu_ {
>>
>> u_int8_t protocol_id[2];
>>
>> u_int8_t protocol_version;
>>
>> u_int8_t bpdu_type;
>>
>> u_int8_t flags;
>>
>> u_int8_t root_id[8];
>>
>> u_int8_t root_path_cost[4];
>>
>>u_int8_t bridge_id[8];
>>
>> u_int8_t port_id[2];
>>
>> u_int8_t message_age[2];
>>
>> u_int8_t max_age[2];
>>
>> u_int8_t hello_time[2];
>>
>> u_int8_t forward_delay[2];
>>
>> u_int8_t v1_length;
>>
>> };
>>
>>
>>
>> In the code, there is an access to the port_id field as follows:
>> EXTRACT_16BITS(&stp_bpdu->port_id). EXTRACT_16BITS calls ntohs() .
>> Since the address of “&stp_bpdu->port_id” is at an odd word (16 bit)
>> boundary, an exception is generated. What is the correct way to fix
>> this? I was going to update EXTRACT_16BITS to check for an odd
>> boundary and fix it up before calling ntohs().
>>
>
> That would probably be a more portable fix than allowing unaligned
> accesses. I think the alignment should be made to the CPU_ALIGNMENT
> macro.
>
>
>
> Can't you also just pull it out a byte at a time, form the net version
> and then ntohs()?
>
>
>
> That's what I coded recently in some marahalling code.
>
>
>
>
>
>>
>>
>> Kevin Kirspel
>>
>> Electrical Engineer - Sr. Staff
>>
>> Idexx Roswell
>>
>> 235 Hembree Park Drive
>>
>> Roswell GA 30076
>>
>> Tel: (770)-510- ext. 81642
>>
>> Direct: (770)-688-1642
>>
>> Fax: (770)-510-4445
>>
>>
>>
>>
>
>> ___
>> devel mailing list
>> devel@rtems.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_m
>> ailman_listinfo_devel&d=DwIFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ
>> 32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=ZD1dtkTMUak_NH2kvhh9fcWsBvl09av5rA
>> xPKDDt1ac&s=QxnRQLVQGW81f8ARsKfj1Hd7M4JNXV0oc_WjhT5dOHw&e=
> ___
> devel mailing list
> devel@rtems.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_ma
> ilman_listinfo_devel&d=DwIFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32
> G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=ZD1dtkTMUak_NH2kvhh9fcWsBvl09av5rAxPKDDt1ac&s=QxnRQLVQGW81f8ARsKfj1Hd7M4JNXV0oc_WjhT5dOHw&e=
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RTEMS Libbsd update.
Hi I have push some waf related changes libbsd. Please make sure you update the `rtems_waf` submodule after updating your local repo. A status indicating an update is needed is: $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: rtems_waf (new commits) no changes added to commit (use "git add" and/or "git commit -a") The command to update is: $ git submodule update rtems_waf Submodule path 'rtems_waf': checked out '9343280a61f0c0736e237168297b9d1490a66255 Note: make sure you use the exact submodule update command or you may end up cloning the FreeBSD source tree. If that happens just press ^C. I suggest you do a `waf distclean` and configure again after updating. Also I recommend using waf 1.8.20. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
stm32h7 on libbsd?
I see STM32H7 was added to the nexus last year in March. Was libbsd/networking tested on any hardware devices? Thanks, Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Libbsd situation.
Hello Karel, On 17.07.23 13:12, Karel Gardas wrote: Hello, if I'm right than RTEMS 6 should be accompanied with libbsd from 6-freebsd-12 branch which should be based on freebsd-12 (stable/12 branch). Please correct me if I'm wrong here. If I'm right above, then there are few things which worries me a bit: (1) FreeBSD's 12 branch is going to be EoLed soon, e.g. December 31, 2023 as claimed on https://www.freebsd.org/security/#sup (2) 6-freebsd-12 branch latest commit in freebsd-org is from Feb 9 22:15:35 2020. Based on that it looks like 6-freebsd-12 branch is >6k commits behind the FreeBSD's stable/12 branch. May this outage be solved by using libbsd master branch? It does not look like as: (i) latest commit in freebsd-org in libbsd master branch is even older than in 6-freebsd-12 and it is from Sep 24 01:58:54 2019. (ii) even if I consider Sebastian's own master-update branch available on his github.com account, it seem this branch synced with what is in 6-freebsd-12 and ends exactly on 2020-02-09. So, it looks like master is also missing few thousands patches from FreeBSD development... Anyway, my biggest worry is that RTEMS 6 libbsd may be based on source code which will lose upstream project support soon after the RTEMS 6 release (assuming RTEMS 6 will happen before Dec 31 2023). So I'm curious if with all those outdatnes it would not be good to jump and update master which would be supported by another 5 years (assuming this is stable/14 branch). E.g. the situation is exactly like with GCC where Sebastian clearly warned about it and project moved from 10 to 12 and now it looks like we will even move to GCC 13 release for RTEMS 6... Except that in case of libbsd it has not happened yet. Am I missing something or is this really a situation with libbsd as of today? your assessment is unfortunately correct. I made some attempts to update libbsd, but other maintainers disagreed with my approach. We have internal plans to rework the libbsd to be able to synchronize more easily with the FreeBSD upstream. The current infrastructure in libbsd was set up to work with Subversion. With Git we have now much better capabilities. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 5/5] libbsd: USB Template Driver Documentation
Signed-off-by: Husni Faiz
---
libbsd/device_driver.rst | 30 ++
libbsd/index.rst | 1 +
2 files changed, 31 insertions(+)
create mode 100644 libbsd/device_driver.rst
diff --git a/libbsd/device_driver.rst b/libbsd/device_driver.rst
new file mode 100644
index 000..7562866
--- /dev/null
+++ b/libbsd/device_driver.rst
@@ -0,0 +1,30 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+Device Driver
+#
+
+Introduction
+
+
+USB
+===
+
+USB Template
+
+
+USB Template driver is initialized based on the value of `hw.usb.template`
+sysctl variable. To set the variable use the `sysctlbyname` system call
+as follows in your application,
+
+ .. code-block:: c
+
+ int template = 1;
+ sysctlbyname("hw.usb.template", NULL, NULL, &template,
sizeof(template));
+
+You can set the variable at runtime using the shell with the syctl utility.
+
+ .. code-block:: shell
+
+ sysctl hw.usb.template=1
+
+NOTE: Template 1 is the CDC Ethernet.
diff --git a/libbsd/index.rst b/libbsd/index.rst
index f790070..1ee349a 100644
--- a/libbsd/index.rst
+++ b/libbsd/index.rst
@@ -21,3 +21,4 @@ RTEMS LibBSD User Manual (|version|).
introduction
quick_start
+ device_driver
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
Hello, since we are maintaining an RTOS: IMHO Real time capabilities would need a higher level, even above code/RAM sizes. Meaining that the libbsd functionality should not have a (significant) negative impact on RTEMS tasks NOT using libbsd. wkr, Thomas. Am 23.01.23 um 14:33 schrieb Christian MAUDERER: Hello, like suggested earlier in the original discussion I would suggest to prioritize our development goals for libbsd and later evaluate the two problems discussed in the thread based on this. Let's first agree on development goals (that also can be added to the libbsd documentation). From the thread and responses, I currently have collected the following goals / priorities. I replaced my original extensibility and debuggability with Joels transparency because it's a good summary term for these two points. From highest to lowest priority: - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Real time capabilities: No hard real time requirements for libbsd core but we have to make sure that it doesn't have a negative impact on other subsystems. - Performance: Whether libbsd performes well enough in the typical use cases. That means (for example): If it makes the system more maintainable, the performance isn't that important. If it reduces the size, we can trade off some performance or real time capabilities. Would you prioritize different? Did I miss some additional points from the discussion? Best regards Christian On 2023-01-20 08:32, Christian MAUDERER wrote: Hello, recently an internal discussion about updates in the libbsd started. All who participated in the discussion agreed that we should move the discussion to a public one. Below you can find the mail thread. It's oldest mail first. Mails are split with lines of = signs. I removed some duplicated mail text in case there were no inline comments. The date/time of the mails are in my current locale which is UTC+1. Best regards Christian = On 2023-01-03 16:52, Thomas DOERFLER wrote: Hello, first of all I wish you all a healthy, happy and successful new year. Unfortunately I already have to re-raise an issue: One of our customers has asked us about the RTEMS libbsd update policy. Since we still use a rather old libbsd version, it contains "OpenSSL 1.1.1d-freebsd 10 Sep 2019", there are many openSSL fixes missing when using RTEMS, and this most likely is true for other parts of libbsd. IMHO we should find a way to overcome the current libbsd update blocking points and try to stay close to the FreeBSD code (maybe in a 1-3 month interval). AFAIK the big blocking point are the different views around changes of the file descriptor handling between RTEMS and BSD (this may be a bit off the real topic, I am not yet into the details). In the next week I would like to get things rolling to see the pros and cons of both possible implementations and I would be happy if those closely involved would support this. Apart from the current blocking point, can we agree that staying close the the FreeBSD code (with a 1-3 month update/sync interval) would be desirable? Kind regards to you all, Thomas. = On 2023-01-12 01:24, Gedare Bloom wrote: Hi Thomas, I think the goal you have stated is laudable and fits with the initial design goals of libbsd. I will take a closer look at this topic and report back soon, I hope. I have remained (purposefully) ignorant about libbsd evolution over time, but I guess it is time for me to learn a bit more and catch up. From what I have understood about the current blocking issue, it has to do with the changes that were made to use FreeBSD File Descriptors and the VFS. However, one of the main problems that was noted actually appears to be just related to the size increase caused by the syscall glue implemented in a single .c file. So, I will plan to start my libbsd learning adventure by trying to split that .c file apart into separate build components to see how/if that alleviates the linked image size. If successful, that should get us closer. I think we can then revisit whether or not the FreeBSD File Descriptors themselves are in fact problematic. It would also be helpful to decide if we want to clarify any requirements for libbsd maintenance. So, for example, the ability to keep it updated on a rolling basis would require good automation and validation that changes/updates remain usable.
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 23.01.23 16:39, Thomas DOERFLER wrote: since we are maintaining an RTOS: IMHO Real time capabilities would need a higher level, even above code/RAM sizes. Meaining that the libbsd functionality should not have a (significant) negative impact on RTEMS tasks NOT using libbsd. There is actually a good example for this area in libbsd, the Epoch Based Reclamation. It has an RTEMS-specific implementation which required to add new features to the low level thread dispatching and scheduling implementation. In particular, the support for thread pinning. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? Best regards Christian On 2023-01-23 16:43, Sebastian Huber wrote: On 23.01.23 16:39, Thomas DOERFLER wrote: since we are maintaining an RTOS: IMHO Real time capabilities would need a higher level, even above code/RAM sizes. Meaining that the libbsd functionality should not have a (significant) negative impact on RTEMS tasks NOT using libbsd. There is actually a good example for this area in libbsd, the Epoch Based Reclamation. It has an RTEMS-specific implementation which required to add new features to the low level thread dispatching and scheduling implementation. In particular, the support for thread pinning. -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 2023-01-25 09:59, Sebastian Huber wrote: On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. So no lower than modularity. Should it be higher than transparency or maintainability? From the earlier comments I don't expect that it should be higher than (core) real time capability. What would be your preferred order? -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 25.01.23 10:01, Christian MAUDERER wrote: On 2023-01-25 09:59, Sebastian Huber wrote: On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. So no lower than modularity. Should it be higher than transparency or maintainability? From the earlier comments I don't expect that it should be higher than (core) real time capability. What would be your preferred order? Lets say you are a user of libbsd version X. Then you want to update to version X + 1. Version X + 1 no longer works on your system, because libbsd needs more RAM than you have. Would you really give this user an answer like this: Sorry, maintainability and transparency is more important for us, so please stick to version X. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 2023-01-25 10:05, Sebastian Huber wrote: On 25.01.23 10:01, Christian MAUDERER wrote: On 2023-01-25 09:59, Sebastian Huber wrote: On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. So no lower than modularity. Should it be higher than transparency or maintainability? From the earlier comments I don't expect that it should be higher than (core) real time capability. What would be your preferred order? Lets say you are a user of libbsd version X. Then you want to update to version X + 1. Version X + 1 no longer works on your system, because libbsd needs more RAM than you have. Would you really give this user an answer like this: Sorry, maintainability and transparency is more important for us, so please stick to version X. Regarding code / RAM size versus maintainability: Maintainability does also include the upgrade process to newer base versions of FreeBSD. So if it's more important that code size doesn't increase compared to how easy libbsd is to maintain, that can make upgrades to newer FreeBSD versions _very_ difficult. I don't think that would be a good trade. Code size versus transparency (how easy it is for someone new to start development and how easy it is to debug through the code) is a bit more opinion based. The current order is from what I have understood in the discussion. I don't have a problem to re-order these. Note: I'm OK with most orders as long as most of the maintainers can agree on one. -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER wrote: > > On 2023-01-25 10:05, Sebastian Huber wrote: > > On 25.01.23 10:01, Christian MAUDERER wrote: > >> On 2023-01-25 09:59, Sebastian Huber wrote: > >>> On 25.01.23 09:52, Christian MAUDERER wrote: > >>>> OK. Updated list based on Thomas and Sebastians feedback: > >>>> > >>>> From highest to lowest priority: > >>>> > >>>> - Real time capabilities: No hard real time requirements for libbsd > >>>> core, but we have to make sure that it doesn't have a (relevant) > >>>> negative impact on other subsystems. > >>>> > >>>> - Maintainability: How easy is it for the people doing the main > >>>> maintenance tasks to do that work. > >>>> > >>>> - Transparency: How easy it is to understand the code? Relevant for > >>>> extending and debugging. > >>>> > >>>> - Code and RAM sizes (or other hardware requirements): Whether we > >>>> meet the minimum hardware requirements. > >>>> > >>>> - Modularity: How well and easy the system can be adapted to target > >>>> applications. Have only few official ways to enable / disable > >>>> modules in the subsystem. > >>>> > >>>> - Performance: Whether libbsd performs well enough in the typical > >>>> use cases. > >>>> > >>>> Any more suggestions for the order? Like I said, I would like to > >>>> integrate that to the libbsd documentation as goals for that > >>>> subsystem that can be used to evaluate different approaches for > >>>> implementing something. Would be good to have some more feedback > >>>> from others too. > >>>> > >>>> For example: I prioritized maintainability over transparency. That > >>>> means that we might choose a solution that's simpler to maintain but > >>>> makes it harder to integrate new modules. Is that OK? > >>>> > >>>> Similar the order of modularity and code / RAM size can be an issue: > >>>> Most of the time these should go well together. But it's quite > >>>> possible that some nice modular configuration options need extra > >>>> code compared to less nice methods. From my point of view we target > >>>> embedded systems where code and RAM size is more important. But I'm > >>>> not sure that this is the focus for everyone else too? > >>> > >>> I would not give the minimum RAM size such a low priority. libbsd > >>> used to work on systems with 16MiB. If you add new things which > >>> require additional 4MiB even if you don't use the stuff, then you > >>> simply kick out systems which used to work with libbsd. > >>> > >> > >> So no lower than modularity. Should it be higher than transparency or > >> maintainability? From the earlier comments I don't expect that it > >> should be higher than (core) real time capability. > >> > >> What would be your preferred order? > > > > Lets say you are a user of libbsd version X. Then you want to update to > > version X + 1. Version X + 1 no longer works on your system, because > > libbsd needs more RAM than you have. Would you really give this user an > > answer like this: > > > > Sorry, maintainability and transparency is more important for us, so > > please stick to version X. > > > > Regarding code / RAM size versus maintainability: > > Maintainability does also include the upgrade process to newer base > versions of FreeBSD. So if it's more important that code size doesn't > increase compared to how easy libbsd is to maintain, that can make > upgrades to newer FreeBSD versions _very_ difficult. I don't think that > would be a good trade. > > Code size versus transparency (how easy it is for someone new to start > development and how easy it is to debug through the code) is a bit more > opinion based. The current order is from what I have understood in the > discussion. I don't have a problem to re-order these. > > Note: I'm OK with most orders as long as most of the maintainers can > agree on one. > -- Thanks for taking this on. Instead of a strict priority for the goals, we might consider a limited set of different priorities that require judgment to make good trade-offs. In this case, I would suggest the following as somewhat equivalent goals, and t
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
> On Jan 25, 2023, at 10:55 , Gedare Bloom wrote: > > On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER > wrote: >> >> On 2023-01-25 10:05, Sebastian Huber wrote: >>> On 25.01.23 10:01, Christian MAUDERER wrote: >>>> On 2023-01-25 09:59, Sebastian Huber wrote: >>>>> On 25.01.23 09:52, Christian MAUDERER wrote: >>>>>> OK. Updated list based on Thomas and Sebastians feedback: >>>>>> >>>>>> From highest to lowest priority: >>>>>> >>>>>> - Real time capabilities: No hard real time requirements for libbsd >>>>>> core, but we have to make sure that it doesn't have a (relevant) >>>>>> negative impact on other subsystems. >>>>>> >>>>>> - Maintainability: How easy is it for the people doing the main >>>>>> maintenance tasks to do that work. >>>>>> >>>>>> - Transparency: How easy it is to understand the code? Relevant for >>>>>> extending and debugging. >>>>>> >>>>>> - Code and RAM sizes (or other hardware requirements): Whether we >>>>>> meet the minimum hardware requirements. >>>>>> >>>>>> - Modularity: How well and easy the system can be adapted to target >>>>>> applications. Have only few official ways to enable / disable >>>>>> modules in the subsystem. >>>>>> >>>>>> - Performance: Whether libbsd performs well enough in the typical >>>>>> use cases. >>>>>> >>>>>> Any more suggestions for the order? Like I said, I would like to >>>>>> integrate that to the libbsd documentation as goals for that >>>>>> subsystem that can be used to evaluate different approaches for >>>>>> implementing something. Would be good to have some more feedback >>>>>> from others too. >>>>>> >>>>>> For example: I prioritized maintainability over transparency. That >>>>>> means that we might choose a solution that's simpler to maintain but >>>>>> makes it harder to integrate new modules. Is that OK? >>>>>> >>>>>> Similar the order of modularity and code / RAM size can be an issue: >>>>>> Most of the time these should go well together. But it's quite >>>>>> possible that some nice modular configuration options need extra >>>>>> code compared to less nice methods. From my point of view we target >>>>>> embedded systems where code and RAM size is more important. But I'm >>>>>> not sure that this is the focus for everyone else too? >>>>> >>>>> I would not give the minimum RAM size such a low priority. libbsd >>>>> used to work on systems with 16MiB. If you add new things which >>>>> require additional 4MiB even if you don't use the stuff, then you >>>>> simply kick out systems which used to work with libbsd. >>>>> >>>> >>>> So no lower than modularity. Should it be higher than transparency or >>>> maintainability? From the earlier comments I don't expect that it >>>> should be higher than (core) real time capability. >>>> >>>> What would be your preferred order? >>> >>> Lets say you are a user of libbsd version X. Then you want to update to >>> version X + 1. Version X + 1 no longer works on your system, because >>> libbsd needs more RAM than you have. Would you really give this user an >>> answer like this: >>> >>> Sorry, maintainability and transparency is more important for us, so >>> please stick to version X. >>> >> >> Regarding code / RAM size versus maintainability: >> >> Maintainability does also include the upgrade process to newer base >> versions of FreeBSD. So if it's more important that code size doesn't >> increase compared to how easy libbsd is to maintain, that can make >> upgrades to newer FreeBSD versions _very_ difficult. I don't think that >> would be a good trade. >> >> Code size versus transparency (how easy it is for someone new to start >> development and how easy it is to debug through the code) is a bit more >> opinion based. The current order is from what I have understood in the >> discussion. I don't have a problem to re-order these. >> >> Not
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 2023-01-25 19:10, Peter Dufault wrote: On Jan 25, 2023, at 10:55 , Gedare Bloom wrote: On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER wrote: On 2023-01-25 10:05, Sebastian Huber wrote: On 25.01.23 10:01, Christian MAUDERER wrote: On 2023-01-25 09:59, Sebastian Huber wrote: On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. So no lower than modularity. Should it be higher than transparency or maintainability? From the earlier comments I don't expect that it should be higher than (core) real time capability. What would be your preferred order? Lets say you are a user of libbsd version X. Then you want to update to version X + 1. Version X + 1 no longer works on your system, because libbsd needs more RAM than you have. Would you really give this user an answer like this: Sorry, maintainability and transparency is more important for us, so please stick to version X. Regarding code / RAM size versus maintainability: Maintainability does also include the upgrade process to newer base versions of FreeBSD. So if it's more important that code size doesn't increase compared to how easy libbsd is to maintain, that can make upgrades to newer FreeBSD versions _very_ difficult. I don't think that would be a good trade. Code size versus transparency (how easy it is for someone new to start development and how easy it is to debug through the code) is a bit more opinion based. The current order is from what I have understood in the discussion. I don't have a problem to re-order these. Note: I'm OK with most orders as long as most of the maintainers can agree on one. -- Thanks for taking this on. Instead of a strict priority for the goals, we might consider a limited set of different priorities that require judgment to make good trade-offs. In this case, I would suggest the following as somewhat equivalent goals, and the sets in priority order: 1. Real-time Impacts + Maintainability Loss 2. Transparency Loss + Modularity Loss + Code/RAM Size Increase 3. Performance Loss I wrote each goal now as a "minimize" objective. I think it is not possible to establish strict priorities on these objectives. Good engineering requires understanding and making good tradeoffs. I believe that #1 addresses the highest requirements we place on RTEMS and the libbsd philosophy. #2 leaves us with the burden of discussing and debating when tradeoffs are made. It may be better in some cases to increase code size by increasing modularity, but in other cases it may be better to reduce transparency to reduce code size. Gedare I'm presenting my concerns without doing appropriate research. This ties in to other needed RTEMS specifications, in particular, the specification of whsy light-weight IP can support, and if it is possible to have a project to tie "libbsd" drivers into the LWIP infrastructure (*I* don't know if that's possible). Yes, I want my cake, and eat it too. "It would be great" if it is clear what small memory platforms l
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 2023-01-26 10:26, Christian MAUDERER wrote: On 2023-01-25 19:10, Peter Dufault wrote: On Jan 25, 2023, at 10:55 , Gedare Bloom wrote: On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER wrote: On 2023-01-25 10:05, Sebastian Huber wrote: On 25.01.23 10:01, Christian MAUDERER wrote: On 2023-01-25 09:59, Sebastian Huber wrote: On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. So no lower than modularity. Should it be higher than transparency or maintainability? From the earlier comments I don't expect that it should be higher than (core) real time capability. What would be your preferred order? Lets say you are a user of libbsd version X. Then you want to update to version X + 1. Version X + 1 no longer works on your system, because libbsd needs more RAM than you have. Would you really give this user an answer like this: Sorry, maintainability and transparency is more important for us, so please stick to version X. Regarding code / RAM size versus maintainability: Maintainability does also include the upgrade process to newer base versions of FreeBSD. So if it's more important that code size doesn't increase compared to how easy libbsd is to maintain, that can make upgrades to newer FreeBSD versions _very_ difficult. I don't think that would be a good trade. Code size versus transparency (how easy it is for someone new to start development and how easy it is to debug through the code) is a bit more opinion based. The current order is from what I have understood in the discussion. I don't have a problem to re-order these. Note: I'm OK with most orders as long as most of the maintainers can agree on one. -- Thanks for taking this on. Instead of a strict priority for the goals, we might consider a limited set of different priorities that require judgment to make good trade-offs. In this case, I would suggest the following as somewhat equivalent goals, and the sets in priority order: 1. Real-time Impacts + Maintainability Loss 2. Transparency Loss + Modularity Loss + Code/RAM Size Increase 3. Performance Loss I wrote each goal now as a "minimize" objective. I think it is not possible to establish strict priorities on these objectives. Good engineering requires understanding and making good tradeoffs. I believe that #1 addresses the highest requirements we place on RTEMS and the libbsd philosophy. #2 leaves us with the burden of discussing and debating when tradeoffs are made. It may be better in some cases to increase code size by increasing modularity, but in other cases it may be better to reduce transparency to reduce code size. Gedare I'm presenting my concerns without doing appropriate research. This ties in to other needed RTEMS specifications, in particular, the specification of whsy light-weight IP can support, and if it is possible to have a project to tie "libbsd" drivers into the LWIP infrastructure (*I* don't know if that's possible). Yes, I want my cake, and eat it too. "It would be grea
[PATCH rtems-libbsd 4/5] wscript: Enable build for LibBSD Doc
Signed-off-by: Husni Faiz --- wscript | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/wscript b/wscript index fd8f10c..5ae735d 100644 --- a/wscript +++ b/wscript @@ -35,7 +35,8 @@ build_all = ['user', 'shell', 'cpu-supplement', 'develenv', - 'legacy-networking'] + 'legacy-networking', + 'libbsd'] building = build_all -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-libbsd error nit
Hi I got an error because I needed to fetch the submodule. The message tells me to see README.waf. The message is out of date since it is now README.md. Is this an error message which is in other repos as well? It seems easy to fix but could be in more than one place. Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Multicast in Libbsd
On 18.06.20 22:47, Joel Sherrill wrote: Hi I have an example FACE application I am trying to port to RTEMS. This is a multi-question email: First, it fails with EADDRNOTAVAIL on this call: // Subscribe to multicast group struct ip_mreq mreq; rc = inet_pton(AF_INET, multicastGroup_m, &mreq.imr_multiaddr.s_addr); mreq.imr_interface.s_addr = htonl(INADDR_ANY); rc = setsockopt( new_socket, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq) ); I assume that is because there is no multicast route. On Linux, you have to do an ifconfig and route to have a multicast route, but I haven't been able to find a multicast setup example for FreeBSD. The Linux commands are: ifconfig lo multicast route add -net 224.0.0.0 netmask 240.0.0.0 dev lo This: https://gist.github.com/hostilefork/f7cae3dc33e7416f2dd25a402857b6c6 Compiles and run without any special configuration on FreeBSD 12.1 The handbook claims that "Multicast applications do not require any special configuration in order to run on FreeBSD" https://www.freebsd.org/doc/handbook/network-routing.html Following is the routing table on a FreeBSD jail with no special 224 route needed. Cédric # netstat -nr Routing tables Internet: Destination Gateway Flags Netif Expire default 172.18.12.1 UGS epair25b 127.0.0.1 link#1 UH lo0 172.18.12.0/24 link#3 U epair25b 172.18.12.25 link#3 UHS lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#1 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%lo0/64 link#1 U lo0 fe80::1%lo0 link#1 UHS lo0 ff02::/16 ::1 UGRS lo0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Multicast in Libbsd
I can agree with Cedric.
I use rtems5 with rtems-libbsd. I initialize the network interfaces of my
target via dhcpcd
and the interfaces are automatically multicast capable.
This works without creating a route:
if (setsockopt(conf->udp, IPPROTO_IP, IP_ADD_MEMBERSHIP,
(char *) &mreq, sizeof(mreq))!=0) {
struct sockaddr_in temp;
char name[40];
...
Heinz
> On 19. Jun 2020, at 17:53, Cedric Berger wrote:
>
> On 18.06.20 22:47, Joel Sherrill wrote:
>
>> Hi
>>
>> I have an example FACE application I am trying to port to RTEMS. This is a
>> multi-question email:
>>
>> First, it fails with EADDRNOTAVAIL on this call:
>>
>> // Subscribe to multicast group
>> struct ip_mreq mreq;
>> rc = inet_pton(AF_INET, multicastGroup_m,
>> &mreq.imr_multiaddr.s_addr);
>> mreq.imr_interface.s_addr = htonl(INADDR_ANY);
>> rc = setsockopt(
>> new_socket,
>> IPPROTO_IP,
>> IP_ADD_MEMBERSHIP,
>> &mreq,
>> sizeof(mreq)
>> );
>>
>> I assume that is because there is no multicast route. On Linux, you have to
>> do an ifconfig and route to have a multicast route, but I haven't been able
>> to find a multicast setup example for FreeBSD. The Linux commands are:
>>
>> ifconfig lo multicast
>> route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
> This:
>
> https://gist.github.com/hostilefork/f7cae3dc33e7416f2dd25a402857b6c6
>
> Compiles and run without any special configuration on FreeBSD 12.1
>
> The handbook claims that "Multicast applications do not require any special
> configuration in order to run on FreeBSD"
>
> https://www.freebsd.org/doc/handbook/network-routing.html
>
> Following is the routing table on a FreeBSD jail with no special 224 route
> needed.
>
> Cédric
>
> # netstat -nr
> Routing tables
>
> Internet:
> DestinationGatewayFlags Netif Expire
> default172.18.12.1UGSepair25b
> 127.0.0.1 link#1 UH lo0
> 172.18.12.0/24 link#3 U epair25b
> 172.18.12.25 link#3 UHS lo0
>
> Internet6:
> Destination Gateway Flags
> Netif Expire
> ::/96 ::1 UGRS
> lo0
> ::1 link#1UH
> lo0
> :::0.0.0.0/96 ::1 UGRS
> lo0
> fe80::/10 ::1 UGRS
> lo0
> fe80::%lo0/64 link#1U
> lo0
> fe80::1%lo0 link#1UHS
> lo0
> ff02::/16 ::1 UGRS
> lo0
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Multicast in Libbsd
This turned out to be a trivial problem but hard to figure out. :(
The code has a POSIX_Init which initializes the stack and then calls the
application's main() which spawns a number of threads which start using the
stack. I disabled the POSIX_Init from calling main(), added mcast-listener
and mcast-writer (standard net code I had) as shell programs, and then
telnet'ed into the target. I could telnet in twice and run a listener in
one session and a writer in another. This proved that multicast was working
and made me wonder if there was a race condition on stack initialization
since it takes a little while to login twice and run two programs.
I put a sleep(10) before calling main() and the program came up. Based on
its output, it got through initialization but then faulted. I tracked that
down to RTEMS implementation of posix_devctl() being correct and the
adapter being used on Linux was incorrect.
*** Is there a reliable way to know the stack is settled out before the
application can run?
*** I still have to get the multicast out of qemu but that's another issue.
Thanks for the suggestions everyone.
--joel
On Fri, Jun 19, 2020 at 2:35 PM Heinz Junkes
wrote:
> I can agree with Cedric.
>
> I use rtems5 with rtems-libbsd. I initialize the network interfaces of my
> target via dhcpcd
> and the interfaces are automatically multicast capable.
>
> This works without creating a route:
>
> if (setsockopt(conf->udp, IPPROTO_IP, IP_ADD_MEMBERSHIP,
> (char *) &mreq, sizeof(mreq))!=0) {
> struct sockaddr_in temp;
> char name[40];
> ...
>
> Heinz
>
>
> > On 19. Jun 2020, at 17:53, Cedric Berger wrote:
> >
> > On 18.06.20 22:47, Joel Sherrill wrote:
> >
> >> Hi
> >>
> >> I have an example FACE application I am trying to port to RTEMS. This
> is a multi-question email:
> >>
> >> First, it fails with EADDRNOTAVAIL on this call:
> >>
> >> // Subscribe to multicast group
> >> struct ip_mreq mreq;
> >> rc = inet_pton(AF_INET, multicastGroup_m,
> &mreq.imr_multiaddr.s_addr);
> >> mreq.imr_interface.s_addr = htonl(INADDR_ANY);
> >> rc = setsockopt(
> >> new_socket,
> >> IPPROTO_IP,
> >> IP_ADD_MEMBERSHIP,
> >> &mreq,
> >> sizeof(mreq)
> >> );
> >>
> >> I assume that is because there is no multicast route. On Linux, you
> have to do an ifconfig and route to have a multicast route, but I haven't
> been able to find a multicast setup example for FreeBSD. The Linux commands
> are:
> >>
> >> ifconfig lo multicast
> >> route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
> > This:
> >
> > https://gist.github.com/hostilefork/f7cae3dc33e7416f2dd25a402857b6c6
> >
> > Compiles and run without any special configuration on FreeBSD 12.1
> >
> > The handbook claims that "Multicast applications do not require any
> special configuration in order to run on FreeBSD"
> >
> > https://www.freebsd.org/doc/handbook/network-routing.html
> >
> > Following is the routing table on a FreeBSD jail with no special 224
> route needed.
> >
> > Cédric
> >
> > # netstat -nr
> > Routing tables
> >
> > Internet:
> > DestinationGatewayFlags Netif Expire
> > default172.18.12.1UGSepair25b
> > 127.0.0.1 link#1 UH lo0
> > 172.18.12.0/24 link#3 U epair25b
> > 172.18.12.25 link#3 UHS lo0
> >
> > Internet6:
> > Destination Gateway Flags
> Netif Expire
> > ::/96 ::1 UGRS
> lo0
> > ::1 link#1UH
> lo0
> > :::0.0.0.0/96 ::1 UGRS
> lo0
> > fe80::/10 ::1 UGRS
> lo0
> > fe80::%lo0/64 link#1U
>lo0
> > fe80::1%lo0 link#1UHS
>lo0
> > ff02::/16 ::1 UGRS
> lo0
> >
> >
> >
> > ___
> > 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: Multicast in Libbsd
On 20/6/20 7:12 am, Joel Sherrill wrote: > *** Is there a reliable way to know the stack is settled out before the > application can run? This is a hard one. Some interfaces have PHYs that take different times to come up, is the stack ready when one of several interfaces is available? Then there is DHCP and the speed of the server responding. I see the state of networking as a system level specification and it is the system design that needs to take this into consideration. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
libbsd rtems 5 branches
Hi What's the difference between these two branches? remotes/origin/5 remotes/origin/5-freebsd-12 --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-libbsd waf params
Since 'waf' requires four params and 'make' only three in config.inc, I got confused with waf. Could anyone help me with waf params? Here is my config.inc: TARGET = arm-rtems4.11 BSP = c/raspberrypi/make PREFIX = /home/gtament/development/rtems/src/b-rpi Thanks in advance) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
pc386 libbsd test failures
Hi Things are looking a better if I build with waf but there is still one failure. I built and ran all these: unix01 rwlock01 selectpollkqueue01 sleep01 syscalls01 commands01 loopback01 swi01 timeout01 init01 thread01 mutex01 commands01 failed with this. But it also has run to completion. Looks about a 1/3 failure rate. === commands01 --- ::1 ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 11.330/11.330/11.330/nan ms PING6(56=40+8+8 bytes) ::1 --> ::1 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.414 ms --- ::1 ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.414/0.414/0.414/0.000 ms assertion "rtems_resource_snapshot_check(&snapshot)" failed: file "../../testsuite/commands01/test_main.c", line 216, function: test_ping6 === === -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd Makefile issues
On 06/23/2015 11:28 AM, Joel Sherrill wrote: Hi I decided to take a look at this and spotted what I think are at least two mistakes but when I fixed them, I got a build error. Help appreciated: Makefile.diff attached. But it then fails like this: $ make i386-rtems4.11-gcc --pipe -B/home/joel/rtems-4.11-work/bsp-install/i386-rtems4.11/pc386/lib/ -specs bsp_specs -qrtems -mtune=i386 -Wall -O2 -g -fno-strict-aliasing -ffreestanding -fno-common -Irtemsbsd/include -Irtemsbsd/i386/include -Ifreebsd/sys -Ifreebsd/sys/i386/include -Ifreebsd/sys/contrib/altq -Ifreebsd/sys/contrib/pf -Ifreebsd/include -Ifreebsd/lib/libc/include -Ifreebsd/lib/libc/isc/include -Ifreebsd/lib/libc/resolv -Ifreebsd/lib/libutil -Ifreebsd/lib/libkvm -Ifreebsd/lib/libmemstat -Ifreebsd/lib/libipsec -Irtemsbsd/sys -ImDNSResponder/mDNSCore -ImDNSResponder/mDNSShared -ImDNSResponder/mDNSPosix -Itestsuite/include -DHAVE_RTEMS_PCI_H=1 -Wall -Wno-format -MT freebsd/contrib/libpcap/scanner.o -MD -MP -MF freebsd/contrib/libpcap/scanner.d -std=gnu11 -D__FreeBSD__=1 -DBSD=1 -DINET6 -D_U_="__attribute__((unused))" -DHAVE_LIMITS_H=1 -DHAVE_INTTYPES=1 -DHAVE_STDINT=1 -DHAVE_STRERROR=1 -DHAVE_STRLCPY=1 -DHAVE_SNPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_SOCKADDR_SA_LEN=1 -DHAVE _NET_IF_MEDIA_H=1 -DHAVE_SYS_IOCCOM_H=1 -DNEED_YYPARSE_WRAPPER=1 -Dyylval=pcap_lval -c freebsd/contrib/libpcap/scanner.c -o freebsd/contrib/libpcap/scanner.o In file included from ../../freebsd/contrib/libpcap/scanner.l:51:0: freebsd/contrib/libpcap/pcap-int.h:39:23: fatal error: pcap/pcap.h: No such file or directory #include Here's the things I did to fix the Makefile. I think you added the quotes (item 1) and maybe item 2. I think the error you are seeing is due to item 3 since it can't find pcap.h. 1) Everywhere the string "-D_U_=__attribute__((unused))" appears in the rules it needs to be quoted. It appears in almost every rule so there are maybe 100s of them. (I used single quotes, FWIW.) 2) Everywhere sting "freebsd/usr.sbin/tcpdump/tcpdump-D__FreeBSD__=1" appears it needs have a space inserted: "freebsd/usr.sbin/tcpdump/tcpdump -D__FreeBSD__=1" Quotes aren't required. Again, there a many of these. 3) Several include paths need to be added: COMMON_FLAGS += -Ifreebsd/contrib/libpcap COMMON_FLAGS += -Irtemsbsd/sys COMMON_FLAGS += -Ifreebsd/usr.sbin/tcpdump/tcpdump COMMON_FLAGS += -Ifreebsd/contrib/tcpdump COMMON_FLAGS += -Ibuild/arm-rtems4.11-realview_pbx_a9_qemu/testsuite/include (The last one contains the bsp name so probably needs to be more general, but seems to work ok as an ad hoc fix.) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd Makefile issues
On 6/23/2015 1:09 PM, Gene Smith wrote: On 06/23/2015 11:28 AM, Joel Sherrill wrote: Hi I decided to take a look at this and spotted what I think are at least two mistakes but when I fixed them, I got a build error. Help appreciated: Makefile.diff attached. But it then fails like this: $ make i386-rtems4.11-gcc --pipe -B/home/joel/rtems-4.11-work/bsp-install/i386-rtems4.11/pc386/lib/ -specs bsp_specs -qrtems -mtune=i386 -Wall -O2 -g -fno-strict-aliasing -ffreestanding -fno-common -Irtemsbsd/include -Irtemsbsd/i386/include -Ifreebsd/sys -Ifreebsd/sys/i386/include -Ifreebsd/sys/contrib/altq -Ifreebsd/sys/contrib/pf -Ifreebsd/include -Ifreebsd/lib/libc/include -Ifreebsd/lib/libc/isc/include -Ifreebsd/lib/libc/resolv -Ifreebsd/lib/libutil -Ifreebsd/lib/libkvm -Ifreebsd/lib/libmemstat -Ifreebsd/lib/libipsec -Irtemsbsd/sys -ImDNSResponder/mDNSCore -ImDNSResponder/mDNSShared -ImDNSResponder/mDNSPosix -Itestsuite/include -DHAVE_RTEMS_PCI_H=1 -Wall -Wno-format -MT freebsd/contrib/libpcap/scanner.o -MD -MP -MF freebsd/contrib/libpcap/scanner.d -std=gnu11 -D__FreeBSD__=1 -DBSD=1 -DINET6 -D_U_="__attribute__((unused))" -DHAVE_LIMITS_H=1 -DHAVE_INTTYPES=1 -DHAVE_STDINT=1 -DHAVE_STRERROR=1 -DHAVE_STRLCPY=1 -DHAVE_SNPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_SOCKADDR_SA_LEN=1 -DHAVE _NET_IF_MEDIA_H=1 -DHAVE_SYS_IOCCOM_H=1 -DNEED_YYPARSE_WRAPPER=1 -Dyylval=pcap_lval -c freebsd/contrib/libpcap/scanner.c -o freebsd/contrib/libpcap/scanner.o In file included from ../../freebsd/contrib/libpcap/scanner.l:51:0: freebsd/contrib/libpcap/pcap-int.h:39:23: fatal error: pcap/pcap.h: No such file or directory #include Here's the things I did to fix the Makefile. I think you added the quotes (item 1) and maybe item 2. I think the error you are seeing is due to item 3 since it can't find pcap.h. 1) Everywhere the string "-D_U_=__attribute__((unused))" appears in the rules it needs to be quoted. It appears in almost every rule so there are maybe 100s of them. (I used single quotes, FWIW.) 2) Everywhere sting "freebsd/usr.sbin/tcpdump/tcpdump-D__FreeBSD__=1" appears it needs have a space inserted: "freebsd/usr.sbin/tcpdump/tcpdump -D__FreeBSD__=1" Quotes aren't required. Again, there a many of these. 3) Several include paths need to be added: COMMON_FLAGS += -Ifreebsd/contrib/libpcap COMMON_FLAGS += -Irtemsbsd/sys COMMON_FLAGS += -Ifreebsd/usr.sbin/tcpdump/tcpdump COMMON_FLAGS += -Ifreebsd/contrib/tcpdump COMMON_FLAGS += -Ibuild/arm-rtems4.11-realview_pbx_a9_qemu/testsuite/include (The last one contains the bsp name so probably needs to be more general, but seems to work ok as an ad hoc fix.) I could repeat those steps but if you have a patch, I am happy to push it. Please.. patch. :) Is it working for you on some target? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd Makefile issues
On 6/23/2015 1:18 PM, Joel Sherrill wrote: On 6/23/2015 1:09 PM, Gene Smith wrote: On 06/23/2015 11:28 AM, Joel Sherrill wrote: Hi I decided to take a look at this and spotted what I think are at least two mistakes but when I fixed them, I got a build error. Help appreciated: Makefile.diff attached. But it then fails like this: $ make i386-rtems4.11-gcc --pipe -B/home/joel/rtems-4.11-work/bsp-install/i386-rtems4.11/pc386/lib/ -specs bsp_specs -qrtems -mtune=i386 -Wall -O2 -g -fno-strict-aliasing -ffreestanding -fno-common -Irtemsbsd/include -Irtemsbsd/i386/include -Ifreebsd/sys -Ifreebsd/sys/i386/include -Ifreebsd/sys/contrib/altq -Ifreebsd/sys/contrib/pf -Ifreebsd/include -Ifreebsd/lib/libc/include -Ifreebsd/lib/libc/isc/include -Ifreebsd/lib/libc/resolv -Ifreebsd/lib/libutil -Ifreebsd/lib/libkvm -Ifreebsd/lib/libmemstat -Ifreebsd/lib/libipsec -Irtemsbsd/sys -ImDNSResponder/mDNSCore -ImDNSResponder/mDNSShared -ImDNSResponder/mDNSPosix -Itestsuite/include -DHAVE_RTEMS_PCI_H=1 -Wall -Wno-format -MT freebsd/contrib/libpcap/scanner.o -MD -MP -MF freebsd/contrib/libpcap/scanner.d -std=gnu11 -D__FreeBSD__=1 -DBSD=1 -DINET6 -D_U_="__attribute__((unused))" -DHAVE_LIMITS_H=1 -DHAVE_INTTYPES=1 -DHAVE_STDINT=1 -DHAVE_STRERROR=1 -DHAVE_STRLCPY=1 -DHAVE_SNPRINTF=1 -DHAVE_VSNPRINTF=1 -DHAVE_SOCKADDR_SA_LEN=1 -DHAVE _NET_IF_MEDIA_H=1 -DHAVE_SYS_IOCCOM_H=1 -DNEED_YYPARSE_WRAPPER=1 -Dyylval=pcap_lval -c freebsd/contrib/libpcap/scanner.c -o freebsd/contrib/libpcap/scanner.o In file included from ../../freebsd/contrib/libpcap/scanner.l:51:0: freebsd/contrib/libpcap/pcap-int.h:39:23: fatal error: pcap/pcap.h: No such file or directory #include Here's the things I did to fix the Makefile. I think you added the quotes (item 1) and maybe item 2. I think the error you are seeing is due to item 3 since it can't find pcap.h. 1) Everywhere the string "-D_U_=__attribute__((unused))" appears in the rules it needs to be quoted. It appears in almost every rule so there are maybe 100s of them. (I used single quotes, FWIW.) 2) Everywhere sting "freebsd/usr.sbin/tcpdump/tcpdump-D__FreeBSD__=1" appears it needs have a space inserted: "freebsd/usr.sbin/tcpdump/tcpdump -D__FreeBSD__=1" Quotes aren't required. Again, there a many of these. 3) Several include paths need to be added: COMMON_FLAGS += -Ifreebsd/contrib/libpcap COMMON_FLAGS += -Irtemsbsd/sys COMMON_FLAGS += -Ifreebsd/usr.sbin/tcpdump/tcpdump COMMON_FLAGS += -Ifreebsd/contrib/tcpdump COMMON_FLAGS += -Ibuild/arm-rtems4.11-realview_pbx_a9_qemu/testsuite/include (The last one contains the bsp name so probably needs to be more general, but seems to work ok as an ad hoc fix.) I could repeat those steps but if you have a patch, I am happy to push it. Please.. patch. :) I forgot this is generated. So the mistakes need to be accounted for in the generator. Is it working for you on some target? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd Makefile issues
On 06/23/2015 02:18 PM, Joel Sherrill wrote: On 6/23/2015 1:09 PM, Gene Smith wrote: Here's the things I did to fix the Makefile. I think you added the quotes (item 1) and maybe item 2. I think the error you are seeing is due to item 3 since it can't find pcap.h. 1) Everywhere the string "-D_U_=__attribute__((unused))" appears in the rules it needs to be quoted. It appears in almost every rule so there are maybe 100s of them. (I used single quotes, FWIW.) 2) Everywhere sting "freebsd/usr.sbin/tcpdump/tcpdump-D__FreeBSD__=1" appears it needs have a space inserted: "freebsd/usr.sbin/tcpdump/tcpdump -D__FreeBSD__=1" Quotes aren't required. Again, there a many of these. 3) Several include paths need to be added: COMMON_FLAGS += -Ifreebsd/contrib/libpcap COMMON_FLAGS += -Irtemsbsd/sys COMMON_FLAGS += -Ifreebsd/usr.sbin/tcpdump/tcpdump COMMON_FLAGS += -Ifreebsd/contrib/tcpdump COMMON_FLAGS += -Ibuild/arm-rtems4.11-realview_pbx_a9_qemu/testsuite/include (The last one contains the bsp name so probably needs to be more general, but seems to work ok as an ad hoc fix.) I could repeat those steps but if you have a patch, I am happy to push it. Please.. patch. :) Is it working for you on some target? It basically works on realview with qemu but the last COMMON_FLAGS addition for include paths will break it for other bsp's I suspect. But I will send the patch via private email since it is quite large. -gene ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
pcpu_find() in rtems-libbsd
Hi I am working through i386 support and turning on the legacy.c file to get to PCI, I ran into needing the method pcpu_find() which finds the BSD per cpu structure for this CPU. struct pcpu *pcpu_find(u_int cpuid); So that leads to the question: + Since this looks to be used only for tracking purposes, can we just provide a method that returns NULL? Any other thoughts on how to deal with this? I could ifdef it, but it seemed less intrusive to define a macro or implementation that returned a NULL. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd Makefile issues
On Jun 23, 2015, at 8:30 PM, Gene Smith wrote: > On 06/23/2015 02:18 PM, Joel Sherrill wrote: >> >> >> On 6/23/2015 1:09 PM, Gene Smith wrote: >>> >>> Here's the things I did to fix the Makefile. I think you added the >>> quotes (item 1) and maybe item 2. I think the error you are seeing is >>> due to item 3 since it can't find pcap.h. >>> >>> 1) Everywhere the string "-D_U_=__attribute__((unused))" appears in the >>> rules it needs to be quoted. It appears in almost every rule so there >>> are maybe 100s of them. (I used single quotes, FWIW.) >>> >>> 2) Everywhere sting "freebsd/usr.sbin/tcpdump/tcpdump-D__FreeBSD__=1" >>> appears it needs have a space inserted: >>> "freebsd/usr.sbin/tcpdump/tcpdump -D__FreeBSD__=1" >>> Quotes aren't required. Again, there a many of these. >>> >>> 3) Several include paths need to be added: >>> COMMON_FLAGS += -Ifreebsd/contrib/libpcap >>> COMMON_FLAGS += -Irtemsbsd/sys >>> COMMON_FLAGS += -Ifreebsd/usr.sbin/tcpdump/tcpdump >>> COMMON_FLAGS += -Ifreebsd/contrib/tcpdump >>> COMMON_FLAGS += >>> -Ibuild/arm-rtems4.11-realview_pbx_a9_qemu/testsuite/include >>> (The last one contains the bsp name so probably needs to be more >>> general, but seems to work ok as an ad hoc fix.) A git pull of rtems-libbsd this morning still has the above problems, so I’ve generated the attached patch. This last -I seems odd. Before I tried building with waf, I could not find a build/ directory anywhere. As mentioned in another e-mail, rtems-libbsd doesn’t currently build for the realview example for me, but for as far as it got, there is only one file that could get picked up by this -I and that is build/arm-rtems4.11-realview_pbx_a9_qemu/testsuite/include/rtems/bsd/test/network-config.h. I don’t find network-config.h anywhere else in either the rtems-libbsd or rtems trees, nor in those created by make and make install of an RTEMS BSP, so I’m not sure what the proper -I option would be. At any rate, in the attached patch I included it (commented out) as -Ibuild/$(TARGET)-$(BSP)/testsuite/include. With this, both make and waf get to the same place before crashing. Ric > >> >> I could repeat those steps but if you have a patch, I am >> happy to push it. >> >> Please.. patch. :) >> >> Is it working for you on some target? >> > > It basically works on realview with qemu but the last COMMON_FLAGS addition > for include paths will break it for other bsp's I suspect. But I will send > the patch via private email since it is quite large. > > -gene > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel 0001-Fixes-as-per-rtems-devel-e-mails.patch Description: Binary data ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-libbsd Build Error
Hi
I am trying to build rtems-libbsd for xilinx_zynq_a9_qemu using
tools and RTEMS built from their master branches. Both the
master and 5-freebsd-12 branch fail to build with this error:
In file included from ../../rtemsbsd/rtems/rtems-kernel-thread.c:56:0:
/home/joel/rtems-class/tools/5/bsp-install/arm-rtems5/xilinx_zynq_a9_qemu/lib/include/rtems/score/objectimpl.h:
In function '_Objects_Free':
/home/joel/rtems-class/tools/5/bsp-install/arm-rtems5/xilinx_zynq_a9_qemu/lib/include/rtems/score/objectimpl.h:937:17:
error: 'Objects_Information {aka struct Objects_Information}' has no member
named '_bsd_free'
( *information->free )( information, the_object );
I think the solution is that the structure member free needs to be renamed.
61357479 (Sebastian Huber 2019-12-16 14:50:59 +0100 213) void ( *free )(
Objects_Information *, Objects_Control * );
FWIW I was looking at the MISRA C/C++ rules earlier this week and this is a
violation of one of them. You should not have variables, methods, structure
members, etc that use the same name as standard library entiries.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Firmware for libbsd drivers
Hello, the i.MX7 has complex DMA controller (SDMA) which needs a firmware https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma/sdma-imx7d.bin under this license (non-BSD) https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.sdma_firmware You can generate a firmware source file with this libbsd provided script: ./firmware-gen.py -l LICENSE.sdma_firmware sdma_fw sdma-imx7d.bin sdma-imx7d.c What do we want to do with such files? Without this firmware you cannot use the DMA controller on this platform. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Severe bug in libbsd
Hello, I fixed a severe bug in libbsd today. All libbsd users should consider to update to the latest version or back port this fix for the callout support: https://git.rtems.org/rtems-libbsd/commit/?id=6d9d7b195621ffda676eda0154ebb8ee24dc3186 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Trouble with rtems-libbsd
Hi
Just reporting as FYI. I'm building for powerpc, but it looks like
it's building some ARM components too and failing.
Thanks in advance!
Jeff
Here's my rtems configure, which seems to work:
# ../rtems/configure --prefix=/home/tester/rtems/kernel/ppc \
--target=powerpc-rtems5 --enable-rtemsbsp=mcp750 \
--enable-posix --disable-networking
Then, pulled rtems-libbsd and ran the submodule commands.
Here's my waf configure, which seems to work too:
# waf configure
--prefix=/home/tester/rtems/kernel/ppc \
--rtems=/home/tester/rtems/kernel/ppc \
--rtems-tools=/home/tester/rtems/tools \
--rtems-bsps=powerpc/mcp750
But then running waf fails with this:
# waf
...
[1328/2017] Compiling freebsd/contrib/tcpdump/util-print.c
[1329/2017] Compiling freebsd/sys/arm/at91/at91_mci.c
In file included from
/home/tester/rtems/rtems-libbsd/freebsd/sys/sys/systm.h:42:0,
from ../../freebsd/sys/arm/at91/at91_mci.c:36:
/home/tester/rtems/rtems-libbsd/freebsd/sys/powerpc/include/machine/cpufunc.h:166:1:
error: redefinition of 'eieio'
eieio(void)
^
In file included from
/home/tester/rtems/kernel/ppc/powerpc-rtems5/mcp750/lib/include/bsp.h:14:0,
from
/home/tester/rtems/kernel/ppc/powerpc-rtems5/mcp750/lib/include/bsp/fdt.h:18,
from
/home/tester/rtems/rtems-libbsd/rtemsbsd/include/rtems/bsd/local/opt_platform.h:1,
from ../../freebsd/sys/arm/at91/at91_mci.c:30:
/home/tester/rtems/kernel/ppc/powerpc-rtems5/mcp750/lib/include/libcpu/io.h:53:20:
note: previous definition of 'eieio' was here
static inline void eieio(void)
^
Waf: Leaving directory
`/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default'
Build failed
-> task in 'bsd' failed (exit status 1):
{task 139731466652368: c at91_mci.c -> at91_mci.c.136.o}
['/home/tester/rtems/tools/bin/powerpc-rtems5-gcc', '-qrtems',
'-B/home/tester/rtems/kernel/ppc/powerpc-rtems5/lib/',
'-B/home/tester/rtems/kernel/ppc/powerpc-rtems5/mcp750/lib/', '--specs',
'bsp_specs', '-mcpu=750', '-mcpu=750', '-mmultiple', '-mmultiple', '-mstring',
'-mstring', '-mstrict-align', '-mstrict-align', '-ffunction-sections',
'-ffunction-sections', '-fdata-sections', '-fdata-sections', '-O2', '-g',
'-fno-strict-aliasing', '-ffreestanding', '-fno-common', '-w',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/rtemsbsd/powerpc/include',
'-I/home/tester/rtems/rtems-libbsd/rtemsbsd/powerpc/include',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/sys/powerpc/include',
'-I/home/tester/rtems/rtems-libbsd/freebsd/sys/powerpc/include',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/rtemsbsd/include',
'-I/home/tester/rtems/rtems-libbsd/rtemsbsd/include',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/sys',
'-I/home/tester/rtems/rtems-libbsd/freebsd/sys',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/sys/contrib/pf',
'-I/home/tester/rtems/rtems-libbsd/freebsd/sys/contrib/pf',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/crypto',
'-I/home/tester/rtems/rtems-libbsd/freebsd/crypto',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/sys/net',
'-I/home/tester/rtems/rtems-libbsd/freebsd/sys/net',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/include',
'-I/home/tester/rtems/rtems-libbsd/freebsd/include',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/lib',
'-I/home/tester/rtems/rtems-libbsd/freebsd/lib',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/lib/libbsdstat',
'-I/home/tester/rtems/rtems-libbsd/freebsd/lib/libbsdstat',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/lib/libc/include',
'-I/home/tester/rtems/rtems-libbsd/freebsd/lib/libc/include',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/lib/libc/isc/include',
'-I/home/tester/rtems/rtems-libbsd/freebsd/lib/libc/isc/include',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/lib/libc/resolv',
'-I/home/tester/rtems/rtems-libbsd/freebsd/lib/libc/resolv',
'-I/home/tester/rtems/rtems-libbsd/build/powerpc-rtems5-mcp750-default/freebsd/lib/libutil&#
Raspberry Pi libbsd experiments
This message is just FYI. I just wanted to document some of the tests I ran on the Pi with Deval's last GSOC rtems-libbsd branch for the Raspberry Pi. https://github.com/deval-maker/rtems-libbsd/tree/RPi_USB_Ethernet There are definitely some timing issues.. When I run ping01, I need a delay between the rtems_bsd_initialize call and the default_network_ifconfig_hwif0. Without the delay, the network device will not be initialized before the ifconfig call is made. Sebastian had mentioned earlier the need to use an event based initialization. Even with the delay, the ifconfig call ends up waiting for USB messages and never returns. Another thing I noticed: If I plug in a USB flash drive into the USB port of the Pi, the ethernet interface will be recognized, and the mac, and phy seems to be setup. Without the drive plugged in, the ethernet device will not fully be initialized. ( see logs below ). This must be a timing issue as well. I guess having the extra USB drive plugged in causes a delay that allows the ethernet device to initialize? The flash drives are recognized, but I'm not sure how close we are to actually being able to read data from them. Here are the logs: 1. Running media01 test on the Raspberry Pi Model B with ethernet and 2 USB flash drives plugged in to the USB ports. Note that I added #define RTEMS_BSD_CONFIG_BSP_CONFIG in default-init.h in the test suite to get the media01 test to recognize the Raspberry Pi USB devices. This define was in the default-network-init.h There are extra debug printfs below, as I was trying to figure out how far the code was getting, and I don't have a debug solution for the Raspberry Pi yet. --- *** LIBBSD MEDIA 1 TEST *** nexus0: bcm283x_dwcotg0: on nexus0 usbus0 on bcm283x_dwcotg0 usbus0: 480Mbps High Speed USB v2.0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop uhub1: on usbus0 uhub1: MTT enabled uhub1: 5 ports with 4 removable, self powered in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop smsc0: on usbus0 in ue_queue_command in ue_queue_command -- calling task? usb_proc_msignal in ue_queue_command -- setup callback and self pointers in ue_queue_command --returning smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: 5a:ee:60:74:67:92 in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x media listener: event = DISK ATTACH, state = INQUIRY, src = umass-sim rtems_bsd_sim_attach_worker: OOPS: inquiry failed in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop umass1: on usbus0 umass1: SCSI over Bulk-Only; quirks = 0x4000 err: ftpd: Error binding control socket: Address not available info: ftpd: FTP daemon started (4 sessions max) info: /dev/pty0../dev/pty4 (5) pseudo-terminals registered. telnetd:bind: Address not available telnetd started with stacksize = 32768 and priority = 100 RTEMS Shell on /dev/console. Use 'help' to list commands. [/] # rtems_bsd_sim_attach_worker: OOPS: test unit ready failed rtems_bsd_sim_attach_worker: OOPS: read capacity failed media listener: event = DISK ATTACH, state = FAILED, src = umass-sim media listener: event = DISK ATTACH, state = INQUIRY, src = umass-sim rtems_bsd_sim_attach_worker: OOPS: inquiry failed rtems_bsd_sim_attach_worker: OOPS: test unit ready failed rtems_bsd_sim_attach_worker: OOPS: read capacity failed media listener: event = DISK ATTACH, state = FAILED, src = umass-sim 2. Same test as above ( media01 ) but without USB flash drives plugged into the USB ports. See how the ethernet is detected, but not as complete as in the previous test: *** LIBBSD MEDIA 1 TEST *** nexus0: bcm283x_dwcotg0: on nexus0 usbus0 on bcm283x_dwcotg0 usbus0: 480Mbps High Speed USB v2.0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop uhub1: on usbus0 uhub1: MTT enabled uhub1: 5 ports with 4 removable, self powered in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop in usb_proc_mwait -- in usb_proc_mwait -- else clause - while loop smsc0: on usbus0 in ue_queue_command in ue_queue_command -- calling task? usb_proc_msignal in ue_queue_command -- setup callback and self pointers in ue_queue_command --returning --- 3. media01 test on the Raspberry Pi Zero with a single USB flash drive plugged in. The Pi Zero just has a single USB por
RTEMS LIBBSD Pipe Support
The attached patch pulls in FreeBSDs pipe functionality into RTEMS LIBBSD. Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 rtems-libbsd-pipe-submit.diff Description: rtems-libbsd-pipe-submit.diff ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
LIBBSD USB Serial Patch
The LIBBSD USB Serial patch depends on the LIBBSD TTY patch I sent out earlier. Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS-libbsd copyright question
Hi all, I have a question about copyright in rtems-libbsd: i ported some usb driver files from FreeBSD, i modified somewhere in these files to suit with rtems-libbsd. Should i add my copyright in these file? Besides, I also modified some files in the rtemsbsd folder,. Should i add my copyright in these file? Best Regards Sichen Zhao ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LIBBSD Build Error
Sorry, should be fixed now: https://git.rtems.org/rtems-libbsd/commit/?id=9db59c71ad8bc1f1852838d147a29467a1cd6e3d -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS-libbsd trailing whitespace
Hi Sebastian, When i import file from freebsd-org by using ./freebsd-to-rtems.py -R && ./freebsd-to-rtems.py, these files seems has many trailing whitespace. When i try to create the patch then apply it, there are many warning. So should i remove these trailing whitespace handly or just leave it. Best Regards Sichen Zhao ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-libbsd Makefile support.
Hi, Should I remove this? I have no idea if it works? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
waf changes to libbsd.
Hi, Now makefile support has been removed from libbsd I would like to move the wscript to not be generated and to have it import the generated part. This will make maintaining the non-generated part easier because I do not need to edit python within python strings. OK? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
LibBSD /etc/rc.conf changes
Hi, The implementation I added to LibBSD parses the rc.conf file and invokes handers for each directive in the file. The approach has exposed a few issues and I have decided to re-implement the code to better follow the FreeBSD approach. Specially the network start up automatically sets up the lo0 interface. With DHCP initialisation waits defaultroute_delay seconds for the default route to be set before moving on once all interfaces are set up. These cannot be implemented with the current way the rc.conf parsing is done. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
LibBSD configuration and initialisation.
Hello,
The following is the current status for LibBSD configuration and
initialisation. I am starting to formalise the way this is done and as a
result I would like any further work on LibBSD to support the
configuration and initialisation methods I present.
User manual document is coming.
Configuration
-
I have added user application support to LibBSD. This follows the same
configuration model RTEMS uses with confdefs.h. In your 'init.c' you
define the features, interfaces, and services and then include
. For example:
/*
* Configure LibBSD.
*/
#define RTEMS_BSD_CONFIG_DOMAIN_PAGE_MBUFS_SIZE (16 * 1024 * 1024)
#define RTEMS_BSD_CONFIG_NET_PF_UNIX
#define RTEMS_BSD_CONFIG_NET_IF_LAGG
#define RTEMS_BSD_CONFIG_NET_IF_VLAN
#define RTEMS_BSD_CONFIG_SERVICE_FTPD
#define RTEMS_BSD_CONFIG_BSP_CONFIG
#define RTEMS_BSD_CONFIG_INIT
#include
rtems_task Init(rtems_task_argument ignored)
{
rtems_bsd_initialize();
my_app();
}
Notes:
- This interface will be documented and it is expected to be maintained.
- All further drivers added to LibBSD should provide the appropriate
layered support. What exists needs to be moved to this model as required.
- Please update the documenting comment sections if present in the
headers. Please fix omission as you find them.
- RTEMS_BSD_CONFIG_BSP_CONFIG creates a suitable default set up that
matches the set up for the testsuite. If you are on a BSP that has a
plug-in bus like the PC and PCI you may want to specialise the
configuration. The header can provide examples of
how to do this.
- The testsuite's 'default-init.h' and default-network-init.h supports
this configuration method.
- I have only concentrated on networking and I have not looked at media,
usb etc, other that attempting to maintain what exists.
Initialisation
--
I have completed the rc.conf changes needed to support interface network
set up and services. For example on the arm/xilinx_zynq_a9_qemu and qemu
you can now enable ftpd with an rc.conf file:
#
# Example rc.conf or arm/xilinx_zynq_a9_qemu with DHCP and ftpd.
#
hostname="awesome"
ifconfig_cgem0="DHCP"
defaultroute_delay="15"
# Services
ftpd_enabled="YES"
ftpd_options="-v -p 21 -C 10 -P 150 -L -I 10 -R /"
A subset of https://www.freebsd.org/cgi/man.cgi?query=rc.conf is
supported. I happy to add more features as demand dictates.
If an interface or service is not configured into the build the lines in
rc.conf are ignored. This is useful when you are testing on different
BSPs with different interfaces. See rcconf02 as an example.
An example Init is:
#include
rtems_task Init(rtems_task_argument ignored)
{
int r;
rtems_bsd_initialize();
/* Run /etc/rc.conf with timeout, verbose */
r = rtems_bsd_run_etc_rc_conf(60, false);
if (r < 0)
fprintf(stderr,
"error: awesome badness: %s\n", strerror(errno);
my_app();
}
Note:
- I consider the existing rtems_*_initialise method of initialisation
depreciated in LibBSD and would like it removed. The global non-const
struct's can then be removed as the services can be initialised by
argc/argv command lines. The ftpd service provides an example. Moving
the initialisation to an options command line allows us to hide these
tables and that means we can make changes without breaking existing user
code.
- VLANs are supported using:
vlans_cgem0="101 102"
ifconfig_cgem0.101="inet 192.0.101.1/24"
ifconfig_cgem0.102="inet 192.0.102.1/24"
- dhcpcd is configured using 'dhcpcd_options', eg
dhcpcd_options="-h foobar"
See https://www.freebsd.org/cgi/man.cgi?query=dhcpcd for details.
- The SYNCDHCP is the same as DHCP as dhcpcd always runs in the
background. Interface probing to ensure it is initialised could be added
if required allow SYNCDHCP to be correctly supported.
- As required by FreeBSD any DHCP interface will block initialisation
until a default route is detected. You can control the timeout with
'defaultroute_delay' and 0 means do not wait.
- rc.conf processing happens on a worker thread and you can specify a
time out so your main line initialisation thread does not block forever
if something blocks the initialisation.
As a back ground task I am adding rc.conf support for the other services
in LibBSD:
telnetd
pppd
mghttpd
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
lpc32xx and rtems-libbsd
I have created a libbsd port for a modified version of the lpc32xx BSP. The lpc code from FREEBSD 10 was backported to FREEBSD 9.3 because FREEBSD 9.3 did not support ARM LPC processors. I ran into some issues that I would like to run by the group. Issue 1 - the order of declared modules in nexus-devices.h does not guarantee that they will come up in that order on boot up. a. The lpc code consists of multiple modules that need to be instantiated in a particular order. When running the libbsd testsuite (mainly dhcp01 and usb01), the boot up order of the modules was different for each test. In one case it was OK but the other was not. b. To have some control over the ordering, I added order support to RTEMS_BSD_DEFINE_NEXUS_DEVICE (RTEMS_BSD_DEFINE_NEXUS_DEVICE_ORDERED). This is modeled off of what FREEBSD does for DRIVER_MODULE (DRIVER_MODULE_ORDERED). A small change to rtems-kernel-nexus.c was needed to support this. Issue 2 - rtems_bsd_get_mac_address() , rtems_bsd_get_task_priority(), and rtems_bsd_get_task_stack_size() are application dependent. Are we against creating a configuration structure to initialize these things before rtems_bsd_initialize() is called? At a bare minimum, the RTEMS BSP could set some variables used by libbsd. Kevin Kirspel Electrical Engineer - Sr. Staff Opti Medical 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
legacy stack or libbsd
I'm trying to figure out when compiling a third party software (EPICS), whether the RTEMS for a target bsp was created with the legacy stack or uses the libbsd stack. Unfortunately I have found some different definitions: in target.cfg : RTEMS_HAS_NETWORKING in bsp.cfg : HAS_NETWORKING in header files #if defined(RTEMS_NETWORKING) Which one should I take best? I tend to RTEMS_HAS_NETWORKING in target.cfg ;-) Danke Heinz smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Problems compiling rtems-libbsd
I am trying to build the rtems-libbsd package to test the new network stack. Configuration works fine, but compiling fails quickly. Log below, any ideas ...? jiri@carbon:~/ibm/src/rtems/rtems-libbsd$ python3 ./waf configure --rtems-bsps=sparc/leon3 --prefix=/opt/rtems/6 --buildset=buildset/default.ini Setting top to : /home/jiri/ibm/src/rtems/rtems-libbsd Setting out to : /home/jiri/ibm/src/rtems/rtems-libbsd/build RTEMS Version : 6 Architectures : riscv-rtems6, sparc-rtems6 Board Support Package (BSP) : sparc-rtems6-leon3 Show commands : no Long commands : no Checking for program 'sparc-rtems6-gcc' : /opt/rtems/6/bin/sparc-rtems6-gcc Checking for program 'sparc-rtems6-g++' : /opt/rtems/6/bin/sparc-rtems6-g++ Checking for program 'sparc-rtems6-gcc' : /opt/rtems/6/bin/sparc-rtems6-gcc Checking for program 'sparc-rtems6-ld' : /opt/rtems/6/bin/sparc-rtems6-ld Checking for program 'sparc-rtems6-ar' : /opt/rtems/6/bin/sparc-rtems6-ar Checking for program 'sparc-rtems6-nm' : /opt/rtems/6/bin/sparc-rtems6-nm Checking for program 'sparc-rtems6-objdump' : /opt/rtems/6/bin/sparc-rtems6-objdump Checking for program 'sparc-rtems6-objcopy' : /opt/rtems/6/bin/sparc-rtems6-objcopy Checking for program 'sparc-rtems6-readelf' : /opt/rtems/6/bin/sparc-rtems6-readelf Checking for program 'sparc-rtems6-strip' : /opt/rtems/6/bin/sparc-rtems6-strip Checking for program 'sparc-rtems6-ranlib' : /opt/rtems/6/bin/sparc-rtems6-ranlib Checking for program 'rtems-ld' : /opt/rtems/6/bin/rtems-ld Checking for program 'rtems-tld' : /opt/rtems/6/bin/rtems-tld Checking for program 'rtems-syms' : /opt/rtems/6/bin/rtems-syms Checking for program 'rtems-bin2c' : /opt/rtems/6/bin/rtems-bin2c Checking for program 'tar' : /bin/tar Checking for program 'gcc, cc' : /opt/rtems/6/bin/sparc-rtems6-gcc Checking for program 'ar' : /opt/rtems/6/bin/sparc-rtems6-ar Checking for program 'g++, c++' : /opt/rtems/6/bin/sparc-rtems6-g++ Checking for program 'ar' : /opt/rtems/6/bin/sparc-rtems6-ar Checking for program 'gas, gcc' : /opt/rtems/6/bin/sparc-rtems6-gcc Checking for program 'ar' : /opt/rtems/6/bin/sparc-rtems6-ar Checking for c flags '-MMD' : yes Checking for cxx flags '-MMD' : yes Compiler version (sparc-rtems6-gcc) : 10.2.1 20200904 (RTEMS 6, RSB 31f936a7b74d60bda609a9960c6e1a705ba54974, Newlib a0d7982) Checking for a valid RTEMS BSP installation : yes Checking for RTEMS_DEBUG : no Checking for RTEMS_MULTIPROCESSING : no Checking for RTEMS_NEWLIB : yes Checking for RTEMS_POSIX_API : yes Checking for RTEMS_SMP : no Checking for RTEMS_NETWORKING : no Checking for header dlfcn.h : yes Checking for header rtems/pci.h : yes Configure variant: : sparc-rtems6-leon3-default Checking for library debugger : yes 'configure' finished successfully (0.871s) jiri@carbon:~/ibm/src/rtems/rtems-libbsd$ python3 ./waf Waf: Entering directory `/home/jiri/ibm/src/rtems/rtems-libbsd/build/sparc-rtems6-leon3-default' [ 7/1954] Compiling freebsd/contrib/libpcap/grammar.c [ 9/1954] Compiling freebsd/sbin/pfctl/parse.c [ 12/1954] Compiling freebsd/contrib/expat/lib/xmltok_ns.c [ 13/1954] Compiling freebsd/contrib/expat/lib/xmltok_impl.c [ 14/1954] Compiling freebsd/contrib/expat/lib/xmltok.c [ 15/1954] Compiling freebsd/lib/libc/net/getnetbynis.c grammar.y: In function 'pcap_parse': grammar.y:693:31: error: 'BPF_MOD' undeclared (first use in this function); did you mean 'BPF_MODE'? grammar.y:693:31: note: each undeclared identifier is reported only once for each function it appears in grammar.y:696:31: error: 'BPF_XOR' undeclared (first use in this function); did you mean 'BPF_OR'? parse.y: In function '_bsd_pfctl_expand_label_str': parse.y:4853:10: error: macro "free" requires 2 arguments, but only 1 given In file included from /opt/rtems/6/sparc-rtems6/leon3/lib/include/sys/malloc.h:39, from ../../freebsd/sys/net/pfvar.h:42, from parse.y:64: /opt/rtems/6/sparc-rtems6/leon3/lib/include/rtems/rtems_bsdnet_internal.h:148: note: macro "free" defined here 148 | #define free(ptr,type) rtems_bsdnet_free(ptr,type) | parse.y: In function '_bsd_pfctl_expand_altq':
Re: stm32h7 on libbsd?
Hello Gedare, I _think_ Sebastian tested it on the same evaluation board that I used for writing the SD driver: STM32H743I-EVAL2. I'm not entirely sure whether the "2" is really relevant or whether that's part of an order number at a distributor. Best regards Christian On 29/06/2021 19:48, Gedare Bloom wrote: I see STM32H7 was added to the nexus last year in March. Was libbsd/networking tested on any hardware devices? Thanks, Gedare ___ 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: stm32h7 on libbsd?
Hello Gedare, On 29/06/2021 20:04, Christian Mauderer wrote: I _think_ Sebastian tested it on the same evaluation board that I used for writing the SD driver: STM32H743I-EVAL2. I'm not entirely sure whether the "2" is really relevant or whether that's part of an order number at a distributor. yes, I used this board to test the network interface driver. It works also on custom hardware. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
