Linux-kernel mailing list archive 1999-23,: Re: FireWire subsystem in development

# Re: FireWire subsystem in development

Bryn Paul Arnold Jones (bpaj@gytha.demon.co.uk)
Mon, 7 Jun 1999 13:27:54 +0100 (GMT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ingo Molnar: "Re: 2.2.9-ac2 locks solid"
- Previous message: Maciej W. Rozycki: "[patch] 2.2.* and 2.3.*: problems with sd_detach"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 7 Jun 1999, Srdjan Sobajic wrote:

> Yesterday, Bryn Jones randomly landed on the keyboard to produce:
>
> > It seems to me that FireWire and USB both have the same configuration
> > issues to resolve, so sharing the higher level configuration between them
> > may be a cunning plan ...
> >
>
> I'm not sure what you meant by configuration issues,

Well I was thinking along the lines of "device x appeared",
"device y disapeared". Just general hot plug things.

> but a problem I see with that is that if we start supporting the 1394
> hard drives then if someone changes the bus configuration the device
> names (if they are all hard-coded as with SCSI/IDE) would possibly
> change. (which doesn't seem like a good thing.)

So don't hard code them. We need the device drivers to support hot
plugging and unplugging.

> I am not totally clear
> as to whether in the USB system this is also a problem-- ie. if I
> change my bus configuration, will the device I have assigned to, say,
> my mouse change also? (For example, say the device attached directly
> to the Root Hub is usb0, which is initially my mouse, but then I
> attach an external hub to the Root Hub, and the mouse to my external
> hub, so that the external hub becomes usb0, and the mouse usb1. How
> will this kind of issue get resolved with USB?)
>

So don't assign names like usb0 (or just make it clear that they are
going to change if you move things arround on the bus). The real way to
support this is like this:

Mouse pluged in and working
<pull mouse>
driver informed mouse at X unpluged, driver cleans up internal resorces.
<plug in hub>
<plug mouse un hub>
driver informed a mouse pluged in at Y, mouse starts working again.

For mice this only gets tricky with two or more, it's disks and other
things where we can have outstanding write requests on that it's tricky
with just one. We really wont to hang on to some sort of serial number
and allow the writes to continue after it comes back.

> I agree that these issues (and others probably) should be worked out
> in conjunction with the USB development...
>

That's all I was really suggesting ;)

Bryn
- --
Or words to that effect ...
PGP pubkeys from http://www.gytha.demon.co.uk/pubkey.asc.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Comment: Silly comment here ...
Charset: noconv

iQA/AwUBN1u6zd94IUtvfSqaEQIJygCgrVGJmpoJb/C32wPJNLocUnF4wwEAoPuG
JDhlUmyPldxekr/tWMLdri2w
=yJ+r
-----END PGP SIGNATURE-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Ingo Molnar: "Re: 2.2.9-ac2 locks solid"
- Previous message: Maciej W. Rozycki: "[patch] 2.2.* and 2.3.*: problems with sd_detach"