date:20200316


On 16/03/2020 00:57, Amar Takhar wrote:


On 2020-03-16 09:20 +1100, Chris Johns wrote:

Is pytest installed by default?

No.  It's a separate package the Python has 'unittest' which is shipped by
default.  For our usage pyttest is more flexible and will create concise code
that is easy to contribute to.  The biggest reason is that it's more suited to
our use.


From the website pytest requires Python 3.5+ and PyPy 3. This is not a 
problem for me in general. We still would like to be compatible to 
Python 2.7, how can we run the tests in such an environment with pytest?


What is the relationship to the standard Python unittest module? Do you 
want to write the tests with unittest and run them with pytest?


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

Re: [PATCH 1/2] Start converting tests to pytest.


On 16/03/2020 00:58, Amar Takhar wrote:


On 2020-03-14 11:12 +1100, Chris Johns wrote:

I would like to hear what Sebastian is considering for the ESA work. I think we
should follow what will be done there and ends up in the engineering manual.

If this is in regard to pytests that are being done for ESA work I agree I
would like to see what is being done there.


I work currently on a draft for the Python development guidelines for 
the engineering manual. I hope to have something ready for review in the 
next days.


Documenting the tests with with pydoc strings in general would be 
overkill from my point of view.


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

[PATCH 01/12] record: Fix format

Update #3904.
---
 trace/record/record-main-lttng.cc | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/trace/record/record-main-lttng.cc 
