Wish List

[[e-mail] [nuttx]]

I am always interested in adding new capabilities to NuttX and NSH. I think it would be a good idea to create a "Wish List" where anyone could post new features that they would like to see the OS.


Is that something that people would use? Would you add things to such a list if it existed?


And how would be best to implement such a list. The Wiki would be an idea except that it has been under such fierce attacks that it is now to protected for anyone to use. We could also create a Bitbucket "issue" to list and talk about new features. There is a bitbucket Wiki, but it also has strong protections.


Greg

[[e-mail] [nuttx]]

I second the idea and i'd be happy to contribute.

Maybe some kind of forum might help for keeping log of written discussions like in the yahoo group?
Users would need login etc so some security issues might disappear. It would help to share files etc too.
Some "pre-made" forums are already quite secured. Just have to choose =)

Regards,
JK

[[e-mail] [nuttx]]

What would be ideal would be a NuttX development team and formal bug/feature tracking system. It would be nice to keep track of bugs and features in a data base, prioritize them, assign them to people, and monitor the progress toward their resolution.


But there is no development team. There is only me. Since there is only me, there is no point to being formal at all. I will basically prioritize things based on if they are interesting to me and resolve them if and when I want to.


I see the main downside of that is that I avoid the larger more extensive changes that are too much for a single person to take on lightly.


For example, I was looking at fstat() this morning. fstat() is one of a few missing file system interfaces. fstat() is really just like stat() but stat() takes a path string as an argument and fstate() takes a file descriptor. I think I have a pretty simple way to implement fstat(), but it requires many files to change. I count nine file system implementations that would have to change in some way. That is more that I want to undertake so fstat() stays on the shelf.


But if there were a team of people who could spare some part time effort to be part of a development team, then there are many things like this that we could do.


Greg

[[e-mail] [nuttx]]

If i could take care of some task to do, i'd be happy to help too =)
I can devote some of my time to it too.

Maybe some custom small web application to manage
-Todo lists and peoples around each tasks
- Bugtracker
- Doc
could be an interesting add . That's something i could shape within a month or two as first task if any need :)

My pleasure to help,
Jerome

[[e-mail] [nuttx]]

Yes, something like that would be welcome. Please feel free to jump in.


Greg



---In ***@yahoogroups.com, <***@open-modular.com> wrote :

If i could take care of some task to do, i'd be happy to help too =)
I can devote some of my time to it too.

Maybe some custom small web application to manage
-Todo lists and peoples around each tasks
- Bugtracker
- Doc
could be an interesting add . That's something i could shape within a month or two as first task if any need :)

My pleasure to help,
Jerome

[[e-mail] [nuttx]]

Post by ***@open-modular.com [nuttx]
Maybe some custom small web application to manage

I suppose one ought to consider a standard open source bug tracker. Maybe

Redmine: http://www.redmine.org/
Bugzilla: https://www.bugzilla.org/
Trac: http://trac.edgewall.org/browser
Mantis: https://www.mantisbt.org/

I have zero web skills but perhaps something like one of those could be hosted on nuttx.org? I am not fully sure of the advantage over say, Bitbucket issues.

Greg

[Gregory Nutt [e-mail] [nuttx]]

Atlassian Jira might be the best integrated solution:
https://www.atlassian.com/software/jira

I don't know very much about it. It is not free but neither is it
expensive.

Post by ***@open-modular.com [nuttx]
Maybe some custom small web application to manage

I suppose one ought to consider a standard open source bug tracker. Maybe
Redmine: http://www.redmine.org/
Bugzilla: https://www.bugzilla.org/
Trac: http://trac.edgewall.org/browser
Mantis: https://www.mantisbt.org/
I have zero web skills but perhaps something like one of those could
be hosted on nuttx.org? I am not fully sure of the advantage over say,
Bitbucket issues.
Greg

[Janne Rosberg [e-mail] [nuttx]]

Hi.

Jira could be "easy" solution as source tree is already in bitbucket.
And you could also get free open source license: https://www.atlassian.com/software/views/open-source-license-request


--Janne

Post by Gregory Nutt ***@yahoo.com [nuttx]
https://www.atlassian.com/software/jira
I don't know very much about it. It is not free but neither is it
expensive.

Post by ***@yahoo.com [nuttx]

Post by ***@open-modular.com [nuttx]
Maybe some custom small web application to manage

I suppose one ought to consider a standard open source bug tracker.

Maybe

Post by ***@yahoo.com [nuttx]
Redmine: http://www.redmine.org/
Bugzilla: https://www.bugzilla.org/
Trac: http://trac.edgewall.org/browser
Mantis: https://www.mantisbt.org/
I have zero web skills but perhaps something like one of those could
be hosted on nuttx.org? I am not fully sure of the advantage over

say,

Post by ***@yahoo.com [nuttx]
Bitbucket issues.
Greg

[[e-mail] [nuttx]]

Hi again,
After Reviewing Atlassian Jira / Open Source Bug Trackers and considering that for the moment there will be not that much committers , moreover regarding the fact that NuttX Source is already hosted on Bitbucket , a custom Web Application might be an overkill for the moment.
I totally approve about Jira by my side =)
regards,
Jerome

[[e-mail] [nuttx]]

We would need to separate how the cost sharing would work. What if people lose interest? What if there is not a critical mass to get things off the ground?

Bitbucket, in general, is free if you have fewer than 5 people on the "team".

Not only is Jira not free, but it is limited to a small number of users. $10/month for up ten users with Jira: https://www.atlassian.com/software/jira/pricing?tab=cloud

I really like the idea of the Bitbucket/Jira integration. But I think that is restrictive since you would like anyone to contribute bugs or enhancement requests.

I have not followed through with https://www.atlassian.com/software/views/open-source-license-request yet.

And I think that would not be useful unless you also had 10 Bitbucket users: https://bitbucket.org/product/pricing?tab=host-in-the-cloud

I imagine that a total cost would be around $20/month. That is not a large amount, especially if there are 10 participants. But it is, of course, nothing that I need for myself. with n_participants == 1, my TODO list text file is about all that I need.

Greg

[[e-mail] [nuttx]]

Greg and all,

Post by ***@yahoo.com [nuttx]
Bitbucket, in general, is free if you have fewer than 5 people on the "team".
Not only is Jira not free, but it is limited to a small number of users.
$10/month for up ten users with Jira: https://www.atlassian.com/software/jira/pricing?tab=cloud

How about moving to github?

As far as we know, github is free for public and open source
projects. So we can use an issue tracking system as well as
source code management without any cost.

Also, they provide webhooks so that CI build systems can
be triggered which would be very useful in the future.

Masayuki

[[e-mail] [nuttx]]

Let's recap.


I originally brought up the question of maintaining a list of new features that people would like to see in NuttX.


Since the development "team" consists of only me. The most appropriate thing would be to just maintain a WishList in the repository, just as I maintain the TODO list in the repository.


So the way this would work is that people would just post ideas to the Yahoo! group and I would add them to the list.


Then I brought up the fact that many NuttX features require changes to numerous files and are really not appropriate for a development team of one. A larger development team would probably need a bug tracker to receive, assign, and coordinate bugs and enhancements. We talked about open source tools and Jira with Bitbucket.


Then there was a suggestion to move to GitHub for the tools.


I just want to remind everyone that this is still a development team of one. There will be no collaboration tools or changes to repositories in the near future, not at lease unless the number of developers swells.


We are getting the cart-before-the-horse. If and when a development team evolves, then a discussion of tools etc. makes since. But for a development team of one, the second and third paragraphs of this email describes the only reasonable process at the present time.


So if people have ideas for new features, please let me know.


Greg

[Michał Łyszczek [e-mail] [nuttx]]

This message is my subjective opinion on the situation and I might as
well be full of BS here - I mean no disrespect for anybody. Here it comes

Post by ***@yahoo.com [nuttx]
Since the development "team" consists of only me. The most
appropriate thing would be to just maintain a WishList in the
repository, just as I maintain the TODO list in the repository.

Maybe let's look at it from the other side. Development team consist
only of you, because there is no good project management tool.

I think that mailing lists are not very popular these days. Forums are
easier to use and are more readable (categories, subforums, nice search
tools, nice presentation of messages and so). Also I think it is easier
(as more intuitive) to use forum than to use mailing lists. Yeah, sure
mailing lists are more robust and are lightier (old techs are cool, we
all know it:-)), but we are not living in 20s any more and I think good
project should have, forum, bugzilla, mailing list, git service and IRC

Moving to github - github seems to have more active developers than
bitbucket. Also github has nice project search tool - people might just
stumble upon project. And it doesn't matter if this is development team
of one - see 3rd paragraph. Make it easy for people to join and
colaborate to the project and they will.

Maybe it is building card before the horses, but since we cannot find
horses why not just build a cart, and when horses are found, we won't
have to build cart anymore.

Looking at the list, there are a lot of people here. I bet you could
easily find people to help you with migrations and new tools.

[SP [e-mail] [nuttx]]

On the reoccurring topic of mailing lists vs forums, both can co-exist.
I find that for core developers (unfortunately only one here.. maybe
expand the team?), mailing lists work better than forums.

No one has mentioned Gitlab.com, which is open source and provides a lot
of tools.

[Patrick Mulder [e-mail] [nuttx]]

On the topic mailing list vs forum, there is a Reddit "forum" already, but
it has not much traction:

https://www.reddit.com/r/nuttx/

It might be a nice place for discussions and tracking general support
topics. Btw, some years ago I tried this forum software:
http://www.discourse.org/ - but it has still higher operational effort
(server updates, database maintenance, etc. )

