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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