b/trace/record/record-main-lttng.cc
index c84f40b..a28de8e 100644
--- a/trace/record/record-main-lttng.cc
+++ b/trace/record/record-main-lttng.cc
@@ -323,11 +323,12 @@ LTTNGClient::AddressToLineMap::iterator 
LTTNGClient::ResolveAddress(
 const ClientItem& item) {
 #ifdef HAVE_LLVM_DEBUGINFO_SYMBOLIZE_SYMBOLIZE_H
   if (resolve_address_) {
-auto res_or_err = symbolizer_.symbolizeCode(elf_file_,
+auto res_or_err = symbolizer_.symbolizeCode(
+elf_file_,
 #if LLVM_VERSION_MAJOR >= 9
-  {item.data, llvm::object::SectionedAddress::UndefSection});
+{item.data, llvm::object::SectionedAddress::UndefSection});
 #else
-  item.data);
+item.data);
 #endif
 
 if (res_or_err) {
-- 
2.16.4

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

[PATCH 06/12] record: Add option to print config default values

Update #3904.
---
 trace/record/record-main-lttng.cc | 35 ++-
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/trace/record/record-main-lttng.cc 
b/trace/record/record-main-lttng.cc
index 891281e..15536f4 100644
--- a/trace/record/record-main-lttng.cc
+++ b/trace/record/record-main-lttng.cc
@@ -759,9 +759,10 @@ static void SignalHandler(int s) {
 }
 
 static const struct option kLongOpts[] = {
-{"elf", 1, NULL, 'e'},   {"help", 0, NULL, 'h'}, {"host", 1, NULL, 'H'},
-{"limit", 1, NULL, 'l'}, {"port", 1, NULL, 'p'}, {"config", 1, NULL, 'c'},
-{NULL, 0, NULL, 0}};
+{"elf", 1, NULL, 'e'},  {"help", 0, NULL, 'h'},
+{"host", 1, NULL, 'H'}, {"limit", 1, NULL, 'l'},
+{"port", 1, NULL, 'p'}, {"config", 1, NULL, 'c'},
+{"defaults", 0, NULL, 'd'}, {NULL, 0, NULL, 0}};
 
 static void Usage(char** argv) {
   std::cout << argv[0] << " [OPTION]... [INPUT-FILE]" << std::endl
@@ -781,9 +782,22 @@ static void Usage(char** argv) {
 << std::endl
 << "  -c, --config=CONFIGan INI-style configuration file"
 << std::endl
+<< "  -d, --defaults print default values for "
+   "configuration file"
+<< std::endl
 << "  INPUT-FILE the input file" << std::endl;
 }
 
+static void PrintDefaults() {
+  std::cout << "[EventNames]" << std::endl;
+
+  for (int i = 0; i <= RTEMS_RECORD_LAST; ++i) {
+std::cout << i << " = "
+  << rtems_record_event_text(static_cast(i))
+  << std::endl;
+  }
+}
+
 int main(int argc, char** argv) {
   const char* host = "127.0.0.1";
   uint16_t port = 1234;
@@ -793,27 +807,30 @@ int main(int argc, char** argv) {
   int opt;
   int longindex;
 
-  while ((opt = getopt_long(argc, argv, "e:hH:l:p:c:", &kLongOpts[0],
+  while ((opt = getopt_long(argc, argv, "hH:p:l:be:c:d", &kLongOpts[0],
 &longindex)) != -1) {
 switch (opt) {
-  case 'e':
-elf_file = optarg;
-break;
   case 'h':
 Usage(argv);
 return 0;
   case 'H':
 host = optarg;
 break;
+  case 'p':
+port = (uint16_t)strtoul(optarg, NULL, 0);
+break;
   case 'l':
 client.set_limit(strtoull(optarg, NULL, 0));
 break;
-  case 'p':
-port = (uint16_t)strtoul(optarg, NULL, 0);
+  case 'e':
+elf_file = optarg;
 break;
   case 'c':
 config_file = optarg;
 break;
+  case 'd':
+PrintDefaults();
+return 0;
   default:
 return 1;
 }
-- 
2.16.4

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

[PATCH 05/12] record: Add support for user defined event names

---
 trace/record/client.h  |  29 
 trace/record/record-client-base.cc |  40 ++
 trace/record/record-main-lttng.cc  | 145 -
 3 files changed, 164 insertions(+), 50 deletions(-)

diff --git a/trace/record/client.h b/trace/record/client.h
index fc240ca..2fe8d51 100644
--- a/trace/record/client.h
+++ b/trace/record/client.h
@@ -37,8 +37,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 class ErrnoException : public std::runtime_error {
  public:
@@ -69,6 +71,33 @@ class FileDescriptor {
   ssize_t (*reader_)(int fd, void* buf, size_t n) = nullptr;
 };
 
+class ConfigFile {
+ public:
+  static const std::string kNoError;
+
+  ConfigFile() = default;
+
+  ConfigFile(const ConfigFile&) = delete;
+
+  ConfigFile& operator=(const ConfigFile&) = delete;
+
+  typedef std::string (*Parser)(void* arg, const char* name, const char* 
value);
+
+  void AddParser(const char* section, Parser parser, void* arg);
+
+  void Parse(const char* file);
+
+ private:
+  std::map > parser_;
+
+  std::string error_;
+
+  static int INIHandler(void* user,
+const char* section,
+const char* name,
+const char* value);
+};
+
 class Client {
  public:
   Client() = default;
diff --git a/trace/record/record-client-base.cc 
b/trace/record/record-client-base.cc
index 197b654..8c467d4 100644
--- a/trace/record/record-client-base.cc
+++ b/trace/record/record-client-base.cc
@@ -48,6 +48,8 @@
 #include 
 #include 
 
+#include 
+
 static ssize_t ReadFile(int fd, void* buf, size_t n) {
   return ::read(fd, buf, n);
 }
@@ -104,6 +106,44 @@ void FileDescriptor::Destroy() {
   }
 }
 
+const std::string ConfigFile::kNoError;
+
+void ConfigFile::AddParser(const char* section, Parser parser, void* arg) {
+  parser_[section] = std::make_pair(parser, arg);
+}
+
+void ConfigFile::Parse(const char* file) {
+  int status = ini_parse(file, INIHandler, this);
+  if (status < 0) {
+throw ErrnoException(std::string("cannot parse configuration file '") +
+ file + "'");
+  } else if (status > 0) {
+throw std::runtime_error(
+std::string("invalid line ") + std::to_string(status) +
+" in configuration file '" + file + "': " + error_);
+  }
+}
+
+int ConfigFile::INIHandler(void* user,
+   const char* section,
+   const char* name,
+   const char* value) {
+  ConfigFile* self = static_cast(user);
+  auto it = self->parser_.find(section);
+  if (it != self->parser_.end()) {
+std::string error = (*it->second.first)(it->second.second, name, value);
+if (error == kNoError) {
+  return 1;
+}
+
+self->error_ = error;
+  } else {
+self->error_ = std::string("unknown section: ") + section;
+  }
+
+  return 0;
+}
+
 void Client::Run() {
   uint64_t todo = UINT64_MAX;
 
diff --git a/trace/record/record-main-lttng.cc 
b/trace/record/record-main-lttng.cc
index 267c1f8..891281e 100644
--- a/trace/record/record-main-lttng.cc
+++ b/trace/record/record-main-lttng.cc
@@ -35,6 +35,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -152,26 +153,11 @@ struct PerCPUContext {
 
 class LTTNGClient : public Client {
  public:
-  LTTNGClient() {
-Initialize(LTTNGClient::HandlerCaller);
-
-std::memset(&pkt_ctx_, 0, sizeof(pkt_ctx_));
-std::memcpy(pkt_ctx_.header.uuid, kUUID, sizeof(pkt_ctx_.header.uuid));
-pkt_ctx_.header.ctf_magic = CTF_MAGIC;
-
-for (size_t i = 0; i < RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT; ++i) {
-  PerCPUContext& pcpu = per_cpu_[i];
-  pcpu.sched_switch.header.id = COMPACT_HEADER_ID;
-  pcpu.sched_switch.header.event_id = 1024;
-  pcpu.irq_handler_entry.header.id = COMPACT_HEADER_ID;
-  pcpu.irq_handler_entry.header.event_id = 1025;
-  pcpu.irq_handler_entry.name[0] = '\0';
-  pcpu.irq_handler_exit.header.id = COMPACT_HEADER_ID;
-  pcpu.irq_handler_exit.header.event_id = 1026;
-  pcpu.irq_handler_exit.ret = 1;
-  pcpu.record_item.header.id = COMPACT_HEADER_ID;
-}
-  }
+  LTTNGClient();
+
+  void ParseConfigFile(const char* config_file);
+
+  void GenerateMetadata();
 
   void OpenExecutable(const char* elf_file);
 
@@ -207,6 +193,8 @@ class LTTNGClient : public Client {
 
   AddressToLineMap address_to_line_;
 
+  std::vector event_to_name_;
+
   static rtems_record_client_status HandlerCaller(uint64_t bt,
   uint32_t cpu,
   rtems_record_event event,
@@ -237,6 +225,10 @@ class LTTNGClient : public Client {
 
   void PrintItem(const ClientItem& item);
 
+  static std::string EventNameParser(void* arg,
+ const char* name,
+ const char* value);
+
   void OpenStreamFiles(uint64_t data);
 
   void CloseStreamFiles()

[PATCH 07/12] record: Add filter base class

Update #3904.
---
 trace/record/client.h  | 21 -
 trace/record/record-client-base.cc | 33 +++--
 2 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/trace/record/client.h b/trace/record/client.h
index 2fe8d51..636fb0b 100644
--- a/trace/record/client.h
+++ b/trace/record/client.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
 /*
- * Copyright (C) 2018, 2019 embedded brains GmbH 
(http://www.embedded-brains.de)
+ * Copyright (C) 2018, 2020 embedded brains GmbH 
(http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -98,6 +99,19 @@ class ConfigFile {
 const char* value);
 };
 
+class Filter {
+ public:
+  Filter() = default;
+
+  Filter(const Filter&) = default;
+
+  Filter& operator=(const Filter&) = default;
+
+  virtual ~Filter() = default;
+
+  virtual bool Run(void** buf, size_t* n) = 0;
+};
+
 class Client {
  public:
   Client() = default;
@@ -114,6 +128,8 @@ class Client {
 
   void RequestStop() { stop_ = 1; }
 
+  void AddFilter(Filter* filter) { filters_.push_back(filter); }
+
   void Destroy();
 
   void set_limit(uint64_t limit) { limit_ = limit; }
@@ -127,9 +143,12 @@ class Client {
 
  private:
   rtems_record_client_context base_;
+  std::list filters_;
   FileDescriptor input_;
   sig_atomic_t stop_ = 0;
   uint64_t limit_ = 0;
+
+  void Flush();
 };
 
 #endif  // RTEMS_TOOLS_TRACE_RECORD_CLIENT_H_
diff --git a/trace/record/record-client-base.cc 
b/trace/record/record-client-base.cc
index 8c467d4..f022db4 100644
--- a/trace/record/record-client-base.cc
+++ b/trace/record/record-client-base.cc
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
 /*
- * Copyright (C) 2018, 2019 embedded brains GmbH 
(http://www.embedded-brains.de)
+ * Copyright (C) 2018, 2020 embedded brains GmbH 
(http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -144,6 +144,24 @@ int ConfigFile::INIHandler(void* user,
   return 0;
 }
 
+void Client::Flush() {
+  while (true) {
+void* p = nullptr;
+size_t n = 0;
+for (auto filter : filters_) {
+  if (!filter->Run(&p, &n)) {
+break;
+  }
+}
+
+if (n > 0) {
+  rtems_record_client_run(&base_, p, n);
+} else {
+  break;
+}
+  }
+}
+
 void Client::Run() {
   uint64_t todo = UINT64_MAX;
 
@@ -159,9 +177,20 @@ void Client::Run() {
   break;
 }
 
-rtems_record_client_run(&base_, buf, static_cast(n));
+void* p = &buf[0];
+size_t k = static_cast(n);
+for (auto filter : filters_) {
+  if (!filter->Run(&p, &k)) {
+std::cerr << "error: input filter failure" << std::endl;
+return;
+  }
+}
+
+rtems_record_client_run(&base_, p, k);
 todo -= static_cast(n);
   }
+
+  Flush();
 }
 
 void Client::Destroy() {
-- 
2.16.4

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

[PATCH 09/12] record: Add support for base64 encoded input

Update #3904.
---
 trace/record/record-main-lttng.cc | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/trace/record/record-main-lttng.cc 
b/trace/record/record-main-lttng.cc
index 15536f4..7d974af 100644
--- a/trace/record/record-main-lttng.cc
+++ b/trace/record/record-main-lttng.cc
@@ -2,7 +2,7 @@
 
 /*
  * Copyright (c) 2019 Ravindra Kumar Meena 
- * Copyright (C) 2018, 2019 embedded brains GmbH 
(http://www.embedded-brains.de)
+ * Copyright (C) 2018, 2020 embedded brains GmbH 
(http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -759,10 +759,11 @@ static void SignalHandler(int s) {
 }
 
 static const struct option kLongOpts[] = {
-{"elf", 1, NULL, 'e'},  {"help", 0, NULL, 'h'},
-{"host", 1, NULL, 'H'}, {"limit", 1, NULL, 'l'},
-{"port", 1, NULL, 'p'}, {"config", 1, NULL, 'c'},
-{"defaults", 0, NULL, 'd'}, {NULL, 0, NULL, 0}};
+{"elf", 1, NULL, 'e'},{"help", 0, NULL, 'h'},
+{"host", 1, NULL, 'H'},   {"port", 1, NULL, 'p'},
+{"limit", 1, NULL, 'l'},  {"base64", 0, NULL, 'b'},
+{"config", 1, NULL, 'c'}, {"defaults", 0, NULL, 'd'},
+{NULL, 0, NULL, 0}};
 
 static void Usage(char** argv) {
   std::cout << argv[0] << " [OPTION]... [INPUT-FILE]" << std::endl
@@ -778,6 +779,8 @@ static void Usage(char** argv) {
 << std::endl
 << "  -l, --limit=LIMIT  limit in bytes to process"
 << std::endl
+<< "  -b, --base64   input is base64 encoded"
+<< std::endl
 << "  -e, --elf=ELF  the ELF executable file"
 << std::endl
 << "  -c, --config=CONFIGan INI-style configuration file"
@@ -801,6 +804,7 @@ static void PrintDefaults() {
 int main(int argc, char** argv) {
   const char* host = "127.0.0.1";
   uint16_t port = 1234;
+  bool is_base64_encoded = false;
   const char* elf_file = nullptr;
   const char* input_file = nullptr;
   const char* config_file = nullptr;
@@ -822,6 +826,9 @@ int main(int argc, char** argv) {
   case 'l':
 client.set_limit(strtoull(optarg, NULL, 0));
 break;
+  case 'b':
+is_base64_encoded = true;
+break;
   case 'e':
 elf_file = optarg;
 break;
@@ -851,6 +858,10 @@ int main(int argc, char** argv) {
   }
 
   try {
+if (is_base64_encoded) {
+  client.AddFilter(new Base64Filter());
+}
+
 client.ParseConfigFile(config_file);
 client.GenerateMetadata();
 
-- 
2.16.4

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

[PATCH 04/12] record: Add INI file parser

Import from:

https://github.com/benhoyt/inih

commit 351217124ddb3e3fe2b982248a04c672350bb0af
Author: Stephan Lachnit 
Date:   Sun Mar 1 07:31:28 2020 +0100

r48 release (#100)

* Bump copyright to 2020
* Remove makefile for static library
* meson: version 48

Signed-off-by: Stephan Lachnit 

Update #3904.
---
 trace/record/inih/LICENSE.txt |  27 
 trace/record/inih/ini.c   | 284 ++
 trace/record/inih/ini.h   | 148 ++
 trace/wscript |   5 +-
 4 files changed, 462 insertions(+), 2 deletions(-)
 create mode 100644 trace/record/inih/LICENSE.txt
 create mode 100644 trace/record/inih/ini.c
 create mode 100644 trace/record/inih/ini.h

diff --git a/trace/record/inih/LICENSE.txt b/trace/record/inih/LICENSE.txt
new file mode 100644
index 000..cb7ee2d
--- /dev/null
+++ b/trace/record/inih/LICENSE.txt
@@ -0,0 +1,27 @@
+
+The "inih" library is distributed under the New BSD license:
+
+Copyright (c) 2009, Ben Hoyt
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+* Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+* 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.
+* Neither the name of Ben Hoyt nor the names of its contributors
+  may be used to endorse or promote products derived from this software
+  without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY BEN HOYT ''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 BEN HOYT 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.
diff --git a/trace/record/inih/ini.c b/trace/record/inih/ini.c
new file mode 100644
index 000..d19d613
--- /dev/null
+++ b/trace/record/inih/ini.c
@@ -0,0 +1,284 @@
+/* inih -- simple .INI file parser
+
+SPDX-License-Identifier: BSD-3-Clause
+
+Copyright (C) 2009-2020, Ben Hoyt
+
+inih is released under the New BSD license (see LICENSE.txt). Go to the project
+home page for more info:
+
+https://github.com/benhoyt/inih
+
+*/
+
+#if defined(_MSC_VER) && !defined(_CRT_SECURE_NO_WARNINGS)
+#define _CRT_SECURE_NO_WARNINGS
+#endif
+
+#include 
+#include 
+#include 
+
+#include "ini.h"
+
+#if !INI_USE_STACK
+#include 
+#endif
+
+#define MAX_SECTION 50
+#define MAX_NAME 50
+
+/* Used by ini_parse_string() to keep track of string parsing state. */
+typedef struct {
+const char* ptr;
+size_t num_left;
+} ini_parse_string_ctx;
+
+/* Strip whitespace chars off end of given string, in place. Return s. */
+static char* rstrip(char* s)
+{
+char* p = s + strlen(s);
+while (p > s && isspace((unsigned char)(*--p)))
+*p = '\0';
+return s;
+}
+
+/* Return pointer to first non-whitespace char in given string. */
+static char* lskip(const char* s)
+{
+while (*s && isspace((unsigned char)(*s)))
+s++;
+return (char*)s;
+}
+
+/* Return pointer to first char (of chars) or inline comment in given string,
+   or pointer to null at end of string if neither found. Inline comment must
+   be prefixed by a whitespace character to register as a comment. */
+static char* find_chars_or_comment(const char* s, const char* chars)
+{
+#if INI_ALLOW_INLINE_COMMENTS
+int was_space = 0;
+while (*s && (!chars || !strchr(chars, *s)) &&
+   !(was_space && strchr(INI_INLINE_COMMENT_PREFIXES, *s))) {
+was_space = isspace((unsigned char)(*s));
+s++;
+}
+#else
+while (*s && (!chars || !strchr(chars, *s))) {
+s++;
+}
+#endif
+return (char*)s;
+}
+
+/* Version of strncpy that ensures dest (size bytes) is null-terminated. */
+static char* strncpy0(char* dest, const char* src, size_t size)
+{
+strncpy(dest, src, size - 1);
+dest[size - 1] = '\0';
+return dest;
+}
+
+/* See documentation in header file. */
+int ini_parse_stream(ini_reader reader, void* stream, ini_handler handler,
+ void* user)
+{
+/* Uses a fair bit of stack (use heap instead if you need to) */
+#if INI_USE_STACK
+char line[INI_MAX_LINE];
+int max_line = INI_MAX_LINE;
+#else
+char* line;
+size_t max_line = INI_INITIA

[PATCH 10/12] record: Add zlib filter class

Update #3904.
---
 trace/record/client.h  | 24 
 trace/record/record-filter-zlib.cc | 77 ++
 trace/wscript  |  5 +++
 3 files changed, 106 insertions(+)
 create mode 100644 trace/record/record-filter-zlib.cc

diff --git a/trace/record/client.h b/trace/record/client.h
index b4a0c26..62ffdb5 100644
--- a/trace/record/client.h
+++ b/trace/record/client.h
@@ -42,6 +42,11 @@
 #include 
 #include 
 #include 
+#include 
+
+#ifdef HAVE_ZLIB_H
+#include 
+#endif
 
 class ErrnoException : public std::runtime_error {
  public:
@@ -132,6 +137,25 @@ class Base64Filter : public Filter {
   bool DecodeChar(int c, char **target);
 };
 
+#ifdef HAVE_ZLIB_H
+class ZlibFilter : public Filter {
+ public:
+  ZlibFilter();
+
+  ZlibFilter(const ZlibFilter&) = default;
+
+  ZlibFilter& operator=(const ZlibFilter&) = default;
+
+  virtual ~ZlibFilter();
+
+  virtual bool Run(void** buf, size_t* n);
+
+ private:
+  z_stream stream_;
+  std::vector buffer_;
+};
+#endif
+
 class Client {
  public:
   Client() = default;
diff --git a/trace/record/record-filter-zlib.cc 
b/trace/record/record-filter-zlib.cc
new file mode 100644
index 000..87b2cfe
--- /dev/null
+++ b/trace/record/record-filter-zlib.cc
@@ -0,0 +1,77 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * 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
+
+#ifdef HAVE_ZLIB_H
+
+#include "client.h"
+
+ZlibFilter::ZlibFilter() : buffer_(65536)
+{
+  inflateInit(&stream_);
+}
+
+ZlibFilter::~ZlibFilter()
+{
+  inflateEnd(&stream_);
+}
+
+bool ZlibFilter::Run(void** buf, size_t* n) {
+  stream_.next_in = static_cast(*buf);
+  stream_.avail_in = *n;
+  stream_.next_out = &buffer_[0];
+  size_t avail_out = 0;
+  size_t buffer_size = buffer_.size();
+  size_t chunk_size = buffer_size;
+  stream_.avail_out = buffer_size;
+
+  while (true) {
+int err = inflate(&stream_, Z_NO_FLUSH);
+if (err != Z_OK && err != Z_STREAM_END) {
+  return false;
+}
+
+if (stream_.avail_in > 0) {
+  chunk_size = buffer_size;
+  buffer_size *= 2;
+  buffer_.resize(buffer_size);
+  stream_.next_out = reinterpret_cast(&buffer_[chunk_size]);
+  stream_.avail_out = chunk_size;
+  avail_out += chunk_size;
+  continue;
+}
+
+*buf = &buffer_[0];
+*n = avail_out + chunk_size - stream_.avail_out;
+return true;
+  }
+}
+
+#endif  // HAVE_ZLIB_H
diff --git a/trace/wscript b/trace/wscript
index 7e35f74..656f92b 100644
--- a/trace/wscript
+++ b/trace/wscript
@@ -42,6 +42,8 @@ def configure(conf):
 pass
 if conf.check_cxx(lib = 'LLVM', mandatory=False):
 conf.check(header_name='llvm/DebugInfo/Symbolize/Symbolize.h', 
features='cxx', mandatory=False)
+if conf.check(header_name='zlib.h', features='cxx', mandatory=False):
+conf.check_cxx(lib = 'z')
 conf.check_cxx(lib = 'ws2_32', mandatory=False)
 conf.write_config_header('config.h')
 
@@ -65,6 +67,8 @@ def build(bld):
 conf['lib'].extend(bld.env.LIB_WS2_32)
 if bld.env.LIB_LLVM:
 conf['lib'].extend(bld.env.LIB_LLVM)
+if bld.env.LIB_Z:
+conf['lib'].extend(bld.env.LIB_Z)
 
 #
 # The list of defines
@@ -81,6 +85,7 @@ def build(bld):
   'record/record-text.c',
   'record/record-client-base.cc',
   'record/record-filter-base64.cc',
+  'record/record-filter-zlib.cc',
   'record/record-main-lttng.cc',
   'record/inih/ini.c'],

[PATCH 00/12] record: Add support for base64 and zlib compressed input

Sebastian Huber (12):
  record: Fix format
  record: Guard config.h include
  record: Format file header
  record: Add INI file parser
  record: Add support for user defined event names
  record: Add option to print config default values
  record: Add filter base class
  record: Add base64 filter class
  record: Add support for base64 encoded input
  record: Add zlib filter class
  record: Add support for zlib compressed input
  record: Increase input buffer and alignment

 trace/record/client.h|  98 +++-
 trace/record/inih/LICENSE.txt|  27 
 trace/record/inih/ini.c  | 284 +++
 trace/record/inih/ini.h  | 148 ++
 trace/record/record-client-base.cc   |  83 +-
 trace/record/record-filter-base64.cc | 103 +
 trace/record/record-filter-zlib.cc   |  77 ++
 trace/record/record-main-lttng.cc| 210 ++
 trace/wscript|  14 +-
 9 files changed, 972 insertions(+), 72 deletions(-)
 create mode 100644 trace/record/inih/LICENSE.txt
 create mode 100644 trace/record/inih/ini.c
 create mode 100644 trace/record/inih/ini.h
 create mode 100644 trace/record/record-filter-base64.cc
 create mode 100644 trace/record/record-filter-zlib.cc

-- 
2.16.4

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

[PATCH 03/12] record: Format file header

Update #3904.
---
 trace/record/client.h  | 6 +++---
 trace/record/record-client-base.cc | 6 +++---
 trace/record/record-main-lttng.cc  | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/trace/record/client.h b/trace/record/client.h
index a865a18..fc240ca 100644
--- a/trace/record/client.h
+++ b/trace/record/client.h
@@ -1,7 +1,7 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
- * SPDX-License-Identifier: BSD-2-Clause
- *
- * Copyright (C) 2018, 2019 embedded brains GmbH
+ * Copyright (C) 2018, 2019 embedded brains GmbH 
(http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
diff --git a/trace/record/record-client-base.cc 
b/trace/record/record-client-base.cc
index 04c0ae8..197b654 100644
--- a/trace/record/record-client-base.cc
+++ b/trace/record/record-client-base.cc
@@ -1,7 +1,7 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
- * SPDX-License-Identifier: BSD-2-Clause
- *
- * Copyright (C) 2018, 2019 embedded brains GmbH
+ * Copyright (C) 2018, 2019 embedded brains GmbH 
(http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
diff --git a/trace/record/record-main-lttng.cc 
b/trace/record/record-main-lttng.cc
index 2a4f509..267c1f8 100644
--- a/trace/record/record-main-lttng.cc
+++ b/trace/record/record-main-lttng.cc
@@ -1,8 +1,8 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
- * SPDX-License-Identifier: BSD-2-Clause
- *
  * Copyright (c) 2019 Ravindra Kumar Meena 
- * Copyright (C) 2018, 2019 embedded brains GmbH
+ * Copyright (C) 2018, 2019 embedded brains GmbH 
(http://www.embedded-brains.de)
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
-- 
2.16.4

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

[PATCH 11/12] record: Add support for zlib compressed input

Update #3904.
---
 trace/record/record-main-lttng.cc | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/trace/record/record-main-lttng.cc 
b/trace/record/record-main-lttng.cc
index 7d974af..7cfa48c 100644
--- a/trace/record/record-main-lttng.cc
+++ b/trace/record/record-main-lttng.cc
@@ -759,11 +759,11 @@ static void SignalHandler(int s) {
 }
 
 static const struct option kLongOpts[] = {
-{"elf", 1, NULL, 'e'},{"help", 0, NULL, 'h'},
-{"host", 1, NULL, 'H'},   {"port", 1, NULL, 'p'},
-{"limit", 1, NULL, 'l'},  {"base64", 0, NULL, 'b'},
-{"config", 1, NULL, 'c'}, {"defaults", 0, NULL, 'd'},
-{NULL, 0, NULL, 0}};
+{"elf", 1, NULL, 'e'},  {"help", 0, NULL, 'h'},
+{"host", 1, NULL, 'H'}, {"port", 1, NULL, 'p'},
+{"limit", 1, NULL, 'l'},{"base64", 0, NULL, 'b'},
+{"zlib", 0, NULL, 'z'}, {"config", 1, NULL, 'c'},
+{"defaults", 0, NULL, 'd'}, {NULL, 0, NULL, 0}};
 
 static void Usage(char** argv) {
   std::cout << argv[0] << " [OPTION]... [INPUT-FILE]" << std::endl
@@ -781,6 +781,8 @@ static void Usage(char** argv) {
 << std::endl
 << "  -b, --base64   input is base64 encoded"
 << std::endl
+<< "  -z, --zlib input is zlib compressed"
+<< std::endl
 << "  -e, --elf=ELF  the ELF executable file"
 << std::endl
 << "  -c, --config=CONFIGan INI-style configuration file"
@@ -805,13 +807,14 @@ int main(int argc, char** argv) {
   const char* host = "127.0.0.1";
   uint16_t port = 1234;
   bool is_base64_encoded = false;
+  bool is_zlib_compressed = false;
   const char* elf_file = nullptr;
   const char* input_file = nullptr;
   const char* config_file = nullptr;
   int opt;
   int longindex;
 
-  while ((opt = getopt_long(argc, argv, "hH:p:l:be:c:d", &kLongOpts[0],
+  while ((opt = getopt_long(argc, argv, "hH:p:l:bze:c:d", &kLongOpts[0],
 &longindex)) != -1) {
 switch (opt) {
   case 'h':
@@ -829,6 +832,9 @@ int main(int argc, char** argv) {
   case 'b':
 is_base64_encoded = true;
 break;
+  case 'z':
+is_zlib_compressed = true;
+break;
   case 'e':
 elf_file = optarg;
 break;
@@ -862,6 +868,12 @@ int main(int argc, char** argv) {
   client.AddFilter(new Base64Filter());
 }
 
+if (is_zlib_compressed) {
+#ifdef HAVE_ZLIB_H
+  client.AddFilter(new ZlibFilter());
+#endif
+}
+
 client.ParseConfigFile(config_file);
 client.GenerateMetadata();
 
-- 
2.16.4

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

[PATCH 08/12] record: Add base64 filter class

Update #3904.
---
 trace/record/client.h|  20 +++
 trace/record/record-filter-base64.cc | 103 +++
 trace/wscript|   1 +
 3 files changed, 124 insertions(+)
 create mode 100644 trace/record/record-filter-base64.cc

diff --git a/trace/record/client.h b/trace/record/client.h
index 636fb0b..b4a0c26 100644
--- a/trace/record/client.h
+++ b/trace/record/client.h
@@ -112,6 +112,26 @@ class Filter {
   virtual bool Run(void** buf, size_t* n) = 0;
 };
 
+class Base64Filter : public Filter {
+ public:
+  Base64Filter() = default;
+
+  Base64Filter(const Base64Filter&) = default;
+
+  Base64Filter& operator=(const Base64Filter&) = default;
+
+  virtual ~Base64Filter() = default;
+
+  virtual bool Run(void** buf, size_t* n);
+
+ private:
+  int digits_ = 0;
+  bool seen_end_ = false;
+  int val_[4];
+
+  bool DecodeChar(int c, char **target);
+};
+
 class Client {
  public:
   Client() = default;
diff --git a/trace/record/record-filter-base64.cc 
b/trace/record/record-filter-base64.cc
new file mode 100644
index 000..12f4bab
--- /dev/null
+++ b/trace/record/record-filter-base64.cc
@@ -0,0 +1,103 @@
+/* SPDX-License-Identifier: ISC */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc.
+ * ("ISC") Copyright (C) 1998-2001, 2003  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#if HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "client.h"
+
+#include 
+
+static const char base64[] =
+"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";
+
+bool Base64Filter::DecodeChar(int c, char **target) {
+  char* s;
+
+  if (seen_end_)
+return false;
+  if ((s = std::strchr(const_cast(base64), c)) == NULL)
+return false;
+  val_[digits_++] = s - base64;
+  if (digits_ == 4) {
+int n;
+unsigned char buf[3];
+if (val_[0] == 64 || val_[1] == 64)
+  return false;
+if (val_[2] == 64 && val_[3] != 64)
+  return false;
+/*
+ * Check that bits that should be zero are.
+ */
+if (val_[2] == 64 && (val_[1] & 0xf) != 0)
+  return false;
+/*
+ * We don't need to test for val_[2] != 64 as
+ * the bottom two bits of 64 are zero.
+ */
+if (val_[3] == 64 && (val_[2] & 0x3) != 0)
+  return false;
+n = (val_[2] == 64) ? 1 : (val_[3] == 64) ? 2 : 3;
+if (n != 3) {
+  seen_end_ = true;
+  if (val_[2] == 64)
+val_[2] = 0;
+  if (val_[3] == 64)
+val_[3] = 0;
+}
+buf[0] = (val_[0] << 2) | (val_[1] >> 4);
+buf[1] = (val_[1] << 4) | (val_[2] >> 2);
+buf[2] = (val_[2] << 6) | (val_[3]);
+char *out = *target;
+for (int i = 0; i < n; ++i) {
+  out[i] = buf[i];
+}
+*target = out + n;
+digits_ = 0;
+  }
+  return true;
+}
+
+bool Base64Filter::Run(void** buf, size_t* n) {
+  char* begin = static_cast(*buf);
+  const char* in = begin;
+  const char* end = in + *n;
+
+  if (begin == end) {
+return digits_ == 0;
+  }
+
+  char* target = begin;
+  while (in != end) {
+int c = *in;
+++in;
+if (c == ' ' || c == '\t' || c == '\n' || c == '\r') {
+  continue;
+}
+
+if (!DecodeChar(c, &target)) {
+  return false;
+};
+  }
+
+  *n = static_cast(target - begin);
+  return true;
+}
diff --git a/trace/wscript b/trace/wscript
index 3ded695..7e35f74 100644
--- a/trace/wscript
+++ b/trace/wscript
@@ -80,6 +80,7 @@ def build(bld):
 source = ['record/record-client.c',
   'record/record-text.c',
   'record/record-client-base.cc',
+  'record/record-filter-base64.cc',
   'record/record-main-lttng.cc',
   'record/inih/ini.c'],
 includes = conf['includes'],
-- 
2.16.4

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

[PATCH 12/12] record: Increase input buffer and alignment

Update #3904.
---
 trace/record/record-client-base.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/trace/record/record-client-base.cc 
b/trace/record/record-client-base.cc
index f022db4..fa75f53 100644
--- a/trace/record/record-client-base.cc
+++ b/trace/record/record-client-base.cc
@@ -170,7 +170,7 @@ void Client::Run() {
   }
 
   while (stop_ == 0 && todo > 0) {
-int buf[8192];
+long buf[8192];
 size_t m = std::min(static_cast(sizeof(buf)), todo);
 ssize_t n = input_.Read(buf, m);
 if (n <= 0) {
-- 
2.16.4

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

[RFC] RTEMS Waf Clang support

Hi Sebastian,

I have pushed a few commits to my repo to support building RTEMS with
Clang/LLVM for RISC-V. Here are the changes [1]. Since I'm still
learning about Waf and the build system, I'd appreciate your input.
Most importantly, I want to know what's the right way to set "target"
and "xlen" variables.

[1] 
https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...aa73f72b929856efdb41f9f8582263b5395a3276

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

Re: [RFC] RTEMS Waf Clang support


On 16/03/2020 12:39, Hesham Almatary wrote:


Hi Sebastian,

I have pushed a few commits to my repo to support building RTEMS with
Clang/LLVM for RISC-V. Here are the changes [1]. Since I'm still
learning about Waf and the build system, I'd appreciate your input.
Most importantly, I want to know what's the right way to set "target"
and "xlen" variables.

[1] 
https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...aa73f72b929856efdb41f9f8582263b5395a3276


You need a new option, e.g.

spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml

It should be enabled by clang and riscv:

enabled-by:
  and:
  - clang
  - riscv

The option must be evaluated before the tool settings:

order: -1000




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

Re: [RFC] RTEMS Waf Clang support

On Mon, 16 Mar 2020 at 11:53, Sebastian Huber
 wrote:
>
> On 16/03/2020 12:39, Hesham Almatary wrote:
>
> > Hi Sebastian,
> >
> > I have pushed a few commits to my repo to support building RTEMS with
> > Clang/LLVM for RISC-V. Here are the changes [1]. Since I'm still
> > learning about Waf and the build system, I'd appreciate your input.
> > Most importantly, I want to know what's the right way to set "target"
> > and "xlen" variables.
> >
> > [1] 
> > https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...aa73f72b929856efdb41f9f8582263b5395a3276
>
> You need a new option, e.g.
>
> spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
>
> It should be enabled by clang and riscv:
>
> enabled-by:
>and:
>- clang
>- riscv
>
> The option must be evaluated before the tool settings:
>
> order: -1000
>
Yes, I thought of that too. But I need to define XLEN to empty or
something for other architectures too since I use it in
RTEMS-BUILD-CPUKIT-OPTCLANG:

> - set-value: --target=${ARCH}${XLEN}-unknown-rtems${__RTEMS_MAJOR__}
> - substitute: null
> - env-append: ABI_FLAGS

How should each RISC-V BSP assign XLEN? I thought of a few ways:
1) to make each BSP yml file do it, or
2) to script it for RISC-V and extract it from the march value,
3) to assign it in a single file and, similar to how
RISC-V-BUILD-BSP-RISC-V-ABI currently works, assign it per variant.

>
>
>


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

Re: [RFC] RTEMS Waf Clang support


On 16/03/2020 13:09, Hesham Almatary wrote:


On Mon, 16 Mar 2020 at 11:53, Sebastian Huber
 wrote:

On 16/03/2020 12:39, Hesham Almatary wrote:


Hi Sebastian,

I have pushed a few commits to my repo to support building RTEMS with
Clang/LLVM for RISC-V. Here are the changes [1]. Since I'm still
learning about Waf and the build system, I'd appreciate your input.
Most importantly, I want to know what's the right way to set "target"
and "xlen" variables.

[1] 
https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...aa73f72b929856efdb41f9f8582263b5395a3276

You need a new option, e.g.

spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml

It should be enabled by clang and riscv:

enabled-by:
and:
- clang
- riscv

The option must be evaluated before the tool settings:

order: -1000


Yes, I thought of that too. But I need to define XLEN to empty or
something for other architectures too since I use it in
RTEMS-BUILD-CPUKIT-OPTCLANG:

Does it not default to the empty string if it is not defined?



- set-value: --target=${ARCH}${XLEN}-unknown-rtems${__RTEMS_MAJOR__}
- substitute: null
- env-append: ABI_FLAGS

How should each RISC-V BSP assign XLEN? I thought of a few ways:
1) to make each BSP yml file do it, or
2) to script it for RISC-V and extract it from the march value,
3) to assign it in a single file and, similar to how
RISC-V-BUILD-BSP-RISC-V-ABI currently works, assign it per variant.


I would do it similar to:

spec/build/bsps/riscv/riscv/RTEMS-BUILD-BSP-RISCV-RISCV-ABI.yml

You can use regular expressions for the matching variant, e.g.

default: ''
default-by-variant:
- value: '32'
  variants:
  - riscv/rv32.*
- value: '64'
  variants:
  - riscv/rv64.*

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

Re: [RFC] RTEMS Waf Clang support

Thanks Sebastian!

I tried to follow your instructions for adding this as a new option, but
unfortunately, XLEN didn't evaluate for RTEMS-BUILD-CPUKIT-OPTCLANG to use.
Here's the diff:

diff --git a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
> b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
> new file mode 100644
> index 00..840a8ecc2c
> --- /dev/null
> +++ b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
> @@ -0,0 +1,19 @@
> +active: true
> +build-type: option
> +default: ''
> +default-by-variant:
> +- value: '64'
> +  variants:
> +  - riscv/rv64.*
> +derived: false
> +enabled-by: []
> +header: ''
> +level: '1.110'
> +links: []
> +name: XLEN
> +normative: true
> +order: -1000
> +ref: ''
> +reviewed: ChapNb5NSPl062d5CnU251RB5J6TljFz_mLkmFdgwVY=
> +text: ''
> +type: build


grepping for XLEN only gets me:

> c4che/spec_build.pickle:133389:ssS'RTEMS-BUILD-CPUKIT-OPTXLEN'
> c4che/spec_build.pickle:133433:S'XLEN'
>
> c4che/spec_build.pickle:154984:S'--target=${ARCH}${XLEN}-unknown-rtems${__RTEMS_MAJOR__}'
>

Am I missing something?


On Mon, 16 Mar 2020 at 12:15, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 16/03/2020 13:09, Hesham Almatary wrote:
>
> > On Mon, 16 Mar 2020 at 11:53, Sebastian Huber
> >  wrote:
> >> On 16/03/2020 12:39, Hesham Almatary wrote:
> >>
> >>> Hi Sebastian,
> >>>
> >>> I have pushed a few commits to my repo to support building RTEMS with
> >>> Clang/LLVM for RISC-V. Here are the changes [1]. Since I'm still
> >>> learning about Waf and the build system, I'd appreciate your input.
> >>> Most importantly, I want to know what's the right way to set "target"
> >>> and "xlen" variables.
> >>>
> >>> [1]
> https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...aa73f72b929856efdb41f9f8582263b5395a3276
> >> You need a new option, e.g.
> >>
> >> spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
> >>
> >> It should be enabled by clang and riscv:
> >>
> >> enabled-by:
> >> and:
> >> - clang
> >> - riscv
> >>
> >> The option must be evaluated before the tool settings:
> >>
> >> order: -1000
> >>
> > Yes, I thought of that too. But I need to define XLEN to empty or
> > something for other architectures too since I use it in
> > RTEMS-BUILD-CPUKIT-OPTCLANG:
> Does it not default to the empty string if it is not defined?
> >
> >> - set-value: --target=${ARCH}${XLEN}-unknown-rtems${__RTEMS_MAJOR__}
> >> - substitute: null
> >> - env-append: ABI_FLAGS
> > How should each RISC-V BSP assign XLEN? I thought of a few ways:
> > 1) to make each BSP yml file do it, or
> > 2) to script it for RISC-V and extract it from the march value,
> > 3) to assign it in a single file and, similar to how
> > RISC-V-BUILD-BSP-RISC-V-ABI currently works, assign it per variant.
>
> I would do it similar to:
>
> spec/build/bsps/riscv/riscv/RTEMS-BUILD-BSP-RISCV-RISCV-ABI.yml
>
> You can use regular expressions for the matching variant, e.g.
>
> default: ''
> default-by-variant:
> - value: '32'
>variants:
>- riscv/rv32.*
> - value: '64'
>variants:
>- riscv/rv64.*
>
>

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

Re: [RFC] RTEMS Waf Clang support



On 16/03/2020 13:51, Hesham Almatary wrote:

Thanks Sebastian!

I tried to follow your instructions for adding this as a new option, 
but unfortunately, XLEN didn't evaluate for 
RTEMS-BUILD-CPUKIT-OPTCLANG to use. Here's the diff:


diff --git a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
new file mode 100644
index 00..840a8ecc2c
--- /dev/null
+++ b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
@@ -0,0 +1,19 @@
+active: true
+build-type: option
+default: ''
+default-by-variant:
+- value: '64'
+  variants:
+  - riscv/rv64.*
+derived: false
+enabled-by: []
+header: ''
+level: '1.110'
+links: []
+name: XLEN
+normative: true
+order: -1000
+ref: ''
+reviewed: ChapNb5NSPl062d5CnU251RB5J6TljFz_mLkmFdgwVY=
+text: ''
+type: build


grepping for XLEN only gets me:

c4che/spec_build.pickle:133389:ssS'RTEMS-BUILD-CPUKIT-OPTXLEN'
c4che/spec_build.pickle:133433:S'XLEN'

c4che/spec_build.pickle:154984:S'--target=${ARCH}${XLEN}-unknown-rtems${__RTEMS_MAJOR__}'


Am I missing something?


Did you link the new item to

spec/build/cpukit/RTEMS-BUILD-CPUKIT-CPUOPTS.yml

?

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

Re: [RFC] RTEMS Waf Clang support

On Mon, 16 Mar 2020 at 12:54, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
> On 16/03/2020 13:51, Hesham Almatary wrote:
>
> Thanks Sebastian!
>
> I tried to follow your instructions for adding this as a new option, but
> unfortunately, XLEN didn't evaluate for RTEMS-BUILD-CPUKIT-OPTCLANG to use.
> Here's the diff:
>
> diff --git a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
>> b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
>> new file mode 100644
>> index 00..840a8ecc2c
>> --- /dev/null
>> +++ b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
>> @@ -0,0 +1,19 @@
>> +active: true
>> +build-type: option
>> +default: ''
>> +default-by-variant:
>> +- value: '64'
>> +  variants:
>> +  - riscv/rv64.*
>> +derived: false
>> +enabled-by: []
>> +header: ''
>> +level: '1.110'
>> +links: []
>> +name: XLEN
>> +normative: true
>> +order: -1000
>> +ref: ''
>> +reviewed: ChapNb5NSPl062d5CnU251RB5J6TljFz_mLkmFdgwVY=
>> +text: ''
>> +type: build
>
>
> grepping for XLEN only gets me:
>
>> c4che/spec_build.pickle:133389:ssS'RTEMS-BUILD-CPUKIT-OPTXLEN'
>> c4che/spec_build.pickle:133433:S'XLEN'
>>
>> c4che/spec_build.pickle:154984:S'--target=${ARCH}${XLEN}-unknown-rtems${__RTEMS_MAJOR__}'
>>
>
> Am I missing something?
>
> Did you link the new item to
>
> spec/build/cpukit/RTEMS-BUILD-CPUKIT-CPUOPTS.yml
>
> ?
>
That's what I was missing, thanks!

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

Re: [RFC] RTEMS Waf Clang support

Sebastian, I modified my patch set to properly add the XLEN option.
This should make it generic enough for other architectures to be built
with Clang/LLVM, but I have only tested RISC-V.
I can git send-email if you want me to.

[1] 
https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...cbe9d2a40fade836667fe2a910b9c2f85866699c

On Mon, 16 Mar 2020 at 13:04, Hesham Almatary  wrote:
>
>
>
> On Mon, 16 Mar 2020 at 12:54, Sebastian Huber 
>  wrote:
>>
>>
>> On 16/03/2020 13:51, Hesham Almatary wrote:
>>
>> Thanks Sebastian!
>>
>> I tried to follow your instructions for adding this as a new option, but 
>> unfortunately, XLEN didn't evaluate for RTEMS-BUILD-CPUKIT-OPTCLANG to use. 
>> Here's the diff:
>>
>>> diff --git a/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml 
>>> b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
>>> new file mode 100644
>>> index 00..840a8ecc2c
>>> --- /dev/null
>>> +++ b/spec/build/cpukit/RTEMS-BUILD-CPUKIT-OPTXLEN.yml
>>> @@ -0,0 +1,19 @@
>>> +active: true
>>> +build-type: option
>>> +default: ''
>>> +default-by-variant:
>>> +- value: '64'
>>> +  variants:
>>> +  - riscv/rv64.*
>>> +derived: false
>>> +enabled-by: []
>>> +header: ''
>>> +level: '1.110'
>>> +links: []
>>> +name: XLEN
>>> +normative: true
>>> +order: -1000
>>> +ref: ''
>>> +reviewed: ChapNb5NSPl062d5CnU251RB5J6TljFz_mLkmFdgwVY=
>>> +text: ''
>>> +type: build
>>
>>
>> grepping for XLEN only gets me:
>>>
>>> c4che/spec_build.pickle:133389:ssS'RTEMS-BUILD-CPUKIT-OPTXLEN'
>>> c4che/spec_build.pickle:133433:S'XLEN'
>>> c4che/spec_build.pickle:154984:S'--target=${ARCH}${XLEN}-unknown-rtems${__RTEMS_MAJOR__}'
>>
>>
>> Am I missing something?
>>
>> Did you link the new item to
>>
>> spec/build/cpukit/RTEMS-BUILD-CPUKIT-CPUOPTS.yml
>>
>> ?
>
> That's what I was missing, thanks!
>
> --
> Hesham



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

Re: [RFC] RTEMS Waf Clang support


On 16/03/2020 14:33, Hesham Almatary wrote:


Sebastian, I modified my patch set to properly add the XLEN option.
This should make it generic enough for other architectures to be built
with Clang/LLVM, but I have only tested RISC-V.
I can git send-email if you want me to.

[1]https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...cbe9d2a40fade836667fe2a910b9c2f85866699c
I think we need a better name for the XLEN. It is a bit RISCV-specific. 
What about ARCH_BITS?

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

Re: [RFC] RTEMS Waf Clang support

On Mon, 16 Mar 2020 at 13:35, Sebastian Huber
 wrote:
>
> On 16/03/2020 14:33, Hesham Almatary wrote:
>
> > Sebastian, I modified my patch set to properly add the XLEN option.
> > This should make it generic enough for other architectures to be built
> > with Clang/LLVM, but I have only tested RISC-V.
> > I can git send-email if you want me to.
> >
> > [1]https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...cbe9d2a40fade836667fe2a910b9c2f85866699c
> I think we need a better name for the XLEN. It is a bit RISCV-specific.
> What about ARCH_BITS?
Makes more sense. I modified it accordingly
https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...8847fa44e68a0d7e0f9e96faf54c88928f8ac141


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

Re: Project Query for #3855 (BSP Buildset for EPICS)

On Mon, Mar 9, 2020 at 9:17 PM Gedare Bloom  wrote:

> On Mon, Mar 9, 2020 at 7:31 AM Mritunjay Sharma
>  wrote:
> >
> > Thank you, Chris, for such a detailed description of my query.
> > Yes, sure. I would be more than happy to help with this fantastic idea
> proposed by Joel. I think I need to reschedule a few things in my proposal
> now. So before things start looking cleaner in my proposal, can we discuss
> more on our Bonus Project? Also, do I have to modify the title of the
> proposal now on https://devel.rtems.org/wiki/GSoC/2020 ?
> >
>
>> No you don't need to modify the title.
>> The bonus task would be to carry out similar activities:
>> * compile CFS by hand, create an RSB "recipe" to build it, then
>> integrate it with vertical buildset configuration.
>> * create vertical buildsets for PC, Raspberry Pi, and other boards.
>> ** EPICS community uses many powerpc boards so adding something there
>> would be good.
>> ** Adding buildsets for the commonly available simulators would be good.
>> My understanding is that building EPICS7 with RTEMS5 is currently
>> non-trivial. I have CC'd Heinz Junkes from EPICS community, and he has
>> agreed intention to co-mentor/advise this project. He is the main
>> person that has been doing work with EPICS7/RTEMS5 so this will be a
>> great resource to lean on.
>
>
 Since all the above-mentioned bonus tasks are similar in nature,
and since I am doing my research in creating vertical buildsets, I am ready
to work on each of them (even if some tasks remain in the current GSoC
timeline, I can work on them after it). Now that Gedare has given the
feedback to the first draft of my proposal, I would like the advice of all
on resetting my timelines. Link to the proposal is available on :
https://devel.rtems.org/wiki/GSoC/2020 under the title BSP Buildset for
EPICS.
I also would like to request Heinz Junkes from EPICS community and members
of RTEMS to please help me out first to Build EPICS 7 from source with
RTEMS 5 so that I can accelerate up a bit with setting up the tools and
environment for the project.



>
>
> > Thanks
> > Mritunjay
> >
> > On Mon, Mar 9, 2020 at 3:43 AM Chris Johns  wrote:
> >>
> >> On 9/3/20 9:05 am, Joel Sherrill wrote:
> >> > Do you think it is full summer of work? I am wondering about a bonus
> project if
> >> > it gets done early. CFS vertical stack might be a good option if no
> one signs up
> >> > for that.
> >>
> >> I was wondering that myself so this is a fantastic idea.
> >>
> >> Can we also look at extending the project to create support to generate
> a, PC,
> >> BBB or RPi ready to run SD card image?
> >>
> >> Chris
> >
> > ___
> > 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

[PATCH rtems-docs] user/raspberrypi: Fix typo

2020-03-16 Thread G S Niteesh Babu

enable-uart should be enable_uart in config.txt
---
 user/bsps/arm/raspberrypi.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
index 72889a5..c26f4b5 100644
--- a/user/bsps/arm/raspberrypi.rst
+++ b/user/bsps/arm/raspberrypi.rst
@@ -46,7 +46,7 @@ Make sure you have these lines below, in your ``config.txt``.
 
 .. code-block:: none
 
- enable-uart=1
+ enable_uart=1
  kernel_address=0x20
  kernel=kernel.img
 
-- 
2.17.1

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

[PATCH 0/1] Add Python development guidelines

This is a first draft of the Python development guildelines for the
RTEMS Software Engineering manual.

For the static analysis tools flake8, pylint, and mypy you can use
configuration files. I would start with the default configuration. For
pylint, you can dump the default configuration with "pylint
--generate-rcfile". Should we use a particular pylint version to
generate configuration file for the RTEMS Project or should we just use
whatever a future version will use as default?  I am not sure about the
mypy configuration.

How do we want to install the Python development tools? In the
rtems-qual repository I simply set up a virtual environment with a
simple Makefile:

https://git.rtems.org/sebh/rtems-qual.git/tree/Makefile

I think we should install specific versions of the tools to avoid that
different developers get different tool reports.

How could a waf integration look like?

Sebastian Huber (1):
  eng: Add Python development guidelines

 eng/management.rst   |   1 +
 eng/python-devel.rst | 136 +++
 2 files changed, 137 insertions(+)
 create mode 100644 eng/python-devel.rst

-- 
2.16.4

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

[PATCH 1/1] eng: Add Python development guidelines

---
 eng/management.rst   |   1 +
 eng/python-devel.rst | 136 +++
 2 files changed, 137 insertions(+)
 create mode 100644 eng/python-devel.rst

diff --git a/eng/management.rst b/eng/management.rst
index 064559c..6eb4217 100644
--- a/eng/management.rst
+++ b/eng/management.rst
@@ -16,5 +16,6 @@ Software Development Management
 vc-users
 vc-authors
 coding
+python-devel
 change-management
 issue-tracking
diff --git a/eng/python-devel.rst b/eng/python-devel.rst
new file mode 100644
index 000..0347892
--- /dev/null
+++ b/eng/python-devel.rst
@@ -0,0 +1,136 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+
+.. _PythonDevelGuide:
+
+Python Development Guidelines
+*
+
+Python is the main programming language for the RTEMS Tools.  The RTEMS Tools
+run on the host computer of an RTEMS user or maintainer.  These guidelines
+cover the Python language version, the source code formatting, use of static
+analysis tools, type annotations, testing, code coverage, and documentation.
+There are exceptions for existing code and third-party code.  It is recommended
+to read the
+`PEP 8 - Style Guide for Python Code 
`_
+and the
+`Google Python Style Guide `_.
+
+Python Language Versions
+
+
+Although the official end-of-life of Python 2.7 was on January 1, 2020, the
+RTEMS Project still cares about Python 2.7 compatibility for some tools.  Every
+tool provided by the RTEMS Project which an RTEMS user may use to develop
+applications with RTEMS should be Python 2.7 compatible.  Examples are the
+build system, the RTEMS Source Builder, and the RTEMS Tester.  The rationale is
+that there are still some maintained Linux distributions in the wild which ship
+only Python 2.7 by default.  An example is CentOS 7 which gets maintenance
+updates until June 2024.  Everything an RTEMS maintainer uses should be written
+in Python 3.6.
+
+Python Code Formatting
+==
+
+Good looking code is important.  Unfortunately, what looks good is a bit
+subjective and varies from developer to developer.  Arguing about the code
+format is not productive.  Code reviews should focus on more important topics,
+e.g. functionality, testability, and performance.  Fortunately, for Python
+there are some good automatic code formatters available.  All new code
+specifically developed for the RTEMS Tools should be piped through the
+`yapf `_ Python code formatter before it is
+committed or sent for review.  Use the default settings of the tool
+(`PEP 8 `_ coding style).
+
+You can disable the automatic formatting by the tool in a region starting with
+the ``#yapf: disable`` comment until the next ``# yapf: enable`` comment, e.g.
+
+.. code-block:: python
+
+# yapf: disable
+FOO = {
+# ... some very large, complex data literal.
+}
+
+BAR = [
+# ... another large data literal.
+]
+# yapf: enable
+
+For a single literal, you can disable the formatting like this:
+
+.. code-block:: python
+
+BAZ = {
+(1, 2, 3, 4),
+(5, 6, 7, 8),
+(9, 10, 11, 12),
+}  # yapf: disable
+
+Static Analysis Tools
+=
+
+Use the ``flake8`` and ``pylint`` static analysis tools for Python.  Do not
+commit your code or sent it for review if the tools find some rule
+violations.  Run the tools with the default configuration.  If you have
+problems to silence the tools, then please ask for help on the :r:list:`devel`.
+Consult the tool documentation to silence false positives.
+
+Type Annotations
+
+
+For Python 3.6 or later code use type annotations.  All public functions of
+your modules should have `PEP 484 `_
+type annotations.  Check for type issues with the
+`mypy `_ static type checker.
+
+Testing
+===
+
+Write unit tests for your code with the standard Python ``unittest`` and
+``unittest.mock`` modules.  Use ``coverage run -m pytest`` to run the tests
+with code coverage support.  If you modify existing code or contribute new code
+to a subproject which uses unit tests and the code coverage metric, then do not
+make the code coverage worse.
+
+Documentation
+=
+
+Document your code using the
+`PEP 257 - Docstring Conventions `_.
+Contrary to PEP 257, use the descriptive-style
+(``"""Fetches rows from a Bigtable."""``) instead of imperative-style
+(``"""Fetch rows from a Bigtable."""``) as recommended by
+`Comments and Docstrings - Functions and Methods 
`_.
+Use the
+`Sphinx

Re: Issues when adding a multi-port PCI serial card

On 13/03/2020 20:16, dufa...@hda.com wrote:

On Mar 13, 2020, at 08:42 , Sebastian Huber
wrote:

Thanks for replying.

On 12/03/2020 21:44, Peter Dufault wrote:

I've added an 8-port RS232 PCI Mezzanine Card to the "beatnik" BSP. The
console (aka serial port) code is confusing.

I decided I should use what is in "bsp/console-termios.h" as opposed to the "legacy
console" approach, *even though* "legacy console" is used in many recent BSPS.

What is a recent BSP for you? I would call all BSPs which still use this
major/minor number drivers a legacy BSP.

The fact that all recent drivers have major and minor numbers of 0 is confusing. I wanted a minor
number in order to enumerate the serial ports. I don't mind that RTEMS goes away from major and
minor numbers, but doing an "ls -l" and seeing all those "0" entries is, as I
said, confusing.

* Does that happen on FreeBSD?

This looks like a bug. I never paid attention to the major/minor numbers.

That approach went well, I created a replacement shared PowerPC console in
"bsps/powerpc/shared/console/console-config.c" with only 129 lines of code and
half of it comments.

This is probably all right. What we don't have in RTEMS is a generic device
enumeration framework.

Are you indirectly replying to my previous comment about wanting a minor number
for serial device enumeration reasons?

Yes, you can modify the generic driver if you need a unit number. It
could also generate the device file path.

For anything with a plug and play hardware (e.g. PCI) I would use the
libbsd for device drivers. It already has everything you need for driver
and device management.

Where does the driver go: Next I had to add the PCI multi-port serial card driver. I put it in
"bsps/shared/dev/pci/mp_serial.c". The other directory choice was "bsps/shared/dev/serial". I didn't like
either, the "dev/pci" is very associated with PCI discovery and the "dev/serial" is very associated with the
generic low-level serial driver support, even thought it has the "legacy-console" cruft in it.

* Where should it go?

The serial drivers which are not specific to a BSP should go to "bsps/shared/dev/serial"
or even "cpukit/dev/serial".

I put the driver in "bsps/shared/dev/serial", I decided that was better than "/dev/pci". I don't
know what goes in "cpukit" versus "bsps".

* What distinguishes where a shared code should go? Should much of what is "bsps/shared"
be in "cpukit" instead?
In "bsps/shared" you can use BSP-specific header files. In "cpukit" you
cannot use them.

Difficulty in assigning common TTY names: Since my new shared PowerPC "console-config.c" created
"/dev/ttyS0" and "/dev/ttyS1" I wanted to name the new serial devices with a number that started at
2, i.e., "/dev/ttyS2".

* Is there a way in the "console-termios" framework to know what the highest "minor
number" for a serial port is? I searched, gave up, and made it a configuration item.

No, we don't have a framework for unit number assignments. It is not that easy if you
look at the FreeBSD code. Why don't use use driver specific names, e.g.
"/dev/pci-serial-XXX"?

I don't want that because I just don't want that, I want generic serial ports to have
generic names such as "/dev/ttySX".

* Can you explain why "/dev/pci-serial-XXX" is a good option for the end-user?

Yes, if it is a PCI-specific driver it should have a PCI-specific path.
If it is managed by a generic console driver, then "/dev/ttySX" is fine.

[...]

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

Re: [RFC] RTEMS Waf Clang support


On 16/03/2020 14:59, Hesham Almatary wrote:


On Mon, 16 Mar 2020 at 13:35, Sebastian Huber
 wrote:

On 16/03/2020 14:33, Hesham Almatary wrote:


Sebastian, I modified my patch set to properly add the XLEN option.
This should make it generic enough for other architectures to be built
with Clang/LLVM, but I have only tested RISC-V.
I can git send-email if you want me to.

[1]https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...cbe9d2a40fade836667fe2a910b9c2f85866699c

I think we need a better name for the XLEN. It is a bit RISCV-specific.
What about ARCH_BITS?

Makes more sense. I modified it accordingly
https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...8847fa44e68a0d7e0f9e96faf54c88928f8ac141


Ok, could you please send the patches which you want to get integrated 
in build branch to the mailing list.


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

Re: What sanitizers preferred?


On 15/03/2020 17:52, suyash singh wrote:


Hello,
Out of
AddressSanitizer , 
ThreadSanitizer , 
MemorySanitizer , and 
DataFlowSanitizer .


Are all of them useful as RTEMS-tools to integrate? Any other 
sanitizers suggested?


Asking as part of my proposed gsoc project,
https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
I am not sure of these sanitizers can be used in RTEMS at all. We don't 
have virtual memory. Firstly, it would be necessary to check for each 
sanitizer if it uses virtual memory. If yes, then is this absolutely 
necessary or just convenient? Also the sanitizers are not available on 
all LLVM architectures. We have to evaluate if the 
architectures-specific adoptions can be used in RTEMS.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] Start converting tests to pytest.

On 2020-03-16 09:40 +0100, Sebastian Huber wrote:
> 
> I work currently on a draft for the Python development guidelines for the
> engineering manual. I hope to have something ready for review in the next 
> days.
> 
> Documenting the tests with with pydoc strings in general would be overkill 
> from
> my point of view.

Yes, typically the test names themselves are self-explanatory.  If they aren't 
then larger tests should be broken into smaller one with descriptive names.

Documentation should be in the source code itself.  Documenting it twice is a 
longterm nightmare as eventually either-or will deviate from each other while 
the documentation doesn't change.

Only in rare cases when a test does something non-obvious should there be any 
documentation and even then that's usually not at the function level but above 
the code snippet.

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

Re: What sanitizers preferred?

2020-03-16 Thread Joel Sherrill

On Mon, Mar 16, 2020 at 11:05 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 15/03/2020 17:52, suyash singh wrote:
>
> Hello,
> Out of
> AddressSanitizer ,
> ThreadSanitizer ,
> MemorySanitizer , and
> DataFlowSanitizer .
>
> Are all of them useful as RTEMS-tools to integrate? Any other sanitizers
> suggested?
>
> Asking as part of my proposed gsoc project,
>
> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
>
> I am not sure of these sanitizers can be used in RTEMS at all. We don't
> have virtual memory. Firstly, it would be necessary to check for each
> sanitizer if it uses virtual memory. If yes, then is this absolutely
> necessary or just convenient? Also the sanitizers are not available on all
> LLVM architectures. We have to evaluate if the architectures-specific
> adoptions can be used in RTEMS.
>

+1

Another area is the compiler stack protection techniques. I have no idea if
those are applicable to RTEMS but they would be useful if they can work.

Ignoring other constraints from embedded systems, any possible technique to
use with RTEMS must be evaluated against the constraints imposed by having
a single address space, no VM, and single process model.

You need to check if any of these will work before this project has a
chance.

I would be willing to entertain a project for an appropriate solution that
is limited to say ARM, x86, and RISC-V.

--joel

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

Re: BSP Wiki Clean Up

Working on #3905 (Clean up BSP Wiki Pages), I have made a list of BSPs that
are not now part of the source tree and recommending them to delete them
and I would like to @rtems-de...@rtems.org  to have a look
of it :

To be removed BSPs

ARM BSPs
1) Cogent CSB637 --csb637
2) Cogent Kit637_v6 -- kit637 v6
3) RTL22xx_t (Philips/NXP ARM7 in Thumb mode) -- rtl22xx t
4) GamePark? Holdings GP2X -- gp2x
5) NXP LPC17XX (pin compatible to LPC24XX with ARM Cortex-M3 core) ?
6) NXP LPC40XX (pin compatible to LPC24XX with ARM Cortex-M4 core) ?
7) Stellaris LaunchPad? XL -- LM4F120
8) STM32F105

Motorola M68xxx and Coldfire BSPs
1) Generic MC68302 -- gen68302
2) Motorola MVME162LX -- mvme162lx
3) ods68302

MIPS BSPs
1) Generic IDT 4600 -- p4000
2) Generic IDT 4650 -- p4650

PowerPC BSPs
1) BAE RAD750 3U and 6U -- rad750
2) DY-4 DMV177 -- dmv177?
3) Frasca ETHCOMM -- eth comm
4) Freescale MPC5554 --Phycore mpc5554?
5) Freescale MPC5674FEVB -- MPC5674FEVB
6) Generic PPC405 -- gen405
7) IMD Helas 403 -- helas403?
8) Motorola MCP750 -- mcp750
9) Motorola/Phytec? Phycore MCP5554 Phycore mpc5554
10)Motorola MTX603e -- mtx603e
11)Motorola MVME2100 -- mvme2100
12)Motorola MVME2307 -- mvme2307
13)Motorola MVME2400 -- mvme2400?
14)Motorola MVME2600 -- mvme2600
15)Motorola MVME2700 -- mvme2700

SPARC BSPs
1) SPARC Instruction Simulator (sis) -- obsoleted in 5.1.

Please tell if I have add to link to them also.

Thanks
Mritunjay

On Sun, Mar 15, 2020 at 10:17 PM Joel Sherrill  wrote:

>
>
> On Sun, Mar 15, 2020 at 11:12 AM Joel Sherrill  wrote:
>
>>
>>
>> On Sat, Mar 14, 2020 at 10:55 PM Gedare Bloom  wrote:
>>
>>> On Sat, Mar 14, 2020 at 2:05 PM Joel Sherrill  wrote:
>>> >
>>> > I put devel@ back on
>>> >
>>> > On Sat, Mar 14, 2020, 2:23 PM Mritunjay Sharma <
>>> mritunjaysharma...@gmail.com> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> I am very much willing to help with this thing. Being a bit new to
>>> the community, I just wanted to know that while deleting the wiki content
>>> on obsolete BSPs, do I need to report it before deleting and create a
>>> ticket for it or I can straightaway delete it?
>>> >
>>> >
>>> > I hate to start with use your judgement but...
>>> >
>>> > You could just ask on the list for deletion confirmation. My
>>> impression is that a deletion pass will be quick.
>>> >
>>> > For moving content to rtems-docs, that will be patches which need
>>> review. So post those.
>>> >
>>> > And I suspect some BSPs will have pages that are useless stubs. Ask
>>> about just deleting instead of converting them.
>>> >
>>> > Thanks for pitching in.
>>>
>>> I would prefer to have an analysis of the difference between what has
>>> been migrated already
>>> https://docs.rtems.org/branches/master/user/bsps/index.html versus
>>> what is in the wiki. If some content needs to move out of the wiki,
>>> then a patch to add it to the docs would be good, then we could
>>> discuss on the list whether or not to move that content or to delete
>>> it.  If content has been migrated or the migration discussion leads to
>>> a decision to delete, then we should remove that page. Removing a page
>>> requires an admin privilege, so I think a list of pages to be removed
>>> should be maintained somewhere like
>>> https://devel.rtems.org/wiki/TBR/BSP
>>
>>
>> I have made a sweep to delete all text which has links to non-existent
>> pages
>> since those do not have to be reviewed.
>>
>> My next pass is to delete all pages for BSPs and ports that have been
>> removed.
>> That is a simple review process.
>>
>
> I have completed this also.
>
>>
>> After that, what should be left is a list of pages which need manual
>> review to
>> extract/convert useful content to the Users Guide. This should be one
>> patch
>> and email per BSP/Wiki page.
>>
>
> This should be ready to dig into. I suspect that a number of the BSP pages
> are
> marginal having been written by Google Code-In students. If they just have
> hardware descriptions from vendor pages and no howtos, what do we want to
> do?
>
>
>>
>> I also found this list:
>>
>> https://devel.rtems.org/wiki/TBR/UserManual which has a variety of topic
>> pages which need review and either deleted or merged into the appropriate
>> documentation.
>>
>> --joel
>>
>>
>>>
>>>
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Mritunjay
>>> >>
>>> >> On Sat, Mar 14, 2020 at 10:30 PM Joel Sherrill 
>>> wrote:
>>> >>>
>>> >>> Hi
>>> >>>
>>> >>> GSoC students and those who are unfortunately self-quarrantined
>>> looking for something to do could really help by reviewing the wiki BSP
>>> pages and helping move the current content to the Users Guide.
>>> >>>
>>> >>> The wiki includes an incomplete and out of date list of BSPs and
>>> architectures that have been removed.
>>> >>>
>>> >>> Wiki is here:
>>> https://devel.rtems.org/wiki/TBR/Website/Board_Support_Packages
>>> >>>
>>> >>> Users Guide is in the rtems-docs repo and viewable online at
>>> docs.rtems.org.
>>> >>>
>>> >>> I think much of the effort is quite straight forward. First p

Re: BSP Wiki Clean Up

2020-03-16 Thread Joel Sherrill

On Mon, Mar 16, 2020, 12:01 PM Mritunjay Sharma <
mritunjaysharma...@gmail.com> wrote:

> Working on #3905 (Clean up BSP Wiki Pages), I have made a list of BSPs
> that are not now part of the source tree and recommending them to delete
> them and I would like to @rtems-de...@rtems.org  to have
> a look of it :
>
> To be removed BSPs
>

I agree with some of these but wonder how you are making the present or not
determination. I think at least rtl22xx_t is present as a variant of
rtl22xx. Look in it's config directory.

https://git.rtems.org/rtems/tree/bsps/arm/rtl22xx/config

>
> ARM BSPs
> 1) Cogent CSB637 --csb637
> 2) Cogent Kit637_v6 -- kit637 v6
> 3) RTL22xx_t (Philips/NXP ARM7 in Thumb mode) -- rtl22xx t
> 4) GamePark? Holdings GP2X -- gp2x
> 5) NXP LPC17XX (pin compatible to LPC24XX with ARM Cortex-M3 core) ?
> 6) NXP LPC40XX (pin compatible to LPC24XX with ARM Cortex-M4 core) ?
> 7) Stellaris LaunchPad? XL -- LM4F120
> 8) STM32F105
>
> Motorola M68xxx and Coldfire BSPs
> 1) Generic MC68302 -- gen68302
> 2) Motorola MVME162LX -- mvme162lx
> 3) ods68302
>
> MIPS BSPs
> 1) Generic IDT 4600 -- p4000
> 2) Generic IDT 4650 -- p4650
>
> PowerPC BSPs
> 1) BAE RAD750 3U and 6U -- rad750
> 2) DY-4 DMV177 -- dmv177?
> 3) Frasca ETHCOMM -- eth comm
> 4) Freescale MPC5554 --Phycore mpc5554?
> 5) Freescale MPC5674FEVB -- MPC5674FEVB
> 6) Generic PPC405 -- gen405
> 7) IMD Helas 403 -- helas403?
> 8) Motorola MCP750 -- mcp750
> 9) Motorola/Phytec? Phycore MCP5554 Phycore mpc5554
> 10)Motorola MTX603e -- mtx603e
> 11)Motorola MVME2100 -- mvme2100
> 12)Motorola MVME2307 -- mvme2307
> 13)Motorola MVME2400 -- mvme2400?
> 14)Motorola MVME2600 -- mvme2600
> 15)Motorola MVME2700 -- mvme2700
>
> SPARC BSPs
> 1) SPARC Instruction Simulator (sis) -- obsoleted in 5.1.
>
> Please tell if I have add to link to them also.
>
> Thanks
> Mritunjay
>
> On Sun, Mar 15, 2020 at 10:17 PM Joel Sherrill  wrote:
>
>>
>>
>> On Sun, Mar 15, 2020 at 11:12 AM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Sat, Mar 14, 2020 at 10:55 PM Gedare Bloom  wrote:
>>>
 On Sat, Mar 14, 2020 at 2:05 PM Joel Sherrill  wrote:
 >
 > I put devel@ back on
 >
 > On Sat, Mar 14, 2020, 2:23 PM Mritunjay Sharma <
 mritunjaysharma...@gmail.com> wrote:
 >>
 >> Hi,
 >>
 >> I am very much willing to help with this thing. Being a bit new to
 the community, I just wanted to know that while deleting the wiki content
 on obsolete BSPs, do I need to report it before deleting and create a
 ticket for it or I can straightaway delete it?
 >
 >
 > I hate to start with use your judgement but...
 >
 > You could just ask on the list for deletion confirmation. My
 impression is that a deletion pass will be quick.
 >
 > For moving content to rtems-docs, that will be patches which need
 review. So post those.
 >
 > And I suspect some BSPs will have pages that are useless stubs. Ask
 about just deleting instead of converting them.
 >
 > Thanks for pitching in.

 I would prefer to have an analysis of the difference between what has
 been migrated already
 https://docs.rtems.org/branches/master/user/bsps/index.html versus
 what is in the wiki. If some content needs to move out of the wiki,
 then a patch to add it to the docs would be good, then we could
 discuss on the list whether or not to move that content or to delete
 it.  If content has been migrated or the migration discussion leads to
 a decision to delete, then we should remove that page. Removing a page
 requires an admin privilege, so I think a list of pages to be removed
 should be maintained somewhere like
 https://devel.rtems.org/wiki/TBR/BSP
>>>
>>>
>>> I have made a sweep to delete all text which has links to non-existent
>>> pages
>>> since those do not have to be reviewed.
>>>
>>> My next pass is to delete all pages for BSPs and ports that have been
>>> removed.
>>> That is a simple review process.
>>>
>>
>> I have completed this also.
>>
>>>
>>> After that, what should be left is a list of pages which need manual
>>> review to
>>> extract/convert useful content to the Users Guide. This should be one
>>> patch
>>> and email per BSP/Wiki page.
>>>
>>
>> This should be ready to dig into. I suspect that a number of the BSP
>> pages are
>> marginal having been written by Google Code-In students. If they just
>> have
>> hardware descriptions from vendor pages and no howtos, what do we want to
>> do?
>>
>>
>>>
>>> I also found this list:
>>>
>>> https://devel.rtems.org/wiki/TBR/UserManual which has a variety of topic
>>> pages which need review and either deleted or merged into the appropriate
>>> documentation.
>>>
>>> --joel
>>>
>>>


 >>
 >>
 >> Thanks,
 >> Mritunjay
 >>
 >> On Sat, Mar 14, 2020 at 10:30 PM Joel Sherrill 
 wrote:
 >>>
 >>> Hi
 >>>
 >>> GSoC students and those who are unfortunately self-quarrantined
 l

Re: BSP Wiki Clean Up

Okay, actually I looked only under
https://git.rtems.org/rtems/tree/bsps/arm/
 (and others like
i386) and now that I know that I have to look deeper, will make a
correction and send it here.

On Mon, Mar 16, 2020 at 11:23 PM Joel Sherrill  wrote:

>
>
> On Mon, Mar 16, 2020, 12:01 PM Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
>
>> Working on #3905 (Clean up BSP Wiki Pages), I have made a list of BSPs
>> that are not now part of the source tree and recommending them to delete
>> them and I would like to @rtems-de...@rtems.org  to
>> have a look of it :
>>
>> To be removed BSPs
>>
>
> I agree with some of these but wonder how you are making the present or
> not determination. I think at least rtl22xx_t is present as a variant of
> rtl22xx. Look in it's config directory.
>
> https://git.rtems.org/rtems/tree/bsps/arm/rtl22xx/config
>
>>
>> ARM BSPs
>> 1) Cogent CSB637 --csb637
>> 2) Cogent Kit637_v6 -- kit637 v6
>> 3) RTL22xx_t (Philips/NXP ARM7 in Thumb mode) -- rtl22xx t
>> 4) GamePark? Holdings GP2X -- gp2x
>> 5) NXP LPC17XX (pin compatible to LPC24XX with ARM Cortex-M3 core) ?
>> 6) NXP LPC40XX (pin compatible to LPC24XX with ARM Cortex-M4 core) ?
>> 7) Stellaris LaunchPad? XL -- LM4F120
>> 8) STM32F105
>>
>> Motorola M68xxx and Coldfire BSPs
>> 1) Generic MC68302 -- gen68302
>> 2) Motorola MVME162LX -- mvme162lx
>> 3) ods68302
>>
>> MIPS BSPs
>> 1) Generic IDT 4600 -- p4000
>> 2) Generic IDT 4650 -- p4650
>>
>> PowerPC BSPs
>> 1) BAE RAD750 3U and 6U -- rad750
>> 2) DY-4 DMV177 -- dmv177?
>> 3) Frasca ETHCOMM -- eth comm
>> 4) Freescale MPC5554 --Phycore mpc5554?
>> 5) Freescale MPC5674FEVB -- MPC5674FEVB
>> 6) Generic PPC405 -- gen405
>> 7) IMD Helas 403 -- helas403?
>> 8) Motorola MCP750 -- mcp750
>> 9) Motorola/Phytec? Phycore MCP5554 Phycore mpc5554
>> 10)Motorola MTX603e -- mtx603e
>> 11)Motorola MVME2100 -- mvme2100
>> 12)Motorola MVME2307 -- mvme2307
>> 13)Motorola MVME2400 -- mvme2400?
>> 14)Motorola MVME2600 -- mvme2600
>> 15)Motorola MVME2700 -- mvme2700
>>
>> SPARC BSPs
>> 1) SPARC Instruction Simulator (sis) -- obsoleted in 5.1.
>>
>> Please tell if I have add to link to them also.
>>
>> Thanks
>> Mritunjay
>>
>> On Sun, Mar 15, 2020 at 10:17 PM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Sun, Mar 15, 2020 at 11:12 AM Joel Sherrill  wrote:
>>>


 On Sat, Mar 14, 2020 at 10:55 PM Gedare Bloom  wrote:

> On Sat, Mar 14, 2020 at 2:05 PM Joel Sherrill  wrote:
> >
> > I put devel@ back on
> >
> > On Sat, Mar 14, 2020, 2:23 PM Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> I am very much willing to help with this thing. Being a bit new to
> the community, I just wanted to know that while deleting the wiki content
> on obsolete BSPs, do I need to report it before deleting and create a
> ticket for it or I can straightaway delete it?
> >
> >
> > I hate to start with use your judgement but...
> >
> > You could just ask on the list for deletion confirmation. My
> impression is that a deletion pass will be quick.
> >
> > For moving content to rtems-docs, that will be patches which need
> review. So post those.
> >
> > And I suspect some BSPs will have pages that are useless stubs. Ask
> about just deleting instead of converting them.
> >
> > Thanks for pitching in.
>
> I would prefer to have an analysis of the difference between what has
> been migrated already
> https://docs.rtems.org/branches/master/user/bsps/index.html versus
> what is in the wiki. If some content needs to move out of the wiki,
> then a patch to add it to the docs would be good, then we could
> discuss on the list whether or not to move that content or to delete
> it.  If content has been migrated or the migration discussion leads to
> a decision to delete, then we should remove that page. Removing a page
> requires an admin privilege, so I think a list of pages to be removed
> should be maintained somewhere like
> https://devel.rtems.org/wiki/TBR/BSP


 I have made a sweep to delete all text which has links to non-existent
 pages
 since those do not have to be reviewed.

 My next pass is to delete all pages for BSPs and ports that have been
 removed.
 That is a simple review process.

>>>
>>> I have completed this also.
>>>

 After that, what should be left is a list of pages which need manual
 review to
 extract/convert useful content to the Users Guide. This should be one
 patch
 and email per BSP/Wiki page.

>>>
>>> This should be ready to dig into. I suspect that a number of the BSP
>>> pages are
>>> marginal having been written by Google Code-In students. If they just
>>> have
>>> hardware descriptions from vendor pages and no howtos, what do we want
>>> to do?
>>>
>>>

 I also found

Re: [PATCH 1/1] eng: Add Python development guidelines

On Mon, Mar 16, 2020 at 9:11 AM Sebastian Huber
 wrote:
>
> ---
>  eng/management.rst   |   1 +
>  eng/python-devel.rst | 136 
> +++
>  2 files changed, 137 insertions(+)
>  create mode 100644 eng/python-devel.rst
>
> diff --git a/eng/management.rst b/eng/management.rst
> index 064559c..6eb4217 100644
> --- a/eng/management.rst
> +++ b/eng/management.rst
> @@ -16,5 +16,6 @@ Software Development Management
>  vc-users
>  vc-authors
>  coding
> +python-devel
>  change-management
>  issue-tracking
> diff --git a/eng/python-devel.rst b/eng/python-devel.rst
> new file mode 100644
> index 000..0347892
> --- /dev/null
> +++ b/eng/python-devel.rst
> @@ -0,0 +1,136 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +
> +.. _PythonDevelGuide:
> +
> +Python Development Guidelines
> +*
> +
> +Python is the main programming language for the RTEMS Tools.  The RTEMS Tools
> +run on the host computer of an RTEMS user or maintainer.  These guidelines
> +cover the Python language version, the source code formatting, use of static
> +analysis tools, type annotations, testing, code coverage, and documentation.
> +There are exceptions for existing code and third-party code.  It is 
> recommended
> +to read the
> +`PEP 8 - Style Guide for Python Code 
> `_
> +and the
> +`Google Python Style Guide 
> `_.
> +
> +Python Language Versions
> +
> +
> +Although the official end-of-life of Python 2.7 was on January 1, 2020, the
> +RTEMS Project still cares about Python 2.7 compatibility for some tools.  
> Every
> +tool provided by the RTEMS Project which an RTEMS user may use to develop
> +applications with RTEMS should be Python 2.7 compatible.  Examples are the
> +build system, the RTEMS Source Builder, and the RTEMS Tester.  The rationale 
> is
> +that there are still some maintained Linux distributions in the wild which 
> ship
> +only Python 2.7 by default.  An example is CentOS 7 which gets maintenance
> +updates until June 2024.  Everything an RTEMS maintainer uses should be 
> written
> +in Python 3.6.
> +
> +Python Code Formatting
> +==
> +
> +Good looking code is important.  Unfortunately, what looks good is a bit
> +subjective and varies from developer to developer.  Arguing about the code
> +format is not productive.  Code reviews should focus on more important 
> topics,
> +e.g. functionality, testability, and performance.  Fortunately, for Python
> +there are some good automatic code formatters available.  All new code
> +specifically developed for the RTEMS Tools should be piped through the
> +`yapf `_ Python code formatter before it is
> +committed or sent for review.  Use the default settings of the tool
s/sent/send

Rest of this looks good to me.

> +(`PEP 8 `_ coding style).
> +
> +You can disable the automatic formatting by the tool in a region starting 
> with
> +the ``#yapf: disable`` comment until the next ``# yapf: enable`` comment, 
> e.g.
> +
> +.. code-block:: python
> +
> +# yapf: disable
> +FOO = {
> +# ... some very large, complex data literal.
> +}
> +
> +BAR = [
> +# ... another large data literal.
> +]
> +# yapf: enable
> +
> +For a single literal, you can disable the formatting like this:
> +
> +.. code-block:: python
> +
> +BAZ = {
> +(1, 2, 3, 4),
> +(5, 6, 7, 8),
> +(9, 10, 11, 12),
> +}  # yapf: disable
> +
> +Static Analysis Tools
> +=
> +
> +Use the ``flake8`` and ``pylint`` static analysis tools for Python.  Do not
> +commit your code or sent it for review if the tools find some rule
> +violations.  Run the tools with the default configuration.  If you have
> +problems to silence the tools, then please ask for help on the 
> :r:list:`devel`.
> +Consult the tool documentation to silence false positives.
> +
> +Type Annotations
> +
> +
> +For Python 3.6 or later code use type annotations.  All public functions of
> +your modules should have `PEP 484 
> `_
> +type annotations.  Check for type issues with the
> +`mypy `_ static type checker.
> +
> +Testing
> +===
> +
> +Write unit tests for your code with the standard Python ``unittest`` and
> +``unittest.mock`` modules.  Use ``coverage run -m pytest`` to run the tests
> +with code coverage support.  If you modify existing code or contribute new 
> code
> +to a subproject which uses unit tests and the code coverage metric, then do 
> not
> +make the code coverage worse.
> +
> +Documentation
> +=
> +
> +Document your code using the
> +`PEP 257 - Docstring Conventions 
>

Re: What sanitizers preferred?

On Mon, Mar 16, 2020 at 10:55 AM Joel Sherrill  wrote:
>
>
>
> On Mon, Mar 16, 2020 at 11:05 AM Sebastian Huber 
>  wrote:
>>
>> On 15/03/2020 17:52, suyash singh wrote:
>>
>> Hello,
>> Out of
>> AddressSanitizer, ThreadSanitizer, MemorySanitizer, and DataFlowSanitizer.
>>
>> Are all of them useful as RTEMS-tools to integrate? Any other sanitizers 
>> suggested?
>>
>> Asking as part of my proposed gsoc project,
>> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
>>
>> I am not sure of these sanitizers can be used in RTEMS at all. We don't have 
>> virtual memory. Firstly, it would be necessary to check for each sanitizer 
>> if it uses virtual memory. If yes, then is this absolutely necessary or just 
>> convenient? Also the sanitizers are not available on all LLVM architectures. 
>> We have to evaluate if the architectures-specific adoptions can be used in 
>> RTEMS.
>
>
> +1
>
> Another area is the compiler stack protection techniques. I have no idea if 
> those are applicable to RTEMS but they would be useful if they can work.
>
> Ignoring other constraints from embedded systems, any possible technique to 
> use with RTEMS must be evaluated against the constraints imposed by having a 
> single address space, no VM, and single process model.
>
> You need to check if any of these will work before this project has a chance.
>
> I would be willing to entertain a project for an appropriate solution that is 
> limited to say ARM, x86, and RISC-V.
>
+1

UBSan is a good candidate.

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

Re: BSP Wiki Clean Up

The updated list of to be removed BSPs. Please check:
To be removed BSPs

ARM BSPs
1) Cogent CSB637 --csb637
2) Cogent Kit637_v6 -- kit637 v6
3) GamePark? Holdings GP2X -- gp2x


Motorola M68xxx and Coldfire BSPs
1) Generic MC68302 -- gen68302
2) ods68302

MIPS BSPs
1) Generic IDT 4600 -- p4000
2) Generic IDT 4650 -- p4650

PowerPC BSPs
1) BAE RAD750 3U and 6U -- rad750
2) DY-4 DMV177 -- dmv177?
3) Frasca ETHCOMM -- eth comm
4) Generic PPC405 -- gen405
5) IMD Helas 403 -- helas403?
6) Motorola MVME2400 -- mvme2400?
7) Motorola MVME2600 -- mvme2600
8) Motorola MVME2700 -- mvme2700

SPARC BSPs
1) SPARC Instruction Simulator (sis) -- obsoleted in 5.1.

On Mon, Mar 16, 2020 at 11:31 PM Mritunjay Sharma <
mritunjaysharma...@gmail.com> wrote:

> Okay, actually I looked only under
> https://git.rtems.org/rtems/tree/bsps/arm/
>  (and others
> like i386) and now that I know that I have to look deeper, will make a
> correction and send it here.
>
> On Mon, Mar 16, 2020 at 11:23 PM Joel Sherrill  wrote:
>
>>
>>
>> On Mon, Mar 16, 2020, 12:01 PM Mritunjay Sharma <
>> mritunjaysharma...@gmail.com> wrote:
>>
>>> Working on #3905 (Clean up BSP Wiki Pages), I have made a list of BSPs
>>> that are not now part of the source tree and recommending them to delete
>>> them and I would like to @rtems-de...@rtems.org  to
>>> have a look of it :
>>>
>>> To be removed BSPs
>>>
>>
>> I agree with some of these but wonder how you are making the present or
>> not determination. I think at least rtl22xx_t is present as a variant of
>> rtl22xx. Look in it's config directory.
>>
>> https://git.rtems.org/rtems/tree/bsps/arm/rtl22xx/config
>>
>>>
>>> ARM BSPs
>>> 1) Cogent CSB637 --csb637
>>> 2) Cogent Kit637_v6 -- kit637 v6
>>> 3) RTL22xx_t (Philips/NXP ARM7 in Thumb mode) -- rtl22xx t
>>> 4) GamePark? Holdings GP2X -- gp2x
>>> 5) NXP LPC17XX (pin compatible to LPC24XX with ARM Cortex-M3 core) ?
>>> 6) NXP LPC40XX (pin compatible to LPC24XX with ARM Cortex-M4 core) ?
>>> 7) Stellaris LaunchPad? XL -- LM4F120
>>> 8) STM32F105
>>>
>>> Motorola M68xxx and Coldfire BSPs
>>> 1) Generic MC68302 -- gen68302
>>> 2) Motorola MVME162LX -- mvme162lx
>>> 3) ods68302
>>>
>>> MIPS BSPs
>>> 1) Generic IDT 4600 -- p4000
>>> 2) Generic IDT 4650 -- p4650
>>>
>>> PowerPC BSPs
>>> 1) BAE RAD750 3U and 6U -- rad750
>>> 2) DY-4 DMV177 -- dmv177?
>>> 3) Frasca ETHCOMM -- eth comm
>>> 4) Freescale MPC5554 --Phycore mpc5554?
>>> 5) Freescale MPC5674FEVB -- MPC5674FEVB
>>> 6) Generic PPC405 -- gen405
>>> 7) IMD Helas 403 -- helas403?
>>> 8) Motorola MCP750 -- mcp750
>>> 9) Motorola/Phytec? Phycore MCP5554 Phycore mpc5554
>>> 10)Motorola MTX603e -- mtx603e
>>> 11)Motorola MVME2100 -- mvme2100
>>> 12)Motorola MVME2307 -- mvme2307
>>> 13)Motorola MVME2400 -- mvme2400?
>>> 14)Motorola MVME2600 -- mvme2600
>>> 15)Motorola MVME2700 -- mvme2700
>>>
>>> SPARC BSPs
>>> 1) SPARC Instruction Simulator (sis) -- obsoleted in 5.1.
>>>
>>> Please tell if I have add to link to them also.
>>>
>>> Thanks
>>> Mritunjay
>>>
>>> On Sun, Mar 15, 2020 at 10:17 PM Joel Sherrill  wrote:
>>>


 On Sun, Mar 15, 2020 at 11:12 AM Joel Sherrill  wrote:

