cpukit/libi2c/libi2c.c rtems_libi2c_register_bus this function saves the specified i2c bus name in a malloced space, but in the end of this function, the malloced space is freed. And in rtems_libi2c_register_drv , busses[busno].name is used to construct the specific device file.
At 2014-12-10 13:34:26, devel-requ...@rtems.org wrote: >Send devel mailing list submissions to > devel@rtems.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.rtems.org/mailman/listinfo/devel >or, via email, send a message with subject or body 'help' to > devel-requ...@rtems.org > >You can reach the person managing the list at > devel-ow...@rtems.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of devel digest..." > > >Today's Topics: > > 1. Re: [PATCH] License: add a 2-clause BSD license file, and > relicense a sparc64 file (Joel Sherrill) > 2. Re: [PATCH] Correct a race condition between the e500 core > decrementer wrapping and the tick interrupt being handled > (Nick Withers) > 3. Re: [PATCH 3/9] sb: Do not report current date (Chris Johns) > 4. Re: Add an --enable-httpd-websocket configure option to > enable WebSocket in the Mongoose HTTP server (Nick Withers) > 5. Re: [PATCH] Teach rtems_tarfs_load() about symlinks (Nick Withers) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Tue, 9 Dec 2014 08:04:10 -0600 >From: Joel Sherrill <joel.sherr...@oarcorp.com> >To: Thomas Doerfler <thomas.doerf...@embedded-brains.de>, > "devel@rtems.org" <devel@rtems.org> >Subject: Re: [PATCH] License: add a 2-clause BSD license file, and > relicense a sparc64 file >Message-ID: <5487015a.9010...@oarcorp.com> >Content-Type: text/plain; charset="windows-1252" > > >On 12/9/2014 1:55 AM, Thomas Doerfler wrote: >> Gedare, >> >> I am also confused about mentioning your copyright in the "LICENSE.2" file. >> >> the patch for lib/libbsp/sparc64/niagara/startup/bspclean.c is fine, it >> tells you are the originator of this file and you apply "License.2" to it. >> >> What exactly does your copyright notice in "License.2" want to say: >> - That you are coypright holder of the license text? >> - That you are (partial) copyright holder of ALL RTEMS source files and >> they are available under this license? >> - That you are the copyright holder of SOME RTEMS files and they are >> available under this license? >> - That any contribution you added to RTEMS is under this license? >> >> IMHO such a global statement, leads to confusion and misinterpretation. >> I may even make a future relicensing more difficult. >I suggested adding a paragraph that tried to clarify this but ultimately >we need a (a) license.2 file and (b) list of people who have agreed to >relicense code to BSD-2 paragraph. >> I personally would prefer to have the "LICENSE.2" file in place (without >> the "Copyright Gedare Bloom" statement") and then each file pointing to >> the corresponding license. >> >> wkr, >> >> Thomas. >> >> >> Am 08.12.2014 um 20:57 schrieb Gedare Bloom: >>> --- >>> LICENSE.2 | 23 >>> ++++++++++++++++++++++ >>> .../lib/libbsp/sparc64/niagara/startup/bspclean.c | 5 +---- >>> 2 files changed, 24 insertions(+), 4 deletions(-) >>> create mode 100644 LICENSE.2 >>> >>> diff --git a/LICENSE.2 b/LICENSE.2 >>> new file mode 100644 >>> index 0000000..e85f6bb >>> --- /dev/null >>> +++ b/LICENSE.2 >>> @@ -0,0 +1,23 @@ >>> + >>> +Copyright (C) 2014. Gedare Bloom. >>> + >>> +Redistribution and use in source and binary forms, with or without >>> +modification, are permitted provided that the following conditions are met: >>> + >>> +1. Redistributions of source code must retain the above copyright notice, >>> this >>> +list of conditions and the following disclaimer. >>> + >>> +2. Redistributions in binary form must reproduce the above copyright >>> notice, >>> +this list of conditions and the following disclaimer in the documentation >>> +and/or other materials provided with the distribution. >>> + >>> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" >>> +AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE >>> +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE >>> ARE >>> +DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE >>> LIABLE >>> +FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL >>> +DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR >>> +SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER >>> +CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT >>> LIABILITY, >>> +OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE >>> USE >>> +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. >>> diff --git a/c/src/lib/libbsp/sparc64/niagara/startup/bspclean.c >>> b/c/src/lib/libbsp/sparc64/niagara/startup/bspclean.c >>> index 88750aa..6c622b6 100644 >>> --- a/c/src/lib/libbsp/sparc64/niagara/startup/bspclean.c >>> +++ b/c/src/lib/libbsp/sparc64/niagara/startup/bspclean.c >>> @@ -1,10 +1,7 @@ >>> /* >>> * Copyright (c) 2014 Gedare Bloom. >>> * >>> - * The license and distribution terms for this file may be >>> - * found in the file LICENSE in this distribution or at >>> - * http://www.rtems.org/license/LICENSE. >>> - */ >>> + * This file's license is 2-clause BSD as in this distribution's LICENSE.2 >>> file. */ >>> >>> #include <bsp.h> >>> #include <bsp/bootcard.h> >>> > >-- >Joel Sherrill, Ph.D. Director of Research & Development >joel.sherr...@oarcorp.com On-Line Applications Research >Ask me about RTEMS: a free RTOS Huntsville AL 35805 >Support Available (256) 722-9985 > > > >------------------------------ > >Message: 2 >Date: Wed, 10 Dec 2014 12:53:28 +1100 >From: Nick Withers <nick.with...@anu.edu.au> >To: Sebastian Huber <sebastian.hu...@embedded-brains.de> >Cc: devel@rtems.org >Subject: Re: [PATCH] Correct a race condition between the e500 core > decrementer wrapping and the tick interrupt being handled >Message-ID: <1418176408.1089.20.ca...@nuc211.anu.edu.au> >Content-Type: text/plain; charset="us-ascii" > >On Wed, 2014-12-03 at 08:09 +0100, Sebastian Huber wrote: >> Hello Nick, >> >> to disable TCR[ARE] is not the right fix. You have to check the >> TSR[DIS] register in the nanoseconds extension. See for example >> lpc-clock-config.c for an example. > >Hi Sebastian, > >Thanks for your help, 'fraid I need to lean on you a little more... > >I don't understand how the proposed solution (or that in >lpc-clock-config.c) can work properly in the case where the nanoseconds >extension could be queried multiple times with an interrupt lock held >(which I believe disables interrupts), preventing the tick from being >incremented, as I believe happens in spnsext01. > >lpc-clock-config.c's lpc_clock_nanoseconds_since_last_tick(), if I'm >understanding it correctly, says "Ah, there's an interrupt pending, so >we need to add another tick period to our current timer value". Cool >bananas. But what if it's called again with the same interrupt still >pending? The timer counter may have wrapped again and we could return an >earlier time. > >...Couldn't we? What am I missing? > >Cheers :-) >-- >Nick Withers > >Embedded Systems Programmer >Department of Nuclear Physics, Research School of Physics and Engineering >The Australian National University (CRICOS: 00120C) > > > >------------------------------ > >Message: 3 >Date: Wed, 10 Dec 2014 14:05:32 +1100 >From: Chris Johns <chr...@rtems.org> >To: Sebastian Huber <sebastian.hu...@embedded-brains.de>, > devel@rtems.org >Subject: Re: [PATCH 3/9] sb: Do not report current date >Message-ID: <5487b87c.1080...@rtems.org> >Content-Type: text/plain; charset=windows-1252; format=flowed > >On 9/12/2014 6:00 pm, Sebastian Huber wrote: >> >> On 08/12/14 21:52, Chris Johns wrote: >>> On 8/12/2014 5:48 pm, Sebastian Huber wrote: >>>> This makes the report reproducible. >>> >>> I think the report should include a date. I do not see any advantage >>> having reproducible reports. The report captures the specific instance >>> of the build. >> >> Yes, it captures a specific instance of the build, but why should the >> date be part of it? > >An instance is what and when. It has a specific locale and this needs to >be captured. > >> What can you do with this date? > >It forms part of the record used to create a formal release. If it is >not captured in the report when the tools are built it needs to captured >elsewhere, ie by the user. > >> >> My goal is to get rid of anything that is host dependent, e.g. the home >> directory path. >> > >The tools built are specific to the that host and so we need to capture >what we need. There is always the possibility things can be removed or >have missed. > >The exact configuration of a host is outside the bounds of what we need >to provide. > >> If you really want the date, then I omit this patch. For XML report >> however I would like to omit the date nonetheless. > >I would like it to remain for the reports. > >> >>> The purpose behind the report is to have an output from the process >>> that can feed into a QA audit type process. Part of the purpose of the >>> RTEMS tools is to create an RTEMS Ecosystem and this is about pushing >>> down into RTEMS report generation for these parts of process so users >>> can feed them up into their configuration management system. >> >> My intention to use this report is to add it eventually to the RTEMS >> sources to that you can determine the tool chain that can build exactly >> this RTEMS version. Since the RSB commit is included in the report, you >> can use the RSB in the best case to build the tools. In the worst case >> the report should contain everything that is necessary to build it >> manually. >> > >This is different and not the purpose of the report. I am happy >internally we share the code to do this but the report we create and >install when the tools are built needs specific details. This is the >purpose of the report. > >I suggest we consider making an sb-source command and add it. This >command can be run to create a suitable configuration file plus fetch >and package all the source and patches without having to run a build >process. > >Chris > > >------------------------------ > >Message: 4 >Date: Wed, 10 Dec 2014 16:05:52 +1100 >From: Nick Withers <nick.with...@anu.edu.au> >To: Sebastian Huber <sebastian.hu...@embedded-brains.de> >Cc: rtems-de...@rtems.org >Subject: Re: Add an --enable-httpd-websocket configure option to > enable WebSocket in the Mongoose HTTP server >Message-ID: <1418187952.1089.21.ca...@nuc211.anu.edu.au> >Content-Type: text/plain; charset="us-ascii" > >On Wed, 2014-12-03 at 08:12 +0100, Sebastian Huber wrote: >> On 03/12/14 08:05, Nick Withers wrote: >> > On Wed, 2014-12-03 at 07:48 +0100, Sebastian Huber wrote: >> >> >Hello Nick, >> >> > >> >> >what is the benefit of providing this WebSocket stuff? >> > I personally use it to serve dynamic content to web clients. The >> > callback mechanism that Mongoose provides allows me to hook these >> > requests into my application and reply with whatever I like. >> > >> > Without processes, CGI's out of the question (well, that's my >> > understanding - haven't looked at it for ages) and I'm not aware of >> > other viable alternatives...? Having the embedded-side constantly write >> > data to files so they could be statically served just wouldn't be >> > workable with this application. >> > >> > Does that make sense? Perhaps I should shoot you off some examples of >> > where I use it? >> >> Ok, I think then we should first enable this unconditionally. If >> someone has code size problems, then we can start with a configure >> option, but this is only a future optimization. >> >> This new feature should have a test case in the existing test. > >How's the attached? >-- >Nick Withers > >Embedded Systems Programmer >Department of Nuclear Physics, Research School of Physics and Engineering >The Australian National University (CRICOS: 00120C) >-------------- next part -------------- >A non-text attachment was scrubbed... >Name: mghttpd-WebSocket.patch >Type: text/x-patch >Size: 8582 bytes >Desc: not available >URL: ><http://lists.rtems.org/pipermail/devel/attachments/20141210/6cf7f7b0/attachment-0001.bin> > >------------------------------ > >Message: 5 >Date: Wed, 10 Dec 2014 16:34:06 +1100 >From: Nick Withers <nick.with...@anu.edu.au> >To: Sebastian Huber <sebastian.hu...@embedded-brains.de> >Cc: rtems-de...@rtems.org >Subject: Re: [PATCH] Teach rtems_tarfs_load() about symlinks >Message-ID: <1418189646.1089.28.ca...@nuc211.anu.edu.au> >Content-Type: text/plain; charset="us-ascii" > >On Wed, 2014-12-03 at 08:23 +0100, Sebastian Huber wrote: >> >> On 03/12/14 07:07, Nick Withers wrote: >> >> > Anyone be interested in committing this? >> > >> > On Fri, 2014-03-07 at 14:37 +1100, Nick Withers wrote: >> > > > Hi all, >> > > > >> > > > The attached patch teaches rtems_tarfs_load() about symlinks, as well >> > > > as >> > > > making it fail if it encounters an unsupported tar file entry type >> > > > (e.g., hard links) rather than silently ignoring the 512 B block. >> > > > >> > > > It tries to be consistent with the existing code which doesn't e.g. >> > > > check tar string field NUL termination or printf() on error. >> > -- Nick Withers Embedded Systems Programmer Department of Nuclear >> > Physics, Research School of Physics and Engineering The Australian >> > National University (CRICOS: 00120C) >> > >> > rtems_tarfs_load_symlinks.patch >> > >From 165b5fd7e0c2d5042a69d209a360522f80697d71 Mon Sep 17 00:00:00 2001 >> > From: Nick Withers <nick.with...@anu.edu.au> >> > Date: Fri, 7 Mar 2014 14:23:30 +1100 >> > Subject: [PATCH] Teach rtems_tarfs_load() about symlinks >> > >> > rtems_tarfs_load() will now also fail if it encounters unsupported tar >> > file entry types (e.g., hard links) >> >> I am not sure if this should now fail if it encounters an unsupported >> tar file entry. This may crash applications that worked for a long >> time. > >Here's a version that doesn't fail like this. > ><Discussion> >Personally, I'd much rather it did (for example, as I recall, there's >nothing to say that an unsupported entry only occupies one block, so you >could be stuffed anyway) and would think it would be an obvious failure >if you're checking the return code. If you're not, I have no sympathy >for you :-P > >I also think that people porting an existing app to RTEMS 4.11 should be >a) not releasing until RTEMS 4.11 itself is finalised OR accepting the >potential for breakage working off off the moving HEAD target and b) >testing thoroughly. > >But hey - I don't have to deal with upset users! ></Discussion> >-- >Nick Withers > >Embedded Systems Programmer >Department of Nuclear Physics, Research School of Physics and Engineering >The Australian National University (CRICOS: 00120C) >-------------- next part -------------- >A non-text attachment was scrubbed... >Name: rtems_tarfs_load_symlinks.patch >Type: text/x-patch >Size: 3132 bytes >Desc: not available >URL: ><http://lists.rtems.org/pipermail/devel/attachments/20141210/3f0cc7a5/attachment.bin> > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >devel mailing list >devel@rtems.org >http://lists.rtems.org/mailman/listinfo/devel > >------------------------------ > >End of devel Digest, Vol 37, Issue 26 >*************************************
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