Post by SP ***@orbitalfox.com [nuttx]
On the reoccurring topic of mailing lists vs forums, both can co-exist.
I find that for core developers (unfortunately only one here.. maybe
expand the team?), mailing lists work better than forums.
No one has mentioned Gitlab.com, which is open source and provides a lot
of tools.
--
SP

[[e-mail] [nuttx]]

Have you considered the Issue list on Bitbucket?

https://bitbucket.org/nuttx/nuttx/issues?status=new&status=open https://bitbucket.org/nuttx/nuttx/issues?status=new&status=open



It can be used as a bugtracker, wishlist and even replace this mailing list if we like.


Regarding this lack of development team. I am a little surprised. You guys are contributing so you are development team.

[[e-mail] [nuttx]]

Many people do use the Bitbucket issue list for reporting bugs.


However, I ignore most of the bug reports posted there. If they are issues related to the core OS, I will probably address them because that is something that a am committed to maintaining. However, I don't believe that there has ever been such an issue reported.


I ignore all bug reports related to specific hardware or tools or environments that people are using. In that case, I expect people to solve those problems themselves and send patches to fixed those bugs upstream.


That is necessary simply because one person cannot provide individual support for every board, every MCU used by every person in the world. No one cares about your problems that much to work on that class of issue for free.


Greg

[[e-mail] [nuttx]]

Post by ***@yahoo.com [nuttx]
Many people do use the Bitbucket issue list for reporting bugs.
However, I ignore most of the bug reports posted there.  If they are issues related to the core OS, I will probably address them because that is something that a am committed to maintaining.  However, I don't believe that there has ever been such an issue reported.
I ignore all bug reports related to specific hardware or tools or environments that people are using.  In that case, I expect people to solve those problems themselves and send patches to fixed those bugs upstream.
That is necessary simply because one person cannot provide individual support for every board, every MCU used by every person in the world.  No one cares about your problems that much to work on that class of issue for free.

As far as I know, I am the only person monitoring the issue list and I do not provide personal service for your hardware.

My recommendation is that you report hardware, driver, or tool problems on this Yahoo! group. You might get lucky and there might be someone here with some insight that can help you.

Greg

[[e-mail] [nuttx]]

Hey, I know all of this :)

People were asking where to put wish list and wanted to spawn additional boards.


Really, just a suggestion. No offense intended.

[[e-mail] [nuttx]]

Post by ***@yahoo.com [nuttx]
Really, just a suggestion. No offense intended.

None taken.

[[e-mail] [nuttx]]

For the particular case of fstat(), I have started the basic work for fstat().  I have committed these basics on a branch called, duh, fstat.

The basic change to a "normal" file system would be like this:

1. Add a new fstat() method.

