[PATCH v3] Add mmap

2019-07-17 Thread Vijay Kumar Banerjee 
---
 freebsd/sys/kern/kern_conf.c   |  8 +++
 freebsd/sys/sys/conf.h |  2 +-
 rtemsbsd/include/machine/vm.h  |  2 ++
 rtemsbsd/sys/fs/devfs/devfs_devs.c | 34 ++
 testsuite/cdev01/test_cdev.c   | 17 ++-
 testsuite/cdev01/test_cdev01.h |  3 ++-
 testsuite/cdev01/test_main.c   |  4 
 7 files changed, 63 insertions(+), 7 deletions(-)

diff --git a/freebsd/sys/kern/kern_conf.c b/freebsd/sys/kern/kern_conf.c
index 92237d9d..560a450a 100644
--- a/freebsd/sys/kern/kern_conf.c
+++ b/freebsd/sys/kern/kern_conf.c
@@ -328,8 +328,8 @@ static struct cdevsw dead_cdevsw = {
.d_write =  dead_write,
.d_ioctl =  dead_ioctl,
.d_poll =   dead_poll,
-#ifndef __rtems__
.d_mmap =   dead_mmap,
+#ifndef __rtems__
.d_strategy =   dead_strategy,
 #endif /* __rtems__ */
.d_name =   "dead",
@@ -522,7 +522,6 @@ giant_kqfilter(struct cdev *dev, struct knote *kn)
return (retval);
 }
 
-#ifndef __rtems__
 static int
 giant_mmap(struct cdev *dev, vm_ooffset_t offset, vm_paddr_t *paddr, int nprot,
 vm_memattr_t *memattr)
@@ -541,6 +540,7 @@ giant_mmap(struct cdev *dev, vm_ooffset_t offset, 
vm_paddr_t *paddr, int nprot,
return (retval);
 }
 
+#ifndef __rtems__
 static int
 giant_mmap_single(struct cdev *dev, vm_ooffset_t *offset, vm_size_t size,
 vm_object_t *object, int nprot)
@@ -667,8 +667,8 @@ prep_cdevsw(struct cdevsw *devsw, int flags)
devsw->d_write = dead_write;
devsw->d_ioctl = dead_ioctl;
devsw->d_poll = dead_poll;
-#ifndef __rtems__
devsw->d_mmap = dead_mmap;
+#ifndef __rtems__
devsw->d_mmap_single = dead_mmap_single;
devsw->d_strategy = dead_strategy;
devsw->d_dump = dead_dump;
@@ -702,8 +702,8 @@ prep_cdevsw(struct cdevsw *devsw, int flags)
FIXUP(d_write,  no_write,   giant_write);
FIXUP(d_ioctl,  no_ioctl,   giant_ioctl);
FIXUP(d_poll,   no_poll,giant_poll);
-#ifndef __rtems__
FIXUP(d_mmap,   no_mmap,giant_mmap);
+#ifndef __rtems__
FIXUP(d_strategy,   no_strategy,giant_strategy);
 #endif /* __rtems__ */
FIXUP(d_kqfilter,   no_kqfilter,giant_kqfilter);
diff --git a/freebsd/sys/sys/conf.h b/freebsd/sys/sys/conf.h
index 4ace162f..c0a66442 100644
--- a/freebsd/sys/sys/conf.h
+++ b/freebsd/sys/sys/conf.h
@@ -209,8 +209,8 @@ struct cdevsw {
d_write_t   *d_write;
d_ioctl_t   *d_ioctl;
d_poll_t*d_poll;
-#ifndef __rtems__
d_mmap_t*d_mmap;
+#ifndef __rtems__
d_strategy_t*d_strategy;
dumper_t*d_dump;
 #endif /* __rtems__ */
diff --git a/rtemsbsd/include/machine/vm.h b/rtemsbsd/include/machine/vm.h
index e69de29b..351b7472 100644
--- a/rtemsbsd/include/machine/vm.h
+++ b/rtemsbsd/include/machine/vm.h
@@ -0,0 +1,2 @@
+#define VM_MEMATTR_DEFAULT 0
+#define VM_MEMATTR_UNCACHEABLE 1
diff --git a/rtemsbsd/sys/fs/devfs/devfs_devs.c 
b/rtemsbsd/sys/fs/devfs/devfs_devs.c
index 7c697b0a..9878936f 100644
--- a/rtemsbsd/sys/fs/devfs/devfs_devs.c
+++ b/rtemsbsd/sys/fs/devfs/devfs_devs.c
@@ -387,6 +387,39 @@ devfs_imfs_kqfilter(rtems_libio_t *iop, struct knote *kn)
return error;
 }
 
