If this interface is obsolete and will be removed, is there any non-obsolete
way of telling the kernel what geometry I want to use for this ide device?
--
Lab tests show that use of micro$oft causes cancer in lab animals
On 5/5/05, Wakko Warner <[email protected]> wrote:
> If this interface is obsolete and will be removed, is there any non-obsolete
> way of telling the kernel what geometry I want to use for this ide device?
Yes, physical geometry - through boot parameters and logical geometry
is not needed for IDE layer to function properly.
Bartlomiej
Bartlomiej Zolnierkiewicz wrote:
> On 5/5/05, Wakko Warner <[email protected]> wrote:
> > If this interface is obsolete and will be removed, is there any non-obsolete
> > way of telling the kernel what geometry I want to use for this ide device?
>
> Yes, physical geometry - through boot parameters and logical geometry
> is not needed for IDE layer to function properly.
I did not ask if it was needed for it to function, I asked how to set it
since the "settings" file is obsolete. Yes, I do need to set this. I want
to know what the "non-obsolete" way is. A project I'm working on uses linux
to do something with the drive and that is dependant on the geometry that
linux provides to programs be the same as what the bios thinks. I know how
to obtain the bios values. I have to set these values to the kernel so
everything functions properly.
If there is no "non-obsolete" way of doing this, then fine, I'll continue
with the settings thing.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Hi,
On 5/5/05, Wakko Warner <[email protected]> wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On 5/5/05, Wakko Warner <[email protected]> wrote:
> > > If this interface is obsolete and will be removed, is there any non-obsolete
> > > way of telling the kernel what geometry I want to use for this ide device?
> >
> > Yes, physical geometry - through boot parameters and logical geometry
> > is not needed for IDE layer to function properly.
>
> I did not ask if it was needed for it to function, I asked how to set it
> since the "settings" file is obsolete. Yes, I do need to set this. I want
> to know what the "non-obsolete" way is. A project I'm working on uses linux
> to do something with the drive and that is dependant on the geometry that
> linux provides to programs be the same as what the bios thinks. I know how
> to obtain the bios values. I have to set these values to the kernel so
> everything functions properly.
>
> If there is no "non-obsolete" way of doing this, then fine, I'll continue
> with the settings thing.
Please be aware that new applications are expected to use
/sys/firmware/edd/default_* instead of legacy HDIO_GETGEO ioctl
and there is currently no way to set these sysfs entries (maybe it
would be worthwile to add such functionality?).
Thanks,
Bartlomiej
On Iau, 2005-05-05 at 13:13, Bartlomiej Zolnierkiewicz wrote:
> Please be aware that new applications are expected to use
> /sys/firmware/edd/default_* instead of legacy HDIO_GETGEO ioctl
> and there is currently no way to set these sysfs entries (maybe it
> would be worthwile to add such functionality?).
Please be aware that edd is platform specific, buggy and dependant on
firmware features that many machines don't have. Don't use the EDD data
its junk. Bartlomiej's advice isn't something I'd agree with on this
point.
The fundamental issue behind all this though and the problem with
HDIO_GETGEO and friends is that geometry is basically a convenient
fiction for legacy software that needs an answer and apps that interact
with it.
For PC type systems you actually want to go and look at the partition
table itself and then follow that if one exists. If it doesn't exist
then you are in firmware magic land and you need to look at the drive's
current geometry reporting as well as the BIOS CMOS data, EDD on the
boxes that have it, openprom etc and so forth. Or better yet look at
parted and at least keep all the crap in one place.
Alan
Bartlomiej Zolnierkiewicz wrote:
> On 5/5/05, Wakko Warner <[email protected]> wrote:
> > If there is no "non-obsolete" way of doing this, then fine, I'll continue
> > with the settings thing.
>
> Please be aware that new applications are expected to use
> /sys/firmware/edd/default_* instead of legacy HDIO_GETGEO ioctl
> and there is currently no way to set these sysfs entries (maybe it
> would be worthwile to add such functionality?).
I am using edd to retrieve these parameters. Unfortunately there are some
utils that I use that I cannot give it the geometry. Those utils depend on
having the proper geometry so that the system can boot properly (no, it's
not booting linux).
I need to work around what I can't fix otherwise. So far, the proc entry is
the only solution I have seen.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Alan Cox wrote:
> On Iau, 2005-05-05 at 13:13, Bartlomiej Zolnierkiewicz wrote:
> > Please be aware that new applications are expected to use
> > /sys/firmware/edd/default_* instead of legacy HDIO_GETGEO ioctl
> > and there is currently no way to set these sysfs entries (maybe it
> > would be worthwile to add such functionality?).
>
> Please be aware that edd is platform specific, buggy and dependant on
> firmware features that many machines don't have. Don't use the EDD data
> its junk. Bartlomiej's advice isn't something I'd agree with on this
> point.
As stated in my last email, I am using EDD. I only need the legacy heads
and sectors. I can figure out the cylinders by that and the size of the
disk.
> The fundamental issue behind all this though and the problem with
> HDIO_GETGEO and friends is that geometry is basically a convenient
> fiction for legacy software that needs an answer and apps that interact
> with it.
Again, I am working with legacy stuff. I'm trying to move away from 2.4 due
to the convienences of 2.6
> For PC type systems you actually want to go and look at the partition
> table itself and then follow that if one exists. If it doesn't exist
> then you are in firmware magic land and you need to look at the drive's
> current geometry reporting as well as the BIOS CMOS data, EDD on the
> boxes that have it, openprom etc and so forth. Or better yet look at
> parted and at least keep all the crap in one place.
I have some utils (mkdosfs comes to mind) that do not let the user specify
heads/sectors/cyls (it doesn't use cyl actually).
--
Lab tests show that use of micro$oft causes cancer in lab animals
On Thu, May 05, 2005 at 11:33:27AM -0400, Wakko Warner wrote:
> I am using edd to retrieve these parameters. Unfortunately there are some
> utils that I use that I cannot give it the geometry. Those utils depend on
> having the proper geometry so that the system can boot properly (no, it's
> not booting linux).
>
> I need to work around what I can't fix otherwise. So far, the proc entry is
> the only solution I have seen.
If those utils just open and read some files under /proc, you could
always overmount those files or use some LD_PRELOAD magic.
--
pozsy
Pozs?r Bal?zs wrote:
> On Thu, May 05, 2005 at 11:33:27AM -0400, Wakko Warner wrote:
> > I am using edd to retrieve these parameters. Unfortunately there are some
> > utils that I use that I cannot give it the geometry. Those utils depend on
> > having the proper geometry so that the system can boot properly (no, it's
> > not booting linux).
> >
> > I need to work around what I can't fix otherwise. So far, the proc entry is
> > the only solution I have seen.
>
> If those utils just open and read some files under /proc, you could
> always overmount those files or use some LD_PRELOAD magic.
No no, I'm using /proc to set the right geometry. The programs use
HDGETGEO.
--
Lab tests show that use of micro$oft causes cancer in lab animals
> As stated in my last email, I am using EDD. I only need the legacy heads
> and sectors. I can figure out the cylinders by that and the size of the
> disk.
Which legacy size do you want though - the partition label, the disks
opinion this week or the CMOS. They can all be different. Linux used to
play "guess roughly what Windows might guess".
> I have some utils (mkdosfs comes to mind) that do not let the user specify
> heads/sectors/cyls (it doesn't use cyl actually).
Presumably they need to follow the MS sequence of guesses then, even on
non PC systems ? So partition table, cmos, drive in that order if I
remember rightly.
Alan Cox wrote:
> > As stated in my last email, I am using EDD. I only need the legacy heads
> > and sectors. I can figure out the cylinders by that and the size of the
> > disk.
>
> Which legacy size do you want though - the partition label, the disks
> opinion this week or the CMOS. They can all be different. Linux used to
> play "guess roughly what Windows might guess".
I think what I wanted got burried in a small geometry war.
> > I have some utils (mkdosfs comes to mind) that do not let the user specify
> > heads/sectors/cyls (it doesn't use cyl actually).
>
> Presumably they need to follow the MS sequence of guesses then, even on
> non PC systems ? So partition table, cmos, drive in that order if I
> remember rightly.
Not the initial problem.
Let me try to state what I originally wanted.
I am currently using edd to get the legacy heads and sectors then using that
and the size of the disk, I deduce the cylinders. Works great, no problems.
fdisk will let me specify and it works great. Ok, so I can do this guessing
game just fine.
Now, i have programs that I can't tell it the geometry (which it does use
and requires to be correct. My guesses using edd are correct). I was using
/proc/ide/hdX/settings to tell the kernel what geometry I want so the
programs that can only ask the kernel can get it right.
2.6.12-rc2. Works great. But what's this? it's obsolete? Ok, it's
obsolete, what is the non-obsolete way of SETTING the geometry. I looked at
ide.c and there's no HDSETGEO. I considered writing this myself or
unobsolete the /proc interface for my kernels, but if there's a "right" way
of doing this, I'd rather do it.
If the "right" way is via IOCTL, my scripts are written in perl that do the
bulk of the guess work.
I did not want this to be a geometry flame war. I realize linux doesn't
give a flying whatever about the geometry (only the number of sectors). The
systems I'm doing this with run OSs other than linux and they do care (i
wish they didn't!) I wasn't asking this for someone to tell me I didn't
need it.
--
Lab tests show that use of micro$oft causes cancer in lab animals
On Iau, 2005-05-05 at 17:33, Wakko Warner wrote:
> Now, i have programs that I can't tell it the geometry (which it does use
> and requires to be correct. My guesses using edd are correct). I was using
> /proc/ide/hdX/settings to tell the kernel what geometry I want so the
> programs that can only ask the kernel can get it right.
And the geometry ioctls are obsolete for the applications too.
> If the "right" way is via IOCTL, my scripts are written in perl that do the
> bulk of the guess work.
I suspect it is for other programs that are still using that geometry
data and
really mkdosfs is what needs fixing ?
Alan Cox wrote:
> On Iau, 2005-05-05 at 17:33, Wakko Warner wrote:
> > Now, i have programs that I can't tell it the geometry (which it does use
> > and requires to be correct. My guesses using edd are correct). I was using
> > /proc/ide/hdX/settings to tell the kernel what geometry I want so the
> > programs that can only ask the kernel can get it right.
>
> And the geometry ioctls are obsolete for the applications too.
What is the right way for apps that need it to get it? Or is the kernel
just going to obsolete geometry entirely?
> > If the "right" way is via IOCTL, my scripts are written in perl that do the
> > bulk of the guess work.
>
> I suspect it is for other programs that are still using that geometry
> data and
> really mkdosfs is what needs fixing ?
mkdosfs definately needs fixing. I intend on filing a bug report about
this.
If I knew more about the dos format, I might not even have to do this.
--
Lab tests show that use of micro$oft causes cancer in lab animals
On Iau, 2005-05-05 at 21:53, Wakko Warner wrote:
> What is the right way for apps that need it to get it? Or is the kernel
> just going to obsolete geometry entirely?
The truth is the kernel never knew. It often got it right on x86 but it
was never reliable. There are too many platform specific heuristics and
complications that depend on the intended use of the geometry for the
kernel to be the right place to do this.
The fact it got pushed out was intentional and something I agree with..