All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Lougher <phillip@lougher.demon.co.uk>
To: Ferenc Wagner <wferi@niif.hu>
Cc: Phillip Lougher <phillip.lougher@gmail.com>,
	linux-fsdevel@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org
Subject: Re: RFC: direct MTD support for SquashFS
Date: Wed, 24 Mar 2010 05:23:07 +0000	[thread overview]
Message-ID: <4BA9A1BB.4000105@lougher.demon.co.uk> (raw)
In-Reply-To: <8739zqpxxw.fsf@tac.ki.iif.hu>

Ferenc Wagner wrote:
> Now with the patch series, sorry.
> 
> Ferenc Wagner <wferi@niif.hu> writes:
> 
>> I've got one more patch, which I forgot to export, to pull out the
>> common logic from the backend init functions back into squashfs_read_data().
>> With the bdev backend, that entails reading the first block twice in a
>> row most of the time.  This again could be worked around by extending
>> the backend interface, but I'm not sure if it's worth it.
> 
> Here it is.  I also corrected the name of SQUASHFS_METADATA_SIZE, so it
> may as well compile now.
> 


Thanks for your patches.

First things first.  Patch sending etiquette :-)

1. Please don't send separate git commits in one big email,  it makes them
    hard to cross-reference (I lost count of the times I had to repeatedly
    scroll though the email to check an earlier commit).

2. Please don't send a patch series consisting of your development process.
    Reviewing takes effort, having reviewed one commit to find it reworked
    in a second commit, and then reworked again, as the code evolves from
    a -> b -> c-> d is irritating, it makes the final solution harder to
    evaluate (because you have to keep all the changes in your head), and
    wastes my time.

3. Incremental patches are valid if they break up a patch series into easily
    digestible changes which can be separately understood, but not if they're
    just reworking your code as development progresses...

OK, now for the specific comments.

Frameworks are supposed to make the code cleaner, more understandable,
and generally better.  Unfortunately, I see no evidence of that in your
patch.  Sorry to be blunt, but there it is.

The backend has seven functions!

+       void	*(*init)(struct squashfs_sb_info *, u64, size_t);
+	void	(*free)(struct squashfs_sb_info *);
+	ssize_t	(*read)(struct squashfs_sb_info *, void **, size_t);
+	int	(*probe)(struct file_system_type *, int, const char *,
+				void*, struct vfsmount *);
+	void	(*kill)(struct squashfs_sb_info *);
+	loff_t  (*size)(const struct super_block *);
+	const char *(*devname)(const struct super_block *, char *);

We move from a single read() function to requiring seven functions to do
the same work, just to add mtd support...

Reading the superblock changes into a 6 function deep nightmare
squashfs_find_backend -> probe -> get_sb_dev -> fill_bdev_super ->
squashfs_fill_super -> add_backend

I find the current 3 function deep situation forced by VFS already a mess,
squashfs_get_sb -> get_sb_bdev -> squashfs_fill_super

Reading a block now takes 3 function calls, init, read, and free.  Plus in
your last commit you make the huge mistake of preferring code elegance over
performance, and resort to calling init, read, and free *twice*, the first
just to read *two* bytes (yes, 2 bytes).  Why do you think the code was
coded that way in the first place?  A fit of absent mindedness perhaps?  No, for
performance reasons.

Secondly you make the classic mistake of concentrating on what you want to do
(add MTD), and not giving a damn about anything else.  You've totally broken all
the read optimisations in zlib decompression for block devices.  Buffer_heads
are deliberately passed directly to the zlib decompressor to allow it to
optimise performance (pass the buffer_head directly to zlib etc.).  Buffer_heads
are exposed to the decompressors without crappy go-between wrappers deliberately.

Unfortunately there are lots of other instances where you've eliminated carefully
optimised code.

That's another of my major issues, the patch seems hugely gratuitous, it
touches a huge amount of files/code it shouldn't do, much of this slicing up
optimisied heavily tested and fragile code into other files/functions hither
and thither.  Unfortunately much of this code took a long time to get
right, and suffered numerous unanticipated edge conditions/fsfuzzer
triggered bugs.  I only touch this code with caution and nothing like to
the extent you've subjected it to.

