On Sat, May 9, 2009 at 16:04, Tejun Heo <tj@xxxxxxxxxx> wrote: > Kay Sievers wrote: >> What does "alt_" stand for? I think that should be more descriptive in >> an exported interface. > > Alternative. > >> And can we please keep the "size_*" in front of the name, so that they >> group together? > > Maybe, but size_alt? Any better ideas? "size_limit" "size_restricted" "size_clipped" "size_constrain" anything that ideally would express that this is smaller than the actual "size", and that is is a "configured" value and not some hardware property. >> Also, values with magic block counts, while there is no way to get the >> blocksize with the same interface, are pretty weird. I think the >> current "size" attribute is just a bug. > > Logical block size is fixed at 512 bytes. Offset and size are always > represented in multiples of 512 bytes and only get converted to > hardware block size in the lld. Oh, good. Didn't know that this will always be 512, even for devices with a native size larger than this. >> Not sure, how that should be solved, by adding a "blocksize" attribute >> that is always in the same context as the current "size*" values, or >> by just using bytes for new attributes here. >> >> Almost all tools I've seen using these attributes, have hardcoded * >> 512 in there, which may cause trouble pretty soon. And this is mostly >> a failure of the interface and not of the users, I think. > > No, it will never break. It will always be 512. Cool. No problem then. :) > For userlevel exporting, it might have been better to use just bytes > there as preformance isn't really an issue, but, well, it's already > determined, so.. Right, but if it can not change, it's fine, I guess. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