[[Pause for some background Info:

Most file systems have a structure that represents a directory entry.  "Normal" file systems have function that files the directory entry associated with a path:

$ grep -l finddirentry */*.c
fat/fs_fat32.c
fat/fs_fat32attrib.c
fat/fs_fat32dirent.c
romfs/fs_romfs.c
romfs/fs_romfsutil.c
smartfs/smartfs_smart.c
smartfs/smartfs_utils.c

The stat() method simply:
- Calls this finddirentry() function to find the directory entry associated with the path, and
- Updates the 'struct stat' buffer from the directory entry.

The open method typically does something like this:
- Calls the finddirentry() function to find the directory entry of the file to open, and
- Save that in the open file info structure, 'struct file'

Every method that operates on the open file can then get the directory entry from this private data that it receives as an input parameter.

Resume]]

2. Create a new stat_common() function by extracting the common stat buffer update logic. This would be extracted from the existing stat() implementation.

3. The new fstat(0 implementation would then simply recover the directory entry from the private data, and call the stat_common() function to update the struct stat.

But there are nine file systems and perhaps only 3 or 4 are "normal" in this way. There are other oddball file systems like unionfs, tmpfs, procfs, nfs, hostfs, binfs that have to be individually examined to see what fstat() should do.

Greg

[Ken Pettit [e-mail] [nuttx]]

Considering I already know the smartfs and hostfs implementations, I
could handle those pretty easily. I could also tackle procfs if needed
as I also have some experience there as well.

Ken

Post by ***@yahoo.com [nuttx]
For the particular case of fstat(), I have started the basic work for
fstat(). I have committed these basics on a branch called, duh, fstat.
1. Add a new fstat() method.
Most file systems have a structure that represents a directory entry.
"Normal" file systems have function that files the directory entry
$ grep -l finddirentry */*.c
fat/fs_fat32.c
fat/fs_fat32attrib.c
fat/fs_fat32dirent.c
romfs/fs_romfs.c
romfs/fs_romfsutil.c
smartfs/smartfs_smart.c
smartfs/smartfs_utils.c
- Calls this finddirentry() function to find the directory entry
associated with the path, and
- Updates the 'struct stat' buffer from the directory entry.
- Calls the finddirentry() function to find the directory entry of the file to open, and
- Save that in the open file info structure, 'struct file'
Every method that operates on the open file can then get the directory
entry from this private data that it receives as an input parameter.
Resume]]
2. Create a new stat_common() function by extracting the common stat
buffer update logic. This would be extracted from the existing stat()
implementation.
3. The new fstat(0 implementation would then simply recover the
directory entry from the private data, and call the stat_common()
function to update the struct stat.
But there are nine file systems and perhaps only 3 or 4 are "normal"
in this way. There are other oddball file systems like unionfs, tmpfs,
procfs, nfs, hostfs, binfs that have to be individually examined to
see what fstat() should do.
Greg

[[e-mail] [nuttx]]

Sure that would be great. I put stub implementations of fstat() in all file systems on the fstat branch. I have looked at SmartFS. It should be trivially easy because it follows the simple pattern of the "normal" file system. I have not looked at hostfs or procfs.


Greg

[[e-mail] [nuttx]]

Post by ***@yahoo.com [nuttx]
For example, I was looking at fstat() this morning. fstat() is one of a few missing file system interfaces. fstat() is really just like stat() but stat() takes a path string as an argument and fstate() takes a file descriptor. I think I have a pretty simple way to implement fstat(), but it requires many files to change. I count nine file system implementations that would have to change in some way. That is more that I want to undertake so fstat() stays on the shelf.

There are other missing file system functions/features:




chmod - privileges are not used in NuttX now. so this is not really important.


truncate - The standard way of setting a fixed file size. Often used with random access, data base files. There is no simple way of doing that now (other than just writing data to the file).


link, unlink, softlink, readlink - For symbolic links. Only the ROMFS file system currently supports hard and soft links, so this is not too important.


File locking


Special files - NuttX support special files only in the top-level pseudo file system. Unix systems support many different special files via mknod(). This would be important only if it is an objective of NuttX to become a true Unix OS. Again only supported by ROMFS.


True inodes - Standard Unix inodes. Currently only supported by ROMFs.




And probably others. These would be a lot more difficult to implement than fstat() because you would really have to dig deep into the internals of the file systems. I would think that truncate() would be the only one that might be worth such a big effort.


File privileges would also be good to support. But this is really a small part of a much larger feature. NuttX has no user IDs, there are no groups, there are no privileges associated with either. User's don't need credentials. This is really a system wide issues of which chmod is only a small part.


User privileges never seemed important to me since NuttX is intended for deeply embedded environments where there are not multiple users with varying levels of trust.

[Marcelo Barros [e-mail] [nuttx]]

Hello

Post by ***@yahoo.com [nuttx]
Hi Greg,
I can devote part of my time to help you to do it.
My knowledge is small (compared to your), but if you tell what need to
be done I could accomplish it.

Me too,it may be a good opportunity to learn and help if I'd receive some
bugs to solve or feature to add.

Marcelo

[[e-mail] [nuttx]]

Hi, Marcelo,

If you would like to help out, I think the first thing to do would be to subscribe to notifications about issues reported in the Bitbucket repositories. That is probably the default way to report problems and gets only moderate usages. It could be used more. I am not sure if anyone other than me is subscribed, so that that might be a good start.

Another way that you could help would be to work on some NuttX projects. Here are a few NuttX projects that I think would be worthy contributions:

1. Bring project Ara's greybus in from the Motorola MDK: https://github.com/MotorolaMobilityLLC/nuttx.git . Greybus is an application layer on top of Unipro:

https://lwn.net/Articles/648400/
https://kernel-recipes.org/en/2015/talks/an-introduction-to-greybus/

At present, Greybus on NuttX is not available to the world on the current NuttX because it is not in the main repository. I don't know the extent of this port. Certainly it is working on an older version of NuttX. But the design has never been reviewed so there could be some integration issues (like non-POSIX application interfaces?).

2. Wireless support. Several people started to work together as a team and developed 6LoWPAN support for NuttX. But that code was never fully verified and never integrated into upstream NuttX. It is not in NuttX, but it is in several Github repositories and will probably be lost.

Other general wireless support is also needed. I think that NuttX should be the leader in IoT OS's, but it cannot be without world class, integrated wireless support.

3. Graphics: NuttX has a Graphics subsystem, but it needs more work to be really usable. Certainly it is usable because there are products based on it, but it is not easy to use.

4. Other CPU configurations. SMP is finally maturing but I think that whole topic of NuttX support for more complex CPU configurations is important Asymmetric processing, with OpenAMP support for example. And KERNEL build support for CPUs with MMUs that is easier to use and more seamless as in the Linux environment. It should be just as easy to build and develop for NuttX in KERNEL mode as it is to write programs for Linux.

5. Automated Testing. As with most large open source projects, testing is a problem that I have not solution for. I do build testing periodically to assure that the configurations still build, but there is no functional testing (beyond the superficial OS test in apps/examples) and no regression testing. We have talked about automated testing in this forum before, but that would require some substantial resources.

Greg

[[e-mail] [nuttx]]

I used to support student projects at the local University. I am retired now and no long support students in this way. But I still have a list of potential student projects. Here is the last list:

1. DHCPv6
2. USB audio class driver(s), Network driver, PID joystick driver
3. Video sub-system, USB video driver
4. Bluetooth / BLE
5. NFS server
6. Run against POSIX conformance tests
7. Processes: Dynamic stack, Fully linked processes, Shared .text, per-
process globals.
8. Per-window frame buffers. Architecturally, a replacement for the
raw window layer. This would greatly improve graphics usability.
9. Inheritable C++ wrapper for NX (INx, CNx).
Convert NxTK to C++. Inherit from INx (CNxTK).
Extend with Widget plugins, frame buffer(?)
10. eMMC support
11. EDF, SCHED_DEADLINE, deadline scheduler
12. Port to Raspberry Pi 2 (or currently most populer SBC) using SMP
13. Traveller: Integrate wedit world building tools, develop a world data
base, integrate a USB joystick or game controller, USB PID joystick
14. Kernel state monitor system. Hardware data collection and software
data analysis.
15. Get NuttX running on a PC.
16. Port a standard graphics interfaces (such as from nano-X) to NX.
Port a tiny browser.

These tend to be things with less, immediate practical value but which I think are would be interesting for a student.

Greg

[[e-mail] [nuttx]]

Hi Greg,

As you told me to jump in , i started working over a little "NuttX-Web" Project.
It would include Documentation , Git Web Interface , Wish List , Task List with affectation tool and Roadmap.

Planned technologies will be MVC + PHP/Javascript/MySQL as it's the common things used in hosting.
I am currently working over the database model to put all the doc over the readmes / todos / function headers into a right place on a SQL database. If anybody feel like to help , he/she's welcome to contact me =)
If it's a useless effort please feel free to tell too =)

A second thing i am working in parrallel is setting up a OpenBSD desktop environment with OpenOCD and the NuttX BuildRoot Toolchains (especially ARMv7 / MIPS / PowerPC GCC-based toolchain with ada language additional support )

That told, i'd like to involve with the following points in the Future:

- MIPS32 - PowerPC Arch Support - Toolchains
- Audio Sub-System (MIDI Support / DSP-Audio )
https://github.com/Neonking/MIDIkit https://github.com/Neonking/MIDIkit
- Video Sub-System (PowerVR support) including Framebuffer , OpenGL ES and NuttX Widgets Library
https://github.com/Neonking/PowerVR https://github.com/Neonking/PowerVR
- Web Sub-system >Port a tiny browser / Web server :
https://github.com/Neonking/lighttpd2 https://github.com/Neonking/lighttpd2
https://github.com/Neonking/litehtml https://github.com/Neonking/litehtml
https://github.com/Neonking/iv https://github.com/Neonking/iv
- Heterogenous MCUs Designs with Multicore Association APIs
http://www.multicore-association.org/workgroup/mcapi.php http://www.multicore-association.org/workgroup/mcapi.php
http://www.multicore-association.org/workgroup/mtapi.php http://www.multicore-association.org/workgroup/mtapi.php
http://www.multicore-association.org/workgroup/mrapi.php http://www.multicore-association.org/workgroup/mrapi.php

Greets,
Jerome

[[e-mail] [nuttx]]

Hi again,
My bad , PowerVR isn't just an API after checking again...
Forget about this, but i still have big interest in being involved in the graphics sub-system anyway.

Greets,
Jerome

[[e-mail] [nuttx]]

The NuttX graphics system is modelled conceptually after the X graphics system. There is a graphic system and windows that have a position in (x,y,z) space so that one window can be "above" and occlude a lower window. And there is a graphics server that lives inside the OS. It communicates with graphic application clients via a message queue.


The primary issues that I see with the graphics system now are:


1. There is a single user mode that is not POSIX compliant and must be removed eventually. This is used for low-end MCUs with graphics and removing this support requires some replacement (repeal and replace). I am thinking that an LCD character driver that wraps the LCD interface would be such a replacement. That would provide the low-level access to the LCD with the burden of the graphics server.


2. Currently when you move a window and expose parts of a "lower" window, the window client of the lower window gets a redraw callbacs. Re-drawing is a difficult thing to do. It means that the application must remember what was on the display and be able to re-create sections of the display. That is really an onerous responsibility and a real burden for application development.


My preferred solution would be "per-window framebuffers". In this case, each window has a block of memory that it rends into. That block of memory is then used to update the memory on the display. Given such a pre-window framebuffer, the issues with redrawing exposed portions of the window becomes a trivial operation and could be handled by lower level logic without bothering the application code.


This, of course, means more memory usage so this would not be for the lower-end MCUs.


3. NxWidgets have the ability to "contain" and manage other widgets. This is a natural part of the design. But a few people have complained that there is no "frame" object to compose displays. This would be answered by a trivial class that just supports methods like addleft(), addright(), addtop(), addbottom(). These do essentially nothing other than automatically manage display regions because such operations are really already inherent in the NxWidgets design. But such an object would certainly make this clearer and much easier to use.


4. For me, the biggest problem with the NxWidgets is the crappy graphics. I just took some images from the web to generate the displays. Making the displays more artistic would be the best improvement of all.


Greg

[[e-mail] [nuttx]]

NuttX does support MIPS32. See under arch/mips. For MCUs, this basically means PIC32.


There are two web servers in the apps/ directory. One ultra time and a port of THTTPD.


Greg

[[e-mail] [nuttx]]

Hi,
yes sure i noticed that MIPS32 is already supported , but
configs/pic32mz-starterkit/README.txt
only mention Mentor and Pinguino Toolchains.
I think that regarding possible GCC options , a mips32-elf-nuttx GCC-Based toolchain might be built?
(at least i did not found the options in buildroot)

I also found that tutorial :
http://forward-in-code.blogspot.fr/2014/11/building-gnat-gpl-2014-for-arm-eabi.html http://forward-in-code.blogspot.fr/2014/11/building-gnat-gpl-2014-for-arm-eabi.html
meaning that ada support might be added to GCC toolchains by tweaking nuttx-buildroot ?

About Webserver, i also noticed THTTPD port but THTTPD project doesn't seem active from a while.

Lighttpd aims to be light and fast Webserver under BSD-Licence , standard-compliant and under active developpment. It is known to be super lightweight with very Fast CGI interface for PHP as example. A port with NXFLAT support might worth it ?

Last but not least, for Lite Web Browser , i've been going further in my searchs
and found NetSurf Librairies for html5/css3/dom and Level5 Javascript interpreter , all the basics to make a small very lightweight Web Browser under compatible MIT licence:
https://github.com/Neonking/libhubbub https://github.com/Neonking/libhubbub > HTML5 Parser
https://github.com/Neonking/LibCSS https://github.com/Neonking/LibCSS > CSS3 Parser
https://github.com/Neonking/LibDOM https://github.com/Neonking/LibDOM > DOM Model Parser
https://github.com/Neonking/iv/tree/master/iv/lv5 https://github.com/Neonking/iv/tree/master/iv/lv5 > Javascript interpreter

Greets,
Jerome

[[e-mail] [nuttx]]

hi again,
By the way about Javascript interpreters for the small web browser i found better than level5 (lighter) :
https://github.com/Neonking/tiny-js https://github.com/Neonking/tiny-js
https://github.com/Neonking/ecmascript https://github.com/Neonking/ecmascript

greets,
Jerome

[[e-mail] [nuttx]]

Have you looked at JerrySript, IoT.js. Samsung has put a big effort into this and it already works with NuttX: https://github.com/Samsung/iotjs/wiki/Getting-Started

https://github.com/Samsung/iotjs
https://github.com/Samsung/jerryscript
http://events.linuxfoundation.org/sites/events/files/slides/openiot-summit-2016-iotjs.pdf
https://github.com/Samsung/iotjs/wiki/Build-for-NuttX

[[e-mail] [nuttx]]

Wow, cool stuff! Thanks for the feedback =)
I'm opened to using it , i just gave priority to MIT Licence in my searchs as i thought it more "compatible".
(Iotjs and Jerryscript are under Apache 2.0) - Jerryscript and Iotjs are for sure "best" candidates seeking at the project descriptions . As it already works within NuttX i'll give it a try for sure.

As Apache 2.0 Sounds suitable , my last find of the day is
https://github.com/graemedouglas/LittleD https://github.com/graemedouglas/LittleD
Small SQL DB usable on embedded devices

Greets,
Jerome

[[e-mail] [nuttx]]

I am not sure exactly what I am looking at, but this script: https://codegists.com/snippet/shell/oneshotsh_felipeasg_shell looks like it would take a bare Ubuntu installation, download everything you need, build NuttX with JerryScript, IoT.js and all of the libraries you need, and even write the code into your STM32F4 Discovery.

[[e-mail] [nuttx]]

If you were not sure, i am , it is a very instructive find (at least for me ^^ )
After discovering Jerryscript and IoT.Js yesterday that's a great introduction to getting started.
Thank you samsung and greg =)

Greets,
Jerome

[[e-mail] [nuttx]]

Hi greg,
Entering the toolchains/building things and making the licence-geek , i was wondering what was your status about getting a BSD Compiler up and running with NuttX ?
I especially think about that one : https://github.com/lugon/LuxCC https://github.com/lugon/LuxCC
Would it be a huge work ? or something slightly doable ?
Greets,
Jerome