In short this doesn't pass my quality threshold or the make the minimum changes
necessary threshold.  I wouldn't consider asking Linus to merge this.

BTW as a comparison, I have added MTD support to Squashfs twice in the
past, *with* bad block support.  The latest has a diff patch of ~500 lines,
with far less complexity and code changes necessary.

BTW2 as evidenced by your FIXME comments against my code in your patch,
you really have to get over the notion that if you don't understand it,
the code must be wrong.

Cheers

Phillip


WARNING: multiple messages have this Message-ID (diff)
From: Phillip Lougher <phillip@lougher.demon.co.uk>
To: Ferenc Wagner <wferi@niif.hu>
Cc: linux-fsdevel@vger.kernel.org,
	Phillip Lougher <phillip.lougher@gmail.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-embedded@vger.kernel.org
Subject: Re: RFC: direct MTD support for SquashFS
Date: Wed, 24 Mar 2010 05:23:07 +0000	[thread overview]
Message-ID: <4BA9A1BB.4000105@lougher.demon.co.uk> (raw)
In-Reply-To: <8739zqpxxw.fsf@tac.ki.iif.hu>

Ferenc Wagner wrote:
> Now with the patch series, sorry.
> 
> Ferenc Wagner <wferi@niif.hu> writes:
> 
>> I've got one more patch, which I forgot to export, to pull out the
>> common logic from the backend init functions back into squashfs_read_data().
>> With the bdev backend, that entails reading the first block twice in a
>> row most of the time.  This again could be worked around by extending
>> the backend interface, but I'm not sure if it's worth it.
> 
> Here it is.  I also corrected the name of SQUASHFS_METADATA_SIZE, so it
> may as well compile now.
> 


Thanks for your patches.

First things first.  Patch sending etiquette :-)

1. Please don't send separate git commits in one big email,  it makes them
    hard to cross-reference (I lost count of the times I had to repeatedly
    scroll though the email to check an earlier commit).

2. Please don't send a patch series consisting of your development process.
    Reviewing takes effort, having reviewed one commit to find it reworked
    in a second commit, and then reworked again, as the code evolves from
    a -> b -> c-> d is irritating, it makes the final solution harder to
    evaluate (because you have to keep all the changes in your head), and
    wastes my time.

3. Incremental patches are valid if they break up a patch series into easily
    digestible changes which can be separately understood, but not if they're
    just reworking your code as development progresses...

OK, now for the specific comments.

Frameworks are supposed to make the code cleaner, more understandable,
and generally better.  Unfortunately, I see no evidence of that in your
patch.  Sorry to be blunt, but there it is.

The backend has seven functions!

+       void	*(*init)(struct squashfs_sb_info *, u64, size_t);
+	void	(*free)(struct squashfs_sb_info *);
+	ssize_t	(*read)(struct squashfs_sb_info *, void **, size_t);
+	int	(*probe)(struct file_system_type *, int, const char *,
+				void*, struct vfsmount *);
+	void	(*kill)(struct squashfs_sb_info *);
+	loff_t  (*size)(const struct super_block *);
+	const char *(*devname)(const struct super_block *, char *);

We move from a single read() function to requiring seven functions to do
the same work, just to add mtd support...

Reading the superblock changes into a 6 function deep nightmare
squashfs_find_backend -> probe -> get_sb_dev -> fill_bdev_super ->
squashfs_fill_super -> add_backend

I find the current 3 function deep situation forced by VFS already a mess,
squashfs_get_sb -> get_sb_bdev -> squashfs_fill_super

Reading a block now takes 3 function calls, init, read, and free.  Plus in
your last commit you make the huge mistake of preferring code elegance over
performance, and resort to calling init, read, and free *twice*, the first
just to read *two* bytes (yes, 2 bytes).  Why do you think the code was
coded that way in the first place?  A fit of absent mindedness perhaps?  No, for
performance reasons.

Secondly you make the classic mistake of concentrating on what you want to do
(add MTD), and not giving a damn about anything else.  You've totally broken all
the read optimisations in zlib decompression for block devices.  Buffer_heads
are deliberately passed directly to the zlib decompressor to allow it to
optimise performance (pass the buffer_head directly to zlib etc.).  Buffer_heads
are exposed to the decompressors without crappy go-between wrappers deliberately.