>
>
> On Sat, Mar 14, 2020 at 10:55 PM Gedare Bloom 
> wrote:
>
>> On Sat, Mar 14, 2020 at 2:05 PM Joel Sherrill  wrote:
>> >
>> > I put devel@ back on
>> >
>> > On Sat, Mar 14, 2020, 2:23 PM Mritunjay Sharma <
>> mritunjaysharma...@gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I am very much willing to help with this thing. Being a bit new to
>> the community, I just wanted to know that while deleting the wiki content
>> on obsolete BSPs, do I need to report it before deleting and create a
>> ticket for it or I can straightaway delete it?
>> >
>> >
>> > I hate to start with use your judgement but...
>> >
>> > You could just ask on the list for deletion confirmation. My
>> impression is that a deletion pass will be quick.
>> >
>> > For moving content to rtems-docs, that will be patches which need
>> review. So post those.
>> >
>> > And I suspect some BSPs will have pages that are useless stubs. Ask
>> about just deleting instead of converting them.
>> >
>> > Thanks for pitching in.
>>
>> I would prefer to have an analysis of the difference between what has
>> been migrated already
>> https://docs.rtems.org/branches/master/user/bsps/index.html versus
>> what is in the wiki. If some content needs to move out of the wiki,
>> then a patch to add it to the docs would be good, then we could
>> discuss on the list whether or not to move that content or to delete
>> it.  If content has been migrated or the migration discussion leads to
>> a decision to delete, then we should remove that page. Removing a page
>> requires an admin privilege, so I think a list of pages to be removed
>> should be maintained somewh

