[lkml]   [2002]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[PATCH] Re: Linux v2.5.32

    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* - 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

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:28    [W:0.029 / U:30.972 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site