Hi Pavel,
Thanks for the detailed reply. I guess you aren't as "horribly out of time" as you said, or
perhaps are no even more out of time :)
We will definitely take a good look at the LinCAN source for baud rate
calculations.
The more I think about it, the more I think it's worth to port Li
+1.
- Sudarshan
On 2015-10-01 11:06, Isaac Gutekunst wrote:
Hi Pavel,
Thanks for the detailed reply. I guess you aren't as "horribly out of
time" as you said, or perhaps are no even more out of time :)
We will definitely take a good look at the LinCAN source for baud rate
calculations.
The
On 1/10/2015 2:56 am, Sebastian Huber wrote:
> diff --git a/wscript b/wscript
> index 673479f..88334e4 100644
> --- a/wscript
> +++ b/wscript
> @@ -1053,42 +1053,41 @@ def build(bld):
>'rtemsbsd/telnetd/pty.c',
>'rtemsbsd/telnetd/telnetd.c']
> if bld.get_env()["
Why do you think it is wrong?
The background for this change is that we need an explicit one-to-one mapping
of libbsd and original FreeBSD files.
- Chris Johns schrieb:
> On 1/10/2015 2:56 am, Sebastian Huber wrote:
> > diff --git a/wscript b/wscript
> > index 673479f..88334e4 100644
> > --
On 2/10/2015 8:33 am, Sebastian Huber wrote:
> Why do you think it is wrong?
Because the check is for 'arm' and the file is 'mips'.
Chris
>
> The background for this change is that we need an explicit one-to-one mapping
> of libbsd and original FreeBSD files.
>
> - Chris Johns schrieb:
>
- Chris Johns schrieb:
> On 2/10/2015 8:33 am, Sebastian Huber wrote:
> > Why do you think it is wrong?
>
> Because the check is for 'arm' and the file is 'mips'.
The mips variant is generic (C code only). There is no functional change.
Before this change we simply copied the file (one-t
On 10/1/2015 2:38 PM, Chris Johns wrote:
On 2/10/2015 8:33 am, Sebastian Huber wrote:
Why do you think it is wrong?
Because the check is for 'arm' and the file is 'mips'.
If I recall correctly, the MIPS version is the most generic
version and it is used for architectures which don't have
t
On 1/10/2015 11:46 am, Pavel Pisa wrote:
> Hello Chris and others,
>
> I have no problem if most of RTEMS makefiles are replaced by something
> better but I would really regret if
>
> /opt/rtems4.11/arm-rtemsX.YY/BSP_Z/Makefile.inc
>
> file is not generated and installed during BSP build proc
On 2/10/2015 9:15 am, Joel Sherrill wrote:
>
>
> On 10/1/2015 2:38 PM, Chris Johns wrote:
>> On 2/10/2015 8:33 am, Sebastian Huber wrote:
>>> Why do you think it is wrong?
>>
>> Because the check is for 'arm' and the file is 'mips'.
>
> If I recall correctly, the MIPS version is the most generic
On 10/1/2015 3:34 PM, Chris Johns wrote:
On 2/10/2015 9:15 am, Joel Sherrill wrote:
On 10/1/2015 2:38 PM, Chris Johns wrote:
On 2/10/2015 8:33 am, Sebastian Huber wrote:
Why do you think it is wrong?
Because the check is for 'arm' and the file is 'mips'.
If I recall correctly, the MIPS
Chris, Makefile isn’t custom support, it’s legacy support. For better or for
worse, if you add barriers to Makefiles you raise eyebrows in the legacy
community. They can understand an effort to adapt from BSD make to GNU make,
but a lack of Makefile support is a check-box not checked. I don’t
Hello all,
On Thursday 01 of October 2015 23:59:05 Peter Dufault wrote:
> Chris, Makefile isn’t custom support, it’s legacy support. For better or
> for worse, if you add barriers to Makefiles you raise eyebrows in the
> legacy community. They can understand an effort to adapt from BSD make to
>
12 matches
Mail list logo