RTEMS Docs: Adding GSoC Getting Started Instructions

2020-03-16 Thread Niteesh G. S.

I am interested in taking up #3907 .
I'll mostly be copying and updating the contents from the old wiki site.

I have the following plan in mind. I'll start working on it if you are
happy with it.

Add a new gsoc section in the user manual
 with contents
from https://devel.rtems.org/wiki/GSoC (index.rst)
Under this section, we'll have the following
1) GSoC getting started instructions (
https://devel.rtems.org/wiki/GSoC/GettingStarted)
2) Mentors list (https://devel.rtems.org/wiki/GSoC/Mentors)
3) Previous year GSoC information under separate pages.

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

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

On 2020-03-16 09:34 +0100, Sebastian Huber wrote:
> On 16/03/2020 00:57, Amar Takhar wrote:
> 
> On 2020-03-16 09:20 +1100, Chris Johns wrote:
> 
> Is pytest installed by default?
> 
> No.  It's a separate package the Python has 'unittest' which is shipped by
> default.  For our usage pyttest is more flexible and will create concise 
> code
> that is easy to contribute to.  The biggest reason is that it's more 
> suited to
> our use.
> 
> From the website pytest requires Python 3.5+ and PyPy 3. This is not a problem
> for me in general. We still would like to be compatible to Python 2.7, how can
> we run the tests in such an environment with pytest?

