Re: [PATCH v2] rtems: Generate

[Sebastian Huber]

On 08/10/2020 08:18, Sebastian Huber wrote:


On 07/10/2020 21:12, Gedare Bloom wrote:


On Wed, Oct 7, 2020 at 11:40 AM Sebastian Huber
 wrote:

On 07/10/2020 17:26, Gedare Bloom wrote:


Thinking about the discussion about ordering directives in the docs,
the generated header reorders directives also. Is it also doing
generation by alphabetical order?

Should we consider using the same order as defined for the API
documentation? I guess this would make the Doxygen consistently
ordered wrt the docs.

This would make things a lot more complicated. For the Doxygen we have
to take also the C language into account. For example before you use a
type, it must be declared. This is done through automatic dependency
tracking and a topological sorting. Adding a manual order into this
stuff would be difficult.

Yeah, maybe. The value of ordering in the headers and doxygen is
probably less than in a manual. We can revisit later if we like. It
shouldn't be too hard in an API header (as opposed to an
implementation header with inlines) to group first the typedefs and
then the function declarations. But I have no real concern about the
ordering here, it was just a thought.


Good, I added a ticket for this:

https://devel.rtems.org/ticket/4134#ticket

It is not on my high priority list.


It turned out to be pretty easy to fix with a bubble sort:

https://git.rtems.org/rtems-central/commit/?id=3f3e088740abc2d00cf9986452bef81eae83260e

Generated :

https://git.rtems.org/rtems/tree/cpukit/include/rtems/io.h

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

Re: [PATCH] testsuites/samples/fileio - Increase of stack size

[Chris Johns]

On 10/10/20 1:05 am, Frank Kühndel wrote:
> I can open a ticket for 5 and 6 if you like.

Please test on 5.1 and if the problem exists then raise a ticket on 5 for the
next milestone.

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

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Chris Johns]

On 10/10/20 7:35 am, Alan Cudmore wrote:
> After doing a lot of tracing through my application, it looks like
> malloc_info works fine before we start our cFS application, but it
> blocks after the cFS is initialized. This suggests some sort of memory
> corruption.
> I started by instrumenting our code to call malloc info during various
> stages of application initialization, and finally narrowed it down to
> the code where we create a RAM Disk and format it with RFS.
> (skipping a bunch of other malloc based troubleshooting.. )
> After I followed the issue into the RFS init, I was able to narrow
> down the place where malloc_info stopped working to here:
> https://git.rtems.org/rtems/tree/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c?h=5#n637
> During the RFS format process.
> In this section of the code, the size variable is 0, meaning it will
> exit the for loop and then return from the function, but it increments
> the "search_map" variable and writes to memory through the pointer one
> more time before exiting the loop and function. It's at this point
> where malloc_info starts blocking.
> 
> It seems to me that this if block should be skipped when size == 0. I
> tried that and the malloc_info issue seems to be fixed.

Would you be able to create a test case for this? The test is ..

https://git.rtems.org/rtems/tree/testsuites/fstests/fsrfsbitmap01/test.c

Or if you could please provide the values in `control` I can add the test.

> Is this an RFS bug writing into other memory, or is this last write
> needed before the function updates?

It would seem so.

> If this looks like a bug, should I write a ticket and provide a patch?

Yes please. It would be nice to have a test case that fails so we can isolate
the cause.

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

Re: Building libbsd after installing libbsd

[Chris Johns]

On 9/10/20 9:13 am, Joel Sherrill wrote:
> On Thu, Oct 8, 2020 at 4:59 PM Chris Johns  > wrote:
> 
> On 9/10/20 8:24 am, Joel Sherrill wrote:
> > Hi
> >
> > I am not sure if this is avoidable but it is surprising. 
> >
> > + build and install rtems to $prefix
> >
> > + build and install libbsd to $prefix
> >
> > + ./waf will then rebuild some files. It appears to be using installed 
> headers
> 
> Is this in rtems or libbsd?
> 
> libbsd. RTEMS can be install and then "./waf" does nothing like you would 
> expect. 
> 

OK.

> > + Then ./waf install and it will also rebuild some files before fails.
> 
> Again which or is it both? 
> 
> libbsd only 

OK

> > I think there is no way to avoid this and waf for libbsd should detect 
> that it
> > sees headers installed from itself and give an error that you need a 
> clean
> > $prefix to build.
> 
> Waf uses an md5 checksum for dependency checking so replacing a file with 
> the
> same file should not trigger a rebuild, the contents have to have 
> changed. This
> is different to make and others that stat a file.
> 
> 
> Then something is confusing it. The first build is with the file in the libbsd
> tree. Running waf again, I think it is using the installed one.  

Oh OK. If the BSP is installed to the same prefix then this is hard to avoid.

> > Just to make sure there wasn't interference between two different BSPs, 
> I
> built
> > and installed one followed by a second different one. That went fine. 
> >
> > The behavior is bizarre and the weird compilation errors are mysterious 
> until
> > you repeat the steps enough to figure it out. Unless someone knows how 
> the
> build
> > can avoid this, I think we need an error check early in the configure
> process.
> 
> This implies some files in one package are overwriting a file installed by
> another package. That should not happen.
> 
> It would be nice to install a manifesto of the files a package installs. 
> I am
> sure it would aid deployment for those wanting to package and deploy 
> RTEMS with
> rpm, deb or what ever else. It would help here as the contents of each 
> could be
> reviewed.
> 
> It would be nice but I don't think that solves this. 

