Is this a bug in libi2c ?
Tom
ventureg at 163.com
Wed Dec 10 06:10:47 UTC 2014
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-request at rtems.org wrote:
>Send devel mailing list submissions to
> devel at 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-request at rtems.org
>
>You can reach the person managing the list at
> devel-owner at 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.sherrill at oarcorp.com>
>To: Thomas Doerfler <Thomas.Doerfler at embedded-brains.de>,
> "devel at rtems.org" <devel at rtems.org>
>Subject: Re: [PATCH] License: add a 2-clause BSD license file, and
> relicense a sparc64 file
>Message-ID: <5487015A.9010807 at 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.sherrill at 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.withers at anu.edu.au>
>To: Sebastian Huber <sebastian.huber at embedded-brains.de>
>Cc: devel at 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.camel at 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 <chrisj at rtems.org>
>To: Sebastian Huber <sebastian.huber at embedded-brains.de>,
> devel at rtems.org
>Subject: Re: [PATCH 3/9] sb: Do not report current date
>Message-ID: <5487B87C.1080306 at 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.withers at anu.edu.au>
>To: Sebastian Huber <sebastian.huber at embedded-brains.de>
>Cc: rtems-devel at rtems.org
>Subject: Re: Add an --enable-httpd-websocket configure option to
> enable WebSocket in the Mongoose HTTP server
>Message-ID: <1418187952.1089.21.camel at 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.withers at anu.edu.au>
>To: Sebastian Huber <sebastian.huber at embedded-brains.de>
>Cc: rtems-devel at rtems.org
>Subject: Re: [PATCH] Teach rtems_tarfs_load() about symlinks
>Message-ID: <1418189646.1089.28.camel at 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.withers at 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 at rtems.org
>http://lists.rtems.org/mailman/listinfo/devel
>
>------------------------------
>
>End of devel Digest, Vol 37, Issue 26
>*************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20141210/22329ae1/attachment-0001.html>
More information about the devel
mailing list