On Fri, 13 Jul 2007, Eric W. Biederman wrote:
> > I doubt that re-probing devices will work. The probe routine won't
> > expect there to be any registered children, so it will try to
> > re-register them.
>
> So really unregister the children. All we really need to do is disassociate
> the drivers from the devices (to reuse the existing code) we don't
> need to rescan for the devices. The associating the device drivers
> with devices takes human measurable amount of time. The only thing
> that takes time is waiting on hardware. Maybe things will suck
> and associating the drivers with the device tree with take a whole
> second on a bad day, I don't think that is enough time to add
> complicated new code paths for the drivers to maintain.
This would be even worse!
Suppose you unbind (or unregister, either way) a disk driver. It's
unbind method will unregister the gendisk structure, thereby deleting
all the partitions and block devices associated with the disk. This
will leave any and all memory mappings dangling in the breeze. When
the kernel resumes from hibernation, nothing will work.
> > On the other hand, post_restore methods could be written to expect
> > something like this.
>
> Please Please Plaese do not start with the existing software suspend
> to disk code and thinking.
Ha! Gotcha. You evidently haven't been reading the linux-pm mailing
list for the last few months. :-)
1. post_restore isn't "existing software suspend to disk code"
(you're supposed to call it "hibernation" now, BTW).
2. post_restore isn't new. It has already been proposed and
generally accepted. It is part of the movement to untangle
and separate the suspend and hibernate code paths.
3. post_restore hasn't been implemented yet. It's barely past
the proposal stage.
4. Maybe _you_ like to discuss complicated issues such as this
one without thinking, but the rest of us prefer a little
cerebration.
> We are not implementing suspend to ram
> here or anything like it.
One of the topics in this discussion has been "suspend-to-both", which
includes suspend-to-RAM.
But anyway, so what? I wasn't talking about suspend-to-RAM; I was
talking about hibernation.
> We already have proven code paths that
> know how to quiesce hardware. We already have proven code paths
> that know how to take quite hardware and make it run. Please let's
> just use them. At least until we can see that they are insufficient
> to the task.
Was this request directed at me or at Rafael? It's hard to tell.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
