Re: RFC: disk geometry via sysfs

[Seewer Philippe]

Bartlomiej Zolnierkiewicz wrote:
>>
>>Q1: Yes or No?
>>If no, the other questions do not apply
> 
> 
> Yes?
> 
> 
>>Q2: Where under sysfs?
>>Either do /sys/block/hdx/heads, /sys/block/hdx/sectors, etc. or should
>>there be a new sub-object like /sys/block/hdx/geometry/heads?
> 
> 
> IMO /sys/block/hdx/sectors could be misleading
> therefore /sys/block/hdx/geometry/ would be better
> 
> 
>>Q3: Writable?
>>Under some (weird) circumstances it would actually be quite nice to
>>overwrite the kernels idea of a disks geometry. This would require a
>>general function like setgeo. Acceptable?
> 
> 
> Don't know.  Maybe you should make it into separate patch
> (incremental to basic functionality) so it can be decided later.
> 
> Cheers,
> Bartlomiej

Hi Bartlomiej

Thanks for your feedback. I'm currently testing the read export and it
seems to work fine.

If possible i'd like your opinion about how to implement write support.
I see 3 possibilities:
-Extend the gendisk struct by geometry information. If the user
overwrites the geometry, values from there are returned instead of
calling getgeo. This is the easiest way, because nothing has to be done
with subsystem drivers. On the other hand, if by chance a driver really
uses the geometry values he'll never know...
-Introduce a setgeo function as a companion to getgeo. Values under
sysfs will only be writable if the underlying drivers supplies this and
all writes will be delegated there. Drawback: Driver maintainers need to
think about this.
-The third way would be to combine both. Store the geometry in gendisk
if no setgeo is provided...

What do you think?

Thank you
Philippe Seewer
-
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/