请勿回复此邮箱，回复或退订请发：stevenxu#aeolustrans#com.Don’t reply via the above email address, please reply or To sign off， please inform via: stevenxu#aeolustrans#com.------------------------------------------------------------------------------------------------------------------------------------------------------------------尊敬的朋友！Dear Madam & Sir, 你不能改变你的过去，但你可以让你的未来变得更美好。一旦时间浪费了，生命就浪费了。You cannot improve your past, but you can improve your future. Once time is wasted, life is wasted. 【风之神】你有中国到南太平洋岛国、澳州北部整箱、拼箱、散杂货、滚装货吗？请找风之神吧！风之神服务可能更好！价格可能更便宜！[ Aeolus ] Do you have goods to transport from Asia to South Pacific Ocean, Southeast Asia? Please call for AEOLUS , You will get our better customer service at less cost. 1、南太平洋岛国：阿洛陶、阿皮亚、楚克、伊拜、富纳富提、富图纳、关岛、霍尼亚拉、卡维恩、金贝、科罗尔、科斯瑞、莱城、拉托卡、马当、马朱罗、马塔乌图、诺劳、努美阿、努库阿洛法、奥鲁湾、帕果-帕果、帕皮提、波纳佩、莫尔兹比港、维拉港、蜡包尔、拉罗汤加、塞班岛、圣吐、锡加维、苏瓦、塔拉瓦岛、瓦利斯群岛、威瓦克、雅浦等。Ports Of South Pacific Ocean: ALOTAU, APIA, CHUUK, EBEYE, FUNAFUTI, FUTUNA, GUAM, HONIARA, KAVIENG, KIMBE, KOROR, KOSRAE, LAE, LAUTOKA, MADANG, MAJURO, MATAUTU, NORO, NOUMEA, NUKUALOFA, OROBAY, PAGO PAGO, PAPEETE, POHNPEI, PORT MORESBY, PORT VILA, RABAUL, RAROTONGE, SAIPAN, SANTO, SUVA, SIGAVE, TARAWA, WALLIS ISLAND, WEWAK, YAP, etc.
2、澳大利亚偏点：达尔文、凯恩斯、麦凯、汤斯维尔等。Ports Of Australia: DARWIN, CAIRNS, MACKAY, TOWNSVILLE, etc.
3、启运港：大连、天津、青岛、南京、上海、宁波、厦门、福州、广州、深圳、香港等。Port Of Departure: Dalian, Tianjin, Qingdao, Nanjing Shanghai, Ningbo, Xiamen, Fuzhou, Guangzhou, Shenzhen, Hongkong
4、货种：整箱、拼箱、危险品、冷冻箱、开顶箱、框架箱、平板箱、散杂货、滚装货。Cargo: FCL, LCL, DG, RF (Refrigerated Container), OT, FR, PR, Bulk Goods, RR, ect.
上海风之神国际货运有限公司是国家批淮的一级货代，专业从事国际货运行业十多年，是老牌的国际货运公司。公司拥有一批专业的人才，专业的电脑系统，能从事复杂的货运操作，可提供全面物流解抉方案。很多跨国公司、大型外贸公司、大型国企都是我们客户。SHANGHAI AEOLUS INT’L TRANSPORTATION CO.,LTD is the national-level freight forwarding agent. Our brand is time-honored brand and our company is a professional business in providing freight services for decades .Our company has many professional talents and professional computer systems for container booking, trucking, commodity inspection and customs clearance.. We can provide overall logistics solution for you. Our customers include big SOEs , big foreign trade companies , global companies. 怎么样？还不赶快定舱！Ok, giving us a opportunity 只有专业，才能做的更好！ Only Be Professional, Can Be Better 商安!Best wishes Steven（南太平洋专家 The Expert Of South）===========================================================================SHANGHHAI AEOLUS INT'L TRANSPORTATION CO.,LTD.电话TEL: +86-21-68981020 手机/微信MP./wechat: +86-13501618920 腾讯: 573142183邮箱EMAIL:stevenxu#aeolustrans#com 网址WED.: www#aeolustrans#com===========================================================================
This is a series I worked on with Baolin in 2017 and 2018, but we
never quite managed to finish up the last pieces. During the
ALSA developer meetup at ELC-E 2018 in Edinburgh, a decision was
made to go with this approach for keeping best compatibility
with existing source code, and then I failed to follow up by
resending the patches.
Now I have patches for all remaining time_t uses in the kernel,
so it's absolutely time to revisit them. I have done more
review of the patches myself and found a couple of minor issues
that I have fixed up, otherwise the series is still the same as
before.
Conceptually, the idea of these patches is:
- 64-bit applications should see no changes at all, neither
compile-time nor run-time.
- 32-bit code compiled with a 64-bit time_t currently
does not work with ALSA, and requires kernel changes and/or
sound/asound.h changes
- Most 32-bit code using these interfaces will work correctly
on a modified kernel, with or without the uapi header changes.
- 32-bit code using SNDRV_TIMER_IOCTL_TREAD requires the
updated header file for 64-bit time_t support
- 32-bit i386 user space with 64-bit time_t is broken for
SNDRV_PCM_IOCTL_STATUS, SNDRV_RAWMIDI_IOCTL_STATUS and
SNDRV_PCM_IOCTL_SYNC_PTR because of i386 alignment. This is also
addressed by the updated uapi header.
- PCM mmap is currently supported on native x86 kernels
(both 32-bit and 64-bit) but not for compat mode. This series breaks
the 32-bit native mmap support for 32-bit time_t, but instead allows
it for 64-bit time_t on both native and compat kernels. This seems to
be the best trade-off, as mmap support is optional already, and most
32-bit code runs in compat mode anyway.
- I've tried to avoid breaking compilation of 32-bit code
as much as possible. Anything that does break however is likely code
that is already broken on 64-bit time_t and needs source changes to
fix them.
I hope I addressed all review comments by now, so please pull this
for linux-5.6.
A git branch with the same contents is available for testing at [1].
Arnd
[1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git y2038-alsa-v7
[2] https://lore.kernel.org/lkml/CAK8P3a2Os66+iwQYf97qh05W2JP8rmWao8zmKoHiXqVHv…
Changes since v6: (Arnd):
- Add a patch to update the API versions
- Hide a timespec reference in #ifndef __KERNEL__ to remove the
last reference to time_t
- Use a more readable way to do padding and describe it in the
changelog
- Rebase to linux-5.5-rc1, changing include/sound/soc-component.h
and sound/drivers/aloop.c as needed.
Changes since v5 (Arnd):
- Rebased to linux-5.4-rc4
- Updated to completely remove timespec and time_t references from alsa
- found and fixed a few bugs
Changes since v4 (Baolin):
- Add patch 5 to change trigger_tstamp member of struct snd_pcm_runtime.
- Add patch 8 to change internal timespec.
- Add more explanation in commit message.
- Use ktime_get_real_ts64() in patch 6.
- Split common code out into a separate function in patch 6.
- Fix tu->tread bug in patch 6 and remove #if __BITS_PER_LONG == 64 macro.
Changes since v3:
- Move struct snd_pcm_status32 to pcm.h file.
- Modify comments and commit message.
- Add new patch2 ~ patch6.
Changes since v2:
- Renamed all structures to make clear.
- Remove CONFIG_X86_X32 macro and introduced new compat_snd_pcm_status64_x86_32.
Changes since v1:
- Add one macro for struct snd_pcm_status_32 which only active in 32bits kernel.
- Convert pcm_compat.c to use struct snd_pcm_status_64.
- Convert pcm_native.c to use struct snd_pcm_status_64.
---
Arnd Bergmann (3):
ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c
ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
ALSA: bump uapi version numbers
Baolin Wang (6):
ALSA: Replace timespec with timespec64
ALSA: Avoid using timespec for struct snd_timer_status
ALSA: Avoid using timespec for struct snd_ctl_elem_value
ALSA: Avoid using timespec for struct snd_pcm_status
ALSA: Avoid using timespec for struct snd_rawmidi_status
ALSA: Avoid using timespec for struct snd_timer_tread
include/sound/pcm.h | 74 ++++++--
include/sound/soc-component.h | 4 +-
include/sound/timer.h | 4 +-
include/uapi/sound/asound.h | 145 +++++++++++++--
sound/core/pcm.c | 12 +-
sound/core/pcm_compat.c | 282 ++++++++----------------------
sound/core/pcm_lib.c | 38 ++--
sound/core/pcm_native.c | 226 +++++++++++++++++++++---
sound/core/rawmidi.c | 132 +++++++++++---
sound/core/rawmidi_compat.c | 87 +++------
sound/core/timer.c | 229 ++++++++++++++++++------
sound/core/timer_compat.c | 62 +------
sound/drivers/aloop.c | 2 +-
sound/pci/hda/hda_controller.c | 10 +-
sound/soc/intel/skylake/skl-pcm.c | 4 +-
15 files changed, 817 insertions(+), 494 deletions(-)
--
2.20.0
The LTP test io_pgetevents02 fails in 32bit compat mode because an
nr_max of -1 appears to be treated as a large positive integer. This
causes pgetevents_time64 to return an event. The test expects the call
to fail and errno to be set to EINVAL.
Using the compat syscall fixes the issue.
Fixes: 7a35397f8c06 ("io_pgetevents: use __kernel_timespec")
Signed-off-by: Richard Palethorpe <rpalethorpe(a)suse.com>
---
arch/x86/entry/syscalls/syscall_32.tbl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
index 960a021d543e..0985d8333368 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -420,7 +420,7 @@
412 i386 utimensat_time64 sys_utimensat
413 i386 pselect6_time64 sys_pselect6 compat_sys_pselect6_time64
414 i386 ppoll_time64 sys_ppoll compat_sys_ppoll_time64
-416 i386 io_pgetevents_time64 sys_io_pgetevents
+416 i386 io_pgetevents_time64 sys_io_pgetevents compat_sys_io_pgetevents_time64
417 i386 recvmmsg_time64 sys_recvmmsg compat_sys_recvmmsg_time64
418 i386 mq_timedsend_time64 sys_mq_timedsend
419 i386 mq_timedreceive_time64 sys_mq_timedreceive
--
2.31.1
I've invited you to fill in the following form:
QQ：2890057524，微信：13247602337（手机同号）在线体验测试效果！
To fill it in, visit:
https://docs.google.com/forms/d/e/1FAIpQLScIta2A_VwoZ50Or7N1TM3di6LZjYjTro-…
您好，冒昧打扰您了，
我司帮助外贸企业拓展全球业务，全球220多个国家，全球几百亿条客户信息，根据您
的需求，精准推荐给您，采购负责人马上就能联系。
微信：13247602337
QQ：2890057524
欢迎前来咨询体验
Google Forms: Create and analyse surveys.
On Mon, Aug 17, 2020 at 03:00:24PM +0000, Roosen Henri wrote:
> On Mon, 2020-08-17 at 16:35 +0200, gregkh(a)linuxfoundation.org wrote:
> > On Mon, Aug 17, 2020 at 02:15:16PM +0000, Roosen Henri wrote:
> > > On Tue, 2020-06-09 at 16:18 +0200, Arnd Bergmann wrote:
> > > > On Tue, Jun 9, 2020 at 2:36 PM Roosen Henri <
> > > > Henri.Roosen(a)ginzinger.com> wrote:
> > > > > Hi Arnd,
> > > > >
> > > > > I hope you are well and could answer me a quick question.
> > > > >
> > > > > I've read on the kernel mailing-list that initially there was
> > > > > an
> > > > > intention to backport the final y2038 patches to v5.4. We're
> > > > > currently targeting to use the v5.4 LTS kernel for a project
> > > > > which
> > > > > should be y2038 compliant.
> > > > >
> > > > > I couldn't find all of the y2038-endgame patches in the current
> > > > > v5.4-stable branch. Are there any patches still required to be
> > > > > backported in order for v5.4 to be y2038 compliant, or can the
> > > > > remaining patches be ignored (because of only cleanup?)? Else,
> > > > > is
> > > > > there still an intention to get the v5.4 LTS kernel y2038
> > > > > compliant?
> > > >
> > > > I don't think there are currently any plans to merge my y2038-
> > > > endgame
> > > > branch
> > > > into the official linux-5.4 lts kernel, but you should be able to
> > > > just pull from
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=…
> > > >
> > > > and get the same results. If you see any problems with that,
> > > > please
> > > > report
> > > > that to me with Cc to the mailing list and perhaps gregkh, so I
> > > > can
> > > > see if
> > > > I can resolve it by rebasing my patches, or if he would like to
> > > > merge
> > > > the
> > > > patches.
> > >
> > > Pulling the y2038-endgame branch does lead to some conflicts, which
> > > are
> > > currently still kinda staightforward to solve.
> > >
> > > However I'd be very interested in getting this branch merged to
> > > v5.4,
> > > so we don't run into more difficult merge conflicts the coming
> > > years
> > > where the v5.4-LTS still gets stable updates (Dec, 2025) and
> > > possibly
> > > to get any related fixes from upstream.
> > >
> > > @Greg: any chance to get the y2038-endgame merged into v5.4.y?
> >
> > I have no idea what this really means, and what it entails, but odds
> > are, no :)
>
> I fully understand, thanks for your statement on this.
>
> >
> > Why not just use a newer kernel? Why are you stuck using a 5.4
> > kernel
> > for a device that has to live in 2038? That feels very foolish to
> > me...
>
> Oh I agree on that :) It's just that these are currently customer
> requirements.
Are you sure that customers really understand what they want?
Usually they want a well-supported, stable, system. Why do they care
about a specific kernel version? That feels odd.
Good luck!
greg k-h
On Mon, Aug 17, 2020 at 02:15:16PM +0000, Roosen Henri wrote:
> On Tue, 2020-06-09 at 16:18 +0200, Arnd Bergmann wrote:
> > On Tue, Jun 9, 2020 at 2:36 PM Roosen Henri <
> > Henri.Roosen(a)ginzinger.com> wrote:
> > > Hi Arnd,
> > >
> > > I hope you are well and could answer me a quick question.
> > >
> > > I've read on the kernel mailing-list that initially there was an
> > > intention to backport the final y2038 patches to v5.4. We're
> > > currently targeting to use the v5.4 LTS kernel for a project which
> > > should be y2038 compliant.
> > >
> > > I couldn't find all of the y2038-endgame patches in the current
> > > v5.4-stable branch. Are there any patches still required to be
> > > backported in order for v5.4 to be y2038 compliant, or can the
> > > remaining patches be ignored (because of only cleanup?)? Else, is
> > > there still an intention to get the v5.4 LTS kernel y2038
> > > compliant?
> >
> > I don't think there are currently any plans to merge my y2038-endgame
> > branch
> > into the official linux-5.4 lts kernel, but you should be able to
> > just pull from
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=…
> >
> > and get the same results. If you see any problems with that, please
> > report
> > that to me with Cc to the mailing list and perhaps gregkh, so I can
> > see if
> > I can resolve it by rebasing my patches, or if he would like to merge
> > the
> > patches.
>
> Pulling the y2038-endgame branch does lead to some conflicts, which are
> currently still kinda staightforward to solve.
>
> However I'd be very interested in getting this branch merged to v5.4,
> so we don't run into more difficult merge conflicts the coming years
> where the v5.4-LTS still gets stable updates (Dec, 2025) and possibly
> to get any related fixes from upstream.
>
> @Greg: any chance to get the y2038-endgame merged into v5.4.y?
I have no idea what this really means, and what it entails, but odds
are, no :)
Why not just use a newer kernel? Why are you stuck using a 5.4 kernel
for a device that has to live in 2038? That feels very foolish to me...
thanks,
greg k-h
--------------------------------------------------------------------------------
This email newsletter was sent to you in graphical HTML format.
If you're seeing this version, your email program prefers plain text emails.
You can read the original version online:
https://ymlptr9.net/zxMlt3
--------------------------------------------------------------------------------
Greetings
Many organizations fail to respond to external and internal
environment which in turn affect the well-being of the organization
and may cause total shutdown and loss of business such as Nokia case.
Other organizations are considering the Marketing Mix along with the
change best practices to insure continued prosperity and revenues.The
study will also conclude the best leadership style that should be
associated with a change. This research is done to investigates the
best practices of organizational change and the best leadership theory
that could be used to implement change. It aims at helping
organizations in implementing a successful change, as well as the
marketing and leadership strategies of change adopted to insure
successful implantation of the change. This study seeks to identify
the most recurrent factors that drives organizational change, and to
illustrate methodologies for an effective change.
We kindly ask you to complete this quick 12 Questons Suervy in this
regard.
https://www.smartsurvey.co.uk/s/ChangeManagementleadershipstyle/
Many Thanks
_____________________________
Unsubscribe / Change Profile: https://ymlptr9.net/ugwhmwyqgsguqhjhbsgessyggemyse
Powered by YourMailingListProvider
