On Sat, Jan 08, 2000 at 12:29:22AM +1300, Mark van Walraven wrote:
> Which leads me wonder how difficult it would be if I wanted to change the
> format of /proc/partitions from:
>
> "%4d %4d %10d %s\n",
> p->major, n,
> p->sizes[n],
> disk_name(p, n, buf)
>
> to:
>
> "%4d %4d %10d %s %02x\n",
> p->major, n,
> p->sizes[n],
> disk_name(p, n, buf),
> p->sys_ind
>
> That is, to include the partition type.
It would be very easy. Please don't.
> It would eliminate the need to be able to parse six kinds of partition
> table in a program I am modifying, but also potentially break many
> programs that rely on the current format. Are, could or should there be
> rules for formats, that they can be extended while retaining backwards
> compatibility? (Creating a parallel "/proc/xpartitions", while easy to
> do, does not appeal to me.)
Without /proc/partitions it is almost impossible to find out
what disks exist, what partitions are recognized by the kernel,
and do "mount by volume label". That is the purpose of /proc/partitions.
On the other hand, finding p->sys_ind is completely trivial
(read the partition table and look up this field - you can steal
the code from any *fdisk version).
Moreover, many types of partition table do not have any p->sys_ind.
- indeed, this is something that applies to DOS-type partition tables only -
so in general it is not meaningful to provide such a field.
[Before people start contradicting - yes, many other types of
partition table also have some kind of a systemtype identifier,
but the values are different, so such an additional field in
/proc/partitions would not be meaningful without the additional
information in what kind of partition table the system type was found.]
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:09 EST