automatic drive recognition (was Re: Cannot Recognise External Drive...)

On 14 Oct, Christopher Mc Carthy wrote:
> is there an easy way to automate this process? Is it just a matter of creating
> a script that performs all the commands (unload modules, modprobe the two
> modules, rescan bus, mount drives) I performed above? Are there any
> superfluous steps?

These are questions of broader interest, which is why a rather
lengthy reply might be in order.

The steps required with kernel 2.4 are normally:
1. load ohci1394 and other drivers it depends on when the
   Firewire controller is available
   (some controllers need pcilynx instead of ohci1394)
2. load sbp2 and other drivers it depends on when the Firewire
   drive is available
3. rescan the pseudo SCSI bus (not needed anymore with kernel 2.6)
4. use the drive, e.g. mount partitions

(I don't go into the steps for unplugging the drive here.)

A general remark to steps 1 and 2: Use modprobe, not insmod.

There are several ways to automate all or parts of the procedure.
On the other hand, there are some things that can go wrong, or
quirky hardware might require special driver parameters, so it is
still good to know how to identify problems and how to do the
steps manually.

For example, the sbp2 driver has to login into a device between
steps 2 and 3. Some devices may refuse the login under certain
conditions, which can often be 'fixed' simply by unplugging and
re-plugging the device.

The recommendation of the linux1394.org FAQ to remove the drivers
and load them again (in case something went wrong on first try)
serves essentially these tasks, in my opinion:
- recover from failed device initialization, e.g. when an
  unsuccessful 'coldplug' situation screwed something up.
- let the user control the timing and order of steps, as well as
  optional module load parameters.
- let the user see exactly which syslog messages and /proc
  contents are produced by the several actions.
In other words, it is _not_ required to unload any 1394 drivers
under normal conditions.

Now to answer your first question.

*How To Automate Step 1:*
- For PCI cards and onboard controllers, Linux distributions may
  provide an init script (rc script) that runs "modprobe ohci1394"
  (or "modprobe pcilynx").
  Some distributions load all kernel drivers listed in /etc/modules
  by one of their int scripts. That is, ohci1394 or pcilynx could
  be added to this file.
  Another option is to link the controller's driver statically into
  the kernel. I do not recommend this.
- For CardBus cards, ohci1394 or pcilynx is usually automagically
  loaded by a hotplug script. All recent Linux distributions have
  that hotplug facility in place and ready to use.

*How To Automate Step 2:*
- This is usually automated by another hotplug script which should
  be readily available in all recent Linux distributions.

*How To Automate Step 3:*
- It is possible to do this in another hotplug script, but I cannot
  recommend this. A technically better solution is a kernel patch
  available from linux1394.org that removes a certain barrier in the
  Linux 2.4 scsi system and lets the sbp2 driver perform that step
  itself --- exactly every time it is needed.
- Forget about this step if you have kernel 2.6.

*How To Automate Step 4:*
The question is if autmation is actually desired here. Several
tools for different task can help here:
- devlabel provides static device names for dynamic device files.
  In other words, it fixes the problem that you can't tell which
  on of your numerous hot-pluggable devices is /dev/sda, which is
  /dev/sdb and so forth (if you don't want to obay an absolute
  order of when to connect which drive).
- automount, supermount can mount known partitions on demand.
- hotplug can run commands like mount after 'add' events.
  (There is also a tiny kernel driver called scsimon that
  generates hotplug events on scsi device additions. This would
  come in handy here. But I do not know about this drivers current
  status and its perspective with respect to kernel 2.6.)

Generally spoken, automation of these steps is a task for system
integrators (Linux distributors), as is integration into desktop
environment GUIs.

Currently, most distributions seem not to have any integration/
automation beyond the hotplug facility. One reason is that before
kernel 2.4.19 came out, the IEEE 1394 subsystem was not reliable
enough for widespread deployment. Another reason is that Firewire
storage devices behave a little different from USB storage devices,
which in turn historically behaved different from PCMCIA storage
devices...

I hope that when kernel 2.6 begins to stabilize and desktop-
oriented Linux OS distributions begin to make use of kernel 2.6,
distributors will also start to really integrate hotpluggable
(storage) devices into desktop environments, controlled device
removal inclusive.

By the way, all distributions that are built around kernel 2.4
now and that support SBP-2 devices (that is, virtually all Linux
distributions to be released in the next time) should include the
patch that I mentioned above (a.k.a. Eric B. Andersen's SCSI
hotplug patch). The pros and cons about including that patch into
the "official" kernel have been discussed in linux-scsi a year ago:
http://marc.theaimsgroup.com/?t=103457426200002&r=1&w=2
As far as I understand it, a definitive decision about inclusion
of the patch into the kernel has not been made, especially in
anticipation of the cleaner solution in kernel 2.5. By now, the
patch has proven to be both useful and reliable in many
installations, more so than the add-single-device method from
userspace. This patch uses the same kernel functions like the
add-single-device method, and it looks for me as if these functions
will remain in all future subrevisions of the official kernel 2.4.
(The sbp2 driver in kernel 2.4 would be useless without these
functions anyway.)

-- 
Stefan Richter
-=====-=--== =-=- -===-
http://arcgraph.de/sr/
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
mailing list Linux1394-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-user