Re: [PATCH 3/7] IMFS: Simplify IMFS_symlink()
On 09/02/15 22:28, Gedare Bloom wrote:
Nit: should the counted string functions be used?
No, the allocation part takes care that we have enough space in the buffer.
On Mon, Feb 9, 2015 at 3:35 PM, Sebastian Huber
wrote:
---
cpukit/libfs/src/imfs/imfs_symlink.c | 33 +++--
1 file changed, 7 insertions(+), 26 deletions(-)
diff --git a/cpukit/libfs/src/imfs/imfs_symlink.c
b/cpukit/libfs/src/imfs/imfs_symlink.c
index 2ddf99c..0f06446 100644
--- a/cpukit/libfs/src/imfs/imfs_symlink.c
+++ b/cpukit/libfs/src/imfs/imfs_symlink.c
@@ -20,7 +20,6 @@
#include "imfs.h"
-#include
#include
static const IMFS_node_control IMFS_node_control_sym_link;
@@ -32,33 +31,23 @@ int IMFS_symlink(
const char *target
)
{
- char *dup_target;
IMFS_jnode_t *new_node;
/*
- * Duplicate link name
- */
- dup_target = strdup(target);
- if (dup_target == NULL) {
-rtems_set_errno_and_return_minus_one(ENOMEM);
- }
-
- /*
* Create a new link node.
*/
new_node = IMFS_create_node(
parentloc,
&IMFS_node_control_sym_link,
-sizeof( IMFS_sym_link_t ),
+sizeof( IMFS_sym_link_t ) + strlen( target ) + 1,
name,
namelen,
( S_IFLNK | ( S_IRWXU | S_IRWXG | S_IRWXO )),
-dup_target
+RTEMS_DECONST( char *, target )
);
- if (new_node == NULL) {
-free(dup_target);
-rtems_set_errno_and_return_minus_one(ENOMEM);
+ if ( new_node == NULL ) {
+rtems_set_errno_and_return_minus_one( ENOMEM );
}
return 0;
@@ -118,23 +107,15 @@ static IMFS_jnode_t *IMFS_node_initialize_sym_link(
{
IMFS_sym_link_t *sym_link = (IMFS_sym_link_t *) node;
- sym_link->name = arg;
+ sym_link->name = (char *) sym_link + sizeof( *sym_link );
+ strcpy( sym_link->name, arg );
return node;
}
-static void IMFS_node_destroy_sym_link( IMFS_jnode_t *node )
-{
- IMFS_sym_link_t *sym_link = (IMFS_sym_link_t *) node;
-
- free( sym_link->name );
-
- IMFS_node_destroy_default( node );
-}
-
static const IMFS_node_control IMFS_node_control_sym_link = {
.handlers = &IMFS_link_handlers,
.node_initialize = IMFS_node_initialize_sym_link,
.node_remove = IMFS_node_remove_default,
- .node_destroy = IMFS_node_destroy_sym_link
+ .node_destroy = IMFS_node_destroy_default
};
--
2.1.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score/or1k/cpu.c: discard linker-symbols.h include and extern the related variable instead
--- cpukit/score/cpu/or1k/cpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/cpukit/score/cpu/or1k/cpu.c b/cpukit/score/cpu/or1k/cpu.c index 9d1ae49..4d6e9c0 100644 --- a/cpukit/score/cpu/or1k/cpu.c +++ b/cpukit/score/cpu/or1k/cpu.c @@ -14,9 +14,10 @@ #include #include #include -#include #include +extern char bsp_start_vector_table_begin[]; + /** * @brief Performs processor dependent initialization. */ -- 2.1.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score/or1k/cpu.c: discard linker-symbols.h include and extern the related variable instead
This looks great if it had a comment. :) On 2/10/2015 1:50 PM, Hesham ALMatary wrote: > --- > cpukit/score/cpu/or1k/cpu.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/cpukit/score/cpu/or1k/cpu.c b/cpukit/score/cpu/or1k/cpu.c > index 9d1ae49..4d6e9c0 100644 > --- a/cpukit/score/cpu/or1k/cpu.c > +++ b/cpukit/score/cpu/or1k/cpu.c > @@ -14,9 +14,10 @@ > #include > #include > #include > -#include > #include > > +extern char bsp_start_vector_table_begin[]; > + > /** > * @brief Performs processor dependent initialization. > */ -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score/or1k/cpu.c: discard linker-symbols.h include and extern the related variable
--- cpukit/score/cpu/or1k/cpu.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/cpukit/score/cpu/or1k/cpu.c b/cpukit/score/cpu/or1k/cpu.c index 9d1ae49..69845ff 100644 --- a/cpukit/score/cpu/or1k/cpu.c +++ b/cpukit/score/cpu/or1k/cpu.c @@ -14,9 +14,14 @@ #include #include #include -#include #include +/* bsp_start_vector_table_begin is the start address of the vector table + * containing addresses to ISR Handlers. It's defined at the BSP linkcmds + * and may differ from one BSP to another. + */ +extern char bsp_start_vector_table_begin[]; + /** * @brief Performs processor dependent initialization. */ -- 2.1.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score/or1k/cpu.c: discard linker-symbols.h include and extern the related variable
Thanks. One down. Crap. It should have had a comment that closed the PR. :( On 2/10/2015 2:04 PM, Hesham ALMatary wrote: > --- > cpukit/score/cpu/or1k/cpu.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/cpukit/score/cpu/or1k/cpu.c b/cpukit/score/cpu/or1k/cpu.c > index 9d1ae49..69845ff 100644 > --- a/cpukit/score/cpu/or1k/cpu.c > +++ b/cpukit/score/cpu/or1k/cpu.c > @@ -14,9 +14,14 @@ > #include > #include > #include > -#include > #include > > +/* bsp_start_vector_table_begin is the start address of the vector table > + * containing addresses to ISR Handlers. It's defined at the BSP linkcmds > + * and may differ from one BSP to another. > + */ > +extern char bsp_start_vector_table_begin[]; > + > /** > * @brief Performs processor dependent initialization. > */ > -- 2.1.0 -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score/or1k/cpu.c: discard linker-symbols.h include and extern the related variable
On Tue, Feb 10, 2015 at 8:21 PM, Joel Sherrill wrote: > Thanks. One down. > > Crap. It should have had a comment that closed the PR. :( Who should add the comment? The ticket is now closed (fixed). In the future patches, should I tag the ticket/PR number part of the commit message? > On 2/10/2015 2:04 PM, Hesham ALMatary wrote: >> --- >> cpukit/score/cpu/or1k/cpu.c | 7 ++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/cpukit/score/cpu/or1k/cpu.c b/cpukit/score/cpu/or1k/cpu.c >> index 9d1ae49..69845ff 100644 >> --- a/cpukit/score/cpu/or1k/cpu.c >> +++ b/cpukit/score/cpu/or1k/cpu.c >> @@ -14,9 +14,14 @@ >> #include >> #include >> #include >> -#include >> #include >> >> +/* bsp_start_vector_table_begin is the start address of the vector table >> + * containing addresses to ISR Handlers. It's defined at the BSP linkcmds >> + * and may differ from one BSP to another. >> + */ >> +extern char bsp_start_vector_table_begin[]; >> + >> /** >> * @brief Performs processor dependent initialization. >> */ >> -- 2.1.0 > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score/or1k/cpu.c: discard linker-symbols.h include and extern the related variable
On 2/10/2015 2:26 PM, Hesham Moustafa wrote: > On Tue, Feb 10, 2015 at 8:21 PM, Joel Sherrill > wrote: >> Thanks. One down. >> >> Crap. It should have had a comment that closed the PR. :( > Who should add the comment? The ticket is now closed (fixed). In the > future patches, should I tag the ticket/PR number part of the commit > message? I think the procedure is to use the git commit message like this: === or1k/cpu.c: Eliminate dependency on BSP provided .h file close === You just posted a patch and I did remember to add the --author info but forgot the PR. >> On 2/10/2015 2:04 PM, Hesham ALMatary wrote: >>> --- >>> cpukit/score/cpu/or1k/cpu.c | 7 ++- >>> 1 file changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git a/cpukit/score/cpu/or1k/cpu.c b/cpukit/score/cpu/or1k/cpu.c >>> index 9d1ae49..69845ff 100644 >>> --- a/cpukit/score/cpu/or1k/cpu.c >>> +++ b/cpukit/score/cpu/or1k/cpu.c >>> @@ -14,9 +14,14 @@ >>> #include >>> #include >>> #include >>> -#include >>> #include >>> >>> +/* bsp_start_vector_table_begin is the start address of the vector table >>> + * containing addresses to ISR Handlers. It's defined at the BSP linkcmds >>> + * and may differ from one BSP to another. >>> + */ >>> +extern char bsp_start_vector_table_begin[]; >>> + >>> /** >>> * @brief Performs processor dependent initialization. >>> */ >>> -- 2.1.0 >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.comOn-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available(256) 722-9985 >> -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score/or1k/cpu.c: discard linker-symbols.h include and extern the related variable
Yeah if you don't mind, when you now the ticket number, just include something like "closes #xyz" On Tue, Feb 10, 2015 at 3:26 PM, Hesham Moustafa wrote: > On Tue, Feb 10, 2015 at 8:21 PM, Joel Sherrill > wrote: >> Thanks. One down. >> >> Crap. It should have had a comment that closed the PR. :( > Who should add the comment? The ticket is now closed (fixed). In the > future patches, should I tag the ticket/PR number part of the commit > message? >> On 2/10/2015 2:04 PM, Hesham ALMatary wrote: >>> --- >>> cpukit/score/cpu/or1k/cpu.c | 7 ++- >>> 1 file changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git a/cpukit/score/cpu/or1k/cpu.c b/cpukit/score/cpu/or1k/cpu.c >>> index 9d1ae49..69845ff 100644 >>> --- a/cpukit/score/cpu/or1k/cpu.c >>> +++ b/cpukit/score/cpu/or1k/cpu.c >>> @@ -14,9 +14,14 @@ >>> #include >>> #include >>> #include >>> -#include >>> #include >>> >>> +/* bsp_start_vector_table_begin is the start address of the vector table >>> + * containing addresses to ISR Handlers. It's defined at the BSP linkcmds >>> + * and may differ from one BSP to another. >>> + */ >>> +extern char bsp_start_vector_table_begin[]; >>> + >>> /** >>> * @brief Performs processor dependent initialization. >>> */ >>> -- 2.1.0 >> >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.comOn-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available(256) 722-9985 >> > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score/or1k/cpu.c: discard linker-symbols.h include and extern the related variable
> On Feb 10, 2015, at 15:30 , Joel Sherrill wrote: > > On 2/10/2015 2:26 PM, Hesham Moustafa wrote: >> On Tue, Feb 10, 2015 at 8:21 PM, Joel Sherrill >> wrote: >>> Thanks. One down. >>> >>> Crap. It should have had a comment that closed the PR. :( >> Who should add the comment? The ticket is now closed (fixed). In the >> future patches, should I tag the ticket/PR number part of the commit >> message? > I think the procedure is to use the git commit message like this: > > === > or1k/cpu.c: Eliminate dependency on BSP provided .h file > > close > === > > You just posted a patch and I did remember to add the --author > info but forgot the PR. >>> On 2/10/2015 2:04 PM, Hesham ALMatary wrote: --- cpukit/score/cpu/or1k/cpu.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/cpukit/score/cpu/or1k/cpu.c b/cpukit/score/cpu/or1k/cpu.c index 9d1ae49..69845ff 100644 --- a/cpukit/score/cpu/or1k/cpu.c +++ b/cpukit/score/cpu/or1k/cpu.c @@ -14,9 +14,14 @@ #include #include #include -#include #include +/* bsp_start_vector_table_begin is the start address of the vector table + * containing addresses to ISR Handlers. It's defined at the BSP linkcmds + * and may differ from one BSP to another. + */ +extern char bsp_start_vector_table_begin[]; + /** * @brief Performs processor dependent initialization. */ -- 2.1.0 >>> -- >>> Joel Sherrill, Ph.D. Director of Research & Development >>> joel.sherr...@oarcorp.comOn-Line Applications Research >>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>> Support Available(256) 722-9985 >>> > I'm not sure what it fixes, but removing a header file and putting an "extern" declaration in a C file instead needs to be explained in a comment. In general that's moving backwards, I guess the comment implies something (that it may differ from one BSP to another), but since an extern in C code is bad practice it should be better explained. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score/or1k/cpu.c: discard linker-symbols.h include and extern the related variable
On 2/10/2015 3:46 PM, Peter Dufault wrote: >> On Feb 10, 2015, at 15:30 , Joel Sherrill wrote: >> >> On 2/10/2015 2:26 PM, Hesham Moustafa wrote: >>> On Tue, Feb 10, 2015 at 8:21 PM, Joel Sherrill >>> wrote: Thanks. One down. Crap. It should have had a comment that closed the PR. :( >>> Who should add the comment? The ticket is now closed (fixed). In the >>> future patches, should I tag the ticket/PR number part of the commit >>> message? >> I think the procedure is to use the git commit message like this: >> >> === >> or1k/cpu.c: Eliminate dependency on BSP provided .h file >> >> close >> === >> >> You just posted a patch and I did remember to add the --author >> info but forgot the PR. On 2/10/2015 2:04 PM, Hesham ALMatary wrote: > --- > cpukit/score/cpu/or1k/cpu.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/cpukit/score/cpu/or1k/cpu.c b/cpukit/score/cpu/or1k/cpu.c > index 9d1ae49..69845ff 100644 > --- a/cpukit/score/cpu/or1k/cpu.c > +++ b/cpukit/score/cpu/or1k/cpu.c > @@ -14,9 +14,14 @@ > #include > #include > #include > -#include > #include > > +/* bsp_start_vector_table_begin is the start address of the vector table > + * containing addresses to ISR Handlers. It's defined at the BSP linkcmds > + * and may differ from one BSP to another. > + */ > +extern char bsp_start_vector_table_begin[]; > + > /** > * @brief Performs processor dependent initialization. > */ > -- 2.1.0 -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 > I'm not sure what it fixes, but removing a header file and putting an > "extern" declaration in a C file instead needs to be explained in a comment. > In general that's moving backwards, I guess the comment implies something > (that it may differ from one BSP to another), but since an extern in C code > is bad practice it should be better explained. The overarching rule is that code in cpukit/ SHALL not include anything from the BSP. It possibly could be moved to cpu.h or a port provided file that defines the symbols expected to be provided by the BSP. I am happy with anything that moves us in a better direction. This was breaking the dependency. > Peter > - > Peter Dufault > HD Associates, Inc. Software and System Engineering > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: BSP requests.
Raspberry Pi times on my PC ( 6 core AMD, 8GB RAM, SSD , Ubuntu 14.04 ) : Standard build system: Bootstrap : 7m4s Configure step: 8s Build: 3m15s Size of RTEMS Tree after bootstrap: 308Mbytes Waf build: configure: ~4s build with tests: 29s Size of RTEMS tree : 188Mbytes Nice improvement! ( although I did not run the standard build with the -j 14 flags, would that speed up the bootstrap? ) Will this waf system work on windows hosts? Thanks, Alan On Tue, Feb 10, 2015 at 12:12 AM, Amar Takhar wrote: > On 2015-02-09 17:32 +, Cudmore, Alan P. (GSFC-5820) wrote: > > I would like to request Raspberry Pi, LEON3, and m68k/mcf5235. > > arm/raspberrypi has been added. > > From scratch it took me exactly 4m10s to add this including the time to > build > RTEMS + all tests: > > > http://git.rtems.org/amar/waf.git/commit/?id=a238716ffddeb74410f6795547129beecc7cfde7 > > > Amar. > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: BSP requests.
On 11/02/2015 1:57 pm, Alan Cudmore wrote: Raspberry Pi times on my PC ( 6 core AMD, 8GB RAM, SSD , Ubuntu 14.04 ) : Standard build system: Bootstrap : 7m4s Configure step: 8s Build: 3m15s Size of RTEMS Tree after bootstrap: 308Mbytes Waf build: configure: ~4s build with tests: 29s Size of RTEMS tree : 188Mbytes Nice improvement! ( although I did not run the standard build with the -j 14 flags, would that speed up the bootstrap? ) The RSB has a sb-bootstrap that makes the bootstrap run in parallel. Will this waf system work on windows hosts? Yes. Using mingw64 (or native Windows) built tools should give you excellent performance. I am working on the RSB using MSYS2 (https://msys2.github.io/). MSYS2 is well worth a look and currently gets a big tick from me. Nice packaging (pacman) and up to date and things seem to just work. I am currently using tmux in a shell on Windows and it is just like FreeBSD or Linux. I have the tools building up to gdb and I am having issues with Python. The Python MSI installer from python.org provides .lib files which mingw64 does not like. There are a few possible work solutions I am looking at but nothing I am happy with. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Waf branch - Configuration [4/6]
On 10/02/2015 8:20 am, Amar Takhar wrote: On 2015-02-10 08:15 +1100, Chris Johns wrote: Look in config.cfg when you do a 'waf' configure for all the available options these are exposed there. Do I just edit these options ? Yes. If so, is this temporary or the way we do this ? I am considering the use case of a project with a release process that includes building RTEMS. I am not sure patching this file is a good idea as it could be a little fragile. What do you mean by 'patching'? It is a configuration file that is generated by using 'waf config'. And as I see below options can be altered in a controlled manner instead of a local patch applied after the config phase. This is what I was meaning. I'm planning on adding an option to support having different config files. I also want to add support for defining options during 'waf config'. Great. So I can take this to mean I will have a way to say "no L2 cache on Zynq" on the command line to 'waf config' ? Environment variables will never be supported or switches during the 'build' phase. +1 on both these. Thanks so much. When changing options configure must always be re-run this is to ensure the build is always done correctly. Ok. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Waf branch - Configuration [4/6]
On 2015-02-11 14:16 +1100, Chris Johns wrote: > And as I see below options can be altered in a controlled manner instead > of a local patch applied after the config phase. This is what I was meaning. Ah, yes it's very controlled in config.cfg. The options are verified (not fully, yet) for sanity as well. > > I'm planning on adding an option to support having different config files. > > I > > also want to add support for defining options during 'waf config'. > > Great. So I can take this to mean I will have a way to say "no L2 cache > on Zynq" on the command line to 'waf config' ? Yes, so you can define --config="L2_CACHE=False" for instance. I'm not sure of the format yet I still do not want to support environment variables. > > Environment > > variables will never be supported or switches during the 'build' phase. > > +1 on both these. Thanks so much. Great and no problem! Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: BSP requests.
On 2015-02-10 21:57 -0500, Alan Cudmore wrote: > Raspberry Pi times on my PC ( 6 core AMD, 8GB RAM, SSD , Ubuntu 14.04 ) : > > Standard build system: > ? ? Bootstrap : 7m4s > ? ? Configure step: 8s > ? ? Build: 3m15s? > > ? ? Size of RTEMS Tree after bootstrap: 308Mbytes > > Waf build: > ? ? configure: ~4s > ? ? build with tests: 29s > > ? ? Size of RTEMS tree : 188Mbytes > > Nice improvement! ( although I did not run the standard build with the -j 14 > flags, would that speed up the bootstrap? ) bootstrap for the old build? For waf adding -j CPUS+1 will definitely speed up the build. > Will this waf system work on windows hosts? Yes, waf works perfectly fine on windows. I'm not sure how many assumptions are made for unix right now I haven't tried it on Windows yet. Give it a shot and let me know. :) Waf will integrate with MSVC as well if anyone would like to use that as an IDE it would be possible. Run waf with the -p command. Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