+static int
+devfs_imfs_mmap(rtems_libio_t *iop, void **addr, size_t len, int prot,
+off_t off)
+{
+   struct cdev *cdev = devfs_imfs_get_context_by_iop(iop);
+   struct file *fp = rtems_bsd_iop_to_fp(iop);
+   struct thread *td = rtems_bsd_get_curthread_or_null();
+   struct file *fpop;
+   struct cdevsw *dsw;
+   int error, ref;
+
+   if (td != 0) {
+   if (cdev == NULL) {
+   error = ENXIO;
+   }
+   if (cdev->si_flags & SI_ALIAS) {
+   cdev = cdev->si_parent;
+   }
+   dsw = dev_refthread(cdev, &ref);
+   if (dsw == NULL) {
+   error = ENXIO;
+   }
+   fpop = td->td_fpop;
+   curthread->td_fpop = fp;
+   error = dsw->d_mmap( cdev, off, (vm_paddr_t *) addr, prot, 
VM_MEMATTR_DEFAULT);
+   td->td_fpop = fpop;
+   dev_relthread(cdev, ref);
+   } else {
+   error = ENOMEM;
+   }
+   return error;
+}
+
 static const rtems_filesystem_file_handlers_r devfs_imfs_handlers = {
.open_h = devfs_imfs_open,
.close_h = devfs_imfs_close,
@@ -403,6 +436,7 @@ static const rtems_filesystem_file_handlers_r 
devfs_imfs_handlers = {
.kqfilter_h = devfs_imfs_kqfilter,
.readv_h = devfs_imfs_readv,
.writev_h = devfs_imfs_writev,
+   .mmap_h = devfs_imfs_mmap,
 };
 
 static const IMFS_node_control devfs_imfs_control = IMFS_GENERIC_INITIALIZER(
diff --git a/testsu

Re: [PATCH v2] Add mmap

2019-07-17 Thread Vijay Kumar Banerjee 
On Wed, Jul 17, 2019 at 10:26 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 16/07/2019 21:47, Vijay Kumar Banerjee wrote:
> > + rv = mmap(NULL, 1, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> > + assert(rv != MAP_FAILED);
> > +
>
> Please change this to:
>
> assert(rv == 0);
>
> Please add assertions for the flags (PROT*, MAP*) to your mmap handler.
>
> Thanks for the review.
I have fixed this in v3 of the patch:
https://lists.rtems.org/pipermail/devel/2019-July/026650.html

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] Add mmap

2019-07-17 Thread Sebastian Huber 

On 17/07/2019 09:02, Vijay Kumar Banerjee wrote:

+   if (td != 0) {
+   if (cdev == NULL) {
+   error = ENXIO;
+   }


Suppose cdev == NULL, then you have a NULL pointer access here:


+   if (cdev->si_flags & SI_ALIAS) {
+   cdev = cdev->si_parent;
+   }



--
Sebastian Huber, embedded brains GmbH

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

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] Add mmap

2019-07-17 Thread Sebastian Huber 

On 17/07/2019 09:02, Vijay Kumar Banerjee wrote:

+static int
+testmmap(struct cdev *dev, vm_ooffset_t offset, vm_paddr_t *paddr,
+ int nprot, vm_memattr_t *memattr)
+{
+   test_state *state = dev->si_drv1;
+


Please add assertions for all parameters.


+   assert(*state == TEST_KQFILTER);
+   *state = TEST_MMAP;
+
+   return 0;
+}


--
Sebastian Huber, embedded brains GmbH

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

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] Add mmap

2019-07-17 Thread Nils Hölscher 
On Wed, 17 Jul 2019 at 09:03, Vijay Kumar Banerjee 
wrote:

> ---
>  freebsd/sys/kern/kern_conf.c   |  8 +++
>  freebsd/sys/sys/conf.h |  2 +-
>  rtemsbsd/include/machine/vm.h  |  2 ++
>  rtemsbsd/sys/fs/devfs/devfs_devs.c | 34 ++
>  testsuite/cdev01/test_cdev.c   | 17 ++-
>  testsuite/cdev01/test_cdev01.h |  3 ++-
>  testsuite/cdev01/test_main.c   |  4 
>  7 files changed, 63 insertions(+), 7 deletions(-)
>
> diff --git a/freebsd/sys/kern/kern_conf.c b/freebsd/sys/kern/kern_conf.c
> index 92237d9d..560a450a 100644
> --- a/freebsd/sys/kern/kern_conf.c
> +++ b/freebsd/sys/kern/kern_conf.c
> @@ -328,8 +328,8 @@ static struct cdevsw dead_cdevsw = {
> .d_write =  dead_write,
> .d_ioctl =  dead_ioctl,
> .d_poll =   dead_poll,
> -#ifndef __rtems__
> .d_mmap =   dead_mmap,
> +#ifndef __rtems__
> .d_strategy =   dead_strategy,
>  #endif /* __rtems__ */
> .d_name =   "dead",
> @@ -522,7 +522,6 @@ giant_kqfilter(struct cdev *dev, struct knote *kn)
> return (retval);
>  }
>
> -#ifndef __rtems__
>  static int
>  giant_mmap(struct cdev *dev, vm_ooffset_t offset, vm_paddr_t *paddr, int
> nprot,
>  vm_memattr_t *memattr)
> @@ -541,6 +540,7 @@ giant_mmap(struct cdev *dev, vm_ooffset_t offset,
> vm_paddr_t *paddr, int nprot,
> return (retval);
>  }
>
> +#ifndef __rtems__
>  static int
>  giant_mmap_single(struct cdev *dev, vm_ooffset_t *offset, vm_size_t size,
>  vm_object_t *object, int nprot)
> @@ -667,8 +667,8 @@ prep_cdevsw(struct cdevsw *devsw, int flags)
> devsw->d_write = dead_write;
> devsw->d_ioctl = dead_ioctl;
> devsw->d_poll = dead_poll;
> -#ifndef __rtems__
> devsw->d_mmap = dead_mmap;
> +#ifndef __rtems__
> devsw->d_mmap_single = dead_mmap_single;
> devsw->d_strategy = dead_strategy;
> devsw->d_dump = dead_dump;
> @@ -702,8 +702,8 @@ prep_cdevsw(struct cdevsw *devsw, int flags)
> FIXUP(d_write,  no_write,   giant_write);
> FIXUP(d_ioctl,  no_ioctl,   giant_ioctl);
> FIXUP(d_poll,   no_poll,giant_poll);
> -#ifndef __rtems__
> FIXUP(d_mmap,   no_mmap,giant_mmap);
> +#ifndef __rtems__
> FIXUP(d_strategy,   no_strategy,giant_strategy);
>  #endif /* __rtems__ */
> FIXUP(d_kqfilter,   no_kqfilter,giant_kqfilter);
> diff --git a/freebsd/sys/sys/conf.h b/freebsd/sys/sys/conf.h
> index 4ace162f..c0a66442 100644
> --- a/freebsd/sys/sys/conf.h
> +++ b/freebsd/sys/sys/conf.h
> @@ -209,8 +209,8 @@ struct cdevsw {
> d_write_t   *d_write;
> d_ioctl_t   *d_ioctl;
> d_poll_t*d_poll;
> -#ifndef __rtems__
> d_mmap_t*d_mmap;
> +#ifndef __rtems__
> d_strategy_t*d_strategy;
> dumper_t*d_dump;
>  #endif /* __rtems__ */
> diff --git a/rtemsbsd/include/machine/vm.h b/rtemsbsd/include/machine/vm.h
> index e69de29b..351b7472 100644
> --- a/rtemsbsd/include/machine/vm.h
> +++ b/rtemsbsd/include/machine/vm.h
> @@ -0,0 +1,2 @@
>
 Hi,

+#define VM_MEMATTR_DEFAULT 0
> +#define VM_MEMATTR_UNCACHEABLE 1
>

Are you sure that these values are correct in general?
BSD defines this only for ARM versions smaller 6.
https://github.com/freebsd/freebsd/blob/1d6e4247415d264485ee94b59fdbc12e0c566fd0/sys/arm/include/vm.h


> diff --git a/rtemsbsd/sys/fs/devfs/devfs_devs.c
> b/rtemsbsd/sys/fs/devfs/devfs_devs.c
> index 7c697b0a..9878936f 100644
> --- a/rtemsbsd/sys/fs/devfs/devfs_devs.c
> +++ b/rtemsbsd/sys/fs/devfs/devfs_devs.c
> @@ -387,6 +387,39 @@ devfs_imfs_kqfilter(rtems_libio_t *iop, struct knote
> *kn)
> return error;
>  }
>
> +static int
> +devfs_imfs_mmap(rtems_libio_t *iop, void **addr, size_t len, int prot,
> +off_t off)
> +{
> +   struct cdev *cdev = devfs_imfs_get_context_by_iop(iop);
> +   struct file *fp = rtems_bsd_iop_to_fp(iop);
> +   struct thread *td = rtems_bsd_get_curthread_or_null();
> +   struct file *fpop;
> +   struct cdevsw *dsw;
> +   int error, ref;
> +
> +   if (td != 0) {
> +   if (cdev == NULL) {
> +   error = ENXIO;
> +   }
> +   if (cdev->si_flags & SI_ALIAS) {
> +   cdev = cdev->si_parent;
> +   }
> +   dsw = dev_refthread(cdev, &ref);
> +   if (dsw == NULL) {
> +   error = ENXIO;
> +   }
> +   fpop = td->td_fpop;
> +   curthread->td_fpop = fp;
> +   error = dsw->d_mmap( cdev, off, (vm_paddr_t *) addr, prot,
> VM_MEMATTR_DEFAULT);
> +   td->td_fpop = fpop;
> +   dev_relthread(cdev, ref);
> +   } else {
> +   error = ENOMEM;
> +   }
> +

Re: GSoC Linux UIO driver for PRU

2019-07-17 Thread Nils Hölscher 
Hi,

I applied the patch and now all compiles.
But I haven't tested anything yet, I am currently working on an application
for testing.
I will keep in contact concerning the mmap patch.

Best,
Nils

On Tue, 16 Jul 2019 at 15:47, Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> On 16/07/2019 15:35, Vijay Kumar Banerjee wrote:
> >
> >
> >
> > On Tue, Jul 16, 2019 at 6:57 PM Nils Hölscher  > > wrote:
> >
> > Thanks I have been able to resolve this.
> >
> > But I have run into another issue.
> > RTEMS port of the character device switch table doesn't support
> > a .d_mmap entry.
> >
> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/sys/conf.h#L199
> >
> > And I am not certain how the
> > struct rtems_filesystem_file_handlers_r and the structs cdevsw are
> > related.
> > The current BSD driver uses two  cdevsw structs, one to manage
> > interrupts and one to manage io.
> > Should or can I switch them out?
> >
> > Hi Nils,
> >
> > I have recently worked on a patch to add d_mmap to libbsd. I couldn't
> > send it to devel because
> > it could not be tested.
> > Christian, by the time the VT issue is resolved. I would like to prepare
> > a separate clean patch
> > for the mmap, what is your suggestion about this?
>
> You create a clean patch only for mmap. Please don't forget to add a
> test case to the libbsd devfs test. Although I would have preferred a
> working driver to test it, it should be OK to be added without one if
> the devfs test works.
>
> Please send a preview of the patch (without devfs test) to the mailing
> list so that Nils can already have a look at it and try it.
>
> Best regards
>
> Christian
>
> >
> > Best,
> > Nils
> >
> > On Tue, 16 Jul 2019 at 13:47, Joel Sherrill  > > wrote:
> >
> >
> >
> > On Tue, Jul 16, 2019, 6:34 AM Nils Hölscher  > > wrote:
> >
> > Hi,
> >
> > I am currently porting the pruss driver functions, that I
> > want to add in:
> > rtems_filesystem_file_handlers_r pruss_irq_handler.
> > But when I add  my functions like this:
> >   .open_h =ti_pruss_irq_open
> > I receive the following compiler warnings:
> > ../../pruss.c:156:13: warning: initialization from
> > incompatible pointer type [-Wincompatible-pointer-types]
> >.open_h = ti_pruss_irq_open,
> >  ^
> > ../../pruss.c:156:13: note: (near initialization for
> > 'pruss_irq_handler.open_h')
> > ../../pruss.c:158:13: warning: initialization from
> > incompatible pointer type [-Wincompatible-pointer-types]
> >.read_h = ti_pruss_irq_read,
> >
> > Can anyone help please?
> >
> >
> > This usually means that either the prototype of the method has
> > not been seen before it is used or the method signature does not
> > match that expected of the indirect method pointer on the left
> > hand side. Make sure the signature matches.
> >
> > The full source can be found here:
> >
> https://github.com/nilhoel1/rtems-pru/blob/pruss-shell/pruss.c#L91
> >
> https://github.com/nilhoel1/rtems-pru/blob/pruss-shell/pruss.c#L155
> >
> > Best,
> > Nils
> >
> > On Mon, 15 Jul 2019 at 10:15, Sebastian Huber
> >  > > wrote:
> >
> > On 15/07/2019 10:10, Nils Hölscher wrote:
> > > Thanks this is very helpful.
> > > But has anyone an existing example of a similar driver?
> > > I wasn't able find one in /bsps, maybe I didn't search
> > long enough.
> >
> > There are some in cpukit:
> >
> > cpukit/libcsupport/src/consolesimple.c:
> > IMFS_make_generic_node(
> > cpukit/libcsupport/src/termios.c:  rv =
> > IMFS_make_generic_node(
> > cpukit/libcsupport/src/consolesimpletask.c:
> > IMFS_make_generic_node(
> > cpukit/include/rtems/imfs.h: *   rv =
> > IMFS_make_generic_node(
> > cpukit/include/rtems/imfs.h:extern int
> > IMFS_make_generic_node(
> > cpukit/libfs/src/imfs/imfs_make_generic_node.c:int
> > IMFS_make_generic_node(
> > cpukit/dev/i2c/i2c-bus.c:  rv = IMFS_make_generic_node(
> > cpukit/dev/i2c/i2c-dev.c:  rv = IMFS_make_generic_node(
> > cpukit/dev/spi/spi-bus.c:  rv = IMFS_make_generic_node(
> > cpukit/libblock/src/blkdev-imfs.c:  int rv =
> > IMFS_make_generic_node(
> >

Re: GSoC Project | Trace Compass

2019-07-17 Thread Sebastian Huber 

Hello Ravindra,

very well done. Having something that is readable by Trace Compass at a 
basic level is a big step forward. Please focus now on providing the 
events in a structure similar to LTTNG.


--
Sebastian Huber, embedded brains GmbH

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

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] ndbm test suite

2019-07-17 Thread Gedare Bloom 
On Wed, Jul 10, 2019 at 1:49 AM Vaibhav Gupta  wrote:
>
> ---
>  testsuites/psxtests/Makefile.am  |   7 +
>  testsuites/psxtests/configure.ac |   1 +
>  testsuites/psxtests/psxndbm01/init.c | 260 +++
>  3 files changed, 268 insertions(+)
>  create mode 100644 testsuites/psxtests/psxndbm01/init.c
>
> diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
> index 59c9f2085b..7d1c0a783c 100755
> --- a/testsuites/psxtests/Makefile.am
> +++ b/testsuites/psxtests/Makefile.am
> @@ -694,6 +694,13 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS) 
> $(TEST_FLAGS_psxmutexattr01) \
> $(support_includes) -I$(top_srcdir)/include
>  endif
>
> +if TEST_psxndbm01
> +psx_tests += psxndbm01
> +psxndbm01_SOURCES = psxndbm01/init.c
> +psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
> +   $(support_includes)
> +endif
> +
>  if TEST_psxobj01
>  psx_tests += psxobj01
>  psx_screens += psxobj01/psxobj01.scn
> diff --git a/testsuites/psxtests/configure.ac 
> b/testsuites/psxtests/configure.ac
> index 85559e4aa5..07d7ccaf55 100644
> --- a/testsuites/psxtests/configure.ac
> +++ b/testsuites/psxtests/configure.ac
> @@ -110,6 +110,7 @@ RTEMS_TEST_CHECK([psxmsgq02])
>  RTEMS_TEST_CHECK([psxmsgq03])
>  RTEMS_TEST_CHECK([psxmsgq04])
>  RTEMS_TEST_CHECK([psxmutexattr01])
> +RTEMS_TEST_CHECK([psxndbm01])
>  RTEMS_TEST_CHECK([psxobj01])
>  RTEMS_TEST_CHECK([psxonce01])
>  RTEMS_TEST_CHECK([psxpasswd01])
> diff --git a/testsuites/psxtests/psxndbm01/init.c 
> b/testsuites/psxtests/psxndbm01/init.c
> new file mode 100644
> index 00..b38900361d
> --- /dev/null
> +++ b/testsuites/psxtests/psxndbm01/init.c
> @@ -0,0 +1,260 @@
> +/**
> + *  @file
> + *  @brief Test suite for ndbm.h methods
> + */
> +
> +/*
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (C) 2019 Vaibhav Gupta
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +/* header files are listed in lexical/lexicographical/alphabetical order */
> +
> +#include 
> +#include   /* contains definitions of `open_flags` */
> +#include 
> +#include/* conatains declarations of ndbm methods */
> +#include 
> +#include 
> +#include 
> +#include/* contains definitions of `file_mode` */
> +#include 
> +#include 
> +#include 
> +
> +const char rtems_test_name[] = "PSXNDBM 01";
> +
> +#define NAME  "VARoDeK"
> +#define PHONE_NO  "123-321-777-888"
> +#define DB_NAME   "phones_test"
> +#define NAME2 "VG"
> +#define PHONE_NO2 "321-123-888-777"
> +
> +/* forward declarations to avoid warnings */
> +rtems_task Init(rtems_task_argument ignored);
> +
> +rtems_task Init(rtems_task_argument ignored)
> +{
> +  datum name = { NAME , sizeof( NAME ) };
> +  datum put_phone_no = { PHONE_NO, sizeof( PHONE_NO ) };
> +  datum get_phone_no, key;
> +
> +  datum name2 = { NAME2 , sizeof( NAME2 ) };
> +  datum put_phone_no2 = { PHONE_NO2 , sizeof( PHONE_NO2 ) };
> +
> +  int i;
> +  char *test_strings;
> +
> +  DBM *db;
> +
> +  TEST_BEGIN();
> +
> +/* A Simple test to check if ndbm methods are call-able */
> +
> +/* Store a simple data
> + * This record (procedure) will be helpful in further tests
> + */
> +
> +  puts( "Open Database." );
> +  db = dbm_open( DB_NAME , O_RDWR | O_CREAT | O_TRUNC , S_IRWXU );
Remove the extra blank space character before the comma.

> +  rtems_test_assert( db != NULL );
> +
> +  puts( "Store Records in Database." );
> +  dbm_store( db , name , put_phone_no , DBM_INSERT );
ditto, and more below.

> +
> +  puts( "Fetch Records from Database and check." );
> +  get_phone_no = dbm_fetch( db , name );
> +  r

Re: [PATCH v3] ndbm test suite

2019-07-17 Thread Vaibhav Gupta 
Thanks for the review!
I will re generate the patch with corrections

On Wed, Jul 17, 2019 at 10:12 PM Gedare Bloom  wrote:

> On Wed, Jul 10, 2019 at 1:49 AM Vaibhav Gupta 
> wrote:
> >
> > ---
> >  testsuites/psxtests/Makefile.am  |   7 +
> >  testsuites/psxtests/configure.ac |   1 +
> >  testsuites/psxtests/psxndbm01/init.c | 260 +++
> >  3 files changed, 268 insertions(+)
> >  create mode 100644 testsuites/psxtests/psxndbm01/init.c
> >
> > diff --git a/testsuites/psxtests/Makefile.am
> b/testsuites/psxtests/Makefile.am
> > index 59c9f2085b..7d1c0a783c 100755
> > --- a/testsuites/psxtests/Makefile.am
> > +++ b/testsuites/psxtests/Makefile.am
> > @@ -694,6 +694,13 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS)
> $(TEST_FLAGS_psxmutexattr01) \
> > $(support_includes) -I$(top_srcdir)/include
> >  endif
> >
> > +if TEST_psxndbm01
> > +psx_tests += psxndbm01
> > +psxndbm01_SOURCES = psxndbm01/init.c
> > +psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
> > +   $(support_includes)
> > +endif
> > +
> >  if TEST_psxobj01
> >  psx_tests += psxobj01
> >  psx_screens += psxobj01/psxobj01.scn
> > diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
> configure.ac
> > index 85559e4aa5..07d7ccaf55 100644
> > --- a/testsuites/psxtests/configure.ac
> > +++ b/testsuites/psxtests/configure.ac
> > @@ -110,6 +110,7 @@ RTEMS_TEST_CHECK([psxmsgq02])
> >  RTEMS_TEST_CHECK([psxmsgq03])
> >  RTEMS_TEST_CHECK([psxmsgq04])
> >  RTEMS_TEST_CHECK([psxmutexattr01])
> > +RTEMS_TEST_CHECK([psxndbm01])
> >  RTEMS_TEST_CHECK([psxobj01])
> >  RTEMS_TEST_CHECK([psxonce01])
> >  RTEMS_TEST_CHECK([psxpasswd01])
> > diff --git a/testsuites/psxtests/psxndbm01/init.c
> b/testsuites/psxtests/psxndbm01/init.c
> > new file mode 100644
> > index 00..b38900361d
> > --- /dev/null
> > +++ b/testsuites/psxtests/psxndbm01/init.c
> > @@ -0,0 +1,260 @@
> > +/**
> > + *  @file
> > + *  @brief Test suite for ndbm.h methods
> > + */
> > +
> > +/*
> > + * SPDX-License-Identifier: BSD-2-Clause
> > + *
> > + * Copyright (C) 2019 Vaibhav Gupta
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + *notice, this list of conditions and the following disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + *notice, this list of conditions and the following disclaimer in
> the
> > + *documentation and/or other materials provided with the
> distribution.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> CONTRIBUTORS BE
> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
> IN
> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
> OF THE
> > + * POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +#ifdef HAVE_CONFIG_H
> > +#include "config.h"
> > +#endif
> > +
> > +/* header files are listed in lexical/lexicographical/alphabetical
> order */
> > +
> > +#include 
> > +#include   /* contains definitions of `open_flags` */
> > +#include 
> > +#include/* conatains declarations of ndbm methods */
> > +#include 
> > +#include 
> > +#include 
> > +#include/* contains definitions of `file_mode` */
> > +#include 
> > +#include 
> > +#include 
> > +
> > +const char rtems_test_name[] = "PSXNDBM 01";
> > +
> > +#define NAME  "VARoDeK"
> > +#define PHONE_NO  "123-321-777-888"
> > +#define DB_NAME   "phones_test"
> > +#define NAME2 "VG"
> > +#define PHONE_NO2 "321-123-888-777"
> > +
> > +/* forward declarations to avoid warnings */
> > +rtems_task Init(rtems_task_argument ignored);
> > +
> > +rtems_task Init(rtems_task_argument ignored)
> > +{
> > +  datum name = { NAME , sizeof( NAME ) };
> > +  datum put_phone_no = { PHONE_NO, sizeof( PHONE_NO ) };
> > +  datum get_phone_no, key;
> > +
> > +  datum name2 = { NAME2 , sizeof( NAME2 ) };
> > +  datum put_phone_no2 = { PHONE_NO2 , sizeof( PHONE_NO2 ) };
> > +
> > +  int i;
> > +  char *test_strings;
> > +
> > +  DBM *db;
> > +
> > +  TEST_BEGIN();
> > +
> > +/* A Simple test to check if ndbm methods are call-able */
> > +
> > +/* Store a simple data
> > + * This record (procedure) will be helpful in further tests
> > + */
> > +
> > +  puts( "Open Database." );

Re: Sources for fenv (ARM, PPC, x86, SPARC and RISC5)

2019-07-17 Thread Gedare Bloom 
On Tue, Jul 16, 2019 at 6:57 AM Joel Sherrill  wrote:
>
> Let's give preference to FreeBSD sources. Notes below.
>
> On Wed, Jul 3, 2019 at 1:08 PM Vaibhav Gupta  wrote:
>>
>> Hello,
>> I have found sources for fenv.
>>
>> 1.1) - ARM FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.c
>> .
>> 1.2) - ARM NetBSD Source :
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/arm/fenv.c
>> -
>
>
> For the ARM FreeBSD source, there are some ifdef's which appear to
> be for architectural variations. Please check the gcc source for arm
> (gcc-XXX/gcc/config/arm) to see if they are defined by gcc. If they
> all are, then there is nothing to consider on how they get tripped.
>
> For example, __ARM_PCS_AAPCS64 is one. That looks like a multilib
> define.
>
>>
>> 2.1) - SPARC NetBSD Source :
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/sparc/fenv.c
>> 
>
>
> This looks good and may work for sparc64 as well as sparc. Check if
> sparc64-rtems5-gcc defines __arch64 as used byL
>
> https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h#L36
>
>>
>> 3.1) - PPC FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.c
>> .
>> 3.2) - PPC NetBSD Source:
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/powerpc/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/powerpc/fenv.c
>> ---
>
>
> Sam advice on PPC. Looks OK, check ifdefs
>
>>
>> 4.1) - x86 FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/x86/fenv.h
>> .
>> 4.2) - x86 NetBSD Source:
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/x86_64/fenv.c
>> --
>
>
> This is not i386 (e.g. 32-bit), it is for the 64-bit target. Good to merge it 
> into
> newlib but we don't have a fully functional port to test this with.
>
>>
>> 5.1) - RISC5 FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.c
>> .
>> 5.2) - RISC5 NetBSD Source:
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/riscv/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/riscv/fenv.c
>> 
>
>
> Same advice.
>
>>
>> 
>>
>> It's impossible to depend on either NetBSD or FreeBSD.
>
>
> Yep. Give preference to FreeBSD but if it isn't in FreeBSD, use NetBSD.
>>
>> .
>> For some architectures, FreeBSD has code,
>> for some, NetBSD has.
>> .
>> For x86, Free BSD has explicit header
>> and NetBSD has .c file.
>
>
> These are all architecture specific files so do not go in a main include
> or source directory. They go in an architecture specific subdirectory.
>
> See 
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libm/machine;h=9b2197b2660fd84c6b64ef265c1ec3b6e30c9074;hb=HEAD
>
> And notice that arm, aarch64, riscv, and i386 are all already there. Looks
> like you can focus on the ones not there (PPC and SPARC). Ignore x86_64
> for now. If there is a ticket for the port, just add a comment to that. I 
> don't
> think we are setup to test that port right now.
>
Since arm/riscv/i386 are there, you might be able to write an fenv
test suite that can pass on one of those archs, and then use it with
confidence to do TDD of other architectures.

> Hope that all makes sense.
>
> --joel
>
>> .
>> .
>> .
>> Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3] ndbm test suite

2019-07-17 Thread Gedare Bloom 
On Wed, Jul 17, 2019 at 11:09 AM Vaibhav Gupta  wrote:
>
> Thanks for the review!
> I will re generate the patch with corrections
>
> On Wed, Jul 17, 2019 at 10:12 PM Gedare Bloom  wrote:
>>
>> On Wed, Jul 10, 2019 at 1:49 AM Vaibhav Gupta  
>> wrote:
>> >
>> > ---
>> >  testsuites/psxtests/Makefile.am  |   7 +
>> >  testsuites/psxtests/configure.ac |   1 +
>> >  testsuites/psxtests/psxndbm01/init.c | 260 +++
>> >  3 files changed, 268 insertions(+)
>> >  create mode 100644 testsuites/psxtests/psxndbm01/init.c
>> >
>> > diff --git a/testsuites/psxtests/Makefile.am 
>> > b/testsuites/psxtests/Makefile.am
>> > index 59c9f2085b..7d1c0a783c 100755
>> > --- a/testsuites/psxtests/Makefile.am
>> > +++ b/testsuites/psxtests/Makefile.am
>> > @@ -694,6 +694,13 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS) 
>> > $(TEST_FLAGS_psxmutexattr01) \
>> > $(support_includes) -I$(top_srcdir)/include
>> >  endif
>> >
>> > +if TEST_psxndbm01
>> > +psx_tests += psxndbm01
>> > +psxndbm01_SOURCES = psxndbm01/init.c
>> > +psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
>> > +   $(support_includes)
>> > +endif
>> > +
>> >  if TEST_psxobj01
>> >  psx_tests += psxobj01
>> >  psx_screens += psxobj01/psxobj01.scn
>> > diff --git a/testsuites/psxtests/configure.ac 
>> > b/testsuites/psxtests/configure.ac
>> > index 85559e4aa5..07d7ccaf55 100644
>> > --- a/testsuites/psxtests/configure.ac
>> > +++ b/testsuites/psxtests/configure.ac
>> > @@ -110,6 +110,7 @@ RTEMS_TEST_CHECK([psxmsgq02])
>> >  RTEMS_TEST_CHECK([psxmsgq03])
>> >  RTEMS_TEST_CHECK([psxmsgq04])
>> >  RTEMS_TEST_CHECK([psxmutexattr01])
>> > +RTEMS_TEST_CHECK([psxndbm01])
>> >  RTEMS_TEST_CHECK([psxobj01])
>> >  RTEMS_TEST_CHECK([psxonce01])
>> >  RTEMS_TEST_CHECK([psxpasswd01])
>> > diff --git a/testsuites/psxtests/psxndbm01/init.c 
>> > b/testsuites/psxtests/psxndbm01/init.c
>> > new file mode 100644
>> > index 00..b38900361d
>> > --- /dev/null
>> > +++ b/testsuites/psxtests/psxndbm01/init.c
>> > @@ -0,0 +1,260 @@
>> > +/**
>> > + *  @file
>> > + *  @brief Test suite for ndbm.h methods
>> > + */
>> > +
>> > +/*
>> > + * SPDX-License-Identifier: BSD-2-Clause
>> > + *
>> > + * Copyright (C) 2019 Vaibhav Gupta
>> > + *
>> > + * Redistribution and use in source and binary forms, with or without
>> > + * modification, are permitted provided that the following conditions
>> > + * are met:
>> > + * 1. Redistributions of source code must retain the above copyright
>> > + *notice, this list of conditions and the following disclaimer.
>> > + * 2. Redistributions in binary form must reproduce the above copyright
>> > + *notice, this list of conditions and the following disclaimer in the
>> > + *documentation and/or other materials provided with the distribution.
>> > + *
>> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
>> > "AS IS"
>> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, 
>> > THE
>> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
>> > PURPOSE
>> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS 
>> > BE
>> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR 
>> > BUSINESS
>> > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
>> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
>> > THE
>> > + * POSSIBILITY OF SUCH DAMAGE.
>> > + */
>> > +
>> > +#ifdef HAVE_CONFIG_H
>> > +#include "config.h"
>> > +#endif
>> > +
>> > +/* header files are listed in lexical/lexicographical/alphabetical order 
>> > */
>> > +
>> > +#include 
>> > +#include   /* contains definitions of `open_flags` */
>> > +#include 
>> > +#include/* conatains declarations of ndbm methods */
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include/* contains definitions of `file_mode` */
>> > +#include 
>> > +#include 
>> > +#include 
>> > +
>> > +const char rtems_test_name[] = "PSXNDBM 01";
>> > +
>> > +#define NAME  "VARoDeK"
>> > +#define PHONE_NO  "123-321-777-888"
>> > +#define DB_NAME   "phones_test"
>> > +#define NAME2 "VG"
>> > +#define PHONE_NO2 "321-123-888-777"
>> > +
>> > +/* forward declarations to avoid warnings */
>> > +rtems_task Init(rtems_task_argument ignored);
>> > +
>> > +rtems_task Init(rtems_task_argument ignored)
>> > +{
>> > +  datum name = { NAME , sizeof( NAME ) };
>> > +  datum put_phone_no = { PHONE_NO, sizeof( PHONE_NO ) };
>> > +  datum get_phone_no, key;
>> > +
>> > +  datum name2 = { NAME2 , sizeof( NAME2 ) };
>> > +  datum put_phone_no2 = { PHONE_NO2 , sizeof( PHONE_NO2 ) };
>> > +
>> > +  int i;
>> > +  char *test_strings;
>> > +
>> > +  DBM *db;
>> > +
>> > +  TEST_B

Re: [PATCH v3] ndbm test suite

2019-07-17 Thread Vaibhav Gupta 
On Wed, Jul 17, 2019, 11:46 PM Gedare Bloom  wrote:

> On Wed, Jul 17, 2019 at 11:09 AM Vaibhav Gupta 
> wrote:
> >
> > Thanks for the review!
> > I will re generate the patch with corrections
> >
> > On Wed, Jul 17, 2019 at 10:12 PM Gedare Bloom  wrote:
> >>
> >> On Wed, Jul 10, 2019 at 1:49 AM Vaibhav Gupta 
> wrote:
> >> >
> >> > ---
> >> >  testsuites/psxtests/Makefile.am  |   7 +
> >> >  testsuites/psxtests/configure.ac |   1 +
> >> >  testsuites/psxtests/psxndbm01/init.c | 260
> +++
> >> >  3 files changed, 268 insertions(+)
> >> >  create mode 100644 testsuites/psxtests/psxndbm01/init.c
> >> >
> >> > diff --git a/testsuites/psxtests/Makefile.am
> b/testsuites/psxtests/Makefile.am
> >> > index 59c9f2085b..7d1c0a783c 100755
> >> > --- a/testsuites/psxtests/Makefile.am
> >> > +++ b/testsuites/psxtests/Makefile.am
> >> > @@ -694,6 +694,13 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS)
> $(TEST_FLAGS_psxmutexattr01) \
> >> > $(support_includes) -I$(top_srcdir)/include
> >> >  endif
> >> >
> >> > +if TEST_psxndbm01
> >> > +psx_tests += psxndbm01
> >> > +psxndbm01_SOURCES = psxndbm01/init.c
> >> > +psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
> >> > +   $(support_includes)
> >> > +endif
> >> > +
> >> >  if TEST_psxobj01
> >> >  psx_tests += psxobj01
> >> >  psx_screens += psxobj01/psxobj01.scn
> >> > diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
> configure.ac
> >> > index 85559e4aa5..07d7ccaf55 100644
> >> > --- a/testsuites/psxtests/configure.ac
> >> > +++ b/testsuites/psxtests/configure.ac
> >> > @@ -110,6 +110,7 @@ RTEMS_TEST_CHECK([psxmsgq02])
> >> >  RTEMS_TEST_CHECK([psxmsgq03])
> >> >  RTEMS_TEST_CHECK([psxmsgq04])
> >> >  RTEMS_TEST_CHECK([psxmutexattr01])
> >> > +RTEMS_TEST_CHECK([psxndbm01])
> >> >  RTEMS_TEST_CHECK([psxobj01])
> >> >  RTEMS_TEST_CHECK([psxonce01])
> >> >  RTEMS_TEST_CHECK([psxpasswd01])
> >> > diff --git a/testsuites/psxtests/psxndbm01/init.c
> b/testsuites/psxtests/psxndbm01/init.c
> >> > new file mode 100644
> >> > index 00..b38900361d
> >> > --- /dev/null
> >> > +++ b/testsuites/psxtests/psxndbm01/init.c
> >> > @@ -0,0 +1,260 @@
> >> > +/**
> >> > + *  @file
> >> > + *  @brief Test suite for ndbm.h methods
> >> > + */
> >> > +
> >> > +/*
> >> > + * SPDX-License-Identifier: BSD-2-Clause
> >> > + *
> >> > + * Copyright (C) 2019 Vaibhav Gupta
> >> > + *
> >> > + * Redistribution and use in source and binary forms, with or without
> >> > + * modification, are permitted provided that the following conditions
> >> > + * are met:
> >> > + * 1. Redistributions of source code must retain the above copyright
> >> > + *notice, this list of conditions and the following disclaimer.
> >> > + * 2. Redistributions in binary form must reproduce the above
> copyright
> >> > + *notice, this list of conditions and the following disclaimer
> in the
> >> > + *documentation and/or other materials provided with the
> distribution.
> >> > + *
> >> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS "AS IS"
> >> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> >> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR PURPOSE
> >> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> CONTRIBUTORS BE
> >> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
> OR
> >> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
> OF
> >> > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> >> > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN
> >> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> >> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> ADVISED OF THE
> >> > + * POSSIBILITY OF SUCH DAMAGE.
> >> > + */
> >> > +
> >> > +#ifdef HAVE_CONFIG_H
> >> > +#include "config.h"
> >> > +#endif
> >> > +
> >> > +/* header files are listed in lexical/lexicographical/alphabetical
> order */
> >> > +
> >> > +#include 
> >> > +#include   /* contains definitions of `open_flags` */
> >> > +#include 
> >> > +#include/* conatains declarations of ndbm methods */
> >> > +#include 
> >> > +#include 
> >> > +#include 
> >> > +#include/* contains definitions of `file_mode` */
> >> > +#include 
> >> > +#include 
> >> > +#include 
> >> > +
> >> > +const char rtems_test_name[] = "PSXNDBM 01";
> >> > +
> >> > +#define NAME  "VARoDeK"
> >> > +#define PHONE_NO  "123-321-777-888"
> >> > +#define DB_NAME   "phones_test"
> >> > +#define NAME2 "VG"
> >> > +#define PHONE_NO2 "321-123-888-777"
> >> > +
> >> > +/* forward declarations to avoid warnings */
> >> > +rtems_task Init(rtems_task_argument ignored);
> >> > +
> >> > +rtems_task Init(rtems_task_argument ignored)
> >> > +{
> >> > +  datum name = { NAME , sizeof( NAME ) };
> >> > +  datum put_phone_no = { PHONE_NO, sizeof( PHONE_N

Re: [PATCH v3] Add mmap

2019-07-17 Thread Christian Mauderer 
On 17/07/2019 11:10, Nils Hölscher wrote:
>  Hi,
> 
> +#define VM_MEMATTR_DEFAULT 0
> +#define VM_MEMATTR_UNCACHEABLE 1
> 
> 
> Are you sure that these values are correct in general?
> BSD defines this only for ARM versions smaller 6.
> https://github.com/freebsd/freebsd/blob/1d6e4247415d264485ee94b59fdbc12e0c566fd0/sys/arm/include/vm.h
>  

Hello Nils,

the VM_MEMATTR_* defines are machine dependent:

https://github.com/freebsd/freebsd/blob/1d6e4247415d264485ee94b59fdbc12e0c566fd0/sys/vm/vm.h#L117

Our "machine" is RTEMS. So theoretically every value could be defined
here. It's just relevant that the RTEMS implementation of the functions
handling these flags know how to use them. Currently the handling is to
ignore them (till someone has a problem with it). So I think the values
should be OK.

By the way: sparc64 in FreeBSD ignores them too. They even define both to 0.

Best regards

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

[PATCH v4] Add mmap

2019-07-17 Thread Vijay Kumar Banerjee 
---
 freebsd/sys/kern/kern_conf.c   |  8 +++
 freebsd/sys/sys/conf.h |  2 +-
 rtemsbsd/include/machine/vm.h  |  2 ++
 rtemsbsd/sys/fs/devfs/devfs_devs.c | 38 ++
 testsuite/cdev01/test_cdev.c   | 21 -
 testsuite/cdev01/test_cdev01.h |  3 ++-
 testsuite/cdev01/test_main.c   |  4 
 7 files changed, 71 insertions(+), 7 deletions(-)

diff --git a/freebsd/sys/kern/kern_conf.c b/freebsd/sys/kern/kern_conf.c
index 92237d9d..560a450a 100644
--- a/freebsd/sys/kern/kern_conf.c
+++ b/freebsd/sys/kern/kern_conf.c
@@ -328,8 +328,8 @@ static struct cdevsw dead_cdevsw = {
.d_write =  dead_write,
.d_ioctl =  dead_ioctl,
.d_poll =   dead_poll,
-#ifndef __rtems__
.d_mmap =   dead_mmap,
+#ifndef __rtems__
.d_strategy =   dead_strategy,
 #endif /* __rtems__ */
.d_name =   "dead",
@@ -522,7 +522,6 @@ giant_kqfilter(struct cdev *dev, struct knote *kn)
return (retval);
 }
 
-#ifndef __rtems__
 static int
 giant_mmap(struct cdev *dev, vm_ooffset_t offset, vm_paddr_t *paddr, int nprot,
 vm_memattr_t *memattr)
@@ -541,6 +540,7 @@ giant_mmap(struct cdev *dev, vm_ooffset_t offset, 
vm_paddr_t *paddr, int nprot,
return (retval);
 }
 
+#ifndef __rtems__
 static int
 giant_mmap_single(struct cdev *dev, vm_ooffset_t *offset, vm_size_t size,
 vm_object_t *object, int nprot)
@@ -667,8 +667,8 @@ prep_cdevsw(struct cdevsw *devsw, int flags)
devsw->d_write = dead_write;
devsw->d_ioctl = dead_ioctl;
devsw->d_poll = dead_poll;
-#ifndef __rtems__
devsw->d_mmap = dead_mmap;
+#ifndef __rtems__
devsw->d_mmap_single = dead_mmap_single;
devsw->d_strategy = dead_strategy;
devsw->d_dump = dead_dump;
@@ -702,8 +702,8 @@ prep_cdevsw(struct cdevsw *devsw, int flags)
FIXUP(d_write,  no_write,   giant_write);
FIXUP(d_ioctl,  no_ioctl,   giant_ioctl);
FIXUP(d_poll,   no_poll,giant_poll);
-#ifndef __rtems__
FIXUP(d_mmap,   no_mmap,giant_mmap);
+#ifndef __rtems__
FIXUP(d_strategy,   no_strategy,giant_strategy);
 #endif /* __rtems__ */
FIXUP(d_kqfilter,   no_kqfilter,giant_kqfilter);
diff --git a/freebsd/sys/sys/conf.h b/freebsd/sys/sys/conf.h
index 4ace162f..c0a66442 100644
--- a/freebsd/sys/sys/conf.h
+++ b/freebsd/sys/sys/conf.h
@@ -209,8 +209,8 @@ struct cdevsw {
d_write_t   *d_write;
d_ioctl_t   *d_ioctl;
d_poll_t*d_poll;
-#ifndef __rtems__
d_mmap_t*d_mmap;
+#ifndef __rtems__
d_strategy_t*d_strategy;
dumper_t*d_dump;
 #endif /* __rtems__ */
diff --git a/rtemsbsd/include/machine/vm.h b/rtemsbsd/include/machine/vm.h
index e69de29b..351b7472 100644
--- a/rtemsbsd/include/machine/vm.h
+++ b/rtemsbsd/include/machine/vm.h
@@ -0,0 +1,2 @@
+#define VM_MEMATTR_DEFAULT 0
+#define VM_MEMATTR_UNCACHEABLE 1
diff --git a/rtemsbsd/sys/fs/devfs/devfs_devs.c 
b/rtemsbsd/sys/fs/devfs/devfs_devs.c
index 7c697b0a..7b09e530 100644
--- a/rtemsbsd/sys/fs/devfs/devfs_devs.c
+++ b/rtemsbsd/sys/fs/devfs/devfs_devs.c
@@ -387,6 +387,43 @@ devfs_imfs_kqfilter(rtems_libio_t *iop, struct knote *kn)
return error;
 }
 
+static int
+devfs_imfs_mmap(rtems_libio_t *iop, void **addr, size_t len, int prot,
+off_t off)
+{
+   struct cdev *cdev = devfs_imfs_get_context_by_iop(iop);
+   struct file *fp = rtems_bsd_iop_to_fp(iop);
+   struct thread *td = rtems_bsd_get_curthread_or_null();
+   struct file *fpop;
+   struct cdevsw *dsw;
+   int error, ref;
+
+   if (td != 0) {
+   if (cdev == NULL) {
+   error = ENXIO;
+   goto err;
+   }
+   if (cdev->si_flags & SI_ALIAS) {
+   cdev = cdev->si_parent;
+   }
+   dsw = dev_refthread(cdev, &ref);
+   if (dsw == NULL) {
+   error = ENXIO;
+   goto err;
+   }
+   fpop = td->td_fpop;
+   curthread->td_fpop = fp;
+   error = dsw->d_mmap( cdev, off, (vm_paddr_t *) addr, prot, 
VM_MEMATTR_DEFAULT);
+   td->td_fpop = fpop;
+   dev_relthread(cdev, ref);
+   } else {
+   error = ENOMEM;
+   }
+
+err:
+   return rtems_bsd_error_to_status_and_errno(error);
+}
+
 static const rtems_filesystem_file_handlers_r devfs_imfs_handlers = {
.open_h = devfs_imfs_open,
.close_h = devfs_imfs_close,
@@ -403,6 +440,7 @@ static const rtems_filesystem_file_handlers_r 
devfs_imfs_handlers = {
.kqfilter_h = devfs_imfs_kqfilter,
.readv_h = devfs_imfs_readv,
.writev_h = devfs_imfs_writev,
+   .mmap_h = devfs_

Re: build of libbsd for powerpc fails with error: redefinition of 'eieio'

2019-07-17 Thread dufault 
> On Jul 17, 2019, at 01:48 , Sebastian Huber 
>  wrote:
> 
> Hello Peter,
> 
> On 16/07/2019 19:58, Peter Dufault wrote:
>> I have a build failure with the MVME5500 “beatnik” BSP. Therefore I tried to 
>> build the “psim” BSP and have the same failure: the FreeBSD PowerPC 
>> “cpufunc.h” and the RTEMS PowerPC “io.h” headers both define static inline 
>> "eioeio()" functions.
>> - RTEMS, libbsd, RSB and the build tools are up-to-date as of this AM.
>> - Building for arm xilinx_zynq_a9_qemu succeeds.
>> - I’ll work-around it but I believe I must have something locally screwed 
>> up, I can't find any recent changes associated with this.
> 
> libbsd doesn't work for all BSPs. For each new BSP you there are probably 
> some things to fix and adjust. I think the  should not include the low 
> level io.h header file. The only powerpc BSP that supported by libbsd is the 
> qoriq.
> 

First an easy question: what rtems-libbsd branch is best to work with: master 
or 5-freebsd-12?

As for properly fixing the include of libcpu/io.h:

This fix is clear:
- Any .c file below bsps/powerpc/shared/ that need it should include 
libcpu/io.h directly.  The header is in bsps/powerpc/include/ and both are 
below bsps/powerpc.

This fix is not clear:
- There are .c files in bsps/shared that reference e.g. “inport_byte()” (e.g. 
bsps/shared/dev/rtc/mc146818a_ioreg.c).  There are definitions of 
“inport_byte()” in cpukit/score headers for x86 architectures and in bsp.h 
headers for PowerPC (arm/gumstix, powerpc/beatnik, powerpc/motorola_powerpc).  
For PowerPC the definition is based on what’s in "libcpu/io.h”.  The PowerPC 
definition of “inport_byte()" should be moved from bsp.h into 
bsps/powerpc/shared/libcpu/io.h, but then I don’t know the right way to get 
that header included in the bsps/shared code, there isn’t something like 
“bsps/shared/include” where a definition could go (and count on proper 
configuration of the BSPs for everything to link properly).

As an aside, mc146818a_ioreg.c is brittle. It requires that “inport_byte" be a 
macro and if its definition is moved out of bsp.h the code will not compile 
properly:

#include 
#include 
#include 
#include 

/*
 *  At this point, not all CPUs or BSPs have defined in/out port routines.
 */
#if defined(__i386__) || defined(__PPC__)
#if defined(inport_byte)
...


> -- 
> 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.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

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

Re: Sources for fenv (ARM, PPC, x86, SPARC and RISC5)

2019-07-17 Thread Joel Sherrill 
On Wed, Jul 17, 2019, 1:12 PM Gedare Bloom  wrote:

> On Tue, Jul 16, 2019 at 6:57 AM Joel Sherrill  wrote:
> >
> > Let's give preference to FreeBSD sources. Notes below.
> >
> > On Wed, Jul 3, 2019 at 1:08 PM Vaibhav Gupta 
> wrote:
> >>
> >> Hello,
> >> I have found sources for fenv.
> >>
> >> 1.1) - ARM FreeBSD Source:
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.c
> >> .
> >> 1.2) - ARM NetBSD Source :
> >> - https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/arm/fenv.c
> >>
> -
> >
> >
> > For the ARM FreeBSD source, there are some ifdef's which appear to
> > be for architectural variations. Please check the gcc source for arm
> > (gcc-XXX/gcc/config/arm) to see if they are defined by gcc. If they
> > all are, then there is nothing to consider on how they get tripped.
> >
> > For example, __ARM_PCS_AAPCS64 is one. That looks like a multilib
> > define.
> >
> >>
> >> 2.1) - SPARC NetBSD Source :
> >> -
> https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/sparc/fenv.c
> >>
> 
> >
> >
> > This looks good and may work for sparc64 as well as sparc. Check if
> > sparc64-rtems5-gcc defines __arch64 as used byL
> >
> >
> https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h#L36
> >
> >>
> >> 3.1) - PPC FreeBSD Source:
> >> -
> https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.h
> >> -
> https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.c
> >> .
> >> 3.2) - PPC NetBSD Source:
> >> -
> https://github.com/NetBSD/src/blob/trunk/sys/arch/powerpc/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/powerpc/fenv.c
> >>
> ---
> >
> >
> > Sam advice on PPC. Looks OK, check ifdefs
> >
> >>
> >> 4.1) - x86 FreeBSD Source:
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/x86/fenv.h
> >> .
> >> 4.2) - x86 NetBSD Source:
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/x86_64/fenv.c
> >>
> --
> >
> >
> > This is not i386 (e.g. 32-bit), it is for the 64-bit target. Good to
> merge it into
> > newlib but we don't have a fully functional port to test this with.
> >
> >>
> >> 5.1) - RISC5 FreeBSD Source:
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.h
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.c
> >> .
> >> 5.2) - RISC5 NetBSD Source:
> >> -
> https://github.com/NetBSD/src/blob/trunk/sys/arch/riscv/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/riscv/fenv.c
> >> 
> >
> >
> > Same advice.
> >
> >>
> >> 
> >>
> >> It's impossible to depend on either NetBSD or FreeBSD.
> >
> >
> > Yep. Give preference to FreeBSD but if it isn't in FreeBSD, use NetBSD.
> >>
> >> .
> >> For some architectures, FreeBSD has code,
> >> for some, NetBSD has.
> >> .
> >> For x86, Free BSD has explicit header
> >> and NetBSD has .c file.
> >
> >
> > These are all architecture specific files so do not go in a main include
> > or source directory. They go in an architecture specific subdirectory.
> >
> > See
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libm/machine;h=9b2197b2660fd84c6b64ef265c1ec3b6e30c9074;hb=HEAD
> >
> > And notice that arm, aarch64, riscv, and i386 are all already there.
> Looks
> > like you can focus on the ones not there (PPC and SPARC). Ignore x86_64
> > for now. If there is a ticket for the port, just add a comment to that.
> I don't
> > think we are setup to test that port right now.
> >
> Since arm/riscv/i386 are there, you might be able to write an fenv
> test suite that can pass on one of those archs, and then use it with
> confidence to do TDD of other architectures.
>

