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

Thanks for all the info. Looking forward to the 2.6 kernel!

>-----Original Message-----
>From: Stefan Richter [mailto:stefanr@s5r6.in-berlin.de]
>Sent: 14 October 2003 21:05
>To: linux1394-user@lists.sourceforge.net
>Cc: cmccarthy@gltrade.com
>Subject: 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
Received on Thu Oct 16 10:21:01 2003