|
From: Yura P. <yu...@de...> - 2006-08-14 03:52:17
|
Changes by: yura Update of /cvs/linux-ntfs/ntfsprogs/ntfsprogs In directory delta357.server4you.de:/tmp/cvs-serv29720/ntfsprogs Modified Files: ntfsinfo.c Log Message: fix endianness in ntfsinfo preparation fix to index code btw, Szaka, you really should consider installing some cross-compiler for BE systems and qemu to test your changes. Index: ntfsinfo.c =================================================================== RCS file: /cvs/linux-ntfs/ntfsprogs/ntfsprogs/ntfsinfo.c,v retrieving revision 1.145 retrieving revision 1.146 diff -u -p -r1.145 -r1.146 --- ntfsinfo.c 13 Aug 2006 19:09:22 -0000 1.145 +++ ntfsinfo.c 14 Aug 2006 03:52:09 -0000 1.146 @@ -6,7 +6,7 @@ * Copyright (c) 2002-2005 Richard Russon * Copyright (c) 2003-2006 Szabolcs Szakacsits * Copyright (c) 2004-2005 Yuval Fledel - * Copyright (c) 2004-2005 Yura Pakhuchiy + * Copyright (c) 2004-2006 Yura Pakhuchiy * Copyright (c) 2005 Cristian Klein * * This utility will dump a file's attributes. @@ -113,7 +113,7 @@ static void version(void) printf(" 2003-2006 Szabolcs Szakacsits\n"); printf(" 2003 Leonard Norrgård\n"); printf(" 2004-2005 Yuval Fledel\n"); - printf(" 2004-2005 Yura Pakhuchiy\n"); + printf(" 2004-2006 Yura Pakhuchiy\n"); printf("\n%s\n%s%s\n", ntfs_gpl, ntfs_bugs, ntfs_home); } @@ -678,7 +678,8 @@ static void ntfs_dump_attr_list(ATTR_REC printf("unnamed\n"); printf("\t\tPadding:\t"); ntfs_dump_bytes((u8 *)entry, entry->name_offset + - 2 * entry->name_length, entry->length); + sizeof(ntfschar) * entry->name_length, + le16_to_cpu(entry->length)); printf("\n"); } free(value); @@ -831,7 +832,10 @@ static void ntfs_dump_acl(const char *pr printf("%sRevision\t %u\n", prefix, acl->revision); - /* don't recalc le16_to_cpu every iteration (minor speedup on big-endians */ + /* + * Do not recalculate le16_to_cpu every iteration (minor speedup on + * big-endian machines. + */ ace_count = le16_to_cpu(acl->ace_count); /* initialize 'ace' to the first ace (if any) */ @@ -859,7 +863,7 @@ static void ntfs_dump_acl(const char *pr } printf("%sACE:\t\t type:%s flags:0x%x access:0x%x\n", prefix, - ace_type, (unsigned int)le16_to_cpu(ace->flags), + ace_type, (unsigned int)ace->flags, (unsigned int)le32_to_cpu(ace->mask)); /* get a SID string */ sid = ntfs_sid_to_mbs(&ace->sid, NULL, 0); @@ -867,7 +871,8 @@ static void ntfs_dump_acl(const char *pr free(sid); /* proceed to next ACE */ - ace = (ACCESS_ALLOWED_ACE *)(((char *)ace) + le32_to_cpu(ace->size)); + ace = (ACCESS_ALLOWED_ACE *)(((char *)ace) + + le32_to_cpu(ace->size)); } } @@ -880,7 +885,8 @@ static void ntfs_dump_security_descripto printf("%s\tRevision:\t\t %u\n", indent, sec_desc->revision); /* TODO: parse the flags */ - printf("%s\tControl:\t\t 0x%04x\n", indent, sec_desc->control); + printf("%s\tControl:\t\t 0x%04x\n", indent, + le16_to_cpu(sec_desc->control)); if (~sec_desc->control & SE_SELF_RELATIVE) { @@ -1153,12 +1159,13 @@ static const char *get_attribute_type_na static void ntfs_dump_attribute_header(ATTR_RECORD *a, ntfs_volume *vol) { printf("Dumping attribute %s (%#02x)\n", - get_attribute_type_name(a->type), a->type); + get_attribute_type_name(a->type), le32_to_cpu(a->type)); ntfs_log_verbose("\tAttribute length:\t %u\n", le32_to_cpu(a->length)); printf("\tResident: \t\t %s\n", a->non_resident ? "No" : "Yes"); ntfs_log_verbose("\tName length:\t\t %u\n", a->name_length); - ntfs_log_verbose("\tName offset:\t\t %u\n", le16_to_cpu(a->name_offset)); + ntfs_log_verbose("\tName offset:\t\t %u\n", + le16_to_cpu(a->name_offset)); /* Dump the attribute (stream) name */ if (a->name_length) { @@ -1573,7 +1580,7 @@ static void ntfs_dump_usa_lsn(const char printf("%sUpd. Seq. Array Count:\t %hu\n", indent, le16_to_cpu(mrec->usa_count)); printf("%sUpd. Seq. Number:\t %hu\n", indent, - *(u16 *)((u8 *)mrec + le16_to_cpu(mrec->usa_ofs))); + le16_to_cpup((u16 *)((u8 *)mrec + le16_to_cpu(mrec->usa_ofs)))); printf("%sLogFile Seq. Number:\t 0x%llx\n", indent, (long long int)sle64_to_cpu(mrec->lsn)); } @@ -1654,7 +1661,8 @@ static void ntfs_dump_attr_index_allocat int entries; entries = ntfs_dump_index_block(tmp_alloc, type, - ir->index_block_size); + le32_to_cpu( + ir->index_block_size)); if (entries != -1) { total_entries += entries; total_indx_blocks++; @@ -1662,7 +1670,8 @@ static void ntfs_dump_attr_index_allocat } } tmp_alloc = (INDEX_ALLOCATION *)((u8 *)tmp_alloc + - ir->index_block_size); + le32_to_cpu( + ir->index_block_size)); bit++; if (bit > 7) { bit = 0; |
|
From: Szakacsits S. <sz...@si...> - 2006-08-14 06:46:40
|
On Mon, 14 Aug 2006, Yura Pakhuchiy wrote: > Modified Files: > ntfsinfo.c > Log Message: > fix endianness in ntfsinfo preparation fix to index code > > btw, Szaka, you really should consider installing some cross-compiler for > BE systems and qemu to test your changes. I've explain this already. All access will be fixed bet setter and getters. It's double work doing now separately. You also offered to correct them, so I can't see problem here. Good teamwork. Thanks. Szaka |
|
From: Yura P. <pak...@gm...> - 2006-08-14 07:09:50
|
On Mon, 14 Aug 2006 at 09:42 +0300, Szakacsits Szabolcs wrote:
> On Mon, 14 Aug 2006, Yura Pakhuchiy wrote:
>
> > Modified Files:
> > ntfsinfo.c
> > Log Message:
> > fix endianness in ntfsinfo preparation fix to index code
> >
> > btw, Szaka, you really should consider installing some cross-compiler for
> > BE systems and qemu to test your changes.
>
> I've explain this already. All access will be fixed bet setter and getters.
> It's double work doing now separately.
> You also offered to correct them, so I can't see problem here. Good
> teamwork. Thanks.
--
Best regards,
Yura
|
|
From: Anton A. <ai...@ca...> - 2006-08-14 07:48:54
|
On Mon, 2006-08-14 at 09:42 +0300, Szakacsits Szabolcs wrote:
> On Mon, 14 Aug 2006, Yura Pakhuchiy wrote:
>
> > Modified Files:
> > ntfsinfo.c
> > Log Message:
> > fix endianness in ntfsinfo preparation fix to index code
> >
> > btw, Szaka, you really should consider installing some cross-compiler for
> > BE systems and qemu to test your changes.
>
> I've explain this already. All access will be fixed bet setter and getters.
> It's double work doing now separately.
You still have not given an example of what that will look like even
though I have asked you at least once before and am asking again now,
please show us an example...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/
|
|
From: Szakacsits S. <sz...@si...> - 2006-08-14 21:59:25
|
On Mon, 14 Aug 2006, Anton Altaparmakov wrote: > On Mon, 2006-08-14 at 09:42 +0300, Szakacsits Szabolcs wrote: > > On Mon, 14 Aug 2006, Yura Pakhuchiy wrote: > > > > > Modified Files: > > > ntfsinfo.c > > > Log Message: > > > fix endianness in ntfsinfo preparation fix to index code > > > > > > btw, Szaka, you really should consider installing some cross-compiler for > > > BE systems and qemu to test your changes. > > > > I've explain this already. All access will be fixed bet setter and getters. > > It's double work doing now separately. > > You still have not given an example of what that will look like even > though I have asked you at least once before and am asking again now, > please show us an example... Actually I did a few times, e.g. here, over three years ago: http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=104887800631790&w=2 Please also note that when I was back I've had over 800 emails, 140+ still not fully read/answered and have/had plenty of other things to arrange and do, among others, to somehow recover from a nasty virus infection. Szaka |
|
From: Anton A. <ai...@ca...> - 2006-08-14 23:36:14
|
On Tue, 15 Aug 2006, Szakacsits Szabolcs wrote: > On Mon, 14 Aug 2006, Anton Altaparmakov wrote: > > On Mon, 2006-08-14 at 09:42 +0300, Szakacsits Szabolcs wrote: > > > On Mon, 14 Aug 2006, Yura Pakhuchiy wrote: > > > > > > > Modified Files: > > > > ntfsinfo.c > > > > Log Message: > > > > fix endianness in ntfsinfo preparation fix to index code > > > > > > > > btw, Szaka, you really should consider installing some cross-compiler for > > > > BE systems and qemu to test your changes. > > > > > > I've explain this already. All access will be fixed bet setter and getters. > > > It's double work doing now separately. > > > > You still have not given an example of what that will look like even > > though I have asked you at least once before and am asking again now, > > please show us an example... > > Actually I did a few times, e.g. here, over three years ago: > > http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=104887800631790&w=2 > > Please also note that when I was back I've had over 800 emails, 140+ still > not fully read/answered and have/had plenty of other things to arrange and > do, among others, to somehow recover from a nasty virus infection. So why did you say that my description and criticims of your getters/setters had nothing to do with what I described? The example that you are showing above is the exact abstraction I was criticising! And if that is all you are planning than no thanks. It is a completely unnecessary performance hit I am not willing to take. If you still think I am misunderstanding you then you will have to give a lot more details than that email you reference above so I can understand what you mean... To help you out here is what I wrote that you said I was misunderstanding: <quote> That is your opinion. I don't like this "setters and getters" abstraction at all. I think it is completely unnecessary code obfuscation and makes the code unreadable and unmaintanable. cpu_to_le* and le*_to_cpu is correct and shows what is going on and nothing else is needed. Sometimes we do _not_ want conversion because we are reading a value and then writing it directly and the conversion just wastes CPU cycles. Further we compare values in little endian when comparing for equality but we compare in cpu endianness when we compare for less/greater than, etc. All this is horrible to implement with your getters/setters abstractions... </quote> And you said that your getters/setters implementation is nothing like what my thinking is but it seems it is exactly like what I am thinking you are wanting to do. Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ |
|
From: Szakacsits S. <sz...@si...> - 2006-08-15 00:00:47
|
On Tue, 15 Aug 2006, Anton Altaparmakov wrote:
>
> So why did you say that my description and criticims of your
> getters/setters had nothing to do with what I described?
Where did I write it is has __nothing__ to do with it? This is what I
wrote:
Yura: If this setters/getters abstraction will be like Anton described,
Szaka: No, it's not.
That's all I can find and that's what I've meant.
> And if that is all you are planning than no thanks. It is a completely
> unnecessary performance hit I am not willing to take. If you still think
> I am misunderstanding you then you will have to give a lot more details
> than that email you reference above so I can understand what you mean...
Talk, talk, talk just because you keep misunderstanding and confusing
things. How about some work getting done? For this year this is the commit
statistic:
443 szaka (including index code)
52 yura
39 antona
5 uvman
I think you barely do anything else just setting back the project for quite
a while. I really hope you don't do this intentionally.
> To help you out here is what I wrote that you said I was misunderstanding:
Thanks.
> <quote>
> That is your opinion. I don't like this "setters and getters" abstraction
> at all. I think it is completely unnecessary code obfuscation and makes
> the code unreadable and unmaintanable. cpu_to_le* and le*_to_cpu is
> correct and shows what is going on and nothing else is needed.
And the code sometimes has different macros for the same member. Or
consistently used badly.
> Sometimes we do _not_ want conversion because we are reading a value and
> then writing it directly and the conversion just wastes CPU cycles.
Then just don't use it. Or use a different macro.
> Further we compare values in little endian when comparing for equality
> but we compare in cpu endianness when we compare for less/greater than,
> etc.
Same.
> And you said that your getters/setters implementation is nothing like what
> my thinking is but it seems it is exactly like what I am thinking you are
> wanting to do.
I don't remember this "nothing like", really. I've never meant it, so I
shouldn't have ever wrote it.
Szaka
|
|
From: Anton A. <ai...@ca...> - 2006-08-15 07:52:37
|
On Tue, 2006-08-15 at 02:56 +0300, Szakacsits Szabolcs wrote:
> On Tue, 15 Aug 2006, Anton Altaparmakov wrote:
> > And if that is all you are planning than no thanks. It is a completely
> > unnecessary performance hit I am not willing to take. If you still think
> > I am misunderstanding you then you will have to give a lot more details
> > than that email you reference above so I can understand what you mean...
>
> Talk, talk, talk just because you keep misunderstanding and confusing
> things. How about some work getting done? For this year this is the commit
> statistic:
>
> 443 szaka (including index code)
> 52 yura
> 39 antona
> 5 uvman
>
> I think you barely do anything else just setting back the project for quite
> a while. I really hope you don't do this intentionally.
What does the above say? Nothing. I have been working on the kernel
drivers for Linux and OSX and neither of those are public at present so
you have no idea how many commits I would have if you add those up.
Anyway there wouldn't be many as for Linux I am not doing any commits -
just working in a local directory without source control and for OSX I
just commit once a week or so as a form of backup mechanism rather than
anything else. That doesn't change the fact that my diff between the
current kernel driver and the modified kernel driver currently is at
751kiB according to diff stat containing 11834 insertions and 3054
deletions and the OSX kernel driver is currently as 23327 lines (counted
with "wc -l"). So I have worked on over 35 thousand lines of code since
going behind closed doors... And note that some of the serious bug
fixes in the Linux kernel driver I asked for permission to submit to the
mainstream kernel and I was allowed to do it. Pretty much the entirety
of the last one or two NTFS kernel driver releases are based on this
work behind closed doors. So it is not like the public is not
benefiting from my work already...
How many lines of code have you done? That's a true measure of how much
work has been done... Commits are totally meaningless in comparison...
I can have hundreds/thousands of commits if I were to commit every
little tiny thing I do but given I am working by myself and don't need
to submit small patches for review to anyone yet I don't bother and just
do lots of work instead.
Anyway this is not a pissing contest so lets stop this here!
All of us want that this project succeeds and I believe we all want that
just the same.
But please don't tell me I am holding the project back. In my opinion I
am taking it forward massively but you can't see that until it is all
released and everyone can then benefit at once fully. It may not be how
you like doing things and I would prefer to just be able to release
everything I do but it is better this way than if I didn't do it at all.
I certainly don't see anyone else doing the needed kernel work...
And yes you think FUSE will work as well as the kernel driver but I
don't agree and in the end when both drivers are complete we can
benchmark them against each other and then we will see. (-: I am sure
both drivers will have good and bad points and both will be able to
merge things from each other to make them even faster...
I still believe that only kernel drivers are really useful as a user
space driver couldn't for example be a root file system (I may be wrong
and it may be possible to do it somehow using an initrd or something - I
have never tried but it certainly is more work then just having a kernel
module to load or even built into the kernel) and also I do not believe
that FUSE can ever be as fast as a kernel implementation.
And I don't think the performance numbers you showed mean that much as
such. If you compared the exact same file system implementation once in
the kernel and once in user space I bet you you would see a difference
in favour of the kernel (certainly last week when I was in California I
heard very different numbers to yours when comparing e.g. ext3 in-kernel
and ex-kernel through FUSE on Linux). Also your numbers are meaningless
because ntfsmount/-3g are single threaded whereas all other drivers you
compared against are multithreaded so the moment you would run a
multithreaded benchmark ntfsmount/-3g would immediately suck _really_
badly performancewise. Imagine "updatedb" running whilst you are trying
to get some work done on the same ntfs partition. That will probably be
quite an unpleasant experience I would imagine unless your CPU is very
very fast and you have tons of ram in which case it might be all not too
bad but it probably still won't be very nice...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/
|