It works on pytest using any Python 2.7+:

verm@peach# pytest-2.7 --version
This is pytest version 4.5.0, imported from 
/usr/local/lib/python2.7/site-packages/pytest.pyc


verm@peach# pytest --version
This is pytest version 4.5.0, imported from 
/usr/local/lib/python3.7/site-packages/pytest.py


Python 2.x support is not going to go away for a while yet.


> What is the relationship to the standard Python unittest module? Do you want 
> to
> write the tests with unittest and run them with pytest?

No, pytest uses an entirely different methodology.  This gives an OK overview 
of 
the differences between the two:

  https://www.slant.co/versus/9148/9149/~unittest_vs_pytest 


It's more suited to our requirements and the ability to do group fixtures is 
fantastic for testing cross platform support among other scenarios.


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

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

I should have also added some of my own reasons why pytest is better for 
writing 
tests in Python:

  - Fantastic exception handling makes it far easier to debug test and code.  
PDB works seamlessly.
  - Far less overhead in creating initial tests.
  - Trivial fixture support
  - Paramaterised tests -- this is incredibly essential / useful.

Another feature that's not often mentioned is pytest discovers tests all on its 
own.  You can put a test anywhere labled test_*.py and it will work.  You can 
run pytest anywhere in the source as well.

The above are starkly different from unittest where these features don't exist 
or are difficult / have a large overhead to implement.


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

