No. But you are welcome to submit patches so the behavior matches Linux.
On Sep 24, 2017 1:09 AM, "xuelin.tian" <xuelin.t...@qkmtech.com> wrote:
> So, is there a substitute function for this in RTEMS, without modifying
> the source code?
>
>
> ------------------ Original ------------------
> *From: * "Joel Sherrill"<j...@rtems.org>;
> *Date: * Sun, Sep 24, 2017 00:15 AM
> *To: * "xuelin.tian"<xuelin.t...@qkmtech.com>;
> *Cc: * "Sebastian Huber"<sebastian.hu...@embedded-brains.de>; "
> users@rtems.org"<users@rtems.org>;
> *Subject: * Re: Re: pthread_getattr_np does not work
>
>
>
> On Fri, Sep 22, 2017 at 9:26 PM, xuelin.tian <xuelin.t...@qkmtech.com>
> wrote:
>
>> Thanks so much for your test.
>>
>
> No problem. Just trying to help.
>
>
>> The parts of this structure I care about most are the stackaddr and
>> stacksize (and guardsize maybe), where stackaddr always returns 0. The
>> value of stacksize is either 8192 or 0, based on the fact that this
>> attribute structure is retrieved from POSIX_Init or other pthreads in my
>> system (maybe I use pthread_create in a wrong way...).
>>
>
> Without looking at the code, 8192 is almost certainly the port specific
> default
> stack size since it is normally a value like that. A stack size request of
> anything
> less than the recommended minimum will always get you an allocation of the
> minimum. So 0 or 8192 might simply indicate whether the structure is
> explicitly
> initialized via pthread_attr_init() or filled in explicitly by the
> application with
> the minimum stack size constant.
>
>
>>
>> So, from the result you post, the stackaddr is 0 too, which means this
>> element is not supported in rtems, or there is something wrong with this
>> function?
>>
>
> This means the user application didn't specify the stack area in RTEMS.
> Since
> this method is "NP", there is no standard specifying the behavior.
>
> This method doesn't exist on FreeBSD and appears to only exist in Linux and
> RTEMS. If there is consensus that it should behave the same on Linux and
> RTEMS, then there should be a ticket filed with (hopefully) patches. <hint>
>
> It isn't a complicated method and all if should take is filling in the
> attribute
> structure with different fields in the TCB. I think it primarily parrots
> back
> the attribute structure passed to pthread_create().
>
> Also writing the man page for the RTEMS POSIX manual would be appreciated.
>
> Nothing like wandering into something that is even beyond unspecified in
> POSIX to a method that is explicitly non-portable for fun. :)
>
> --joel
>
> --joel
>
>>
>>
>> ------------------ Original ------------------
>> *From: * "Joel Sherrill"<j...@rtems.org>;
>> *Date: * Fri, Sep 22, 2017 10:15 PM
>> *To: * "xuelin.t...@qkmtech.com"<xuelin.t...@qkmtech.com>;
>> *Cc: * "Sebastian Huber"<sebastian.hu...@embedded-brains.de>; "
>> users@rtems.org"<users@rtems.org>;
>> *Subject: * Re: Re: pthread_getattr_np does not work
>>
>> The test does verify the values. I don't see a specific case of creating
>> a thread
>> with a non-standard stack value and verifying that value in the task but
>> the
>> test creates a thread which retrieves its values and verifies many (most,
>> all?)
>> of them:
>>
>> (gdb)
>> Thread - pthread_getattr_np - Verify value
>> 46 sc = pthread_getattr_np( Thread_id, &attr );
>> (gdb)
>> 47 rtems_test_assert( sc == 0 );
>> (gdb)
>> 52 puts( "Thread - pthread_setschedparam: Setting highest priority
>> SCHED_FIFO" );
>> (gdb) p attr
>> $1 = {is_initialized = 1, stackaddr = 0x0, stacksize = 8192,
>> contentionscope = 0, inheritsched = 2, schedpolicy = 2, schedparam = {
>> sched_priority = 3, sched_ss_low_priority = 285216961,
>> sched_ss_repl_period = {tv_sec = 0, tv_nsec = 16},
>> sched_ss_init_budget = {tv_sec = 0, tv_nsec = 1}, sched_ss_max_repl =
>> 0},
>> guardsize = 0, cputime_clock_allowed = 1, detachstate = 1,
>> affinitysetsize = 0, affinityset = 0x0, affinitysetpreallocated = {
>> __bits = {0}}}
>>
>> Clearly the attribute structure returned is not all zero.
>>
>> I am not sure what you are seeing but it doesn't match what I see in
>> this test on the erc32.
>>
>> --joel
>>
>> On Fri, Sep 22, 2017 at 4:04 AM, xuelin.t...@qkmtech.com <
>> xuelin.t...@qkmtech.com> wrote:
>>
>>> OK, no problem, thanks anyway.
>>>
>>> ------------------------------
>>> Best wishes,
>>> xuelin.t...@qkmtech.com
>>>
>>>
>>> *From:* Sebastian Huber <sebastian.hu...@embedded-brains.de>
>>> *Date:* 2017-09-22 16:58
>>> *To:* xuelin.t...@qkmtech.com; users@rtems.org
>>> *Subject:* Re: pthread_getattr_np does not work
>>> On 22/09/17 10:55, xuelin.t...@qkmtech.com wrote:
>>>
>>> > OK, I will try to do some fix on this function. And if Sherrill and
>>> > you have time, please take some time on this. Thanks a lot.
>>>
>>> No, sorry. I have no time to fix this.
>>>
>>> --
>>> Sebastian Huber, embedded brains GmbH
>>>
>>> Address : Dornierstr. 4
>>> <https://maps.google.com/?q=Dornierstr.+4&entry=gmail&source=g>,
>>> 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.
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>
>> 自动判断 中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语
>> 丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语
>> 冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语
>> 北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语
>> 茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语祖鲁语 自动选择 中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语
>> 俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语
>> 加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语
>> 拉脱维亚语毛利语马其顿语蒙古语马拉地语马来语马耳他语挪威语(伯克梅尔)荷兰语北梭托语旁遮普语波兰语葡萄牙语克丘亚语罗马尼亚语梵文北萨摩斯语
>> 斯洛伐克语斯洛文尼亚语阿尔巴尼亚语瑞典语斯瓦希里语叙利亚语泰米尔语泰卢固语塔加路语茨瓦纳语土耳其语宗加语鞑靼语乌克兰语乌都语乌兹别克语越南语班图语
>> 祖鲁语 有道翻译 百度翻译 必应翻译 谷歌翻译 谷歌翻译（国内） 翻译 朗读 复制 正在查询，请稍候…… 重试 朗读 复制 复制 朗读 复制 via
>> 译
>
>
>
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
