---559023410-1804928587-905899558=:3921
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 15 Sep 1998, Gordon Chaffee wrote:
> If you want to make improvements, go ahead and create a patch. The
> particular code in question has been around for a long time. It seems
I'm rather familiar with the free software idea, and would love to
contribute to such projects... however, it's been my experience from
participating (intemittenly(sp?)) on this list for a couple of years that
obscure patches submitted by unknown people don't usually have much
change entering into codebase, and often for good reasons - last year I
had another performance-patch I didn't post for the simple reason that I
_knew_ it would have broken things on pracctically every other platform
besides mine, and I couldn't find anybody on other platforms to review it
;) So sometimes it seems more worth it to just simply remind people on
some basic principles of the area, and hope things get fixed
particularily as the code goes over it's usual cycles...
On that slightly sourer note, I did nevertheless get interested on this
particular problem, so I wrote the patch referred to. On a slight
tangent, you welcomed people to "look over the code"; I don't usually do
that, since kernels are quite new stuff to me. Places I've started with,
including this, are ones I've spotted by using the built-in kernel
profiler (plus a hacked-together improved version of readprofile
utility). Consistent with this, usually when I find a place with
inefficiencies I can't even be sure whether they're intentional or not -
like in this case I don't actually have any of the FAT, VFAT etc. specs
so I don't know if it's actually ever possible for cluster_size not to be
a power of two (I just checked mkfs.msdos does require it to be, but this
is still not to say it couldn't be something else with other tools). In
this patch, I've therefore included a "fallback-case" in case this
assumption isn't true; for all I know it's said to be true in some spec,
if not I'm sure people will tell if this patch will misbehave on them...
Enough of the ramble, though... there's still possible improvements: Are
the chosen algorithms best possible, and clear enough? I doubt this,
actually, but then, I'm always a bit of a perfectionist ;) Also, if the
assumption on powers of two proves to be true, there's many places where
multiplication by cluster-size could be replaced by shift operation.
sb->cluster_size might in fact be done away with completely.
-Donwulff
---559023410-1804928587-905899558=:3921
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="fatsmap-09161998.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SOL.3.90.980916014558.3921B@ankkuri.uwasa.fi>
Content-Description:
ZGlmZiAtLXVuaWZpZWQgLS1yZWN1cnNpdmUgbGludXguMTIwL2ZzL2ZhdC9j
YWNoZS5jIGxpbnV4L2ZzL2ZhdC9jYWNoZS5jDQotLS0gbGludXguMTIwL2Zz
L2ZhdC9jYWNoZS5jCVRodSBKYW4gMjIgMDM6NDY6NTYgMTk5OA0KKysrIGxp
bnV4L2ZzL2ZhdC9jYWNoZS5jCVdlZCBTZXAgMTYgMDM6NTY6MDQgMTk5OA0K
QEAgLTI3Niw4ICsyNzYsMTMgQEANCiAJCQlyZXR1cm4gMDsNCiAJCXJldHVy
biBzZWN0b3Irc2ItPmRpcl9zdGFydDsNCiAJfQ0KLQljbHVzdGVyID0gc2Vj
dG9yL3NiLT5jbHVzdGVyX3NpemU7DQotCW9mZnNldCA9IHNlY3RvciAlIHNi
LT5jbHVzdGVyX3NpemU7DQorCWlmKHNiLT5jbHVzdGVyX3NoaWZ0KSB7DQor
CQljbHVzdGVyID0gc2VjdG9yPj5zYi0+Y2x1c3Rlcl9zaGlmdDsNCisJCW9m
ZnNldCA9IHNlY3RvciAmIChzYi0+Y2x1c3Rlcl9zaXplLTEpOw0KKwl9IGVs
c2Ugew0KKwkJY2x1c3RlciA9IHNlY3RvciAvIHNiLT5jbHVzdGVyX3NpemU7
DQorCQlvZmZzZXQgPSBzZWN0b3IgJSBzYi0+Y2x1c3Rlcl9zaXplOw0KKwl9
DQogCWlmICghKGNsdXN0ZXIgPSBmYXRfZ2V0X2NsdXN0ZXIoaW5vZGUsY2x1
c3RlcikpKSByZXR1cm4gMDsNCiAJcmV0dXJuIChjbHVzdGVyLTIpKnNiLT5j
bHVzdGVyX3NpemUrc2ItPmRhdGFfc3RhcnQrb2Zmc2V0Ow0KIH0NCmRpZmYg
LS11bmlmaWVkIC0tcmVjdXJzaXZlIGxpbnV4LjEyMC9mcy9mYXQvaW5vZGUu
YyBsaW51eC9mcy9mYXQvaW5vZGUuYw0KLS0tIGxpbnV4LjEyMC9mcy9mYXQv
aW5vZGUuYwlTYXQgQXByICA0IDIwOjQ1OjE1IDE5OTgNCisrKyBsaW51eC9m
cy9mYXQvaW5vZGUuYwlXZWQgU2VwIDE2IDAzOjMzOjM1IDE5OTgNCkBAIC0y
ODIsNyArMjgyLDcgQEANCiAJaW50IGZhdDMyOw0KIAlzdHJ1Y3QgZmF0X21v
dW50X29wdGlvbnMgb3B0czsNCiAJY2hhciBidWZbNTBdOw0KLQlpbnQgaTsN
CisJaW50IGksajsNCiAJY2hhciBjdmZfZm9ybWF0WzIxXTsNCiAJY2hhciBj
dmZfb3B0aW9uc1sxMDFdOw0KIA0KQEAgLTM1Miw3ICszNTIsMTQgQEANCiAJ
bG9naWNhbF9zZWN0b3Jfc2l6ZSA9DQogCQlDRl9MRV9XKGdldF91bmFsaWdu
ZWQoKHVuc2lnbmVkIHNob3J0ICopICZiLT5zZWN0b3Jfc2l6ZSkpOw0KIAlz
ZWN0b3JfbXVsdCA9IGxvZ2ljYWxfc2VjdG9yX3NpemUgPj4gU0VDVE9SX0JJ
VFM7DQotCU1TRE9TX1NCKHNiKS0+Y2x1c3Rlcl9zaXplID0gYi0+Y2x1c3Rl
cl9zaXplKnNlY3Rvcl9tdWx0Ow0KKwlpID0gYi0+Y2x1c3Rlcl9zaXplKnNl
Y3Rvcl9tdWx0Ow0KKwlNU0RPU19TQihzYiktPmNsdXN0ZXJfc2l6ZSA9IGk7
DQorCWZvcihqPTA7KGk9aT4+MSkhPTA7aisrKTsNCisJaWYoKDE8PGopIT1i
LT5jbHVzdGVyX3NpemUqc2VjdG9yX211bHQpIHsNCisJCXByaW50aygiZmF0
X3JlYWRfc3VwZXI6IENsdXN0ZXIgc2l6ZSB3YXMgbm90IHBvd2VyIG9mIHR3
byFcbiIpOw0KKwkJaj0wOw0KKwl9DQorCU1TRE9TX1NCKHNiKS0+Y2x1c3Rl
cl9zaGlmdCA9IGo7DQogCU1TRE9TX1NCKHNiKS0+ZmF0cyA9IGItPmZhdHM7
DQogCU1TRE9TX1NCKHNiKS0+ZmF0X3N0YXJ0ID0gQ0ZfTEVfVyhiLT5yZXNl
cnZlZCkqc2VjdG9yX211bHQ7DQogCWlmICghYi0+ZmF0X2xlbmd0aCAmJiBi
LT5mYXQzMl9sZW5ndGgpIHsNCkBAIC01NTcsOCArNTY0LDEzIEBADQogCWlm
ICgoaW5vZGUtPmlfaW5vID09IE1TRE9TX1JPT1RfSU5PKSAmJiAoc2ItPmZh
dF9iaXRzICE9IDMyKSkgew0KIAkJcmV0dXJuIHNiLT5kaXJfc3RhcnQgKyBi
bG9jazsNCiAJfQ0KLQljbHVzdGVyID0gYmxvY2svc2ItPmNsdXN0ZXJfc2l6
ZTsNCi0Jb2Zmc2V0ID0gYmxvY2sgJSBzYi0+Y2x1c3Rlcl9zaXplOw0KKwlp
ZihzYi0+Y2x1c3Rlcl9zaGlmdCkgew0KKwkJY2x1c3RlciA9IGJsb2NrPj5z
Yi0+Y2x1c3Rlcl9zaGlmdDsNCisJCW9mZnNldCA9IGJsb2NrICYgKHNiLT5j
bHVzdGVyX3NpemUtMSk7DQorCX0gZWxzZSB7DQorCQljbHVzdGVyID0gYmxv
Y2sgLyBzYi0+Y2x1c3Rlcl9zaXplOw0KKwkJb2Zmc2V0ID0gYmxvY2sgJSBz
Yi0+Y2x1c3Rlcl9zaXplOw0KKwl9DQogCWlmICghKGNsdXN0ZXIgPSBmYXRf
Z2V0X2NsdXN0ZXIoaW5vZGUsY2x1c3RlcikpKSByZXR1cm4gMDsNCiAJcmV0
dXJuIChjbHVzdGVyLTIpKnNiLT5jbHVzdGVyX3NpemUrc2ItPmRhdGFfc3Rh
cnQrb2Zmc2V0Ow0KIH0NCmRpZmYgLS11bmlmaWVkIC0tcmVjdXJzaXZlIGxp
bnV4LjEyMC9pbmNsdWRlL2xpbnV4L21zZG9zX2ZzX3NiLmggbGludXgvaW5j
bHVkZS9saW51eC9tc2Rvc19mc19zYi5oDQotLS0gbGludXguMTIwL2luY2x1
ZGUvbGludXgvbXNkb3NfZnNfc2IuaAlGcmkgSmFuICA5IDAwOjAyOjQxIDE5
OTgNCisrKyBsaW51eC9pbmNsdWRlL2xpbnV4L21zZG9zX2ZzX3NiLmgJV2Vk
IFNlcCAxNiAwMzoyMjo1NyAxOTk4DQpAQCAtMzQsNiArMzQsNyBAQA0KIA0K
IHN0cnVjdCBtc2Rvc19zYl9pbmZvIHsNCiAJdW5zaWduZWQgc2hvcnQgY2x1
c3Rlcl9zaXplOyAvKiBzZWN0b3JzL2NsdXN0ZXIgKi8NCisJdW5zaWduZWQg
c2hvcnQgY2x1c3Rlcl9zaGlmdDsgLyogZm9yIGZhc3QgYm1hcCAqLw0KIAl1
bnNpZ25lZCBjaGFyIGZhdHMsZmF0X2JpdHM7IC8qIG51bWJlciBvZiBGQVRz
LCBGQVQgYml0cyAoMTIgb3IgMTYpICovDQogCXVuc2lnbmVkIHNob3J0IGZh
dF9zdGFydCxmYXRfbGVuZ3RoOyAvKiBGQVQgc3RhcnQgJiBsZW5ndGggKHNl
Yy4pICovDQogCXVuc2lnbmVkIHNob3J0IGRpcl9zdGFydCxkaXJfZW50cmll
czsgLyogcm9vdCBkaXIgc3RhcnQgJiBlbnRyaWVzICovDQo=
---559023410-1804928587-905899558=:3921--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/