Agreed.

> > I think it is sufficient to check if machine/rtems-bsd-nexus-bus.h is
> installed
> > already ad give a nice explanation and failure during configure.
> 
> Adding this would limit those develop and maintaining these packages.
> 
> The behavior now seems to confuse in-tree and installed header files is my 
> guess.

I have not seen this. I am sure it does.
>  
> 
> 
> > Thoughts?
> 
> Should we understand the interactions before we decide on a solution?
> 
> 
> Sure. If there really is an avoidable bug.

It should be looked into and resolved.

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

Re: [PATCH v2] rtems: Generate

[Chris Johns]

On 12/10/20 1:16 am, Sebastian Huber wrote:
> On 08/10/2020 08:18, Sebastian Huber wrote:
> 
>> On 07/10/2020 21:12, Gedare Bloom wrote:
>>
>>> On Wed, Oct 7, 2020 at 11:40 AM Sebastian Huber
>>>  wrote:
 On 07/10/2020 17:26, Gedare Bloom wrote:

> Thinking about the discussion about ordering directives in the docs,
> the generated header reorders directives also. Is it also doing
> generation by alphabetical order?
>
> Should we consider using the same order as defined for the API
> documentation? I guess this would make the Doxygen consistently
> ordered wrt the docs.
 This would make things a lot more complicated. For the Doxygen we have
 to take also the C language into account. For example before you use a
 type, it must be declared. This is done through automatic dependency
 tracking and a topological sorting. Adding a manual order into this
 stuff would be difficult.
>>> Yeah, maybe. The value of ordering in the headers and doxygen is
>>> probably less than in a manual. We can revisit later if we like. It
>>> shouldn't be too hard in an API header (as opposed to an
>>> implementation header with inlines) to group first the typedefs and
>>> then the function declarations. But I have no real concern about the
>>> ordering here, it was just a thought.
>>
>> Good, I added a ticket for this:
>>
>> https://devel.rtems.org/ticket/4134#ticket
>>
>> It is not on my high priority list.
> 
> It turned out to be pretty easy to fix with a bubble sort:
> 
> https://git.rtems.org/rtems-central/commit/?id=3f3e088740abc2d00cf9986452bef81eae83260e


Nice. The contextlib has changed since python 2, the redirect looks interesting.

> Generated :
> 
> https://git.rtems.org/rtems/tree/cpukit/include/rtems/io.h

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

Re: waf for RTEMS Applications

[Chris Johns]

On 10/10/20 9:26 am, Joel Sherrill wrote:
> I decided to try this out today. The users manual is pretty good but has some
> spots which lean to 5 and haven't been updated. 

Great.

> Also mentions updating your PATH
> early and isn't really needed until rtems-run can't find qemu. :)

I have treated qemu like any other command I have on my host, there needs to be
a valid $PATH. I never install qemu into an RTEMS prefix so a wipe and rebuild
does not require a qemu rebuild.

I wonder if having a $PATH set to the RTEMS Tools prefix plus having qemu
installed there is just a specific case happened to work so you assumed this was
planed or expected?

There no specific support in the ecosystem to treat qemu as an office RTEMS
tool. I am not sure how you would handle this.

> My big questions are from this exercise are:
> 
> + How would one use this without using git

Who does not use git? ;) :)

Copy? I checked 5.1 and there no tarball in the release and I think there 
should be.
 
> + Without using git submodules?

Manually but you would need to track the repo. You would need to treat it the
same as any other piece of source in a git repo you wanted to include in an
application.

> + What if I didn't want any external network references? I don't see waf or
> rtems_waf in the release image.

That would be a bug in the release script. The release script handles
rtems-libbsd now. Creating a tarball from git with submodules has a few steps.
 
> + rtems-run's output seemed cryptic when it couldn't find the simulator to 
> run.

Please raise a ticket on rtems-run (rtems-test will be included) if you think we
could do better.

> It was easy enough after accounting for odd 5/6 items, misc issues that are OK
> for me to encounter but not a starting user, and the example worked. I am just
> putting on my user hat as best I can to comment on the process.

This is really great feedback. I do not think anything here is major, just a
bunch of small bits that need to work together.

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

Re: [PATCH] shell: Remove not functioning fdisk mount/unmount command

[Chris Johns]

Frank,

As Gedare has said great analysis. Thank you.

I have no idea why I did not test the `fdisk mound/unmount` command, maybe I did
not know it existed, but it has proved to be a good way for us to know the old
interface is not used.

The change is OK to push.

On 10/10/20 3:03 am, Peter Dufault wrote:
> Yes, and you don't want to support two ways to do something if it hasn't been 
> noticed in ten years.

Yes and the mount command I added had a universal way to pass in specific file
system options.

Chris

>> On Oct 9, 2020, at 11:37 , Gedare Bloom  wrote:
>>
>> Excellent analysis. I would like Chris to weigh in, but the rationale
>> to remove instead of try to fix makes sense because it is basically an
>> undocumented shell API.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel