linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Viro <viro@math.psu.edu>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"Udo A. Steinberg" <us15@os.inf.tu-dresden.de>,
	linux-kernel@vger.kernel.org
Subject: [PATCH] Re: Linux v2.5.32
Date: Tue, 27 Aug 2002 22:07:00 -0400 (EDT)	[thread overview]
Message-ID: <Pine.GSO.4.21.0208272105510.6084-100000@weyl.math.psu.edu> (raw)
In-Reply-To: <1030487747.7171.4.camel@irongate.swansea.linux.org.uk>



On 27 Aug 2002, Alan Cox wrote:

> On Tue, 2002-08-27 at 21:47, Alexander Viro wrote:
> > IDE merge is b0rken wrt partitioning.  Patchset that is supposed to fix
> > that stuff is on ftp.math.psu.edu/pub/viro/IDE/* - waiting for ACK from
> > Alan.
> 
> Bug me in a few days. To be honest I think its more productive to assume
> you are right because I have too much other stuff to deal with during
> the current RH beta to give rapid answers on 2.5 stuff

OK.  Here's the contents of patchset, patches will go in followups (and
not Cc'd to l-k)

1)	moves stuff from ide_register_subdriver() (associating drive with
high-level driver) to ide-probe.c, so that remaining stuff can be safely
called in parallel with IO on other drives [Andre]

2)	finishes introduction of ->reinit() - Jens had missed MOD_DEC_USE_COUNT
on several exits from ide-cd one and forgot to remove the loop from ide-floppy
ide-tape and ide-scsi ones ;-) (->reinit() is the body of loop in ->init() -
stuff that should be done one drive; in 2.5.32 ide-disk one is OK, ide-cd is
OK modulo minor bugs and in the rest it's a copy of ->init())

3)	puts drives on cyclic lists - per-driver ones for drives that had
been claimed by high-level drivers and ata_unused for unclaimed drives.
We put drives on ata_unused in the very end of ideprobe_init() and then
move them to drivers' lists as they are claimed.

4)	checks for media type, ->driver_req, etc. are moved from the
ide_scan_devices() to ->reinit().  ide_scan_devices() had lost first
two arguments (it will completely disappear later).

5)	duplicate calls of ide_cdrom_init(), idedisk_init(), etc. are
removed from ide_init_builtin_drivers() (they were called both from
there (i.e. from ide_init()) and later as module_init() for high-level
drivers).

6)	loops in ide_cdrom_init()/ide_cdrom_exit(), etc. are pulled into
ide_register_module()/ide_unregister_module() resp.

7)	->owner added to ide_driver_t.  MOD_INC_USE_COUNT/MOD_DEC_USE_COUNT
taken out of ->reinit().  ide_reinit_drive() turned into "call ->reinit()
for all high-level drivers that are registered until somebody claims the
drive" (instead of open-coded variant in 2.5.32; cleaner and works correctly
for modular drivers).

8)	That's the central part of the series:
	ide_reinit_drive() turned into ata_attach().  Said beast takes a
drive, tries to feed it to high-level drivers and drops it on the ata_unused
if nobody claims the sucker.  IOW, that's what ide_register_module() used
to do, but for a single drive.
	ideprobe_init() calls ata_attach() instead of putting on ata_unused.
	ide_register_module() eliminated.  Some of the callers do not need
it anymore, some (ide_replace_subdriver()) actually want ata_attach(drive).
	ide_scan_devices() is gone.  There were two remaining callers - in
ide_register_module() and ide_unregister_module().  The former had been
turned into "put driver on the list, empty ata_unused into temporary list
and call ata_attach() on all drives there".  The latter is "remove driver
from the list, call ->cleanup() and ata_attach() for all drives" (->cleanup()
gives the drive up, ata_attach() gives the remaining drivers a shot for
that drive; if nobody claims it - it's put on ata_unused).

9)	->init() for high-level drivers is never called (other than as
module_init() when they are initialized).  Method removed, instances
cleaned up.

10)	instead of messing with ide_module_t, we put ide_driver_t themselves
on a (cyclic) list - said list being the only use of ide_module_t for
high-level drivers.  ide_register_module()/ide_unregister_module() takes
ide_driver_t now (renamed to ide_register_driver()).  /proc/ide/drivers
switched to use of that cyclic list and uses seq_file instead of old
home-grown code.

11)	2.5 bits:
	add_gendisk()/del_gendisk() moved into ->reinit() and ->cleanup() of
ide-{disk,cd,floppy} - i.e. moments when high-levle driver claims/gives up
a drive.
	register_disk() also shifted into ->reinit().
	consequently, revalidate_drives() is gone (it did messy postponed
rereading of partition tables; not needed anymore).  Ditto for ide_geninit().
	regular 2.5 changes in ->revalidate() and BLKRRPART handling - same
as all other block devices.

The reason why we couldn't do just #11 and be done with that is simple -
high-level drivers were rude and considered drives fair game as soon
as they had been probed.  That is *wrong* - we might be still doing
"unsafe" work with the interface (or related interfaces) and any regular
IO at that point is a Bad Thing(tm).  As the result we had to use very
odd logics in partition handling, registering, etc.

New variant lets the probing code to decide when it's safe to put the drives
in circulation - no high-level driver will see a drive until ata_attach()
is called.  Which puts the knowledge of ordering between configuring and
normal IO into the probing code where it belongs.  High-level drivers
don't have to think about it anymore - as soon as drive is given to them
it's safe to do IO on it.

Ordering issues between configuring different interfaces, etc. still
remain where they were - that's a separate story and it belongs to the
low-level driver cleanups.  Moreover, place where we are calling
ata_attach() is very conservative - we do _all_ configuring of interfaces
and then call ata_attach() on everything we'd found.  Eventually, low-level
drivers should be able to do "configure our group of interfaces, then call
ata_attach() on their drives", but that, again, is a separate story -
one I'd happily leave to the folks who do cleanup of low-level drivers.
All ordering issues with high-level drivers are reduced to one rule:
don't call ata_attach() on a drive before it's safe to get IO on it.

The patchset doesn't fix all problems with the driver - code that
went into 2.5 had been derived from 2.4.19 and several megabytes of
fixes went into 2.4.20-ac since then.  However, these fixes are mostly
in low-level drivers, so they shouldn't cause problems with porting and
I'll happily leave that fun to Jens when he comes back.


  reply	other threads:[~2002-08-28  2:02 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-27 19:47 Linux v2.5.32 Linus Torvalds
2002-08-27 20:22 ` Stephane Wirtel
2002-08-27 20:36   ` Thunder from the hill
2002-08-27 20:48     ` Stephane Wirtel
2002-08-27 20:54   ` Gabor Z. Papp
2002-08-28  6:18     ` Jan-Benedict Glaw
2002-08-28  7:41       ` Edward Coffey
2002-08-28  8:35       ` Russell King
2002-08-27 20:43 ` Udo A. Steinberg
2002-08-27 20:47   ` Andre Hedrick
2002-08-27 20:47   ` Alexander Viro
2002-08-27 22:35     ` Alan Cox
2002-08-28  2:07       ` Alexander Viro [this message]
2002-08-28  1:21     ` Arador
2002-08-28  2:17       ` Alexander Viro
2002-08-27 22:28 ` Chris Funderburg (at home)
2002-08-28  7:31 ` Linux v2.5.32 - some menuconfig oddities Helge Hafting
2002-08-28  7:43   ` Gabor Kerenyi
2002-08-28  8:14 ` Linux v2.5.32 Edward Coffey
2002-08-28  8:17   ` Writing files to remote storage Kevin Liao
2002-08-28 14:18     ` Alan Cox
2002-08-28 13:00 ` 2.5.32 doesn't beep? Mikael Pettersson
2002-08-28 13:05   ` Vojtech Pavlik
2002-08-28 13:12     ` Mikael Pettersson
2002-08-28 13:58     ` Gerhard Mack
2002-08-28 14:33       ` Jos Hulzink
2002-08-28 14:49       ` Vojtech Pavlik
2002-08-28 20:04     ` Mikael Pettersson
2002-08-28 20:30       ` Vojtech Pavlik
2002-08-29  8:41         ` Gerd Knorr
2002-08-28 17:21 ` Linux v2.5.32 Adrian Bunk
2002-08-31 16:54 ` Linux v2.5.32 (Config options to have a working keyboard) Axel Siebenwirth

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=Pine.GSO.4.21.0208272105510.6084-100000@weyl.math.psu.edu \
    --to=viro@math.psu.edu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    --cc=us15@os.inf.tu-dresden.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).