> quickly checking viro's changes in this area, it seems other partitions
> schemes are touched by the same problem...
I stand corrected. after looking a little bit deeper, the sun partition
has been corrected, the other are not touched.
However, I found out that sgi partitionning had this "renumbering"
issue even before viro's patch.
I don't know if this is correct, in any case this is an untested patch
that changes this behaviour for sgi partitions.
patch is attached because of dumb mailer.
thanks,
ghoz
On Mon, Jul 28, 2003 at 11:45:12PM +0200, Ghozlane Toumi wrote:
> However, I found out that sgi partitionning had this "renumbering"
> issue even before viro's patch.
> I don't know if this is correct, in any case this is an untested patch
> that changes this behaviour for sgi partitions.
> patch is attached because of dumb mailer.
> --------------------
> for(i = 0; i < 16; i++, p++) {
> blocks = be32_to_cpu(p->num_blocks);
> start = be32_to_cpu(p->first_block);
> if (blocks)
> - put_partition(state, slot++, start, blocks);
> + put_partition(state, i+1, start, blocks);
> }
> --------------------
Hmm. The previous change was not because there is something
intrinsically good with some way of numbering partitions,
but because it is very inconvenient when partition numbering
changes.
Thus, the previous patch made OSF in 2.6 do as it did in 2.4.
But here the 2.6 behaviour is already that of 2.4.21, and you
change away from that. Not a good idea.
Andries
You wrote :
> On Mon, Jul 28, 2003 at 11:45:12PM +0200, Ghozlane Toumi wrote:
>
> > However, I found out that sgi partitionning had this "renumbering"
> > issue even before viro's patch.
> > I don't know if this is correct, in any case this is an untested patch
> > that changes this behaviour for sgi partitions.
> > patch is attached because of dumb mailer.
> > --------------------
> > for(i = 0; i < 16; i++, p++) {
> > blocks = be32_to_cpu(p->num_blocks);
> > start = be32_to_cpu(p->first_block);
> > if (blocks)
> > - put_partition(state, slot++, start, blocks);
> > + put_partition(state, i+1, start, blocks);
> > }
> > --------------------
>
> Hmm. The previous change was not because there is something
> intrinsically good with some way of numbering partitions,
> but because it is very inconvenient when partition numbering
> changes.
Yes, you are right. It's just tht looking at similar paritionning code,
like osf, sun, ultrix, I didn't see/know why sgi would be different.
but I've never approached an sgi in my life and thus don't know
anything about irix partitionnnig uses.
> But here the 2.6 behaviour is already that of 2.4.21, and you
> change away from that. Not a good idea.
Agreed, obviously.
ghoz