grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Set size of partition correctly in grub_disk_open()


From: Yoshinori K. Okuji
Subject: Re: [PATCH] Set size of partition correctly in grub_disk_open()
Date: Sun, 9 Jul 2006 03:11:33 +0200
User-agent: KMail/1.8.2

On Sunday 09 July 2006 01:35, Jeroen Dekkers wrote:
> The illogical thing for me is: You ask to open a partition, you get
> back a structure that has half the properties of the partition, and
> the other half has the properties of the disk the partition is on.

I don't see this. When you open a partiton or a disk, you get a device but not 
a disk... don't you?

> For me the grub_disk_* seem to just be an abstract interface to either
> open a disk or a partition. This just worked all fine, except that
> total_sectors that doesn't match what grub_disk_read() does.

Because, for me, a partition is an attribute for a disk.

> > > It's also not really useful: if you're opening a
> > > partition, your are interested in the size of the partition most of
> > > the time, not the size of the disk the partition is on.
> >
> > No. When you open something, you usually have no interest in the size.
>
> Yes, but those unusual places that do have interest in it want to know
> the size of the partition and not the size of the disk that contains
> the partition.

It depends on a case. I sometimes wanted to know disk information even when 
opening a partition, but I don't remember which case exactly. I must take a 
look at the code.

> > blocklist does not. I fixed this bug some weeks ago.
>
> grub_fs_blocklist_open() has the following:
>
> if (disk->total_sectors < blocks[i].offset + blocks[i].length)
>   {
>     grub_error (GRUB_ERR_BAD_FILENAME, "beyond the total sectors");
>     goto fail;
>   }

Ah, you meant the blocklist _filesystem_. I misunderstood that you meant the 
blocklist _command_. Yes, you are right. This is a bug. I haven't tested the 
blocklist filesystem with a partition, so I didn't know this bug. I will fix 
it later.

> > I don't remember about AFFS. I haven't proofread the code carefully.
>
> AFAICS it calculates the position of the root block wrong, by assuming
> that disk->total_sectors is the size of the partition it's reading.

I see. It is definitely a bug. I must fix it.

> The RAID superblock is located at 64KiB before the end of the device,
> which can either be a partition or a whole disk. (For AFFS it seems
> that the root block is located in the middle of the partition)

OK.

> So why do I get a disk structure when I want to open a partition, and
> not a partition structure, if disk structures aren't for partitions?

You get *both*. I assume that the question is the hierarchy. The current 
design is based on this concept:

device -> disk -> partition
      \
       -> net -> protocol

I did want to abstract all kinds of devices as just devices, whenever 
possible. And the real character of a given device is described as attributes 
to the device (here, "disk" and "net"). In this organization, it is natural 
to have "partition" under "disk". If this order is reverse, it is very 
strange to me, because "partition" does not exist without "disk", as the 
purpose of "partition" is to partition a disk. Am I wrong?

Okuji




reply via email to

[Prev in Thread] Current Thread [Next in Thread]