[[e-mail] [nuttx]]

Post by ***@open-modular.com [nuttx]
Entering the toolchains/building things and making the licence-geek , i was wondering what was your status about getting a BSD Compiler up and running with NuttX ?

The license of the toolchain is not important. The licensing only effects the distribution of binaries containing NuttX, not the particular tools that you use to develop NuttX.

Post by ***@open-modular.com [nuttx]
I especially think about that one : https://github.com/lugon/LuxCC https://github.com/lugon/LuxCC
Would it be a huge work ? or something slightly doable ?

I don't know anything about that particular compiler. NuttX already supports several different compilers. I do this by enforcing several rules:


1. Everything outside of arch/ and configs/ must conform to C89 C. Because of that I can support some of the strangest old compilers. I am an off-and-on retro computing enthusiast so it is important to me to support old tools and old CPUs. So almost any ANSII C compiler create in the last few decades should work. K&R would not work.


2. I do not permit any compiler specific #pragmas or attributes outside of arch/ and configs/. I provide the file include/nuttx/compiler.h to hide all compiler dependencies. So, if I have done things right, you should only have to change that header file to add support for any new compiler.


3. Outside of arch/ and configs/ I enforce funky storage classes like FAR, NEAR, and CODE. This is really only necessary for a few architectures, but it is another example of the effort I do to keep compiler independence.


Notice that within the arch/ and configs/ directories I have not been so strict, so if you run into problems that is where you will find the problems.


Greg

[[e-mail] [nuttx]]

Another thing that needs to be added to the WishList is some wireless support.

That was already an aborted started on a 6loWPAN implementation. There at some hooks out for ieee802.154 MAC and a 6loWPAN in NuttX now (see wireless/802154 and net/6lowpan). There is an unverified implementation of the ieee802.154 MAC and some wireless device drivers out there in some Bitbucket repositories, but no 6loWPAN implementation.

In GitHub, I find these two implementations. Both are license compatible:

https://github.com/ARMmbed/sal-stack-nanostack
https://github.com/hso-esk/emb6

I spent some time looking at the second one. The repository is huge, about 55MiB of code. But, like NuttX, this is almost all platform and test code. The basic emb6 sub-directory is 2.3MiB. Still pretty big but it seems complete with implementations for (or at least hooks for) things like TLS (AES, ECC, SHA2), multicast, RPL, DNS, SLIP and more.

Right now I have some free time and I could dedicate some effort into integrating this. But I am somewhat uncomfortable with that it is outside of my area of expertise. Is there anyone out there more knowledgeable that I who has any opinion about these 6loWPAN implementations?

Greg

[Marcelo Barros [e-mail] [nuttx]]

Greg

Post by ***@yahoo.com [nuttx]
Another thing that needs to be added to the WishList is some wireless support.
That was already an aborted started on a 6loWPAN implementation. There at
some hooks out for ieee802.154 MAC and a 6loWPAN in NuttX now (see
wireless/802154 and net/6lowpan). There is an unverified implementation of
the ieee802.154 MAC and some wireless device drivers out there in some
Bitbucket repositories, but no 6loWPAN implementation.
https://github.com/ARMmbed/sal-stack-nanostack
https://github.com/hso-esk/emb6
I spent some time looking at the second one. The repository is huge, about
55MiB of code. But, like NuttX, this is almost all platform and test code.
The basic emb6 sub-directory is 2.3MiB. Still pretty big but it seems
complete with implementations for (or at least hooks for) things like TLS
(AES, ECC, SHA2), multicast, RPL, DNS, SLIP and more.
Right now I have some free time and I could dedicate some effort into
integrating this. But I am somewhat uncomfortable with that it is outside
of my area of expertise. Is there anyone out there more knowledgeable that
I who has any opinion about these 6loWPAN implementations?]

So, my question was already answered (sorry, some days without computer
after a failure).
I will take a look on them. I have used another one from OpenWSN project.

Marcelo

[[e-mail] [nuttx]]

Regarding 6lowpan, it is included in contiki os (also seems to have BSD license -- http://www.contiki-os.org/license.html http://www.contiki-os.org/license.html). Not sure if 6lowpan stack could be easily extracted from contiki os and if it could be easily reused. At least it should be possible to use contiki implementation as one more example.

Vytautas

[[e-mail] [nuttx]]

hi,
about wireless stacks i found some unexhaustive list here :
https://en.wikipedia.org/wiki/Comparison_of_802.15.4_radio_modules#Integrated_MCU_and_transceiver_modules https://en.wikipedia.org/wiki/Comparison_of_802.15.4_radio_modules#Integrated_MCU_and_transceiver_modules
look at the right column there are some links to 'common' used stacks (6lowpan listed for example)
I know , this is not a 802.11 list but 802.15 is somewhat used in embedded systems and not uncompatible.

I already have others center of interest to cover before , so wireless won't be on the bench before a while or not at all if someone cover the thing ^^.
I nevertheless have some samples of these:
https://www.maximintegrated.com/en/products/comms/wireless-rf/MAX2829.html https://www.maximintegrated.com/en/products/comms/wireless-rf/MAX2829.html
http://www.st.com/en/wireless-connectivity/spirit1.html http://www.st.com/en/wireless-connectivity/spirit1.html
that i'd like to get up and running with NuttX.

I can send freely some of these ICs to peoples interested about working the subject of wireless.

Best regards,
Jerome

[Marcelo Barros [e-mail] [nuttx]]

Greg,

Post by ***@yahoo.com [nuttx]
I used to support student projects at the local University.
I am retired now and no long support students in this way. But I still
...

Hum, every week I have a new student entering in my room and asking for
some course conclusion works.
I will start to present this list to them (even though lot of them are only
motivated by the "course conclusion" and not by the "work" part :) ).

Marcelo

[Marcelo Barros [e-mail] [nuttx]]

Hi Greg



Another way that you could help would be to work on some NuttX projects.

...
2. Wireless support. Several people started to work together as a team and
developed 6LoWPAN support for NuttX....

This item is related to some issues I am involved. I have been discussing
it (with Alan) and tested the nRF24Lx radio using Nuttx. Maybe it is good
starting point.

The idea is to create a stack from the ground or find and integrate a known
stack the fits in the NuttX terms (if any) ?

Marcelo

[[e-mail] [nuttx]]

Hi Greg,

It would be nice to have a port of NuttX to Raspberry Pi and drivers for TI PCM5242 IC, TI TPA6133A, and TI PCM1522, so I could use my HiFi IQaudiO DAC+ and HiHiBerry Pi-DAC+ with IT.
The Raspbian OS is pretty slow at initialization.


Best,
Andre

[[e-mail] [nuttx]]

There has been interest in a Raspberry Pi port in the past.


The basic bring-up to a shell prompt would probably require about 3 man-weeks or so, but a verified port with a full suite of drivers would probably be around a 4 man-month effort.


It would require a very dedicated person with much to gain personally in order to do that. Or it could be done with a small group of like-minded, capable people working together to create the port.


I would certainly be interested in being one of those people and could probably contribute a lot to the basic bring-up, but it would require more get the full OS support that you envision.


Greg

[Maciej Wójcik [e-mail] [nuttx]]

One future that is missing and most important (for me) is encrypted HTTP.
Without encryption our "Internet of Things" devices are at most "Local Network of Things Devices". They are vulnerable to anyone knowing how to use Wireshark.
Maybe it would be possible to back-port it from Samsung fork without a lot of effort.

On Sunday, February 12, 2017 5:37 PM, "***@yahoo.com [nuttx]" <***@yahoogroups.com> wrote:


  I am always interested in adding new capabilities to NuttX and NSH.  I think it would be a good idea to create a "Wish List" where anyone could post new features that they would like to see the OS.
Is that something that people would use?  Would you add things to such a list if it existed?
And how would be best to implement such a list.  The Wiki would be an idea except that it has been under such fierce attacks that it is now to protected for anyone to use.  We could also create a Bitbucket "issue" to list and talk about new features.  There is a bitbucket Wiki, but it also has strong protections.
Greg