Unfortunately there are lots of other instances where you've eliminated carefully
optimised code.

That's another of my major issues, the patch seems hugely gratuitous, it
touches a huge amount of files/code it shouldn't do, much of this slicing up
optimisied heavily tested and fragile code into other files/functions hither
and thither.  Unfortunately much of this code took a long time to get
right, and suffered numerous unanticipated edge conditions/fsfuzzer
triggered bugs.  I only touch this code with caution and nothing like to
the extent you've subjected it to.

In short this doesn't pass my quality threshold or the make the minimum changes
necessary threshold.  I wouldn't consider asking Linus to merge this.

BTW as a comparison, I have added MTD support to Squashfs twice in the
past, *with* bad block support.  The latest has a diff patch of ~500 lines,
with far less complexity and code changes necessary.

BTW2 as evidenced by your FIXME comments against my code in your patch,
you really have to get over the notion that if you don't understand it,
the code must be wrong.

Cheers

Phillip

  reply	other threads:[~2010-03-24  5:22 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-16 13:38 RFC: direct MTD support for SquashFS Ferenc Wagner
2010-03-16 13:38 ` Ferenc Wagner
2010-03-16 14:26 ` Peter Korsgaard
2010-03-16 14:26   ` Peter Korsgaard
2010-03-16 19:18   ` Vitaly Wool
2010-03-16 19:18     ` Vitaly Wool
2010-03-16 19:18     ` Vitaly Wool
2010-03-18 16:38   ` Ferenc Wagner
2010-03-18 16:38     ` Ferenc Wagner
2010-03-18 16:38     ` Ferenc Wagner
2010-03-18 16:38     ` Ferenc Wagner
2010-03-18 21:40     ` Phillip Lougher
2010-03-18 21:40       ` Phillip Lougher
2010-03-18 22:52       ` Ferenc Wagner
2010-03-19  1:05       ` Ferenc Wagner
2010-03-19  7:30         ` Phillip Lougher
2010-03-19 14:12           ` Ferenc Wagner
2010-03-23 11:34       ` Ferenc Wagner
2010-03-23 11:34         ` Ferenc Wagner
2010-03-23 20:45       ` Ferenc Wagner
2010-03-23 20:47       ` Ferenc Wagner
2010-03-23 20:47         ` Ferenc Wagner
2010-03-24  5:23         ` Phillip Lougher [this message]
2010-03-24  5:23           ` Phillip Lougher
2010-03-24  6:35           ` Peter Korsgaard
2010-03-24  6:35             ` Peter Korsgaard
2010-03-24 11:28             ` Ferenc Wagner
2010-03-24 11:35               ` Peter Korsgaard
2010-03-24 13:48           ` Ferenc Wagner
2010-03-24 13:48             ` Ferenc Wagner
2010-03-30 13:32             ` [PATCH 0/3] " Ferenc Wagner
2010-03-30 13:32             ` Ferenc Wagner
2010-03-30 13:32               ` Ferenc Wagner
2010-03-31  6:35               ` Marco Stornelli
2010-03-31  6:35                 ` Marco Stornelli
2010-03-30 13:32             ` [PATCH 1/3] squashfs: parametrize decompressors on buffer_head operations Ferenc Wagner
2010-03-30 13:32             ` Ferenc Wagner
2010-03-30 13:32               ` Ferenc Wagner
2010-03-30 13:32             ` [PATCH 2/3] squashfs: gather everything block device specific into block.c Ferenc Wagner
2010-03-30 13:32               ` Ferenc Wagner
2010-03-30 16:50               ` Ferenc Wagner
2010-03-30 16:50                 ` Ferenc Wagner
2010-03-30 13:32             ` Ferenc Wagner
2010-03-30 13:32             ` [PATCH 3/3] squashfs: add MTD backend Ferenc Wagner
2010-03-30 13:32               ` Ferenc Wagner
2010-03-30 13:32               ` Ferenc Wagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BA9A1BB.4000105@lougher.demon.co.uk \
    --to=phillip@lougher.demon.co.uk \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=phillip.lougher@gmail.com \
    --cc=wferi@niif.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.