Re: [PATCH 1/1] eng: Add Python development guidelines

On Mon, Mar 16, 2020 at 9:11 AM Sebastian Huber
 wrote:
>
> ---
>  eng/management.rst   |   1 +
>  eng/python-devel.rst | 136 
> +++
>  2 files changed, 137 insertions(+)
>  create mode 100644 eng/python-devel.rst
>
> diff --git a/eng/management.rst b/eng/management.rst
> index 064559c..6eb4217 100644
> --- a/eng/management.rst
> +++ b/eng/management.rst
> @@ -16,5 +16,6 @@ Software Development Management
>  vc-users
>  vc-authors
>  coding
> +python-devel
>  change-management
>  issue-tracking
> diff --git a/eng/python-devel.rst b/eng/python-devel.rst
> new file mode 100644
> index 000..0347892
> --- /dev/null
> +++ b/eng/python-devel.rst
> @@ -0,0 +1,136 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +
> +.. _PythonDevelGuide:
> +
> +Python Development Guidelines
> +*
> +
> +Python is the main programming language for the RTEMS Tools.  The RTEMS Tools
> +run on the host computer of an RTEMS user or maintainer.  These guidelines
> +cover the Python language version, the source code formatting, use of static
> +analysis tools, type annotations, testing, code coverage, and documentation.
> +There are exceptions for existing code and third-party code.  It is 
> recommended
> +to read the
> +`PEP 8 - Style Guide for Python Code 
> `_
> +and the
> +`Google Python Style Guide 
> `_.
> +
> +Python Language Versions
> +
> +
> +Although the official end-of-life of Python 2.7 was on January 1, 2020, the
> +RTEMS Project still cares about Python 2.7 compatibility for some tools.  
> Every
> +tool provided by the RTEMS Project which an RTEMS user may use to develop
> +applications with RTEMS should be Python 2.7 compatible.  Examples are the
> +build system, the RTEMS Source Builder, and the RTEMS Tester.  The rationale 
> is
> +that there are still some maintained Linux distributions in the wild which 
> ship
> +only Python 2.7 by default.  An example is CentOS 7 which gets maintenance
> +updates until June 2024.  Everything an RTEMS maintainer uses should be 
> written
> +in Python 3.6.
> +
> +Python Code Formatting
> +==
> +
> +Good looking code is important.  Unfortunately, what looks good is a bit
> +subjective and varies from developer to developer.  Arguing about the code
> +format is not productive.  Code reviews should focus on more important 
> topics,
> +e.g. functionality, testability, and performance.  Fortunately, for Python
> +there are some good automatic code formatters available.  All new code
> +specifically developed for the RTEMS Tools should be piped through the
> +`yapf `_ Python code formatter before it is
> +committed or sent for review.  Use the default settings of the tool
> +(`PEP 8 `_ coding style).
> +
> +You can disable the automatic formatting by the tool in a region starting 
> with
> +the ``#yapf: disable`` comment until the next ``# yapf: enable`` comment, 
> e.g.
> +
> +.. code-block:: python
> +
> +# yapf: disable
> +FOO = {
> +# ... some very large, complex data literal.
> +}
> +
> +BAR = [
> +# ... another large data literal.
> +]
> +# yapf: enable
> +
> +For a single literal, you can disable the formatting like this:
> +
> +.. code-block:: python
> +
> +BAZ = {
> +(1, 2, 3, 4),
> +(5, 6, 7, 8),
> +(9, 10, 11, 12),
> +}  # yapf: disable
> +
> +Static Analysis Tools
> +=
> +
> +Use the ``flake8`` and ``pylint`` static analysis tools for Python.  Do not
> +commit your code or sent it for review if the tools find some rule

