Hi,
I am new to linux kernel and trying to understand the process of
different git branch to work.
So, if I am not wrong then there are different branch like stable, next,
staging etc. Previously I work with staging branch so if I am making
any changes for drivers/staging I have to work with staging branch like
follow.
git clone
git checkout -t -b staging-testing origin/staging-testing
git chekcout -b MY_LOCAL_BRANCH
not do work and subimt
So, how it work for other source structure, like now I want to make some
for y2038 -> drivers/scsi which branch should I set up and work with,
next/stable/or is there any specific y2038 branch.
Any wiki link or documentation that explain this full process which
branch to work with when making changes to specific directory will be
useful.
Thanks,
Shirish
These series of patches try to convert parport device(ppdev) to
y2038 safe, and support y2038 safe and unsafe application at the
same time. There were some discussions in y2038 mailing list[1].
An y2038 safe application/kernel use 64bit time_t(aka time64_t)
to avoid 32-bit time types broken in the year 2038. Given that
some time relative struct(e.g. timeval in ppdev.c) is mainly the
offset of the real time, the old 32bit time_t in such application
is safe. We need to handle the 32bit time_t and 64bit time_t
application at the same time. My approach here is handle them as
different ioctl command for different size of timeval.
Build successful on arm64 and arm.
[1] https://lists.linaro.org/pipermail/y2038/
Bamvor Jian Zhang (2):
ppdev: convert to y2038 safe
ppdev: add support for compat ioctl
drivers/char/ppdev.c | 86 ++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 66 insertions(+), 20 deletions(-)
--
2.1.4
Here is the sixth version for converting parport device(ppdev) to
y2038 safe. The first four could found at [1][2][3][4][5].
An y2038 safe application/kernel use 64bit time_t(aka time64_t)
instead of 32bit time_t. Given that some time relative struct(e.g.
timeval in ppdev.c) is mainly the offset of the real time, the old
32bit time_t in such application is safe. We need to handle the
32bit time_t and 64bit time_t application at the same time.
My approach here is handle them as different ioctl command for
different size of timeval.
Build successful on arm64 and arm.
Changes since v5:
1. Replace PP[GS]ETTIME_safe/unsafe with PP[GS]ETTIME32/64.
2. Rewirte PPSETTIME ioctl with jiffies_to_timespec64 in order to
replace user fake HZ(TICK_USEC) to kernel HZ(TICK_NSEC).
3. define tv_sec as long and tv_usec as int in pp_set_timeout. It
should be enough for the timeout.
Change since v4:
1. change type of tv_sec and tv_usec to s64 in pp_set_timeout.
Use s64 could avoid s64 cast to s32 in arm 32bit.
Changes since V3:
1. create pp_set_timeout, pp_get_timeout to reduce the duplicated
code in my patch according to the suggestion of arnd.
I use div_u64_rem instead of jiffies_to_timespec64 because
it could save a divide operaion.
[1] https://lists.linaro.org/pipermail/y2038/2015-June/000522.html
[2] https://lists.linaro.org/pipermail/y2038/2015-June/000567.html
[3] https://lists.linaro.org/pipermail/y2038/2015-November/001093.html
[4] https://lists.linaro.org/pipermail/y2038/2015-November/001132.html
[5] https://lists.linaro.org/pipermail/y2038/2015-December/001201.html
Bamvor Jian Zhang (2):
ppdev: convert to y2038 safe
ppdev: add support for compat ioctl
drivers/char/ppdev.c | 86 ++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 66 insertions(+), 20 deletions(-)
--
2.1.4
This is the basic framework for the 64 bit time migration for filesystems.
There might be some changes or additions required as I start adapting to
filesystems.
This gives the basic high level concept so that we can start discussing.
Actual changes to vfs and other file systems will be in a separate
series.
Deepa Dinamani (4):
fs: vfs: add accessors for inode times
fs: Add new data type for inode times
fs: Add support for 64 bit time
fs: macros and functions support 64 bit time
include/linux/fs.h | 42 ++++++++++++++++++++++++++++++++-------
include/linux/stat.h | 12 +++++++++---
include/linux/time.h | 2 ++
include/linux/time64.h | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/time/time.c | 28 ++++++++++++++++++++++++++
5 files changed, 127 insertions(+), 10 deletions(-)
--
1.9.1
Here is the fifth version for converting parport device(ppdev) to
y2038 safe. The first four could found at [1], [2], [3], [4].
An y2038 safe application/kernel use 64bit time_t(aka time64_t)
instead of 32bit time_t. There are the 5 cases need to support:
summary |u:arch |u:tv_sec |k:arch |k:tv_sec
-------------------|-------|---------|-------|--------
32_y2038_unsafe |32 |32 |32 |32
32_y2038_safe |32 |64 |32 |64
compat_y2038_unsafe|32 |32 |64 |64
compat_y2038_safe |32 |64 |64 |64
64_y2038_safe |64 |64 |64 |64
notes:
1. xxx_y2038_safe/unsafe. 32 means app running on the 32bit
kernel. Compat means 32bit app running on 64bit kernel. 64
means 64bit app running on 64bit kernel.
2. 1.3.5 are the original one, we need keep the compatability.
2,4 is new one we need to support.
There are different ways to do this. Convert to 64bit time and/or
define COMPAT_USE_64BIT_TIME 0 or 1 to indicate y2038 safe or unsafe.
But it is not mean that we need to convert all the time relative
struct to 64bit. Because some time relative struct(e.g. timeval in
ppdev.c) is mainly the offset of the real time.
The main issue in ppdev.c is PPSETTIME/PPGETTIME which transfer
timeval between user space and kernel. My approach here is handle them
as different ioctl command.
Build successful on arm64 and arm.
Change since v4:
1. change type of tv_sec and tv_usec to s64 in pp_set_timeout.
Use s64 could avoid s64 cast to s32 in arm 32bit.
Changes since V3:
1. create pp_set_timeout, pp_get_timeout to reduce the duplicated
code in my patch according to the suggestion of arnd.
I use div_u64_rem instead of jiffies_to_timespec64 because
it could save a divide operaion.
[1] https://lists.linaro.org/pipermail/y2038/2015-June/000522.html
[2] https://lists.linaro.org/pipermail/y2038/2015-June/000567.html
[3] https://lists.linaro.org/pipermail/y2038/2015-November/001093.html
[4] https://lists.linaro.org/pipermail/y2038/2015-November/001132.html
Bamvor Jian Zhang (2):
ppdev: convert to y2038 safe
ppdev: add support for compat ioctl
drivers/char/ppdev.c | 92 ++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 72 insertions(+), 20 deletions(-)
--
2.1.4
On Friday 27 November 2015 18:00:29 WEN Pingbo wrote:
> To solve the y2038 problem in input_event, I had some attempts before [1],
> and this is the second one.
>
> We can force userspace to use monotonic time in event timestamp, so the
> 'struct timeval' is enough to keep y2038-safe, as Arnd suggested. But we
> can not find a way to make kernel compatible with old binaries, which use
> realtime, and there are still some devices, which depend on realtime.
>
> So I get a idea to add a new evdev interface, which is y2038 safe. And
> userspace can switch between the old and new interface via ioctl.
>
> The patch series add three evdev interface type:
>
> - EV_IF_LEGACY
> send event by input_event. This is the default option, keep kernel
> backward compatible.
The problem I see with this approach is that it still breaks any
legacy source code that is compiled with a new libc that uses 64-bit
time_t. If we are requiring source code changes for building users
of input devices with a new libc, we can easily get them to handle
the overflow (they normally only care about the microsecond portion
anyway, so it doesn't matter in most cases), or to use monotonic time.
Did I miss something here?
Arnd
Notice to Appear,
You have not paid for driving on a toll road.
You are kindly asked to pay your debt as soon as possible.
You can review the invoice in the attachment.
Sincerely,
Floyd Donovan,
E-ZPass Agent.
Hi,
Is your target market already defined?
Are your new customer acquisition efforts ineffective through direct mail,
phone contact, or traditional mass media?
Where do you find verified Email Marketing lists mailing lists that I know
are deliverable?
Our highly targeted databases are guaranteed to put you, your sales teams,
and your products or services in front of the correct buying contacts in
your industry. With the highest ROI of all marketing channels, acquisition
email as a lead generation medium is second to none.
We provide verified prospect lists from your industry and region today,
complete with vital company and contact information, and of course, email
addresses.
Our lists will allow you to:
. Extend your reach: Introduce your company, product or service to
new audiences.
. Extend your relevance: Reach more of the correct prospects and
relevant buyers through the most active and responsive business
communication channel available today, email.
We're so confident in our data that we'll allow you to sample it at no cost.
Test us.test the data.it's that simple!
Talk to us or reply back with your target market criteria, including your
target industries and the job titles for the contacts who are the primary
purchasers of your products and services. We will get back to you with the
sample.
Jessica Smith
Sr. Marketing Executive
____________________________________________________________________________
__
We respect your privacy. If you do not wish to receive future e-mail please
reply with "REMOVE".
On Friday 27 November 2015 18:00:31 WEN Pingbo wrote:
> This patch depends on 'introduce new evdev interface'.
>
> Userspace cat set / get evdev interface type via the two ioctl
> commands. And default interface type is EV_IF_LEGACY, so the old binary
> will work normal with new kernel. Maybe we should change this default
> option to encourage people to move to new interface.
>
> And since all events are stored as input_value in evdev, there are no
> need to flush evdev_client's buffer if we change clk_type and if_type.
I would split out the change to evdev_set_clk_type into a separate patch.
> + case EVIOCSIFTYPE:
> + if (get_user(if_type, ip))
> + return -EFAULT;
> +
> + return evdev_set_if_type(client, if_type);
> + case EVIOCGIFTYPE:
> + return put_user(client->if_type, ip);
> }
This look asymmetric: EVIOCSIFTYPE uses a EVDEV_* constant, while
EVIOCGIFTYPE returns a EV_IF_* constant. Should those just
be the same constants anyway?
Arnd
