Andries, others,
Thanks for hacking through the code of fs/partitions/ibm.c.
Your patch does not work at all because you are relying on the
data in the part component of the hd structure, which does not
hold the geometry data of the disk but the data of the partitions
on that disk. Besides that, exactly these data are to be set up
by the code in fs/partitions/ibm.c.
The geometry data is stored in the device driver. As in oposition
to the partition schemes the device drivercan be a loadable
module, fs/partitions.c should not at all directly call or use symbols
from the device driver.
My preferred solution would be having partition schemes as
loadable modules, too. Maybe I'll find some time to post the
approriate patch on this list soon...
Regards,
Holger Smolinski
IBM Germany
Linux/390 Kernel Development
Sch?naicher Str.220, D-71032 B?blingen
>Reading patch-2.4.2 I met a strange amount of crap in
>partitions/ibm.c. It is as if the author does not know
>where the kernel keeps the starting offset of a partition,
>and simulates a HDIO_GETGEO ioctl from user space.
>I think the following patch does the same and removes a lot
>of cruft. (Warning: (i) untested, uncompiled; (ii) pasted
>from another window - tabs will have become spaces.)
>Andries
From [email protected] Mon Feb 26 12:10:59 2001
Andries, others,
Thanks for hacking through the code of fs/partitions/ibm.c.
Your patch does not work at all because you are relying on the
data in the part component of the hd structure, which does not
hold the geometry data of the disk but the data of the partitions
on that disk.
Hmm. To me "geometry" means things with sectors, heads and cylinders -
something you do not need at all. You only need to know whether you
have to read sector 1 or 2 from this disk.
Besides that, exactly these data are to be set up
by the code in fs/partitions/ibm.c.
No.
ibm_partition() is called from check_partition(), which does
first_sector = hd->part[MINOR(dev)].start_sect;
and then calls ibm_partition() with first_sector as third parameter.
Clearly, this assumes that hd->part[MINOR(dev)].start_sect
has a value already.
The "start" field of the struct returned by HDIO_GETGEO does not
tell us where the partition table lives.
It tells us where the partition starts. Maybe there is no table.
For an entire disk the answer will be zero.
Thus, I think the present setup of ibm_partition() is broken.
(If I have a disk with ibm partition, then it seems right now
it cannot be moved to some ide or scsi machine because the
information you want is returned only by the
device->discipline->fill_geometry()
call in dasd.c, and not by the HDIO_GETGEO of any other driver.)
Andries
[And, of course, similarly, these fill_geometry() routines are broken.]
Andries,
okay, your arguments appear correct to me. Additionally there has some
other work
to be done... I include the patch to be applied from my point of view:
(See attached file: ibmpart.diff)
It includes the adaptions to the dasd_*.c files in drivers/s390/block and
also should
fix the fill_geometry functions to make HDIO_GETGEO work like others.
Gruesse / Regards
Dr. Holger Smolinski
Linux for S/390 Design & Development,
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, D-71032 Boeblingen
Phone/FAX: +49 7031 16 (x902) - 4652/3456
> your arguments appear correct to me
> I include the patch to be applied from my point of view
Good. Had no time today to look at the details, but at first sight
this is a big improvement. May want to nitpick a little some other time.
Andries