Michael.
Michael Schmitz - 01.07.18, 04:43:
> Am 30.06.18 um 19:49 schrieb Martin Steigerwald:
> > I am really inclined to point some AmigaOS 4 developers to this
> > discussion and just looked for an archive. Unfortunately there does
> > not appear to be a working one. The one mentioned on
> >
>
FWIW on the other side this appears to be a good source of Amiga software data.
http://amigadev.elowar.com/
{^_^}
On 20180630 19:43, Michael Schmitz wrote:
Martin,
Am 30.06.18 um 19:49 schrieb Martin Steigerwald:
I am really inclined to point some AmigaOS 4 developers to this
discussion and j
Martin,
Am 30.06.18 um 19:49 schrieb Martin Steigerwald:
> I am really inclined to point some AmigaOS 4 developers to this
> discussion and just looked for an archive. Unfortunately there does not
> appear to be a working one. The one mentioned on
>
> http://www.linux-m68k.org/mail.html
>
> http:
Hi Geert,
Am 01.07.2018 um 09:10 schrieb Geert Uytterhoeven:
Hi Michael,
On Fri, Jun 29, 2018 at 11:12 AM Michael Schmitz wrote:
Am 28.06.18 um 01:30 schrieb Geert Uytterhoeven:
On Wed, Jun 27, 2018 at 4:47 AM wrote:
From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
?
Hi Andreas,
On Fri, Jun 29, 2018 at 3:26 PM Andreas Schwab wrote:
> On Jun 29 2018, Michael Schmitz wrote:
> > Would MSDOS recognize the GPT partition as 'probably FAT', and attempt
> > to use it?
>
> GPT has the concept of a protective MBR which should prevent such errors.
Thanks, good to know
Hi Michael,
On Fri, Jun 29, 2018 at 11:12 AM Michael Schmitz wrote:
> Am 28.06.18 um 01:30 schrieb Geert Uytterhoeven:
> > On Wed, Jun 27, 2018 at 4:47 AM wrote:
> >> From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
> > ??
> >
> >> The Amiga RDB partition parser module uses
As software is discovered to be "broken" at it to the appropriate incompatible
list.
Otherwise permanently limit AmigaDOS to 2TB.
{^_^}
On 20180630 02:07, Martin Steigerwald wrote:
jdow - 30.06.18, 08:47:
Let's get everybody:
On 20180629 22:26, Michael Schmitz wrote:
> Joanne,
>
> Am 3
Get everybody
On 20180630 00:49, Martin Steigerwald wrote:
> Whoa, my summary essay triggered digging even more accurately into that
> matter. For some obscure reason I am even enjoying this. :)
>
> jdow - 30.06.18, 05:56:
>> On 20180629 18:31, Michael Schmitz wrote:> Joanne,
>>
>> > Am 30.
For Linux:
1) Make a change to the Linux RDB parser so that the product of the "CHS" values
goes to at least a 64 bit entity, It may need to go to a 128 bit entity when we
are encoding data in DNA, crystal lattices, or something else super dense. The
parser simply feeds data to the OS. No warni
jdow - 30.06.18, 08:47:
> Let's get everybody:
>
> On 20180629 22:26, Michael Schmitz wrote:
> > Joanne,
> >
> > Am 30.06.18 um 15:56 schrieb jdow:
> > As far as I can guess from the code, pb_Environment[3] (number
> > of
>
> heads)
>
> > and pb_Environment[5
Michael. Joanne.
I do think this discussion is slightly getting out of hand… so I suggest
to focus on what its up to the kernel to do and what is not. And to
focus only on what is up to the RDB parser, cause the patch is on
changing that. The RDB parser is not responsible for what any file
sys
Whoa, my summary essay triggered digging even more accurately into that
matter. For some obscure reason I am even enjoying this. :)
jdow - 30.06.18, 05:56:
> On 20180629 18:31, Michael Schmitz wrote:> Joanne,
>
> > Am 30.06.18 um 12:57 schrieb jdow:
> >> On 20180629 17:44, Michael Schmitz wrot
Let's get everybody:
On 20180629 22:26, Michael Schmitz wrote:
> Joanne,
>
>
> Am 30.06.18 um 15:56 schrieb jdow:
>>
> As far as I can guess from the code, pb_Environment[3] (number of
heads)
> and pb_Environment[5] (number of sectors per cylinder) are abitrarily
> chosen so the
Joanne,
Am 30.06.18 um 15:56 schrieb jdow:
>
> >>> As far as I can guess from the code, pb_Environment[3] (number of
> >> heads)
> >>> and pb_Environment[5] (number of sectors per cylinder) are abitrarily
> >>> chosen so the partition size can be expressed as a difference between
> >>> pb_Environ
On 20180629 18:31, Michael Schmitz wrote:> Joanne,
>
>
> Am 30.06.18 um 12:57 schrieb jdow:
>> On 20180629 17:44, Michael Schmitz wrote:
>>
>>> struct PartitionBlock {
>>>__be32 pb_ID;
>>>__be32 pb_SummedLongs;
>>>__s32 pb_ChkSum;
>>>__u32 pb_H
Joanne,
Am 30.06.18 um 12:57 schrieb jdow:
> On 20180629 17:44, Michael Schmitz wrote:
>
> > struct PartitionBlock {
> > __be32 pb_ID;
> > __be32 pb_SummedLongs;
> > __s32 pb_ChkSum;
> > __u32 pb_HostID;
> > __be32 pb_Next;
> > __u32
On 20180629 17:44, Michael Schmitz wrote:
> struct PartitionBlock {
> __be32 pb_ID;
> __be32 pb_SummedLongs;
> __s32 pb_ChkSum;
> __u32 pb_HostID;
> __be32 pb_Next;
> __u32 pb_Flags;
> __u32 pb_Reserved1[2];
> __u3
On 20180629 16:24, Michael Schmitz wrote:
> Martin,
>
>
...
> The problem that still remains is with unpatched legacy versions. RDB
> does support large enough partitions out of the box, due to C/H/S all
> using u32. We all agree there. The question is with file systems and
Nope, I bothered to re
Joanne,
Am 30.06.18 um 11:24 schrieb jdow:
>
> On 20180629 14:45, Martin Steigerwald wrote:
> > Beware: Essay ahead which proofs it to the point that there is no
> > overflow in RDB before 96 bits maximum value of sectors:
>
> Time to go into more detail on RDBs. It isn't as simple as it started
Martin,
Am 30.06.18 um 09:24 schrieb Martin Steigerwald:
> Hi Michael.
>
> Michael Schmitz - 29.06.18, 11:07:
>>> But it's up to the person (which is not Linux) formatting the disk
>>> to
>>> not try to use
>>> it on systems that cannot handle it, and may destroy it.
>>>
> Let me clarify: wha
On 20180629 14:45, Martin Steigerwald wrote:
> Beware: Essay ahead which proofs it to the point that there is no
> overflow in RDB before 96 bits maximum value of sectors:
Time to go into more detail on RDBs. It isn't as simple as it started to appear.
extract from hardblocks.h RDSK block defi
Beware: Essay ahead which proofs it to the point that there is no
overflow in RDB before 96 bits maximum value of sectors:
jdow - 29.06.18, 11:32:
> On 20180629 01:42, Michael Schmitz wrote:
> > Hi Geert,
> >
> > Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
> Do we really need the warni
Hi Michael.
Michael Schmitz - 29.06.18, 11:07:
> > But it's up to the person (which is not Linux) formatting the disk
> > to
> > not try to use
> > it on systems that cannot handle it, and may destroy it.
> >
> >>> Let me clarify: what exactly would the kernel option allow? When
> >>> to use it?>
Hi,
Geert Uytterhoeven - 29.06.18, 10:51:
> On Fri, Jun 29, 2018 at 10:43 AM Michael Schmitz
wrote:
> > Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
> > >>> Do we really need the warning?
> > >>> Once the parsing is fixed doing 64-bit math, it does not matter
> > >>> for
> > >>> Linux anymor
Hi Michael.
Michael Schmitz - 29.06.18, 10:42:
> Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
> >>> Do we really need the warning?
> >>> Once the parsing is fixed doing 64-bit math, it does not matter
> >>> for
> >>> Linux anymore.
> >>
> >> Well, irony of this is: In my case the RDB has been
On Jun 29 2018, Michael Schmitz wrote:
> Would MSDOS recognize the GPT partition as 'probably FAT', and attempt
> to use it?
GPT has the concept of a protective MBR which should prevent such errors.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 25
On 20180629 01:42, Michael Schmitz wrote:
Hi Geert,
Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
Do we really need the warning?
Once the parsing is fixed doing 64-bit math, it does not matter for
Linux anymore.
Well, irony of this is: In my case the RDB has been created on a machine
wit
Hi Geert,
Am 29.06.18 um 21:12 schrieb Geert Uytterhoeven:
> Hi Michael,
>
> On Fri, Jun 29, 2018 at 11:08 AM Michael Schmitz wrote:
>> Am 29.06.18 um 20:51 schrieb Geert Uytterhoeven:
Would MSDOS recognize the GPT partition as 'probably FAT', and attempt
to use it?
>>> No idea...
>>>
>
Hi Geert,
Am 29.06.18 um 21:10 schrieb Geert Uytterhoeven:
>
>> The question is - can writes to the disk cause any damage to data on the
>> disk, as seen by old OS versions? If the answer is no, we won't need the
>> option after all.
> You mean someone relying on the parameters of his RDB to over
Hi Michael,
On Fri, Jun 29, 2018 at 11:08 AM Michael Schmitz wrote:
> Am 29.06.18 um 20:51 schrieb Geert Uytterhoeven:
> >> Would MSDOS recognize the GPT partition as 'probably FAT', and attempt
> >> to use it?
> > No idea...
> >
> > Probably some old Windows or MacOS versions will just suggest t
Hi Geert,
Am 28.06.18 um 01:30 schrieb Geert Uytterhoeven:
> Hi Michael,
>
> Thanks for your patch!
>
> On Wed, Jun 27, 2018 at 4:47 AM wrote:
>> From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
> ??
>
>> The Amiga RDB partition parser module uses int for partition sector
>
Hi Michael,
On Fri, Jun 29, 2018 at 10:58 AM Michael Schmitz wrote:
> Am 28.06.18 um 18:45 schrieb Geert Uytterhoeven:
> > On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz
> > wrote:
> >> Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> > And as stated in my other reply to the patch:
> >
Hi Geert,
Am 29.06.18 um 20:51 schrieb Geert Uytterhoeven:
> Hi Michael,
>
>> Would MSDOS recognize the GPT partition as 'probably FAT', and attempt
>> to use it?
> No idea...
>
> Probably some old Windows or MacOS versions will just suggest to
> format your "new" disk ;-)
Yep, that's what I'd e
Hi Geert,
Am 28.06.18 um 18:45 schrieb Geert Uytterhoeven:
> Hi Michael,
>
> On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz wrote:
>> Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> And as stated in my other reply to the patch:
> partition needs 64 bit disk device support in AmigaO
Hi Michael,
On Fri, Jun 29, 2018 at 10:43 AM Michael Schmitz wrote:
> Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
> >>> Do we really need the warning?
> >>> Once the parsing is fixed doing 64-bit math, it does not matter for
> >>> Linux anymore.
> >> Well, irony of this is: In my case the RD
Hi Geert,
Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
>
>>> Do we really need the warning?
>>> Once the parsing is fixed doing 64-bit math, it does not matter for
>>> Linux anymore.
>> Well, irony of this is: In my case the RDB has been created on a machine
>> with a native OS. So Linux warn
On 20180628 00:39, Geert Uytterhoeven wrote:
Hi Martin,
On Thu, Jun 28, 2018 at 9:29 AM Martin Steigerwald wrote:
Michael Schmitz - 28.06.18, 06:58:
[…]
In the interest of least surprises, we have to fix the 32 bit
overflow (so we can even detect that it would have happened), and
give the use
Hi Joanne,
On Thu, Jun 28, 2018 at 11:20 AM jdow wrote:
> On 20180627 23:45, Geert Uytterhoeven wrote:
> > On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz
> > wrote:
> >> Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> > And as stated in my other reply to the patch:
> > partition n
Hi Martin,
On Thu, Jun 28, 2018 at 9:13 AM Martin Steigerwald wrote:
> Geert Uytterhoeven - 28.06.18, 08:45:
> > On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz
> wrote:
> > > Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> > > >>> And as stated in my other reply to the patch:
> > > >>> par
On 20180627 23:45, Geert Uytterhoeven wrote:
Hi Michael,
On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz wrote:
Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
And as stated in my other reply to the patch:
partition needs 64 bit disk device support in AmigaOS or AmigaOS
like
operating s
Hi Martin,
On Thu, Jun 28, 2018 at 9:29 AM Martin Steigerwald wrote:
> Michael Schmitz - 28.06.18, 06:58:
> […]
> > >> In the interest of least surprises, we have to fix the 32 bit
> > >> overflow (so we can even detect that it would have happened), and
> > >> give the user the chance to carefull
Hi Michael.
Probably I was right with not submitting a patch myself. I´d likely
would have been overwhelmed by the discussion and feedback :)
Michael Schmitz - 28.06.18, 06:58:
[…]
> >> In the interest of least surprises, we have to fix the 32 bit
> >> overflow (so we can even detect that it wou
Hi Geert.
Geert Uytterhoeven - 28.06.18, 08:45:
> On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz
wrote:
> > Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> > >>> And as stated in my other reply to the patch:
> > >>> partition needs 64 bit disk device support in AmigaOS or AmigaOS
> > >>>
Hi Michael,
On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz wrote:
> Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> >>> And as stated in my other reply to the patch:
> >>> partition needs 64 bit disk device support in AmigaOS or AmigaOS
> >>> like
> >>> operating systems (NSD64, TD64 or SCS
Hi Martin,
Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
And as stated in my other reply to the patch:
partition needs 64 bit disk device support in AmigaOS or AmigaOS
like
operating systems (NSD64, TD64 or SCSI direct)
I'd probably leave it at 'disk needs 64 bit disk device support on
n
Three issues exist here in two different places.
As far as a 32 TG disk is concerned RDBs can describe it and mount it safely -
sort of - modulo the following issues. They are not a problem, I believe, with
Amiga OSs new enough to understand RDBs. I cannot prove that. They are not
sufficient,
Error : Conventional RDBs cannot define more than 4,294,967,296 blocks.
or
Error : Conventional RDB block count overflow.
That is a HARD limit. The documentation for error should suggest larger
logical block (cluster, whatever) sizes as a way out. Of course, block size
"could" go u
Um. new 64 bit stuff must be invisible to old 32 bit stuff.
{^_^}
On 20180627 14:20, Martin Steigerwald wrote:
Hi Michael.
Michael Schmitz - 27.06.18, 22:13:
On Wed, Jun 27, 2018 at 8:24 PM, Martin Steigerwald
wrote:
Thanks a lot again for your patch.
schmitz...@gmail.com - 27.06.18, 03:24
Oops! It MUST be 64 bit or everything go boom.
{O.O}
On 20180627 06:30, Geert Uytterhoeven wrote:
Hi Michael,
Thanks for your patch!
On Wed, Jun 27, 2018 at 4:47 AM wrote:
From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
??
The Amiga RDB partition parser module us
Hi Michael.
Michael Schmitz - 27.06.18, 22:13:
> On Wed, Jun 27, 2018 at 8:24 PM, Martin Steigerwald
wrote:
> > Thanks a lot again for your patch.
> >
> > schmitz...@gmail.com - 27.06.18, 03:24:
> >> + if (start_sect > INT_MAX || nr_sects > INT_MAX
> >> + ||
Hi Geert,
thanks for your feedback!
On Thu, Jun 28, 2018 at 1:30 AM, Geert Uytterhoeven
wrote:
> Hi Michael,
>
> Thanks for your patch!
>
> On Wed, Jun 27, 2018 at 4:47 AM wrote:
>> From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
>
> ??
Comes from not using git send-emai
Hi Martin,
thanks for your comments.
On Wed, Jun 27, 2018 at 8:24 PM, Martin Steigerwald wrote:
> Thanks a lot again for your patch.
>
> schmitz...@gmail.com - 27.06.18, 03:24:
>> + if (start_sect > INT_MAX || nr_sects > INT_MAX
>> + || (start_sect + nr_sects)
Hi Michael,
Thanks for your patch!
On Wed, Jun 27, 2018 at 4:47 AM wrote:
> From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
??
> The Amiga RDB partition parser module uses int for partition sector
> address and count, which will overflow for disks 2 TB and larger.
>
> Us
Thanks a lot again for your patch.
schmitz...@gmail.com - 27.06.18, 03:24:
> + if (start_sect > INT_MAX || nr_sects > INT_MAX
> + || (start_sect + nr_sects) > INT_MAX) {
> + pr_err("%s: Warning: RDB partition
> overflow!\n", +
schmitz...@gmail.com - 27.06.18, 03:24:
> From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
>
> The Amiga RDB partition parser module uses int for partition sector
> address and count, which will overflow for disks 2 TB and larger.
>
> Use sector_t as type for sector address
>From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
The Amiga RDB partition parser module uses int for partition sector
address and count, which will overflow for disks 2 TB and larger.
Use sector_t as type for sector address and size (as expected by
put_partition) to allow us
56 matches
Mail list logo