#yiv7128060853 -- #yiv7128060853ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7128060853 #yiv7128060853ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7128060853 #yiv7128060853ygrp-mkp #yiv7128060853hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv7128060853 #yiv7128060853ygrp-mkp #yiv7128060853ads {margin-bottom:10px;}#yiv7128060853 #yiv7128060853ygrp-mkp .yiv7128060853ad {padding:0 0;}#yiv7128060853 #yiv7128060853ygrp-mkp .yiv7128060853ad p {margin:0;}#yiv7128060853 #yiv7128060853ygrp-mkp .yiv7128060853ad a {color:#0000ff;text-decoration:none;}#yiv7128060853 #yiv7128060853ygrp-sponsor #yiv7128060853ygrp-lc {font-family:Arial;}#yiv7128060853 #yiv7128060853ygrp-sponsor #yiv7128060853ygrp-lc #yiv7128060853hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7128060853 #yiv7128060853ygrp-sponsor #yiv7128060853ygrp-lc .yiv7128060853ad {margin-bottom:10px;padding:0 0;}#yiv7128060853 #yiv7128060853actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7128060853 #yiv7128060853activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7128060853 #yiv7128060853activity span {font-weight:700;}#yiv7128060853 #yiv7128060853activity span:first-child {text-transform:uppercase;}#yiv7128060853 #yiv7128060853activity span a {color:#5085b6;text-decoration:none;}#yiv7128060853 #yiv7128060853activity span span {color:#ff7900;}#yiv7128060853 #yiv7128060853activity span .yiv7128060853underline {text-decoration:underline;}#yiv7128060853 .yiv7128060853attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv7128060853 .yiv7128060853attach div a {text-decoration:none;}#yiv7128060853 .yiv7128060853attach img {border:none;padding-right:5px;}#yiv7128060853 .yiv7128060853attach label {display:block;margin-bottom:5px;}#yiv7128060853 .yiv7128060853attach label a {text-decoration:none;}#yiv7128060853 blockquote {margin:0 0 0 4px;}#yiv7128060853 .yiv7128060853bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv7128060853 .yiv7128060853bold a {text-decoration:none;}#yiv7128060853 dd.yiv7128060853last p a {font-family:Verdana;font-weight:700;}#yiv7128060853 dd.yiv7128060853last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv7128060853 dd.yiv7128060853last p span.yiv7128060853yshortcuts {margin-right:0;}#yiv7128060853 div.yiv7128060853attach-table div div a {text-decoration:none;}#yiv7128060853 div.yiv7128060853attach-table {width:400px;}#yiv7128060853 div.yiv7128060853file-title a, #yiv7128060853 div.yiv7128060853file-title a:active, #yiv7128060853 div.yiv7128060853file-title a:hover, #yiv7128060853 div.yiv7128060853file-title a:visited {text-decoration:none;}#yiv7128060853 div.yiv7128060853photo-title a, #yiv7128060853 div.yiv7128060853photo-title a:active, #yiv7128060853 div.yiv7128060853photo-title a:hover, #yiv7128060853 div.yiv7128060853photo-title a:visited {text-decoration:none;}#yiv7128060853 div#yiv7128060853ygrp-mlmsg #yiv7128060853ygrp-msg p a span.yiv7128060853yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv7128060853 .yiv7128060853green {color:#628c2a;}#yiv7128060853 .yiv7128060853MsoNormal {margin:0 0 0 0;}#yiv7128060853 o {font-size:0;}#yiv7128060853 #yiv7128060853photos div {float:left;width:72px;}#yiv7128060853 #yiv7128060853photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv7128060853 #yiv7128060853photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv7128060853 #yiv7128060853reco-category {font-size:77%;}#yiv7128060853 #yiv7128060853reco-desc {font-size:77%;}#yiv7128060853 .yiv7128060853replbq {margin:4px;}#yiv7128060853 #yiv7128060853ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv7128060853 #yiv7128060853ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv7128060853 #yiv7128060853ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv7128060853 #yiv7128060853ygrp-mlmsg select, #yiv7128060853 input, #yiv7128060853 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv7128060853 #yiv7128060853ygrp-mlmsg pre, #yiv7128060853 code {font:115% monospace;}#yiv7128060853 #yiv7128060853ygrp-mlmsg * {line-height:1.22em;}#yiv7128060853 #yiv7128060853ygrp-mlmsg #yiv7128060853logo {padding-bottom:10px;}#yiv7128060853 #yiv7128060853ygrp-msg p a {font-family:Verdana;}#yiv7128060853 #yiv7128060853ygrp-msg p#yiv7128060853attach-count span {color:#1E66AE;font-weight:700;}#yiv7128060853 #yiv7128060853ygrp-reco #yiv7128060853reco-head {color:#ff7900;font-weight:700;}#yiv7128060853 #yiv7128060853ygrp-reco {margin-bottom:20px;padding:0px;}#yiv7128060853 #yiv7128060853ygrp-sponsor #yiv7128060853ov li a {font-size:130%;text-decoration:none;}#yiv7128060853 #yiv7128060853ygrp-sponsor #yiv7128060853ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv7128060853 #yiv7128060853ygrp-sponsor #yiv7128060853ov ul {margin:0;padding:0 0 0 8px;}#yiv7128060853 #yiv7128060853ygrp-text {font-family:Georgia;}#yiv7128060853 #yiv7128060853ygrp-text p {margin:0 0 1em 0;}#yiv7128060853 #yiv7128060853ygrp-text tt {font-size:120%;}#yiv7128060853 #yiv7128060853ygrp-vital ul li:last-child {border-right:none !important;}#yiv7128060853

[Sebastien Lorquet [e-mail] [nuttx]]

Hello,

that is TLS or SSL. Would be also useful for non HTTP "secure" network connections.

Sebastien

Post by Maciej Wójcik ***@yahoo.com [nuttx]
One future that is missing and most important (for me) is encrypted HTTP.
Without encryption our "Internet of Things" devices are at most "Local Network
of Things Devices". They are vulnerable to anyone knowing how to use Wireshark.
Maybe it would be possible to back-port it from Samsung fork without a lot of effort.
I am always interested in adding new capabilities to NuttX and NSH. I think it
would be a good idea to create a "Wish List" where anyone could post new
features that they would like to see the OS.
Is that something that people would use? Would you add things to such a list if
it existed?
And how would be best to implement such a list. The Wiki would be an idea
except that it has been under such fierce attacks that it is now to protected
for anyone to use. We could also create a Bitbucket "issue" to list and talk
about new features. There is a bitbucket Wiki, but it also has strong protections.
Greg

[Sebastien Lorquet [e-mail] [nuttx]]

This is related to a potential crypto interfaces for nuttx.

my head is full of ideas and I have an accurate description of a crypto
framework for nuttx ala PKCS#11, it just have to be done but I have no time for
that :(

I could talk about that with interested developers with available brain time.

Sebastien

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
Hello,
that is TLS or SSL. Would be also useful for non HTTP "secure" network connections.
Sebastien

Post by Maciej Wójcik ***@yahoo.com [nuttx]
One future that is missing and most important (for me) is encrypted HTTP.
Without encryption our "Internet of Things" devices are at most "Local Network
of Things Devices". They are vulnerable to anyone knowing how to use Wireshark.
Maybe it would be possible to back-port it from Samsung fork without a lot of effort.
I am always interested in adding new capabilities to NuttX and NSH. I think it
would be a good idea to create a "Wish List" where anyone could post new
features that they would like to see the OS.
Is that something that people would use? Would you add things to such a list if
it existed?
And how would be best to implement such a list. The Wiki would be an idea
except that it has been under such fierce attacks that it is now to protected
for anyone to use. We could also create a Bitbucket "issue" to list and talk
about new features. There is a bitbucket Wiki, but it also has strong protections.
Greg

------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/nuttx/join
(Yahoo! ID required)

<*> To change settings via email:
nuttx-***@yahoogroups.com
nuttx-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
nuttx-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Marcelo Barros [e-mail] [nuttx]]

Hi Sebastien

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
that is TLS or SSL. Would be also useful for non HTTP "secure" network connections.

Yes. I would like to share some experiences about this point.

Last year I compiled mbed TLS for NuttX but I didn't like the final result.
The amount of memory used can be huge depending on the features you are
interesting in. For instance, RSA algorithms may have large allocation
peaks, like 40kB or more. This happens because the integer precision math
is variable, generating many allocs / deallocs. Elliptical (ECC) algorithms
are more economic and I had 9kB peaks. However, I could not live using only
ECC as some sites require RSA. You can imagine the problem if we have a
heap fragmentation or some deallocation bug... there are hundreds of
allocations even for simple operations !

I created some allocation hooks and did a histogram for memory size
allocations. In general, we have many small size allocations (e.g. 64
bytes, 32 bytes) and just few large allocations (e.g. 1k). The idea was to
create multiple memory pools with variable size instead using heap
allocations. I did some tests using this strategy but I gave up: it was not
feasible for small CPUS using RSA (although it could prove it was for ECC).
However, it seems a valid strategy for medium size uCs.

There are other stacks, like axTLS, but all I checked were based on similar
multi precision integer libraries, with many allocations. I could find any
static implementation.

I took a look in some projects using mbed TLS. In general they do a careful
selection of features to create a smaller stack but do not touch the
allocation problem. If your server is prepared to accept this subset (for
instance, only ECC) when the TLS session is opened, mbed TLS could be used.
If not, probably your memory will not be enough (I had problems with some
sites requesting more secure and complex crypto modes).

Using ESP8266 I touched other big problem: buffer size for HTTPS (in fact,
any secure socket) should be 16kB, as recommended by RFC. Some certificates
are exchanged when the session is opened and their chain can be large.
ESP8266 (based on axTLS) has a maximum buffer size of 4k, useless for some
applications due to certificate sizes (I tested it). ESP32 is based on mbed
TLS as far as I know but I couldn't check the limits.

In summary, the amount of memory is huge and small boards like the
inexpensive F103 board (20k of RAM) can not support it. Stacks relays on
allocations and I got disappointed with the results. Memory pools can be
viable but require more studies. Certification chains can be huge,
requesting 16k of RAM.

Marcelo Barros

[[e-mail] [nuttx]]

Hi ,
Maybe some principles can be backported from this : http://www.matrixssl.org/ http://www.matrixssl.org/ (GPL) ?
Best regards,
Jerome

[Marcelo Barros [e-mail] [nuttx]]

Maybe, I didn't investigate matrix SSL due to license restrictions but you
are right, we can learn the methodology. I will take a look in the source
code.

Post by ***@open-modular.com [nuttx]
Hi ,
http://www.matrixssl.org/ (GPL) ?
Best regards,
Jerome

[Sebastien Lorquet [e-mail] [nuttx]]

honestly the only thing that mbed suggests to me is "bag of crap from A to Z".

moreover running anything interesting on the F103 is probably a dream...

I dont think that mbed is a good example and should be copied in nuttx. and the
big mem alloc patterns you found are one more example.