This is a great idea!

>
> > Hope that all makes sense.
> >
> > --joel
> >
> >> .
> >> .
> >> .
> >> Vaibhav Gupta
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Sources for fenv (ARM, PPC, x86, SPARC and RISC5)

2019-07-17 Thread Vaibhav Gupta 
On Tue, Jul 16, 2019 at 6:26 PM Joel Sherrill  wrote:

> Let's give preference to FreeBSD sources. Notes below.
>
> On Wed, Jul 3, 2019 at 1:08 PM Vaibhav Gupta 
> wrote:
>
>> Hello,
>> I have found sources for fenv.
>>
>> 1.1) - ARM FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.c
>> .
>> 1.2) - ARM NetBSD Source :
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/arm/fenv.c
>>
>> -
>>
>
> For the ARM FreeBSD source, there are some ifdef's which appear to
> be for architectural variations. Please check the gcc source for arm
> (gcc-XXX/gcc/config/arm) to see if they are defined by gcc. If they
> all are, then there is nothing to consider on how they get tripped.
>
> For example, __ARM_PCS_AAPCS64 is one. That looks like a multilib
> define.
>
Okay!

>
>
>> 2.1) - SPARC NetBSD Source :
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/sparc/fenv.c
>>
>> 
>>
>
> This looks good and may work for sparc64 as well as sparc. Check if
> sparc64-rtems5-gcc defines __arch64 as used byL
>
> https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h#L36
>
>
>
>> 3.1) - PPC FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.c
>> .
>> 3.2) - PPC NetBSD Source:
>> -
>> https://github.com/NetBSD/src/blob/trunk/sys/arch/powerpc/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/powerpc/fenv.c
>>
>> ---
>>
>
> Sam advice on PPC. Looks OK, check ifdefs
>
>
>> 4.1) - x86 FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/x86/fenv.h
>> .
>> 4.2) - x86 NetBSD Source:
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/x86_64/fenv.c
>> --
>>
>
> This is not i386 (e.g. 32-bit), it is for the 64-bit target. Good to merge
> it into
> newlib but we don't have a fully functional port to test this with.
>
>
>> 5.1) - RISC5 FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.c
>> .
>> 5.2) - RISC5 NetBSD Source:
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/riscv/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/riscv/fenv.c
>> 
>>
>
> Same advice.
>
>
>> 
>>
>> It's impossible to depend on either NetBSD or FreeBSD.
>>
>
> Yep. Give preference to FreeBSD but if it isn't in FreeBSD, use NetBSD.
>
>> .
>> For some architectures, FreeBSD has code,
>> for some, NetBSD has.
>> .
>> For x86, Free BSD has explicit header
>> and NetBSD has .c file.
>>
>
> These are all architecture specific files so do not go in a main include
> or source directory. They go in an architecture specific subdirectory.
>
Yah, so here was one confusion.
I was going through fenv sources of SPARC in NetBSD
NetBSD has defined two headers for fenv
1- https://github.com/NetBSD/src/blob/trunk/include/fenv.h
---This contains function prototypes
.
2- https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
---This defines macros
.
And hence, I will have to use either FreeBSD or NetBSD depending in the
architecture, I am planning for this approach:
I will make a generic header file, `fenv.h`, which will contain function
prototypes
and other data which are common in all architectures.
Then I will place architecture specific data in their respective `fenv.c`
file
along with the function definitions.

