linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: netdevice problem - 1394 SPB-2 Drives
Date: Thu, 18 Jan 2001 21:47:37 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-97985555106395@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-97984098021600@msgid-missing>

>    How do you guys seeing 1394 disk drives fitting into the hot-plug mix?

Right on top of basic 1394 hotplug support!

The hotplug bus support for PCI and USB is pretty similar ... how well
do these map to the ieee1394 subsystem?

    - Drivers that are already linked into the kernel need to be
      dealing with binding to devices as they're plugged in, and 
      cleanly unbinding as they're unplugged.  PCI and USB seem
      to have reasonable probe() models to borrow from.  USB has
      a thread (khubd) to enumerate new devices, Cardbus has a
      similar one (watcher).

    - MODULE_DEVICE_TABLE support should tie into the driver binding,
      so that it's exported (by *_device_id entries) by modutils so
      that usermode drivers can connect.  "modules.ieee1394map" ?

    - Some invocation of the hotplug helper (/sbin/hotplug by default)
      on device add/remove events, so that the right driver module can
      be loaded (if needed) and configured (ditto).

    - There should be a /proc/bus/... entry for the 1394 busses, which
      lets usermode code at least find out about the devices that are
      present.  (Some info gets passed to /sbin/hotplug; likely not
      everything that every device needs for modprobe/configure.)

Then on top of that core framework, some higher level component ought
to report events appropriate to each driver.  

That's where I'd hope that disks on SCSI, IEEE1394, USB, and so on would
just be able to rely on what, say, the block device system does.  Which
might not involve a call to /sbin/hotplug ... some folk want devfsd to
handle such stuff.   (Me, I'd rather not have daemons around.)

It could be fun to see v4L hotplugging pop up a video window when you
plug in your video camera on IEEE1394 or USB ... ;-)


> The performance is much higher than USB, similar maybe to SCSI,

Faster than current USB, yes.  USB 2.0 hardware is starting to become
available though; 480 Mbps (60 MByte/sec) looks to get interesting.
Yes, the upcoming generation of Firewire will be even faster!


>     but as of
> right now I do not believe that it will be possible to boot from a 1394
> drive, so the file system problems may not be a bad as SCSI.
>
>    We do have the beginnings of drive support there. Folks are starting to
> use 1394 hard disks, as well as CDs and DVDs.

If the Firewire drivers are statically linked, I'd hope that it would be
possible to boot from such a disk drive.  Given boot rom support, that is.

The hotplug boot time issue I know is how devices connected to a hotplug
bus at boot time get configured, when the bus driver is statically linked
and initted.  Right now it's best if you plug them in after hotplug
processing starts in userland; it doesn't look at what's there already.

- Dave




_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2001-01-18 21:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-18 18:03 netdevice problem - 1394 SPB-2 Drives Mark Knecht
2001-01-18 18:20 ` Greg KH
2001-01-18 18:45 ` Mark Knecht
2001-01-18 18:49 ` Greg KH
2001-01-18 21:47 ` David Brownell [this message]
2001-01-18 23:18 ` Oliver Neukum
2001-01-19  0:22 ` Mark Knecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-97985555106395@msgid-missing \
    --to=david-b@pacbell.net \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).