[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9e3b638d-76f2-8520-2a24-7de0cd0bc149@dpolakovic.space>
Date: Sun, 30 Jun 2024 17:27:24 +0200
From: David Polakovic <email@...lakovic.space>
To: Bagas Sanjaya <bagasdotme@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc: Theodore Ts'o <tytso@....edu>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ingo Molnar <mingo@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: proposition for fixing Y292B bug
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...
>
Powered by blists - more mailing lists