>
> See
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libm/machine;h=9b2197b2660fd84c6b64ef265c1ec3b6e30c9074;hb=HEAD
>
> And notice that arm, aarch64, riscv, and i386 are all already there. Looks
> like you can focus on the ones not there (PPC and SPARC). Ignore x86_64
> for now. If there is a ticket for the port, just add a comment to that. I
> don't
> think we are setup to test that port right now.
>
> Hope that all makes sense.
>
Yes, thank you!

>
> --joel
>
> .
>> .
>> .
>> Vaibhav Gupta
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Sources for fenv (ARM, PPC, x86, SPARC and RISC5)

2019-07-17 Thread Vaibhav Gupta 
On Wed, Jul 17, 2019 at 11:42 PM Gedare Bloom  wrote:

> On Tue, Jul 16, 2019 at 6:57 AM Joel Sherrill  wrote:
> >
> > Let's give preference to FreeBSD sources. Notes below.
> >
> > On Wed, Jul 3, 2019 at 1:08 PM Vaibhav Gupta 
> wrote:
> >>
> >> Hello,
> >> I have found sources for fenv.
> >>
> >> 1.1) - ARM FreeBSD Source:
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.c
> >> .
> >> 1.2) - ARM NetBSD Source :
> >> - https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/arm/fenv.c
> >>
> -
> >
> >
> > For the ARM FreeBSD source, there are some ifdef's which appear to
> > be for architectural variations. Please check the gcc source for arm
> > (gcc-XXX/gcc/config/arm) to see if they are defined by gcc. If they
> > all are, then there is nothing to consider on how they get tripped.
> >
> > For example, __ARM_PCS_AAPCS64 is one. That looks like a multilib
> > define.
> >
> >>
> >> 2.1) - SPARC NetBSD Source :
> >> -
> https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/sparc/fenv.c
> >>
> 
> >
> >
> > This looks good and may work for sparc64 as well as sparc. Check if
> > sparc64-rtems5-gcc defines __arch64 as used byL
> >
> >
> https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h#L36
> >
> >>
> >> 3.1) - PPC FreeBSD Source:
> >> -
> https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.h
> >> -
> https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.c
> >> .
> >> 3.2) - PPC NetBSD Source:
> >> -
> https://github.com/NetBSD/src/blob/trunk/sys/arch/powerpc/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/powerpc/fenv.c
> >>
> ---
> >
> >
> > Sam advice on PPC. Looks OK, check ifdefs
> >
> >>
> >> 4.1) - x86 FreeBSD Source:
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/x86/fenv.h
> >> .
> >> 4.2) - x86 NetBSD Source:
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/x86_64/fenv.c
> >>
> --
> >
> >
> > This is not i386 (e.g. 32-bit), it is for the 64-bit target. Good to
> merge it into
> > newlib but we don't have a fully functional port to test this with.
> >
> >>
> >> 5.1) - RISC5 FreeBSD Source:
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.h
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.c
> >> .
> >> 5.2) - RISC5 NetBSD Source:
> >> -
> https://github.com/NetBSD/src/blob/trunk/sys/arch/riscv/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/riscv/fenv.c
> >> 
> >
> >
> > Same advice.
> >
> >>
> >> 
> >>
> >> It's impossible to depend on either NetBSD or FreeBSD.
> >
> >
> > Yep. Give preference to FreeBSD but if it isn't in FreeBSD, use NetBSD.
> >>
> >> .
> >> For some architectures, FreeBSD has code,
> >> for some, NetBSD has.
> >> .
> >> For x86, Free BSD has explicit header
> >> and NetBSD has .c file.
> >
> >
> > These are all architecture specific files so do not go in a main include
> > or source directory. They go in an architecture specific subdirectory.
> >
> > See
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libm/machine;h=9b2197b2660fd84c6b64ef265c1ec3b6e30c9074;hb=HEAD
> >
> > And notice that arm, aarch64, riscv, and i386 are all already there.
> Looks
> > like you can focus on the ones not there (PPC and SPARC). Ignore x86_64
> > for now. If there is a ticket for the port, just add a comment to that.
> I don't
> > think we are setup to test that port right now.
> >
> Since arm/riscv/i386 are there, you might be able to write an fenv
> test suite that can pass on one of those archs, and then use it with
> confidence to do TDD of other architectures.
>
Sure, I will move ahead with this.
Thank you!

