All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.cz>
To: Martin Dalecki <dalecki@evision-ventures.com>
Cc: Pavel Machek <pavel@suse.cz>, Jens Axboe <axboe@suse.de>,
	kernel list <linux-kernel@vger.kernel.org>,
	torvalds@transmeta.com
Subject: Re: IDE cleanup for 2.5.4-pre3
Date: Fri, 15 Feb 2002 13:20:30 +0100	[thread overview]
Message-ID: <20020215132030.A5096@suse.cz> (raw)
In-Reply-To: <20020208231346.GA1209@elf.ucw.cz> <20020211094230.E1957@suse.de> <20020211134443.GC20854@atrey.karlin.mff.cuni.cz> <20020211181013.K729@suse.de> <20020213225326.A10409@suse.cz> <20020214094046.B37@toy.ucw.cz> <3C6CC19C.3040608@evision-ventures.com>
In-Reply-To: <3C6CC19C.3040608@evision-ventures.com>; from dalecki@evision-ventures.com on Fri, Feb 15, 2002 at 09:06:52AM +0100

On Fri, Feb 15, 2002 at 09:06:52AM +0100, Martin Dalecki wrote:

> It seems bigger as it is at first glance, however if you start to read 
> it at ide.h, the rest should
> be, well,  obivous...
> 
> Anyway please let me explain some bits: the end_request() function familiy
> (not the global one, but the IDE specific ones), did bear a permuted 
> parameter ordering.
> After fixing this it turned out that at all places the huk parameter 
> wasn't the
> hwgroup, but just the drive in question itself. I have changed this to
> be more sane, which allowed to remove many unneccessary code duplication,
> or rather obfuscation, in between the __ide_end_request() and 
> ide_end_request() functions.
> This simplification is actually the "spreading" part of the game.

Yes, this is very nice.

> In a next step rather as much as possible should be moved from beeing 
> hooked on
> the disk to be hooked on the request itself - which seems more natural 
> and would make
> the overall code treamlined with other similar driver mid-layers (SCSI 
> comes to mind).
> 
> In a third step one should take care to remove the excessive usage of 
> single linked
> lists inside the ide driver, where possible and make it be handled the 
> same way like
> in SCSI and elsewere in the kernel... The overall perspecive is to make 
> as much as possible
> common between all block device handlers no matter whatever SCSI/IDE/I2O 
> or FW or iSCSI.
> 
> I have taken as much care as possible to not break anything. In esp. it 
> all has ben tested
> in life on my home system with L120 (aka ide-floppy), an CD-RW, and two 
> disks.
> The only blind fly is ide-tape... but the patch can be easly verifyed 
> for correctness by reading
> through it.
> 
> PS. I have killed deliberately some one-shoot functions as well, since 
> those where only
> obscuring the overall code structure even more....

And these steps also sound very good to me.

-- 
Vojtech Pavlik
SuSE Labs

  reply	other threads:[~2002-02-15 12:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-08 23:13 IDE cleanup for 2.5.4-pre3 Pavel Machek
2002-02-11  8:42 ` Jens Axboe
2002-02-11 13:44   ` Pavel Machek
2002-02-11 17:10     ` Jens Axboe
2002-02-13 21:53       ` Vojtech Pavlik
2002-02-14  9:40         ` Pavel Machek
2002-02-15  8:06           ` Martin Dalecki
2002-02-15 12:20             ` Vojtech Pavlik [this message]
2002-02-15 12:24               ` Martin Dalecki
2002-02-15 12:37                 ` Vojtech Pavlik
2002-02-15 20:45             ` Pavel Machek
2002-02-15 21:24               ` Vojtech Pavlik
2002-02-16  9:39                 ` Martin Dalecki
2002-02-16  9:38               ` Martin Dalecki
2002-02-16 18:22                 ` Andre Hedrick
2002-02-16 21:51                   ` Martin Dalecki
     [not found]               ` <Pine.LNX.4.10.10202151719420.10501-100000@master.linux-ide.org>
2002-02-16 22:46                 ` Pavel Machek
2002-02-17 13:52             ` Pavel Machek
2002-02-19 10:13               ` Martin Dalecki

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=20020215132030.A5096@suse.cz \
    --to=vojtech@suse.cz \
    --cc=axboe@suse.de \
    --cc=dalecki@evision-ventures.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=torvalds@transmeta.com \
    /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.