* /proc/ide/hd?/settings obsolete in 2.6.
@ 2005-05-05 0:48 Wakko Warner
2005-05-05 10:10 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 14+ messages in thread
From: Wakko Warner @ 2005-05-05 0:48 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 0:48 /proc/ide/hd?/settings obsolete in 2.6 Wakko Warner
@ 2005-05-05 10:10 ` Bartlomiej Zolnierkiewicz
2005-05-05 11:13 ` Wakko Warner
0 siblings, 1 reply; 14+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2005-05-05 10:10 UTC (permalink / raw)
To: linux-kernel
On 5/5/05, Wakko Warner <wakko@animx.eu.org> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 10:10 ` Bartlomiej Zolnierkiewicz
@ 2005-05-05 11:13 ` Wakko Warner
2005-05-05 12:13 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 14+ messages in thread
From: Wakko Warner @ 2005-05-05 11:13 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-kernel
Bartlomiej Zolnierkiewicz wrote:
> On 5/5/05, Wakko Warner <wakko@animx.eu.org> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 11:13 ` Wakko Warner
@ 2005-05-05 12:13 ` Bartlomiej Zolnierkiewicz
2005-05-05 14:56 ` Alan Cox
2005-05-05 15:33 ` Wakko Warner
0 siblings, 2 replies; 14+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2005-05-05 12:13 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz, linux-kernel
Hi,
On 5/5/05, Wakko Warner <wakko@animx.eu.org> wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On 5/5/05, Wakko Warner <wakko@animx.eu.org> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 12:13 ` Bartlomiej Zolnierkiewicz
@ 2005-05-05 14:56 ` Alan Cox
2005-05-05 15:38 ` Wakko Warner
2005-05-05 15:33 ` Wakko Warner
1 sibling, 1 reply; 14+ messages in thread
From: Alan Cox @ 2005-05-05 14:56 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 12:13 ` Bartlomiej Zolnierkiewicz
2005-05-05 14:56 ` Alan Cox
@ 2005-05-05 15:33 ` Wakko Warner
2005-05-05 15:53 ` Pozsár Balázs
1 sibling, 1 reply; 14+ messages in thread
From: Wakko Warner @ 2005-05-05 15:33 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-kernel
Bartlomiej Zolnierkiewicz wrote:
> On 5/5/05, Wakko Warner <wakko@animx.eu.org> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 14:56 ` Alan Cox
@ 2005-05-05 15:38 ` Wakko Warner
2005-05-05 16:21 ` Alan Cox
0 siblings, 1 reply; 14+ messages in thread
From: Wakko Warner @ 2005-05-05 15:38 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 15:33 ` Wakko Warner
@ 2005-05-05 15:53 ` Pozsár Balázs
2005-05-05 16:20 ` Wakko Warner
0 siblings, 1 reply; 14+ messages in thread
From: Pozsár Balázs @ 2005-05-05 15:53 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz, linux-kernel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 15:53 ` Pozsár Balázs
@ 2005-05-05 16:20 ` Wakko Warner
0 siblings, 0 replies; 14+ messages in thread
From: Wakko Warner @ 2005-05-05 16:20 UTC (permalink / raw)
To: Pozs?r Bal?zs; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 15:38 ` Wakko Warner
@ 2005-05-05 16:21 ` Alan Cox
2005-05-05 16:33 ` Wakko Warner
0 siblings, 1 reply; 14+ messages in thread
From: Alan Cox @ 2005-05-05 16:21 UTC (permalink / raw)
To: Wakko Warner; +Cc: Linux Kernel Mailing List
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 16:21 ` Alan Cox
@ 2005-05-05 16:33 ` Wakko Warner
2005-05-05 17:58 ` Alan Cox
0 siblings, 1 reply; 14+ messages in thread
From: Wakko Warner @ 2005-05-05 16:33 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 16:33 ` Wakko Warner
@ 2005-05-05 17:58 ` Alan Cox
2005-05-05 20:53 ` Wakko Warner
0 siblings, 1 reply; 14+ messages in thread
From: Alan Cox @ 2005-05-05 17:58 UTC (permalink / raw)
To: Wakko Warner; +Cc: Linux Kernel Mailing List
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 ?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 17:58 ` Alan Cox
@ 2005-05-05 20:53 ` Wakko Warner
2005-05-05 22:16 ` Alan Cox
0 siblings, 1 reply; 14+ messages in thread
From: Wakko Warner @ 2005-05-05 20:53 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: /proc/ide/hd?/settings obsolete in 2.6.
2005-05-05 20:53 ` Wakko Warner
@ 2005-05-05 22:16 ` Alan Cox
0 siblings, 0 replies; 14+ messages in thread
From: Alan Cox @ 2005-05-05 22:16 UTC (permalink / raw)
To: Wakko Warner; +Cc: Linux Kernel Mailing List
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..
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2005-05-05 22:18 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-05 0:48 /proc/ide/hd?/settings obsolete in 2.6 Wakko Warner
2005-05-05 10:10 ` Bartlomiej Zolnierkiewicz
2005-05-05 11:13 ` Wakko Warner
2005-05-05 12:13 ` Bartlomiej Zolnierkiewicz
2005-05-05 14:56 ` Alan Cox
2005-05-05 15:38 ` Wakko Warner
2005-05-05 16:21 ` Alan Cox
2005-05-05 16:33 ` Wakko Warner
2005-05-05 17:58 ` Alan Cox
2005-05-05 20:53 ` Wakko Warner
2005-05-05 22:16 ` Alan Cox
2005-05-05 15:33 ` Wakko Warner
2005-05-05 15:53 ` Pozsár Balázs
2005-05-05 16:20 ` Wakko Warner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.