>
> > Hope that all makes sense.
> >
> > --joel
> >
> >> .
> >> .
> >> .
> >> Vaibhav Gupta
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v4] Add mmap

2019-07-17 Thread Sebastian Huber 

On 17/07/2019 22:28, Vijay Kumar Banerjee wrote:

+static int
+testmmap(struct cdev *dev, vm_ooffset_t offset, vm_paddr_t *paddr,
+ int nprot, vm_memattr_t *memattr)
+{
+   test_state *state = dev->si_drv1;
+
+   assert(memattr == VM_MEMATTR_DEFAULT);
+   assert(paddr != NULL);
+   assert(nprot != PROT_NONE);


If you know the value in your test, then test for this value. You should 
avoid != tests whenever possible.


Here the nprot should be PROT_READ | PROT_WRITE?

Does the MAP_SHARED not end up here somehow?


+   assert(*state == TEST_KQFILTER);
+   *state = TEST_MMAP;
+
+   return 0;
+}
+


--
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: build of libbsd for powerpc fails with error: redefinition of 'eieio'

2019-07-17 Thread Sebastian Huber 

On 17/07/2019 23:42, dufa...@hda.com wrote:

On Jul 17, 2019, at 01:48 , Sebastian Huber 
 wrote:

Hello Peter,

