Frediano Ziglio <[email protected]> writes:
> Yes and not... HDIO_GETGEO still exists and report inconsistent
> informations. IMHO should be removed. I know this breaks some
> existing programs however these programs do not actually works
> correctly.
Existing programs work fine if you do something like this first:
echo bios_head:255 > /proc/ide/hda/settings
I know this works because it is how I convince Parted to prep a blank
drive for installing Windows. In fact, it is the only way for me to
communicate the geometry to Parted, as far as I know. (Other tools
usually have command-line switches or "expert" settings to control the
geometry; Parted does not.)
SCSI and RAID devices already return a suitable geometry in
HDIO_GETGEO on all of the systems that I or my users have tried.
So one approach is to leave HDIO_GETGEO alone, and to have a userspace
gadget run early to "fix" the kernel's notion of the geometry. This
would avoid the need to rewrite every partitioning tool.
- Pat
On Thursday 03 of June 2004 16:46, Patrick J. LoPresti wrote:
> Frediano Ziglio <[email protected]> writes:
> > Yes and not... HDIO_GETGEO still exists and report inconsistent
> > informations. IMHO should be removed. I know this breaks some
> > existing programs however these programs do not actually works
> > correctly.
>
> Existing programs work fine if you do something like this first:
>
> echo bios_head:255 > /proc/ide/hda/settings
>
> I know this works because it is how I convince Parted to prep a blank
> drive for installing Windows. In fact, it is the only way for me to
> communicate the geometry to Parted, as far as I know. (Other tools
> usually have command-line switches or "expert" settings to control the
> geometry; Parted does not.)
>
> SCSI and RAID devices already return a suitable geometry in
> HDIO_GETGEO on all of the systems that I or my users have tried.
>
> So one approach is to leave HDIO_GETGEO alone, and to have a userspace
> gadget run early to "fix" the kernel's notion of the geometry. This
> would avoid the need to rewrite every partitioning tool.
This is a bandaid not a solution and it is just silly (you push
some values into kernel just to read them back by user-space).
Also what if kernel is compiled with CONFIG_PROC_FS=n
or if I decide to pull out /proc/ide/hdx/settings one day?
[ I'm counting days. 8) ]
Cheers,
Bartlomiej
Bartlomiej Zolnierkiewicz <[email protected]> writes:
> > So one approach is to leave HDIO_GETGEO alone, and to have a
> > userspace gadget run early to "fix" the kernel's notion of the
> > geometry. This would avoid the need to rewrite every partitioning
> > tool.
>
> This is a bandaid not a solution and it is just silly (you push
> some values into kernel just to read them back by user-space).
It might be silly if we were designing all this from scratch. But in
the context of current practice and current tools, it is not so
obvious, at least to me. HDIO_GETGEO has existed forever, and it is
used by all current partitioning tools (and some non-partitioning
tools, such as dosemu).
> Also what if kernel is compiled with CONFIG_PROC_FS=n
> or if I decide to pull out /proc/ide/hdx/settings one day?
Then my code will break. :-)
I have no theoretical objection to eliminating HDIO_GETGEO and
/proc/ide/hdx/settings. But it would be polite to have a nice long
deprecation period because these interfaces ARE in use. It is the
only way to use Parted for my application, for example.
- Pat