I work in a smart card and crypto company and I am sure that a small and
efficient tls library could be created. There is no need for a generic variable
size bigint library, code could be optimized for specific sizes, and carefully
controlled crypto calculations should be possible without spending multiple
kilobytes of memory. RSA2048 = 256 bytes.

So yes, I think that a new, dedicated, carefully crafted TLS library is required
for nuttx, not a raw port from somewhere else. Maybe we can start with some
other lib, but we should not be afraid to make deep and proper changes, just
like nuttx started witn uip and ended up with a quite extensive rewrite.

Such a nuttx tls lib should be able to take advantage of any available hardware
crypto acceleration, even if partial (eg, only AES).

Also, dont think that RSA is "deprecated" or something like that because ECC is
"more secure faster and smaller numbers". The high number of bits of RSA numbers
is a very effective defense against quantum algorithms that may come out one
day. Entanglement of 2048 qbits is far more difficult than entanglement of 256
or 512 qbits...

Sebastien

Post by Marcelo Barros ***@gmail.com [nuttx]
Hi Sebastien

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
that is TLS or SSL. Would be also useful for non HTTP "secure" network

connections.
Yes. I would like to share some experiences about this point.
Last year I compiled mbed TLS for NuttX but I didn't like the final result. The
amount of memory used can be huge depending on the features you are interesting
in. For instance, RSA algorithms may have large allocation peaks, like 40kB or
more. This happens because the integer precision math is variable, generating
many allocs / deallocs. Elliptical (ECC) algorithms are more economic and I had
9kB peaks. However, I could not live using only ECC as some sites require RSA.
You can imagine the problem if we have a heap fragmentation or some deallocation
bug... there are hundreds of allocations even for simple operations !
I created some allocation hooks and did a histogram for memory size allocations.
In general, we have many small size allocations (e.g. 64 bytes, 32 bytes) and
just few large allocations (e.g. 1k). The idea was to create multiple memory
pools with variable size instead using heap allocations. I did some tests using
this strategy but I gave up: it was not feasible for small CPUS using RSA
(although it could prove it was for ECC). However, it seems a valid strategy for
medium size uCs.
There are other stacks, like axTLS, but all I checked were based on similar
multi precision integer libraries, with many allocations. I could find any
static implementation.
I took a look in some projects using mbed TLS. In general they do a careful
selection of features to create a smaller stack but do not touch the allocation
problem. If your server is prepared to accept this subset (for instance, only
ECC) when the TLS session is opened, mbed TLS could be used. If not, probably
your memory will not be enough (I had problems with some sites requesting more
secure and complex crypto modes).
Using ESP8266 I touched other big problem: buffer size for HTTPS (in fact, any
secure socket) should be 16kB, as recommended by RFC. Some certificates are
exchanged when the session is opened and their chain can be large. ESP8266
(based on axTLS) has a maximum buffer size of 4k, useless for some applications
due to certificate sizes (I tested it). ESP32 is based on mbed TLS as far as I
know but I couldn't check the limits.
In summary, the amount of memory is huge and small boards like the inexpensive
F103 board (20k of RAM) can not support it. Stacks relays on allocations and I
got disappointed with the results. Memory pools can be viable but require more
studies. Certification chains can be huge, requesting 16k of RAM.
Marcelo Barros

[Marcelo Barros [e-mail] [nuttx]]

Sebastien,

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
honestly the only thing that mbed suggests to me is "bag of crap from A to Z".

Yep, it seems a PC code adapted to run on some (big) embedded systems.
It easy to see, just check the stack usage in function calls and all
(terrible) examples (in terms of memory, at least).

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
moreover running anything interesting on the F103 is probably a dream...

ECC is possible, but probably not together NuttX. :/

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
I dont think that mbed is a good example and should be copied in nuttx. and the
big mem alloc patterns you found are one more example.

Agree.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
So yes, I think that a new, dedicated, carefully crafted TLS library is required
for nuttx, not a raw port from somewhere else. Maybe we can start with
some ...

I am available to help, I am not sure if I have the experience to
coordinate such project (in terms of crypto experience, I mean).

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
Also, dont think that RSA is "deprecated" or something like that because ECC is
"more secure faster and smaller numbers"....

RSA is a requirement. No doubt. There are many things outside based on it.
And it becomes stronger after people saying that NSA ECC curves may be
insecure.

https://www.schneier.com/blog/archives/2015/10/why_is_the_nsa_.html
https://tools.ietf.org/html/rfc7748
(Schneier talking about the problem and IETF curves)

Marcelo Barros

[[e-mail] [nuttx]]

Hi Sebastien,Marcelo,

Seems that you got the crypto subject in hand =) Personnally that's not my cup of tea :p

I totally agree on a dedicated crypto lib if you feel like working on it , that would be really great.
I mentionned MatrixSSL because it could be a very good base to be backported in NuttX, small footprint goal and multiple protocols implemented.
Maybe Sebastien has other code base he was thinking about ?

Greets,
Jerome

[[e-mail] [nuttx]]

Hi again,
One (system?) feature that would be cool to see implemented is a distributed and a journalised file system.
Maybe something like these (just examples):

http://ori.scs.stanford.edu/ http://ori.scs.stanford.edu/ ?

https://en.wikipedia.org/wiki/UBIFS https://en.wikipedia.org/wiki/UBIFS
http://www.linux-mtd.infradead.org/doc/ubifs.html http://www.linux-mtd.infradead.org/doc/ubifs.html

It's licence compatible but the current source might need some work.

Also , Greg, i wanted to ask you where you might put the non-symetrical multi-core logics in the NuttX tree?
(Later Multicore APIs from OpenAMP implementation)

Best regards,
Jerome

[[e-mail] [nuttx]]

FAT is used almost exclusively on removable media and with USB MSC devices because that is what you have to interoperate with Windows. But having a journaling file system that is resistant to unexpected power failure might be a good thing. FAT is relatively resistant, compared to some others, but usually does lead to data loss because of in-RAM buffering.

Of course, no ports of GPL file systems can be considered. Nor does it make sense to consider a port of a large Linux file system into a small embedded system.

UBIFS, like SmartFS and NXFFS, works directly on FLASH versus via a block driver. It is GPLv2 and not suitable for NuttX for that reason: http://lists.infradead.org/pipermail/linux-mtd/2014-August/055120.html

Such a journaling file system would really only be of value to an internal volume and only with if you had support for the USB MTP class. My understanding is that, unlike USB MSC, MTP does not depend on direct access to media, but rather goes through the device;s file system... whatever that may be.

Internal volumes could be on serial FLASH or what I would really like to see is eMMC support. I think the eMMC + Journaling File System + USB MTP would be a great combination.

[Ken Pettit [e-mail] [nuttx]]

Post by ***@yahoo.com [nuttx]
Such a journaling file system would really only be of value to an
internal volume and only with if you had support for the USB MTP
class. My understanding is that, unlike USB MSC, MTP does not depend
on direct access to media, but rather goes through the device;s file
system... whatever that may be.

Sure would be nice to be able to pull the Tinyara OS SmartFS code back
into NuttX since Samsung added journaling with redundant journal entries
(along with bad sector management), but alas, it cannot be done.

Ken

[[e-mail] [nuttx]]

Maybe something based upon these guidelines could lead to some nice new filesystem features?
http://www.linux-mtd.infradead.org/doc/JFFS3design.pdf http://www.linux-mtd.infradead.org/doc/JFFS3design.pdf
At least it sounds more easier / less heavy to port than UbiFS (just given as -bad- example).
And as well as it's just a spec , BSD code can be wrote upon this,and the spec isn't 5km long.

About distributed file system i guess that it's 'applicative' side for you greg?

Bests,
Jerome

[[e-mail] [nuttx]]

Currently all file systems are part of the OS. There is no user file system like FuseFS (although I have bits and pieces of a fusefs in-work in a local directory).


Therefore, all file systems have to be part of the OS.


[Rant Alert: Somewhere beginning around here, this email devolves into another of my rants. Skip if like.]


I am not opposed to porting applications to NuttX in, perhaps, the apps/ directory. The apps/ directory is not maintained so well; it is just a catch-all area for useful things.


I do have a rule that I do not support custom forks of other active open source projects in the apps/ directory. Some old dead projects are hosted in apps/ (like Modbus), but no active projects. For active projects we only do a build that works like this:


1. Downloads a versioned copy of the active project from its source repository,
2. Applies NuttX specific patches, and
3, And builds.



If extensive changes are required to work with NuttX, then you should be working with the owners of those projects to work the NuttX port into their repositories.


In general, I am not a fan, of poriting third party code. Very little under nuttx/ is ported in that way. Bits and pieces do come from other places (like parts of the C library comes from BSD, parts of the TCP state machine come from uIP, etc.) But I feel good to say that it is primarily an original development.


[Now we are really waist-deep in the rant]


Modern embedded software development seems to work like this:


1. Search for someone else's work that meets your needs,
2. Hack up the code so that it works in the new environment, and
3. Say you are done.


Not very interesting. The real pleasure of programming comes from working from specifications and data sheets to get a real understanding and then developing the software yourself. That is more in the spirit of NuttX.


If you are developing code for profit, then getting the most functionality with the minimal expenditure of effort is the best strategy for success. I do understand that, but that is not consistent with the NuttX way of doing things. I developed the project for my own personal satisfaction and my concerns are with the proper architecture of the system, consistency and modularity in the implementation and interfaces used with the OS, and a consistent roadmap that does not go down the rathole of personal, business objectives.


I am not anti-business. Not at all. But I am very pro-NuttX.


