Hi Vyacheslav, ------------------------------ On Wed, Apr 9, 2014 7:46 AM BST Vyacheslav Dubeyko wrote: >On Tue, 2014-04-08 at 20:53 +0100, Hin-Tak Leung wrote: > >[snip] > >> >> If you insist on doing Chinese all the way, 127/3 = 42 is really a bit low for a >> descriptive string of any usage, but does anybody use non-english extended >> attributes on any OSes? >> > >If you think that nobody use non-english extended attributes then it >doesn't make sense to make any fixes in xattr subsystem of HFS+. And >partial code changing in hfsplus_listxattr() is completely useless. >Because getxattr() and setxattr() series of methods will be the primary >source of error in the case of worst-case unicode to char conversion. > That was an information-gathering question - and also, once a feature is generally available on every fs, it probably will be used (and abused). Nobody uses attributes much ATM probably because there are a few common fs'es which does not have them (*cough* fat32 *cough*). Maybe the Chinese or the Koreans would use local namspaces for their version of selinux :-). There are different ways of dividing a series of patches. One can go about it purpose-based; but then, API-based (a patch for every usage instance of one function, one type of changes) is valid too, and sometimes cleaner to review. I have thought of one reason why one might want to split the current patch up: for cherry-picking/back-porting the long name fix to much older kernels which do not have the relatively new attribute stuff. But then, it is simple enough that it isn't too painful to backport by hand, if anybody really want it. Anyway, there are more patches to come, I am just not insisting on a declaring a plan for an explicit series. Anybody who wants to put his name down on further corrections is free to have a go. >Otherwise, you can use any splitting of fixes between patches. In my >last e-mail I suggested to use kmem cache approach for xattr names >instead of kmalloc only. I looked up what kmem cache does - I am not entirely convinced it would be faster/better. Remember we are talking about converting stack allocations which last the duration of 1 routine (the listxattr is longer, but all the others seem to be quite short), to dynamic allocations. They are fairly short-duration. kmem cache is more useful with things like inodes and dentry, which are relatively long lasting uniform sizes, but comes and goes. It could even be the case that kmem cache is *slower* in this case because of its small over-heads for exremely temporary allocations like these. We just don't know yet - or at least I don't know it yet :-). Hin-Tak -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