On 16/07/2019 19:58, Peter Dufault wrote:

I have a build failure with the MVME5500 “beatnik” BSP. Therefore I tried to build the 
“psim” BSP and have the same failure: the FreeBSD PowerPC “cpufunc.h” and the RTEMS 
PowerPC “io.h” headers both define static inline "eioeio()" functions.
- RTEMS, libbsd, RSB and the build tools are up-to-date as of this AM.
- Building for arm xilinx_zynq_a9_qemu succeeds.
- I’ll work-around it but I believe I must have something locally screwed up, I 
can't find any recent changes associated with this.


libbsd doesn't work for all BSPs. For each new BSP you there are probably some things 
to fix and adjust. I think the  should not include the low level io.h 
header file. The only powerpc BSP that supported by libbsd is the qoriq.



First an easy question: what rtems-libbsd branch is best to work with: master 
or 5-freebsd-12?


For production systems I would use 5-freebsd-12.  I regularly 
synchronize it with the FreeBSD stable/12 branch.




As for properly fixing the include of libcpu/io.h:

This fix is clear:
- Any .c file below bsps/powerpc/shared/ that need it should include 
libcpu/io.h directly.  The header is in bsps/powerpc/include/ and both are 
below bsps/powerpc.


Yes.



This fix is not clear:
- There are .c files in bsps/shared that reference e.g. “inport_byte()” (e.g. 
bsps/shared/dev/rtc/mc146818a_ioreg.c).  There are definitions of “inport_byte()” in 
cpukit/score headers for x86 architectures and in bsp.h headers for PowerPC (arm/gumstix, 
powerpc/beatnik, powerpc/motorola_powerpc).  For PowerPC the definition is based on 
what’s in "libcpu/io.h”.  The PowerPC definition of “inport_byte()" should be 
moved from bsp.h into bsps/powerpc/shared/libcpu/io.h, but then I don’t know the right 
way to get that header included in the bsps/shared code, there isn’t something like 
“bsps/shared/include” where a definition could go (and count on proper configuration of 
the BSPs for everything to link properly).