This dovetails in with the discussions going on now about security and wireless etc. If you just search for someone else's work to meet your need, then your need will never be perfectly met. It does take more time to develop from scratch, but I think that end result is worth the effort.


For example, the NuttX version of ROMFS. Linux has a huge version of ROMFS that is GPLv2. I never even looked at that; but in the Linux document directory, there is a technical description of the ROMFS and I used that to develop the NuttX ROMFS from scratch. Since it follows the specification, it works perfectly with the open source genromfs utility.


Greg

[Sebastien Lorquet [e-mail] [nuttx]]

Hello,

Post by ***@yahoo.com [nuttx]
For example, the NuttX version of ROMFS. Linux has a huge version of ROMFS that
is GPLv2. I never even looked at that; but in the Linux document directory,
there is a technical description of the ROMFS and I used that to develop the
NuttX ROMFS from scratch. Since it follows the specification, it works
perfectly with the open source genromfs utility.
Greg

Something like that could be done for a journalled flash file system. the JFFS3
design doc is very good, this could be used to develop a similar FS, with more
optimizations for NOR flash where multiple overlaid writes to a single sector
are possible.

While I'm here, a flash filesystem with an atomic update capability could be
nice, we had to hack one from user space for the project we have at my day job.

We did something like SQL transactions, or FS snapshots:

-mark a point
-write/create some files

and then you can either rollback the state of the FS to the previous point, or
commit the changes to the FS.

It was a very strong requirement from our customer. We did it in our app, but
these functions could be IOCTLs on a mount point.

Sebastien

[Sebastien Lorquet [e-mail] [nuttx]]

Post by ***@yahoo.com [nuttx]
For example, the NuttX version of ROMFS. Linux has a huge version of ROMFS that
is GPLv2. I never even looked at that; but in the Linux document directory,
there is a technical description of the ROMFS and I used that to develop the
NuttX ROMFS from scratch. Since it follows the specification, it works
perfectly with the open source genromfs utility.
Greg

Something like that could be done for a journalled flash file system. the JFFS3
design doc is very good, this could be used to develop a similar FS, with more
optimizations for NOR flash where multiple overlaid writes to a single sector
are possible.

While I'm here, a flash filesystem with an atomic update capability could be
nice, we had to hack one from user space for the project we have at my day job.

We did something like SQL transactions, or FS snapshots:

-mark a point
-write/create some files

and then you can either rollback the state of the FS to the previous point, or
commit the changes to the FS.

It was a very strong requirement from our customer. We did it in our app, but
these functions could be IOCTLs on a mount point.

Sebastien


------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/nuttx/join
(Yahoo! ID required)

<*> To change settings via email:
nuttx-***@yahoogroups.com
nuttx-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
nuttx-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Marcelo Barros [e-mail] [nuttx]]

So, Sebastião/Jerome, what we can effectively do?

Post by ***@open-modular.com [nuttx]
Hi Sebastien,Marcelo,
Seems that you got the crypto subject in hand =) Personnally that's not my cup of tea :p
I totally agree on a dedicated crypto lib if you feel like working on it ,
that would be really great.
I mentionned MatrixSSL because it could be a very good base to be
backported in NuttX, small footprint goal and multiple protocols
implemented.
Maybe Sebastien has other code base he was thinking about ?
Greets,
Jerome

[[e-mail] [nuttx]]

Hi Marcelo,

I have the NuttX-Web proposal to focus on so MatrixSSL backport (that seems the easiest path to me) would have to wait on my side. I'll try not to spare more than i already did ^^.

Anyway, a good entry point could be listing the algorithms/Concepts and any roadmap we would like to see backported from MatrixSSL, because surely all is not needed. Unfortunately crypto isn't one of my fields.
As Far as I know (hope i don't mess up) at a lower level crypto interfaces often become very arch specific (RNG etc) so this 'syscall' aspect might require Greg or Sebastien advice.

Best regards,
Jerome

[Sebastien Lorquet [e-mail] [nuttx]]

Hello

Here is what I did. I wrote a spec in 2014 (wow, 3 years). It should be updated
and improved but the main goal is expressed and understandable.

This crypto API would be the base for a TLS implementation.

It is flexible enough to support software implementations, or hardware in the
SoC, or even external hardware (Trusted platform modules, seen at atmel, maxim,
etc) or even a Trustzone software based thing.)

The big advantage of a completely separate crypto core is that the critical
algorithms are well isolated and its code quality can be ensured.

Sure, more critical code will be present in the tls lib, but I can assure you
that I would severly review any code going into this crypto core library to
ensure its secure and proper design.

The related github repo is obviously not up to date but the relevant code can
easily be carved out from this old repo and ported to a recent nuttx.

Sébastien Lorquet

Post by ***@open-modular.com [nuttx]
Hi Marcelo,
I have the NuttX-Web proposal to focus on so MatrixSSL backport (that seems the
easiest path to me) would have to wait on my side. I'll try not to spare more
than i already did ^^.
Anyway, a good entry point could be listing the algorithms/Concepts and any
roadmap we would like to see backported from MatrixSSL, because surely all is
not needed. Unfortunately crypto isn't one of my fields.
As Far as I know (hope i don't mess up) at a lower level crypto interfaces often
become very arch specific (RNG etc) so this 'syscall' aspect might require Greg
or Sebastien advice.
Best regards,
Jerome

[[e-mail] [nuttx]]

Great! Thanks, Sebastien. I love fresh developments from a specification.


I will also be happy to contribute to this effort too. I propose the following:


1. A few people ... 2 or 3? ... should offer to support the development. Perhaps, one person should step up and "lead" the effort. Probably not me because this is not my primary expertise and because I am too bossy.


2. We should carve up the work so that multiple people can contribute. This primary amounts to defining clean interfaces. The interface definition is the contract that lets up work independently.


3. I can create a branch in the main repository. We can use that branch for combining, synchronizing, and reviewing code changes.


4. When it all works, we merge the branch into the master.


Is anyone up to that?


Greg

[[e-mail] [nuttx]]

Hi,
I would be pleased to support Sebastien's lead on that JFFS3 implementation, Filesystems are a bit more my field.
Bests,
Jerome

[Sebastien Lorquet [e-mail] [nuttx]]

heh... this branch of the discussion is for crypto, not jffs3 :)

I will not lead anything about file systems, because thats very complex and I am
not an expert. I can help with ideas, however.

About crypto, yes, I am qualified to lead that development, but I'm afraid I
will not be able to commit to that for long, because I have little time :(

To begin with, I should finish this spec. I am hesitant to allow Greg to start a
branch, I already did that for ieee 802.15.4 and could not finish it, and no one
offered support to help me with that framework. my experience is that when you
start something like that, you are alone to finish it...

I have a very big todo list... and very little free time!

For the moment I would be grateful if someone could actually read my PDF,
understand it, and evaluate if that would be usable to port a random embedded
TLS library...

How to choose a TLS library? pick the smallest one with a compatible licence...
it will be a challenge to understand how it works!

That's why I suggested writing one from scratch, that may not be more difficult
or time consuming than to understand existing code!

Sebastien

Post by ***@open-modular.com [nuttx]
Hi,
I would be pleased to support Sebastien's lead on that JFFS3 implementation,
Filesystems are a bit more my field.
Bests,
Jerome

[[e-mail] [nuttx]]

Sorry for the misunderstanding. Just one thing i noticed is the paradigm of cipher suite size, that's why i was interested about how matrixSSL took the issue, not the point at all to integrate any non-BSD code.

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
How to choose a TLS library? pick the smallest one with a compatible licence...
it will be a challenge to understand how it works!
That's why I suggested writing one from scratch, that may not be more difficult
or time consuming than to understand existing code!

Totally agree. You feel like inspired about the subject =) As i said crypto isn't really my thing even if i enjoy using it.

By my side, I would be very interested to work on a JFFS3 implementation with someone a bit more experienced than me (Ken,would you be interested?) Greg , about eMMC is there any standard you had in mind ?

Bests,
Jerome

[Marcelo Barros [e-mail] [nuttx]]

Hi again,

