Re: RFC: disk geometry via sysfs

From: Phillip Susi
Date: Thu Feb 16 2006 - 10:35:14 EST


Seewer Philippe wrote:
Thats the problem point here. As of 2.6 the kernel does no longer know
anything about bios geometry. The exception here might be for older
drives which do not support lba, where the physical geometry is the one
the bios reports (if not configured diffently).

This is, as we all know, intentional. Because it's quite impossible to
always and accurately match bios disk information to drives reported by
drivers.


If it is intentional that the kernel not keep track of the bios geometry, then it should not track geometry at all. The only reason for the existence of GETGEO is so partitioning tools can figure out what to put in the MBR for the disk geometry. If they do not get the values that the bios reports, then they are getting useless information.

Why give the illusion that they got the right information when you are just lieing to them? Wouldn't it be better to fail the request so the tool knows it can't get the right info from the system?

Not only windows but other os as well.

The problem here is a general interface problem. Tools want one
interface (be it ioctl or sysfs). If they can depend on a kernel
interface only partially and have to determine values themeself
otherwise, that interface should be dropped. Again i'm talking about the
interface, not actual code which might still depend on c/h/s.


Exactly, the interface should be completely dropped since it really is useless to the tools anyhow without accurate information from the bios.

On the other hand, if we keep that interface (or perhaps ioctl for
compatibility and sysfs for newer things) and introduce a means to tell
the driver via userspace what we want, many things can be solved. For
example for older drives which need chs, userspace can tell the driver
what the bios uses if values differ. For other implementations which
return defaults which are correct in 80% of all cases, the other 20% can
be overridden.


That is true, but since the kernel doesn't use this information, it amounts to holding onto a user space configuration parameter. Since it's just a user space configuration parameter, shouldn't that go in a conf file in /etc or something, rather than burdening the kernel with that information? And since the kernel won't remember the settings across boots, then you're going to end up with them stored in a conf file anyhow with a boot time script that copies it to the kernel, so that fdisk can read it back from the kernel later. Since you likely will only partition a drive when installing, is there even a need to store it at all, let alone in the kernel? Just let fdisk ask the user or choose defaults.

It's of course not really the kernel's responsability to fix things (or
better allow the user to fix things) not important to Linux, but i think
for the sake of compatility necessary.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/