From: David Polakovic <email@dpolakovic.space>
To: Bagas Sanjaya <bagasdotme@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Theodore Ts'o <tytso@mit.edu>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: proposition for fixing Y292B bug
Date: Sun, 30 Jun 2024 17:27:24 +0200 [thread overview]
Message-ID: <9e3b638d-76f2-8520-2a24-7de0cd0bc149@dpolakovic.space> (raw)
In-Reply-To: <ZoFgga45QCh2uA0i@archie.me>
Thanks for reply.
My proposed solution was to create this BigInt datatype, which
stores the value in array. The functions for division, multiplication,
addition, subtraction and comparison could be stored in separate
".h" library for manipulation with BigInt datatype. The paper speaks
more in detail.
And yes, this truly is an userspace solution, but for kernel space
implementation I have zero to none experience. Therefore I wrote
here.
dpo
On 6/30/24 15:41, Bagas Sanjaya wrote:
> On Sun, Jun 30, 2024 at 10:05:18AM +0200, David Polakovic wrote:
>> Hello dear developers and enthusiasts.
>>
>> My name is David and recently I wrote a blog post about "necessity"
>> of fixing 64-bit signed integer overflow of time_t, sometime in year
>> 292 billion. I proposed this to simply have software complete solution
>> for timekeeping. The blog had somewhat nice feedback and few people
>> told me to write to your mailing list.
>>
>> As I mention in the list, I am no way experienced enough in kernel
>> space to turn this into full merge request, so I post it to you and
>> if anyone would like to build on this idea, it is GPLd for your convenience.
>>
>> Any feedback is highly appreciated so please, include me in CC's.
>>
>> The blog is written with funny attitude, but it is in no way meant to
>> be joke, parody or insult.
>> https://dpolakovic.space/blogs/y292b
> Reading your paper, it seems like the userspace solution is to introduce bigger
> int type (i.e. int128/bigint); and you want the same to apply to kernel, right?
> Also, if that happens, I think C also needs built-in bigint type.
>
> Confused...
>
next prev parent reply other threads:[~2024-06-30 15:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-30 8:05 David Polakovic
2024-06-30 13:41 ` Bagas Sanjaya
2024-06-30 15:27 ` David Polakovic [this message]
2024-07-01 9:07 ` Bagas Sanjaya
2024-07-01 13:31 ` Alexander Lobakin
2024-07-03 15:29 ` David Polakovic
2024-07-04 17:49 ` Theodore Ts'o
2024-07-04 21:13 ` David Polakovic
2024-07-05 14:12 ` Bagas Sanjaya
2024-07-05 2:59 ` H. Peter Anvin
2024-07-05 14:17 ` Bagas Sanjaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9e3b638d-76f2-8520-2a24-7de0cd0bc149@dpolakovic.space \
--to=email@dpolakovic.space \
--cc=akpm@linux-foundation.org \
--cc=bagasdotme@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®