About crypto, yes, I am qualified to lead that development, but I'm afraid I

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
will not be able to commit to that for long, because I have little time :(

Count on me. I have some time, probably less than I would like to donate
but ...
Unfortunately my unique related work was a set of crypto functions for
802.15.4, in openwsn stack.
A ccm* implementation, in fact:
https://github.com/marcelobarrosalmeida/ccms

How to choose a TLS library? pick the smallest one with a compatible

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
licence...
it will be a challenge to understand how it works!

I will try again to find some library. Last time I did it the result was
disappointed. Give me some time and I will drop a result here.

Marcelo

[[e-mail] [nuttx]]

An alternative, worthy effort would be to backport the journaling that was added to the existing SmartFS from the Samsun Tiven code base. This would be a pretty simple, porting job... probably only a few days of effort.

You can see the Tiven SmarFS version here: https://git.tizen.org/cgit/rtos/tinyara/tree/os/fs/smartfs/smartfs_smart.c

The part that needs to be ported is contained within CONFIG_SMARTFS_JOURNALING and so should be easy to extract.

Samsung modified the license to Apache, but we would not not taking their code, only some conditional logic that we reimplement. Also Ken Pettit is the copyright holder of all of SmartFS files and has complete say in the licensing of any release.

Note also that you cannot do any direct comparisons between NuttX and TinyARA files because they also reformatted the files to a different coding standard. Perhaps if you ran both the NuttX and TinyARA versions of the files through tools/indent.sh, they might be comparable with diff.

Greg

[Ken Pettit [e-mail] [nuttx]]

All,

At the end of each day, I spend a portion of my 5 minutes of free time
thinking about the SmartFS journaling and JFFS3 (as of yesterday). Not
being a licensing expert, I had wondered if it would be possible to
back-port the Samsung journaling changes to the NuttX code base. It
isn't clear to me at what point type type of port starts to break the
Apache license. There are also some CONFIG_SMARTFS_JOURNALING additions
in the MTD layer as well (see
https://git.tizen.org/cgit/rtos/tinyara/tree/os/fs/driver/mtd/smart.c
for those changes). I haven't studied the journaling changes in depth
to understand them yet, but as Greg said, I suspect it wouldn't take
much to back-port this logic and test it.

As far as a filesystem inspired by JFFS3, that would be a rather large
undertaking. First of all, the JFFS3 document referenced describes some
solutions for the scaleablility of JFFS2, but also raises just about as
many questions as it solves. There is really no description of how to
handle wear-leveling or bad sector management. Is the presumption made
that it would mimic JFFS2 in these areas? Is that adequate and
compatible with the JFFS3 changes proprosed? Can a transactional model
be added relatively easily? What would NOR in-place write optimiztions
look like algorithmically. These are all questions that would need to be
addressed in a more complete spec I think.

Also, looking at the test reports from the user-mode JFFS3
implementation that was implemented, the RAM usage is measured in number
of 100's of KB. I suppose for larger embedded systems with 4-8 MByte
SRAM available, this is okay, but not for a microcontroller based
solution such as STM32F4xxx with 192K total SRAM (for instance). It
isn't clear wht the SRAM requirement would be for a smaller NOR-based FLASH.

Having said all of this, it does seem that NuttX needs a filesystem that
is capable of running on NAND flash. I had some ideas about how to
implement this in SmartFS, but never had the time to persue it
completely. Knowing how involved filesystem development can be, I would
have to give it a bit more thought in my "free time" before deciding to
lead such an effort.

Ken

Post by ***@yahoo.com [nuttx]
An alternative, worthy effort would be to backport the journaling that
was added to the existing SmartFS from the Samsun Tiven code base.
This would be a pretty simple, porting job... probably only a few days
of effort.
https://git.tizen.org/cgit/rtos/tinyara/tree/os/fs/smartfs/smartfs_smart.c
The part that needs to be ported is contained within
CONFIG_SMARTFS_JOURNALING and so should be easy to extract.
Samsung modified the license to Apache, but we would not not taking
their code, only some conditional logic that we reimplement. Also Ken
Pettit is the copyright holder of all of SmartFS files and has
complete say in the licensing of any release.
Note also that you cannot do any direct comparisons between NuttX and
TinyARA files because they also reformatted the files to a different
coding standard. Perhaps if you ran both the NuttX and TinyARA
versions of the files through tools/indent.sh, they might be
comparable with diff.
Greg

[[e-mail] [nuttx]]

You are the copyright holder.. you should not have to worry about the licensing. The rest of us do. As the copyright holder, you are free to change licensing as it suits you.


Also remember that a copyright only covers the presentation of the file, it does not protect the content of the file. That would require a trademark or patent or some other legal mechanism.


So be paranoic safe and non-controversial, you could treat the code as a source of design information. Don't copy-paste. I personally don't think there is any issue for you in any case. But I am not attorney so if you end up spending the rest of your life behind bars, I will offer my sincere apology.


If you are concerned you could also ask Samsung if they have any issue. Since they took megabytes of NuttX code and changed the license, they have some moral obligations. Interesting even though I am the copyright holder on most of the code and I was NEVER asked about the licensing change. I wonder how they can do that? Take someone else's code and arbitrary change the license to make things difficult for others.


Greg

[Ken Pettit [e-mail] [nuttx]]

Hi Greg,

I think duplicating the effort of Samsung's journaling additions to
SmartFS would take quite a bit of time without a large level of
"copy-paste-reformat". They added about 1,500 lines of code to
fs/smartfs/smartfs_utils.c to perform the actual journaling
implementation. All the hooks in smartfs_smart.c are really only
calling into the utils extensions. They also added all the code wrapped
by the CONFIG_SMARTFS_DYNAMIC_HEADER definition, along with new
journaling structure definitions in the header file, etc.

Seems like the only viable way of back-porting the journaling feature
would be to either ask Samsung's permission or just do it and wait for
your sincere apology. But I'm not even sure how to go about asking for
Samsung's permission.

Ken

Post by ***@yahoo.com [nuttx]
You are the copyright holder.. you should not have to worry about the
licensing. The rest of us do. As the copyright holder, you are free
to change licensing as it suits you.
Also remember that a copyright only covers the presentation of the
file, it does not protect the content of the file. That would require
a trademark or patent or some other legal mechanism.
So be paranoic safe and non-controversial, you could treat the code as
a source of design information. Don't copy-paste. I personally don't
think there is any issue for you in any case. But I am not attorney
so if you end up spending the rest of your life behind bars, I will
offer my sincere apology.
If you are concerned you could also ask Samsung if they have any
issue. Since they took megabytes of NuttX code and changed the
license, they have some moral obligations. Interesting even though I
am the copyright holder on most of the code and I was NEVER asked
about the licensing change. I wonder how they can do that? Take
someone else's code and arbitrary change the license to make things
difficult for others.
Greg

[[e-mail] [nuttx]]

Hi Ken,
I'd be interested to work with you on Journalized/Ditributed FileSystems in NuttX in a near future .
I didn't said that JFFS3 offer the solution we want , it was just a 'thinking guideline' like when i mentionned other stuffs.For sure staying original, lightweight and BSD is the goal, at least to me.

So as first non web goal i'd be pleased to work on that journaling backport from Tizen as it might be a worthy work. Just don't expect me to do that very quick :) I'd be pleased to exchange with you about filesystem paradigms.

About 'Backporting', it means to me to mimic principles offered by some base to start , not copying the whole thing (and taking care to avoid it). It's slightly different than violating licence.
At some point it becomes your creation and not someone's else work reuse. You are violating someone else's work if you use it -as is- and don't touch the stuff, but if you rewrite things from scratch helped by some 'source' guideline, it sounds not violating licence to me but getting 'inspired'. At least i see the difference.

Bests regards,
Jerome

[Marcelo Barros [e-mail] [nuttx]]

Sebastian,

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
Here is what I did. I wrote a spec in 2014 (wow, 3 years). It should be updated
and improved but the main goal is expressed and understandable.
Sorry if my question seems naive but how do I fit certificates in this

proposal ? I mean handling certificates not just in https but as regular
action when deploying IoT devices, for instance, some CA public certificate
and a private certificate for the node (kept in safe area, of course).


Marcelo

[Sebastien Lorquet [e-mail] [nuttx]]

Hello

For me, certificates are part of a separate x509 library,also a dependency for TLS.

The reason for that is that I expect that certificate management to be a bit
heavy, and I think it is not a hard requirement for a generic crypto lib: the
user may want to use the crypto lib "just" to do AES with a STM32 and may not
want to carry a full x509 implementation.

I want the crypto core to stay as light as possible and focussed on crypto only.
On protected build, it will live in the "kernel", not in the apps. x509 would
probably be a userland library.

So the crypto lib would only verify the certificate signatures. But if we think
that this feature SHALL be added to the crypto lib, we can do it later, as a
build option.

Sebastien

Post by Marcelo Barros ***@gmail.com [nuttx]
Sebastian,
Here is what I did. I wrote a spec in 2014 (wow, 3 years). It should be updated
and improved but the main goal is expressed and understandable.
Sorry if my question seems naive but how do I fit certificates in this proposal
? I mean handling certificates not just in https but as regular action when
deploying IoT devices, for instance, some CA public certificate and a private
certificate for the node (kept in safe area, of course).
Marcelo

[Marcelo Barros [e-mail] [nuttx]]

Hi Sebastien,

I got your point.
I am worried about the use cases, as I pointed when talking about IoT
deployment and HTTPS.
Obviously it can be shared among different libraries, split into
kernel/user, and so on.
As you said, the proposed crypto lib is part of this solution and there are
some parts missing, like TLS and x509.
Maybe we should cite/list these additional parts and how they are related.

Marcelo

Post by Sebastien Lorquet ***@lorquet.fr [nuttx]
Hello
For me, certificates are part of a separate x509 library,also a dependency for TLS.
The reason for that is that I expect that certificate management to be a bit
heavy, and I think it is not a hard requirement for a generic crypto lib: the
user may want to use the crypto lib "just" to do AES with a STM32 and may not
want to carry a full x509 implementation.
I want the crypto core to stay as light as possible and focussed on crypto only.
On protected build, it will live in the "kernel", not in the apps. x509 would
probably be a userland library.
So the crypto lib would only verify the certificate signatures. But if we think
that this feature SHALL be added to the crypto lib, we can do it later, as a
build option.
Sebastien

Post by Marcelo Barros ***@gmail.com [nuttx]
Sebastian,
Here is what I did. I wrote a spec in 2014 (wow, 3 years). It should be

updated

Post by Marcelo Barros ***@gmail.com [nuttx]
and improved but the main goal is expressed and understandable.
Sorry if my question seems naive but how do I fit certificates in this

proposal

Post by Marcelo Barros ***@gmail.com [nuttx]
? I mean handling certificates not just in https but as regular action

when

Post by Marcelo Barros ***@gmail.com [nuttx]
deploying IoT devices, for instance, some CA public certificate and a

private

Post by Marcelo Barros ***@gmail.com [nuttx]
certificate for the node (kept in safe area, of course).
Marcelo