This is the "sent" that should be "send" :)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.


On 16/03/2020 20:26, Amar Takhar wrote:


I should have also added some of my own reasons why pytest is better for writing
tests in Python:

   - Fantastic exception handling makes it far easier to debug test and code.
 PDB works seamlessly.
   - Far less overhead in creating initial tests.
   - Trivial fixture support
   - Paramaterised tests -- this is incredibly essential / useful.

Another feature that's not often mentioned is pytest discovers tests all on its
own.  You can put a test anywhere labled test_*.py and it will work.  You can
run pytest anywhere in the source as well.

The above are starkly different from unittest where these features don't exist
or are difficult / have a large overhead to implement.


Ok, I guess I have to adjust my draft of the Python guidelines:

https://lists.rtems.org/pipermail/devel/2020-March/058289.html


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

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.


On 16/03/2020 21:01, Sebastian Huber wrote:


On 16/03/2020 20:26, Amar Takhar wrote:

I should have also added some of my own reasons why pytest is better 
for writing

tests in Python:

   - Fantastic exception handling makes it far easier to debug test 
and code.

 PDB works seamlessly.
   - Far less overhead in creating initial tests.
   - Trivial fixture support
   - Paramaterised tests -- this is incredibly essential / useful.

Another feature that's not often mentioned is pytest discovers tests 
all on its
own.  You can put a test anywhere labled test_*.py and it will work.  
You can

run pytest anywhere in the source as well.

The above are starkly different from unittest where these features 
don't exist

or are difficult / have a large overhead to implement.


Ok, I guess I have to adjust my draft of the Python guidelines:

https://lists.rtems.org/pipermail/devel/2020-March/058289.html


I converted an example test from unittest to pytest:

https://git.rtems.org/sebh/rtems-qual.git/commit/?id=823c74c5d68a5b0913eba2bd9202897cb883dcef

Using plain assert statements is quite nice. Also the "tmpdir" fixture 
is really nice.


Chris, what do you think about using pytest in favour of the standard 
Python unitttest?


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

Re: [PATCH] rtems: Add support for building with Clang/LLVM

Hi Chris,

On Sun, 15 Mar 2020 at 21:09, Chris Johns  wrote:

> Hi Hesham,
>
> This is a great addition to rtems_waf, some comments below.
>
> On 16/3/20 2:56 am, Hesham Almatary wrote:
> > ---
> >  rtems.py | 85 +---
> >  1 file changed, 62 insertions(+), 23 deletions(-)
> >
> > diff --git a/rtems.py b/rtems.py
> > index ffb386f..f1ef4de 100644
> > --- a/rtems.py
> > +++ b/rtems.py
> > @@ -1,4 +1,5 @@
> >
> > +# Copyright 2020 Hesham Almatary
> >  # Copyright 2012-2016 Chris Johns (chr...@rtems.org)
> >  #
> >  # Redistribution and use in source and binary forms, with or without
> > @@ -63,6 +64,10 @@ def options(opt):
> > default = 'all',
> > dest = 'rtems_bsps',
> > help = 'List of BSPs to build.')
> > +opt.add_option('--rtems-compiler',
> > +   default = 'gcc',
> > +   dest = 'rtems_compiler',
> > +   help = 'RTEMS compiler to use available options are
> clang and gcc (defaults to gcc).')
> >  opt.add_option('--show-commands',
> > action = 'store_true',
> > default = False,
> > @@ -104,15 +109,17 @@ def init(ctx, filters = None, version = None,
> long_commands = False, bsp_init =
> >  #
> >  # Check the tools, architectures and bsps.
> >  #
> > -rtems_version, rtems_path, rtems_tools, archs, arch_bsps = \
> > +rtems_compiler, rtems_version, rtems_path, rtems_tools, archs,
> arch_bsps = \
> >  check_options(ctx,
> >env.options['prefix'],
> > +  env.options['rtems_compiler'],
> >env.options['rtems_tools'],
> >env.options['rtems_path'],
> >env.options['rtems_version'],
> >env.options['rtems_archs'],
> >env.options['rtems_bsps'])
> >
> > +print("RTEMS Compiler is " + rtems_compiler)
>
> Please use `conf.msg()`. See
> https://git.rtems.org/rtems_waf/tree/rtems.py#n248
>
> >  #
> >  # Update the contexts for all the bsps.
> >  #
> > @@ -176,9 +183,10 @@ def configure(conf, bsp_configure = None):
> >  else:
> >  long_commands = 'no'
> >
> > -rtems_version, rtems_path, rtems_tools, archs, arch_bsps = \
> > +rtems_compiler, rtems_version, rtems_path, rtems_tools, archs,
> arch_bsps = \
> >  check_options(conf,
> >conf.options.prefix,
> > +  conf.options.rtems_compiler,
> >conf.options.rtems_tools,
> >conf.options.rtems_path,
> >conf.options.rtems_version,
> > @@ -222,13 +230,19 @@ def configure(conf, bsp_configure = None):
> >  conf.env.RTEMS_ARCH_RTEMS = arch
> >  conf.env.RTEMS_BSP = bsp
> >
> > -tools = _find_tools(conf, arch, rtems_tools, tools)
> > +tools = _find_tools(conf, arch, rtems_compiler, rtems_tools,
> tools)
> >  for t in tools[arch]:
> >  conf.env[t] = tools[arch][t]
> >
> > -conf.load('gcc')
> > -conf.load('g++')
> > -conf.load('gas')
> > +if rtems_compiler == 'gcc':
> > +conf.load('gcc')
> > +conf.load('g++')
> > +conf.load('gas')
> > +elif rtems_compiler == 'clang':
> > +conf.load('clang')
> > +conf.load('clang++')
> > +else:
> > +conf.fatal('Unknown RTEMS compiler: ' + rtems_compiler)
> >
> >  #
> >  # Get the version of the tools being used.
> > @@ -388,7 +402,7 @@ def tweaks(conf, arch_bsp):
> >  if '-ffunction-sections' in conf.env.CFLAGS:
> >conf.env.LINKFLAGS += ['-Wl,--gc-sections']
> >
> > -def check_options(ctx, prefix, rtems_tools, rtems_path, rtems_version,
> rtems_archs, rtems_bsps):
> > +def check_options(ctx, prefix, rtems_compiler, rtems_tools, rtems_path,
> rtems_version, rtems_archs, rtems_bsps):
> >  #
> >  # Set defaults
> >  #
> > @@ -406,6 +420,12 @@ def check_options(ctx, prefix, rtems_tools,
> rtems_path, rtems_version, rtems_arc
> >  if rtems_tools is None:
> >  rtems_tools = rtems_path
> >
> > +#
> > +# Check the compiler option is valid.
> > +#
> > +if rtems_compiler not in ['gcc', 'clang']:
>
> Key in compiler dict? See below.
>
> > +ctx.fatal('Valid RTEMS compilers are gcc or clang')
> > +
> >  #
> >  # Check the paths are valid.
> >  #
> > @@ -476,7 +496,7 @@ def check_options(ctx, prefix, rtems_tools,
> rtems_path, rtems_version, rtems_arc
> >  #
> >  arch_bsps = filter(ctx, 'bsps', arch_bsps)
> >
> > -return rtems_version, rtems_path, tools, archs, arch_bsps
> > +return rtems_compiler, rtems_version, rtems_path, tools, archs,
> arch_bsps
> >
> >  def check_env(ctx, var):
> >

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

On 2020-03-16 21:21 +0100, Sebastian Huber wrote:
> >
> > https://lists.rtems.org/pipermail/devel/2020-March/058289.html
> 
> I converted an example test from unittest to pytest:

There's no reason to use classes here you should use simple functions.

Classes are only useful if you want to maintain a state using a setup or 
teardown.  Look at test_macro.py for an example of this.

You should be using a setup similar to test_host.py which is just simple 
functions it's less work and easier to read.

This is one of the best features of pytest. :)

BTW examples are in my rtemstoolkit patch.

> https://git.rtems.org/sebh/rtems-qual.git/commit/?id=823c74c5d68a5b0913eba2bd9202897cb883dcef
> 
> Using plain assert statements is quite nice. Also the "tmpdir" fixture 
> is really nice.

Yes, pytest  has quite a few fixtures that make life extremely easy.  Also just 
using asserts really saves a lot of time and is easier to develop with.  No 
need 
to remember dozens of unique functions.

Amar.

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

Re: [PATCH rtems_littlevgl 1/2] waf: Remove unnecessary code.

2020-03-16 Thread Vijay Kumar Banerjee

Hi!

On Wed, Mar 11, 2020 at 7:59 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> ---
>  lvgl.py | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/lvgl.py b/lvgl.py
> index 5452ed0..d6584f7 100644
> --- a/lvgl.py
> +++ b/lvgl.py
> @@ -77,12 +77,6 @@ def build(bld):
>  if source_dir not in include_paths:
>  include_paths.append(source_dir)
>
> -bld.objects(target = objects,
> -features = 'c',
> -cflags = '-O2',
> -includes = includes,
> -source = source)
> -
>  bld.stlib(target = 'lvgl',
>features = 'c',
>includes = includes,
>

I think `use=objects` isn't required either in the next line. This builds
fine.

Best regards,
Vijay

> --
> 2.16.4
>
> ___
> 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: RTEMS Docs: Adding GSoC Getting Started Instructions

On Mon, Mar 16, 2020 at 12:56 PM Niteesh G. S.  wrote:
>
> I am interested in taking up #3907. I'll mostly be copying and updating the 
> contents from the old wiki site.
>
> I have the following plan in mind. I'll start working on it if you are happy 
> with it.
>
> Add a new gsoc section in the user manual with contents
> from https://devel.rtems.org/wiki/GSoC (index.rst)
> Under this section, we'll have the following
> 1) GSoC getting started instructions 
> (https://devel.rtems.org/wiki/GSoC/GettingStarted)
> 2) Mentors list (https://devel.rtems.org/wiki/GSoC/Mentors)
> 3) Previous year GSoC information under separate pages.
>

I think it should be separated somewhat. This GSoC stuff is not right
to put in the User Manual, except for the Getting Started guide. There
is the full "Quick Start"
https://docs.rtems.org/branches/master/user/start/index.html#  that
may be too complicated for new users, but that area of the user manual
is probably where the simplified "GSoC" guide should live.

That said, I'd be OK with introducing a new "Learning with RTEMS"
Manual that covers both SoC, GCI, and maybe can be expanded over time.
As a kind of "beginner friendly / student-oriented" guide?

> Niteesh
> ___
> 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: BSP Wiki Clean Up

2020-03-16 Thread Joel Sherrill

On Mon, Mar 16, 2020 at 1:35 PM Mritunjay Sharma <
mritunjaysharma...@gmail.com> wrote:

> The updated list of to be removed BSPs. Please check:
>

One of us should have mentioned that there is a script at the top of the
RTEMS source tree
named "rtems-bsps which prints a report with all BSPs. Makes this a bit
easier.


> To be removed BSPs
>
> ARM BSPs
> 1) Cogent CSB637 --csb637
> 2) Cogent Kit637_v6 -- kit637 v6
>

These two are variants of csb337


> 3) GamePark? Holdings GP2X -- gp2x
>

I concur with gp32. I deleted it.



>
>
> Motorola M68xxx and Coldfire BSPs
> 1) Generic MC68302 -- gen68302
>

I concur and deleted this.


> 2) ods68302
>

