Messages in this thread | | | Date | Wed, 15 Feb 2006 08:57:06 +0100 | From | "Seewer Philippe" <> | Subject | Re: RFC: disk geometry via sysfs |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |