[lkml]   [2002]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: swsusp: don't eat ide disks
    >Note that "should work" does not necessarily mean "does work". For
    >example, in the IDE world, some of the generic packet command stuff is
    >only understood by ide-cd.c, and the generic IDE layer doesn't necessarily
    >understand it even if you have a disk that speaks ATAPI. I think Jens will
    >fix that wart.

    Which is why, IMHO (am I repeating myself ? :) that command has to
    be sent down the queue by the _lowest_ level device driver, that
    is ide-cd, ide-disk, etc...

    This is the way our new device model is designed, at least from
    my understanding of our numerous discussions with Patrick. The
    actual device beeing suspended is the ide-disk (/cd/tape/...),
    it is the target of the suspend request, it gets it from it's
    parent in the bus binding (PCI mostly, non-PCI controllers will
    have to provide something here), and it's the only place of code
    that _knows_ what have to be done.

    "knowing" that an ATA disk wants a SYNC. CACHE and/or STANDBY
    command while an ATAPI CD wants a packet command (with eventually
    a door unlock, and a check unit attention on resume) is not
    the responsibility of the block layer nor even the ATA layer,
    that would be a layering violation. It's the driver for the
    actual device which is the one to know what to do with it's
    device and when to do it (when = bus binding).

    Pavel propose to stop processes & threads to make things easier
    regarding VM, I now tend to think it will indeed make things
    less intricated at first and agree we should keep it for now
    especially with suspend-to-disk, but it's not the responsibility
    of any generic, subsystem or whatever code to actually go suspend
    the IO queues down to the drivers (it may be to stop feeding them,
    which is the point of stopping processes).

    I have the feeling that Alan is trying to avoid any kind of
    responsibility upon drivers ;) Well, unfortunately, I think
    we have no choice here, and that mean yes, we will have
    eventually a few broken drivers that won't play nice with
    suspend-to-disk/ram at first, and yes, users will notice,
    post bug reports, and hopefully this will be fixed over


    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:30    [W:0.024 / U:1.444 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site