I would move the

#define outport_byte(port,value) outb(value,port)
#define outport_word(port,value) outw(value,port)
#define outport_long(port,value) outl(value,port)

#define inport_byte(port,value) (value = inb(port))
#define inport_word(port,value) (value = inw(port))
#define inport_long(port,value) (value = inl(port))

from the PowerPC  to .



As an aside, mc146818a_ioreg.c is brittle. It requires that “inport_byte" be a 
macro and if its definition is moved out of bsp.h the code will not compile properly:

#include 
#include 
#include 
#include 

/*
  *  At this point, not all CPUs or BSPs have defined in/out port routines.
  */
#if defined(__i386__) || defined(__PPC__)
#if defined(inport_byte)
...


Use

#ifdef __PPC__
#include 
#endif

--
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

GSoC Project | Basic Support for Trace Compass

2019-07-17 Thread Ravindra Kumar Meena 
Hi,

I am facing difficulty in adding event.header in client-side.

struct event_header_compact {
enum : uint5_t { compact = 0 ... 30, extended = 31 } id;
variant  {
struct {
uint27_clock_monotonic_t timestamp;
} compact;
struct {
uint32_t id;
uint64_clock_monotonic_t timestamp;
} extended;
} v;
} align(8);

This is what I have tried.

https://github.com/rmeena840/rtems-tools/commit/b2ffc3d5b5ffd97075f1ed9028bcb8098e241e2b

Have a look. Please don't build it it's not working yet.

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project | Basic Support for Trace Compass

2019-07-17 Thread Sebastian Huber 

On 18/07/2019 07:38, Ravindra Kumar Meena wrote:

Hi,

I am facing difficulty in adding event.header in client-side.

struct event_header_compact {
enum : uint5_t { compact = 0 ... 30, extended = 31 } id;
variant  {
struct {
uint27_clock_monotonic_t timestamp;
} compact;
struct {
uint32_t id;
uint64_clock_monotonic_t timestamp;
} extended;
} v;
} align(8);

This is what I have tried.

https://github.com/rmeena840/rtems-tools/commit/b2ffc3d5b5ffd97075f1ed9028bcb8098e241e2b

Have a look. Please don't build it it's not working yet.


I would use two structures for this in C, one for the compact header and 
one for the large header. I would not use bit fields in C.


You have to figure out how the 27-bit timestamp works. It must relative 
to some reference point.


How is the id used? We are interested in the sched_switch events.

--
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