I concur and deleted this.

>
> MIPS BSPs
> 1) Generic IDT 4600 -- p4000
> 2) Generic IDT 4650 -- p4650
>

I concur and deleted these.

>
> PowerPC BSPs
> 1) BAE RAD750 3U and 6U -- rad750
>

Unfortunately, we will have to discuss this. This is a restricted
distribution
BSP that is available from NASA. This is used on a few missions.


> 2) DY-4 DMV177 -- dmv177?
> 3) Frasca ETHCOMM -- eth comm
> 4) Generic PPC405 -- gen405
> 5) IMD Helas 403 -- helas403?
>

These I concur and addressed.


> 6) Motorola MVME2400 -- mvme2400?
> 7) Motorola MVME2600 -- mvme2600
> 8) Motorola MVME2700 -- mvme2700
>

These are odd. They are supported by the motorola_powerpc BSP. One variant
of it supports all the mvme2xxx boards, mtx603e, and mcp750.

>
> SPARC BSPs
> 1) SPARC Instruction Simulator (sis) -- obsoleted in 5.1.
>

I thought there was more content in that page. But it is low value. I
deleted it.

I also deleted the leon2 page as low value.

On your next pass, look for BSP pages which look like very minimal
descriptions
of the board hardware with no useful information about how to use the board
with
RTEMS. :)

--joel


>
> On Mon, Mar 16, 2020 at 11:31 PM Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
>
>> Okay, actually I looked only under
>> https://git.rtems.org/rtems/tree/bsps/arm/
>>  (and others
>> like i386) and now that I know that I have to look deeper, will make a
>> correction and send it here.
>>
>> On Mon, Mar 16, 2020 at 11:23 PM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, Mar 16, 2020, 12:01 PM Mritunjay Sharma <
>>> mritunjaysharma...@gmail.com> wrote:
>>>
 Working on #3905 (Clean up BSP Wiki Pages), I have made a list of BSPs
 that are not now part of the source tree and recommending them to delete
 them and I would like to @rtems-de...@rtems.org  to
 have a look of it :

 To be removed BSPs

>>>
>>> I agree with some of these but wonder how you are making the present or
>>> not determination. I think at least rtl22xx_t is present as a variant of
>>> rtl22xx. Look in it's config directory.
>>>
>>> https://git.rtems.org/rtems/tree/bsps/arm/rtl22xx/config
>>>

 ARM BSPs
 1) Cogent CSB637 --csb637
 2) Cogent Kit637_v6 -- kit637 v6
 3) RTL22xx_t (Philips/NXP ARM7 in Thumb mode) -- rtl22xx t
 4) GamePark? Holdings GP2X -- gp2x
 5) NXP LPC17XX (pin compatible to LPC24XX with ARM Cortex-M3 core) ?
 6) NXP LPC40XX (pin compatible to LPC24XX with ARM Cortex-M4 core) ?
 7) Stellaris LaunchPad? XL -- LM4F120
 8) STM32F105

 Motorola M68xxx and Coldfire BSPs
 1) Generic MC68302 -- gen68302
 2) Motorola MVME162LX -- mvme162lx
 3) ods68302

 MIPS BSPs
 1) Generic IDT 4600 -- p4000
 2) Generic IDT 4650 -- p4650

 PowerPC BSPs
 1) BAE RAD750 3U and 6U -- rad750
 2) DY-4 DMV177 -- dmv177?
 3) Frasca ETHCOMM -- eth comm
 4) Freescale MPC5554 --Phycore mpc5554?
 5) Freescale MPC5674FEVB -- MPC5674FEVB
 6) Generic PPC405 -- gen405
 7) IMD Helas 403 -- helas403?
 8) Motorola MCP750 -- mcp750
 9) Motorola/Phytec? Phycore MCP5554 Phycore mpc5554
 10)Motorola MTX603e -- mtx603e
 11)Motorola MVME2100 -- mvme2100
 12)Motorola MVME2307 -- mvme2307
 13)Motorola MVME2400 -- mvme2400?
 14)Motorola MVME2600 -- mvme2600
 15)Motorola MVME2700 -- mvme2700

 SPARC BSPs
 1) SPARC Instruction Simulator (sis) -- obsoleted in 5.1.

 Please tell if I have add to link to them also.

 Thanks
 Mritunjay

 On Sun, Mar 15, 2020 at 10:17 PM Joel Sherrill  wrote:

>
>
> On Sun, Mar 15, 2020 at 11:12 AM Joel Sherrill  wrote:
>
>>
>>
>> On Sat, Mar 14, 2020 at 10:55 PM Gedare Bloom 
>> wrote:
>>
>>> On Sat, Mar 14, 2020 at 2:05 PM Joel Sherrill 
>>> wrote:
>>> >
>>> > I put devel@ back on
>>> >
>>> > On Sat, Mar 14, 2020, 2:23 PM Mritunjay Sharma <
>>> mritunjaysharma...@gmail.com> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> I am very much willing to help with this thing. Being a bit new
>>> to the community, I just wanted to know that while deleting the wiki
>>> content on obsolete BSPs, do I need to report it before deleting and 
>>> cr

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

2020-03-16 Thread Chris Johns

On 17/3/20 7:21 am, Sebastian Huber wrote:
> Chris, what do you think about using pytest in favour of the standard Python
> unitttest?

I am fine with pytest. Testing is a development feature and so we can have a
different criteria for the needed dependencies.

Chris

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

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.

On 2020-03-17 10:55 +1100, Chris Johns wrote:
> On 17/3/20 7:21 am, Sebastian Huber wrote:
> > Chris, what do you think about using pytest in favour of the standard Python
> > unitttest?
> 
> I am fine with pytest. Testing is a development feature and so we can have a
> different criteria for the needed dependencies.

If we're choosing pytest I'd like to see explicit documentation of what pattern 
to use for which situations.

It's really easy to fall into traditional patterns for non Python languages 
which means we lose advantages of going to pytest.

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

Re: [PATCH] rtems: Add support for building with Clang/LLVM

2020-03-16 Thread Chris Johns

On 17/3/20 7:30 am, Hesham Almatary wrote:
> Hi Chris,
> 
> On Sun, 15 Mar 2020 at 21:09, Chris Johns  > wrote:
> 
> Hi Hesham,
> 
> This is a great addition to rtems_waf, some comments below.
> 
> On 16/3/20 2:56 am, Hesham Almatary wrote:
> > ---
> >  rtems.py | 85 +---
> >  1 file changed, 62 insertions(+), 23 deletions(-)
> >
> > diff --git a/rtems.py b/rtems.py
> > index ffb386f..f1ef4de 100644
> > --- a/rtems.py
> > +++ b/rtems.py
> > @@ -1,4 +1,5 @@
> > 
> > +# Copyright 2020 Hesham Almatary
> >  # Copyright 2012-2016 Chris Johns (chr...@rtems.org
> )
> >  #
> >  # Redistribution and use in source and binary forms, with or without
> > @@ -63,6 +64,10 @@ def options(opt):
> >                     default = 'all',
> >                     dest = 'rtems_bsps',
> >                     help = 'List of BSPs to build.')
> > +    opt.add_option('--rtems-compiler',
> > +                   default = 'gcc',
> > +                   dest = 'rtems_compiler',
> > +                   help = 'RTEMS compiler to use available options are
> clang and gcc (defaults to gcc).')
> >      opt.add_option('--show-commands',
> >                     action = 'store_true',
> >                     default = False,
> > @@ -104,15 +109,17 @@ def init(ctx, filters = None, version = None,
> long_commands = False, bsp_init =
> >          #
> >          # Check the tools, architectures and bsps.
> >          #
> > -        rtems_version, rtems_path, rtems_tools, archs, arch_bsps = \
> > +        rtems_compiler, rtems_version, rtems_path, rtems_tools, archs,
> arch_bsps = \
> >              check_options(ctx,
> >                            env.options['prefix'],
> > +                          env.options['rtems_compiler'],
> >                            env.options['rtems_tools'],
> >                            env.options['rtems_path'],
> >                            env.options['rtems_version'],
> >                            env.options['rtems_archs'],
> >                            env.options['rtems_bsps'])
> > 
> > +        print("RTEMS Compiler is " + rtems_compiler)
> 
> Please use `conf.msg()`. See 
> https://git.rtems.org/rtems_waf/tree/rtems.py#n248
> 
> >          #
> >          # Update the contexts for all the bsps.
> >          #
> > @@ -176,9 +183,10 @@ def configure(conf, bsp_configure = None):
> >      else:
> >          long_commands = 'no'
> > 
> > -    rtems_version, rtems_path, rtems_tools, archs, arch_bsps = \
> > +    rtems_compiler, rtems_version, rtems_path, rtems_tools, archs,
> arch_bsps = \
> >          check_options(conf,
> >                        conf.options.prefix,
> > +                      conf.options.rtems_compiler,
> >                        conf.options.rtems_tools,
> >                        conf.options.rtems_path,
> >                        conf.options.rtems_version,
> > @@ -222,13 +230,19 @@ def configure(conf, bsp_configure = None):
> >          conf.env.RTEMS_ARCH_RTEMS = arch
> >          conf.env.RTEMS_BSP = bsp
> > 
> > -        tools = _find_tools(conf, arch, rtems_tools, tools)
> > +        tools = _find_tools(conf, arch, rtems_compiler, rtems_tools, 
> tools)
> >          for t in tools[arch]:
> >              conf.env[t] = tools[arch][t]
> > 
> > -        conf.load('gcc')
> > -        conf.load('g++')
> > -        conf.load('gas')
> > +        if rtems_compiler == 'gcc':
> > +            conf.load('gcc')
> > +            conf.load('g++')
> > +            conf.load('gas')
> > +        elif rtems_compiler == 'clang':
> > +            conf.load('clang')
> > +            conf.load('clang++')
> > +        else:
> > +            conf.fatal('Unknown RTEMS compiler: ' + rtems_compiler)
> > 
> >          #
> >          # Get the version of the tools being used.
> > @@ -388,7 +402,7 @@ def tweaks(conf, arch_bsp):
> >      if '-ffunction-sections' in conf.env.CFLAGS:
> >        conf.env.LINKFLAGS += ['-Wl,--gc-sections']
> > 
> > -def check_options(ctx, prefix, rtems_tools, rtems_path, rtems_version,
> rtems_archs, rtems_bsps):
> > +def check_options(ctx, prefix, rtems_compiler, rtems_tools, rtems_path,
> rtems_version, rtems_archs, rtems_bsps):
> >      #
> >      # Set defaults
> >      #
> > @@ -406,6 +420,12 @@ def check_options(ctx, prefix, rtems_tools,
> rtems_path, rtems_version, rtems_arc
> >      if rtems_tools is None:
> >          rtems_tools = rtems_path
> > 
> > +    #
> > +    # Check the compiler option is valid.
> > +    #
> > +    if rtems_compiler not

Is there a way to modify PHY register in libBSD?

2020-03-16 Thread jameszxj

Hi,
    I used ukphy driver in project, now I want to tune some PHY 
registers. Is there a way to modify PHY registers like *phy_fixup in Linux? Or 
other ways?
I think that modify the driver source directly is not a good way.___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems: Add support for building with Clang/LLVM


On 17/03/2020 03:09, Chris Johns wrote:


That follows the rtems/waf (new build system) convention by default.

Do you mean the work Sebastian is doing? If you are, it currently might but that
work is not finished and it may change, partially to make it consistent with
this package. This has not been discussed.


We discussed the way to find tools during the waf configure phase. See 
bottom of this email:


https://lists.rtems.org/pipermail/devel/2019-December/056291.html

Maybe I misinterpreted your steps 1. to 3. In the waf configure output 
you see the absolute paths of the tools. So you can check if they are 
the right ones.


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

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.


On 16/03/2020 21:49, Amar Takhar wrote:


On 2020-03-16 21:21 +0100, Sebastian Huber wrote:

https://lists.rtems.org/pipermail/devel/2020-March/058289.html

I converted an example test from unittest to pytest:

There's no reason to use classes here you should use simple functions.

Classes are only useful if you want to maintain a state using a setup or
teardown.  Look at test_macro.py for an example of this.

So you would not use test classes to group tests for a specific class?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.


On 16/03/2020 20:26, Amar Takhar wrote:


I should have also added some of my own reasons why pytest is better for writing
tests in Python:

   - Fantastic exception handling makes it far easier to debug test and code.
 PDB works seamlessly.
   - Far less overhead in creating initial tests.
   - Trivial fixture support
   - Paramaterised tests -- this is incredibly essential / useful.

Another feature that's not often mentioned is pytest discovers tests all on its
own.  You can put a test anywhere labled test_*.py and it will work.  You can
run pytest anywhere in the source as well.

The above are starkly different from unittest where these features don't exist
or are difficult / have a large overhead to implement.

What is your recommendation with respect to the use of unittest.mock?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] Add a message to run 'pytest' to run rest of test suite.