Re: [linux-usb-devel] Re: A different look at block device hotswap in the Linux kernel

Re: [linux-usb-devel] Re: A different look at block device hotswap in the Linux kernel

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

On Thu, Jan 23, 2003 at 05:54:57PM -0700, Steven Dake wrote:
> >I want:
> >LLDD to SCSI: device is gone
> >SCSI to LLDD: Ok. I'll handle from here on.
> >LLDD: OK. I am gone. And won't have any contact until the next device is
> >plugged in.
> >  
> >
> The downside of this approach is that the LLDD must now be able to 
> detect insertions and removals when it may not be able to do so.  If it 
> is able to do so, then fine, it can tell upper layers about it, but the 
> actual control of removal of a device should occur higher up to fix 
> several problems with the approach of having the LLDD manage the hotswap 
> state of the device.

Huh?

Aren't we talking about a hotplug scenario?  How can you talk about the
'LLDD must now be able to detect... when it may not be able to do so.'?

Oh... I see.  We keep talking about devices.  I'm trying to hotswap an
entire host, which is mapped to a single USB device.

But the theory is the same, really.

In the end, you can only hotswap something that is hotswapable.  That means
that the driver has to support the hotswap system, whatever it is.

If you can't support hotswap detection, then this entire scenario is
reduced to 'what happens if I blow a FET on my HD', because it's the exact
same thing.  Recovering from fatal error is a separate discussion.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

A:  The most ironic oxymoron wins ...
DP: "Microsoft Works"
A:  Uh, okay, you win.
					-- A.J. & Dust Puppy
User Friendly, 1/18/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

RE: A different look at block device hotswap in the Linux kernel

[Cress, Andrew R]

My $.02:

The comparing of a saved device list snapshot with the current device should
be the responsibility of a user-space daemon, provided that the kernel
exposes enough information  to uniquely identify the devices (like serial
numbers, or some other UID if no ser num exists).  

The kernel would assume that the device is new (not the same) unless told so
by a daemon that is watching.  

Andy

-----Original Message-----
From: Matthew Jacob [mailto:mjacob@feral.com] 
Sent: Friday, January 24, 2003 10:26 AM
To: David Brownell
Cc: Oliver Neukum; Steven Dake; Luben Tuikov; Alan Stern; Matthew Dharm;
Mike Anderson; Greg KH; linux-usb-devel@lists.sourceforge.net; Linux SCSI
list
Subject: Re: A different look at block device hotswap in the Linux kernel



> >>...
> >
> >
> > Could this time limit be fixed (or parameterized) known to all LLDDs?
> > This would allow one to try and avoid flooding SCSI with detach/reattach
> > events for the 'same' device.
>
> And what exactly is the "same" device?  And who's keeping history
> about devices that have previously been attached?  And, says the guy
> who's full of questions, didn't Linus want to get rid of such history?

Hrmm. That's a damned good point. I was going to say things like "the
FC HBA driver knows that device XYX left the fabric and now has
returned", but if XYZ left the fabric, why am I keeping track of it
still? Once gone, it's gone. I had convinced myself that if an FC device
(re)appears, it's not up to the HBA to say it's the same (the content
may have been changed even if the container tag is the same).

Hrm.


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: A different look at block device hotswap in the Linux kernel

[Bryan Henderson]

>The comparing of a saved device list snapshot with the current device
should
>be the responsibility of

>From a usability standpoint, I don't think any such comparing should be
done by anyone.  When I unplug a device and then plug it in again, I want a
total reset.  I'm willing to take my lumps if I unplug something that isn't
in a state to be safely unplugged.

It's like when I pull the power plug because my system is totally hosed and
I want to start over.  I know I can cause damage by doing that, but I would
be upset if the new system booted back to the broken state it was in when I
unplugged it.

RE: A different look at block device hotswap in the Linux kernel

[Matthew Jacob]

>
> It's like when I pull the power plug because my system is totally hosed and
> I want to start over.  I know I can cause damage by doing that, but I would
> be upset if the new system booted back to the broken state it was in when I
> unplugged it.

I had this conversation with doug offlist- this is a policy choice. You
may want your device to reattach as totally new. You may, on the other
hand, want your device to resume where you left off. I can see valid
reasons for wanting either behaviour (but it can't/shouldn't be deduced
by the OS).

Re: [linux-usb-devel] RE: A different look at block device hotswap in the Linux kernel

[Andries Brouwer]

On Fri, Jan 24, 2003 at 10:09:32AM -0800, Matthew Jacob wrote:

> > It's like when I pull the power plug because my system is totally hosed and
> > I want to start over.  I know I can cause damage by doing that, but I would
> > be upset if the new system booted back to the broken state it was in when I
> > unplugged it.
> 
> You may want your device to reattach as totally new. You may, on the other
> hand, want your device to resume where you left off. I can see valid
> reasons for wanting either behaviour (but it can't/shouldn't be deduced
> by the OS).

The kernel does not remember this device once it is gone.
If user space thinks it recognizes it, it must have a means to
tell the kernel what it should do. What kind of info?
The only thing that I can think of right now is the name.
User space may tell the kernel under what name a device should
be accessible.

[Today user space can tell the kernel the numbering of the partitions.]

More generally, the question of what "same device" means
depends on the application. Is /dev/fd0 the same device
as /dev/fd0 also when the floppy is different?
Yes, the name is the same. The contents not.

In all cases user space does not tell the kernel "it is the same as ..."
since the kernel does not remember anyway. User space just instructs
the kernel to do certain definite things.

Andries