Re: RFC: disk geometry via sysfs

[Seewer Philippe]

Phillip Susi wrote:
> 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.
>>
> 
The problem does not end with fdisk. There are tons of tools (sfdisk,
parted, dosemu, ...) which would be affected.
-
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/