From owner-freebsd-doc@FreeBSD.ORG Sat Sep 27 15:20:14 2003 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CCFD16A4EE for ; Sat, 27 Sep 2003 15:20:14 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BCA844003 for ; Sat, 27 Sep 2003 15:20:12 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h8RMKCFY025660 for ; Sat, 27 Sep 2003 15:20:12 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h8RMKCl5025659; Sat, 27 Sep 2003 15:20:12 -0700 (PDT) (envelope-from gnats) Resent-Date: Sat, 27 Sep 2003 15:20:12 -0700 (PDT) Resent-Message-Id: <200309272220.h8RMKCl5025659@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Dan Pelleg Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 963EB16A4B3 for ; Sat, 27 Sep 2003 15:19:02 -0700 (PDT) Received: from gw.pelleg.org (gw.pelleg.org [205.201.13.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E3144402B for ; Sat, 27 Sep 2003 15:18:54 -0700 (PDT) (envelope-from dpelleg@cs.cmu.edu) Received: from lank.here (lank.wburn [192.168.3.41]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "gw.pelleg.org", Issuer "Dan Pelleg" (verified OK)) by gw.pelleg.org (Postfix) with ESMTP id 8C0D95A3A for ; Sat, 27 Sep 2003 18:18:52 -0400 (EDT) Received: by lank.here (Postfix, from userid 7675) id B853AB4A; Sat, 27 Sep 2003 18:18:49 -0400 (EDT) Message-Id: <20030927221849.B853AB4A@lank.here> Date: Sat, 27 Sep 2003 18:18:49 -0400 (EDT) From: Dan Pelleg To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/57298: Using compact flash cards X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dan Pelleg List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2003 22:20:14 -0000 >Number: 57298 >Category: docs >Synopsis: Using compact flash cards >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Sep 27 15:20:11 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Dan Pelleg >Release: FreeBSD 4.9-PRERELEASE i386 >Organization: >Environment: System: FreeBSD l 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #5: Tue Sep 16 20:15:41 EDT 2003 d@p i386 >Description: How to use removable media cards under FreeBSD. This is a lightly edited version of a Daemon News article I wrote (published in the May 2003 issue). Submitted as an addition to the multimedia chapter of the handbook, although I'm not 100% sure there is no better place for it. >How-To-Repeat: >Fix: --- en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml.orig Fri Sep 26 20:33:58 2003 +++ en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml Sat Sep 27 18:03:44 2003 @@ -1409,4 +1409,382 @@ + + + + + + Dan + Pelleg + Contributed by + + + + + + + Using Removable Memory Devices + + Many consumer electronic devices now support removable memory + cards. They provide a fast and easy way to transfer information to + and from a PC. Here we explore the ways to use those cards under + &os;. Our goal is to minimize the administrative overhead for the + user - eliminating the need for root access or + manual mounts. For simple tasks such as uploading files from the + card we can even come up with a completely hands-off operation - + the user doesn't have to do anything but insert the card in, wait + for a while, and then pop it back out. + + + Introduction + + The discussion refers to Compact Flash (CF) cards. However, + most of the instructions also apply, with slight modifications, + to other types of 'flash' media (SmartMedia, MMC, MemoryStick and + all their variations), as well as cameras, MP3 players, and other + devices supported by the &man.umass.4 device driver. + + Compact Flash cards typically interface to a PC in one of + two ways: an external USB card-reader, or through the PC-CARD + (also known as "PCMCIA") slot. For the PC-CARD case, a cheap + adapter allows insertion of CF media to a standard PC-CARD slot. + Some laptops have a special CF slot, eliminating the need for an + adapter. The way &os; accesses your device will vary, depending + on the reader type. PC-CARD readers will show up as ATA disks, + while USB readers will show up as SCSI disks. + + Once the "disks" show up, we can mount the filesystem on + them, and then manipulate it in the standard way - copying and + deleting files. We explore two approaches to doing this. The + first involves a script that handles the specific task of + uploading all of the new files from the CF card to the PC, + requiring no user intervention. The second is more general, and + uses the automounter to mount the filesystem as soon as it is + accessed, letting the user directly manipulate it. + + To make things easy to follow, we first detail the steps + for USB readers, and then explain how the same procedures work + for PC-CARD devices. + + + + USB-Based Compact-Flash Readers + + Requirements + + Support for USB readers requires the &man.umass.4 + driver. As the manpage tells you, you will need the + following options in your kernel config: + + device usb +device ohci (OR device uhci) +device umass +device scbus +device da +device pass + + Note that the GENERIC kernel that comes with 4.8 + already includes them all. After recompiling your kernel + (or not, if you're using GENERIC), you should be able to + plug the reader into the USB slot and have it show up. + Usually, the media has to be already in the reader before + you plug in the USB connector. So, if things don't work + for you, unplug the reader from the USB slot, stick the + memory card in, and plug it into USB again. + + The message log will tell you the device name for + the CF card. umass-attached + devices will show up like this: + + da0 at umass-sim0 bus 0 target 0 lun 0 + + indicating that the device name is + da0. Note that if you already + have SCSI devices in the system, this might interfere + with whatever you have in &man.fstab.5;. To avoid nasty + surprises, you should wire down all of your other SCSI + devices so their numbering doesn't change. + + If the reader is supported, at this point you + should be able to mount the device. If you are using a + card from a standard camera or music player, the + following command, typed as root, will mount it under + /mnt: + + &prompt.root; mount -t msdos /dev/da0s1 /mnt + + In theory, at this point you can become + root whenever you want and + mount the device. However the goal + here is to try and avoid this step. The following + section and describe two + different strategies that accomplish this. + + + + Using an upload script + + Most often, the computer is used as a backing store + for the small-capacity CF card. You take a few photos on + your digital camera, and want to make sure you have + copied them to a "real" disk so you can later process + them. We use a script that uploads all the new photos + from a CF card into the PC's disk-drive. Once installed, + it will go into action as soon as the CF media is + attached. It will mount the + filesystem, copy the new files over, and then unmount it. + The only thing the user has to do is insert the media and + later pull it out. + + You can download a copy of the + script. We assume you have it installed at + /usr/local/sbin/copy-flash and + marked it as executable. + + Next, you will need the USB daemon, &man.usbd.8;. + Add this line to /etc/rc.conf, + unless it's already there: + + usbd_enable="YES" + + To make the script run when a USB reader is + attached, add an entry to + /etc/usbd.conf. It will look like + this: + + device "CF card" +devname "umass[0-9]+" +attach "/usr/local/sbin/copy-flash da0 /tmp/cf CFOWNER" + + where da0 should be + substituted by whatever device you see in the message + log. Before you use this hook, replace the string + CFOWNER. It should be a user name, and the copied files + will be owned by that user. This is normally you or the + primary user of the machine. Also, create the target + directory into which the files will be copied. In this + example it is /tmp/cf. Make sure you + choose a partition that is big enough to contain all the + files you plan on using. Finally, don't forget to kill + and restart usbd. + + The provided script will also sound a short melody + once the copying is done. This lets you know it is safe + to pull out the CF card. If you don't hear it, add the + &man.spkr.4 psuedo-device to your kernel. + + + + + PC-CARD readers + + This section repeats the previous one, this time + explaining how to make a PC-CARD slot (or a dedicated CF + slot) work. + + + Requirements + + Compared to USB readers, PC-CARD readers are + simpler. They only require the &man.pccardd.8 daemon + to run. In all likelihood, you already have it. If + not, add the following line to + /etc/rc.conf: + + pccard_enable="YES" + + Again, the message log will tell us the name of + the device. For example, one + pccardd-attached device shows up + as: + + ad8: 124MB <SAMSUNG CF/ATA> [496/16/32] at ata4-master BIOSPIO + + indicating that the device is ad8. + + + + Using an upload script + + The same script as + above can be used for PC-CARD readers. The only + difference is what runs it - in this case, it is + pccardd instead of + usbd. Add this entry to + /etc/pccardd.conf (create the file + if it doesn't exist on your system): + + # GENERIC Flash ATA / ATA HDD + generic fixed_disk + config 0x1 "ata" ? + insert /usr/local/sbin/copy-flash $device /tmp/cf CFOWNER + logstr "GENERIC Flash ATA / ATA HDD" + + Again, change CFOWNER to the name of the user you + want to have access to the files. + + + + Using the automounter + + Much of the information in this section is from a + + Dæmon News article by Renaud Waldura . The + automounter can mount filesystems automatically whenever + they are accessed. That is, you simply + ls or cd to a + directory that represents a filesystem, and the + automounter intercepts the operation, and makes sure the + underlying filesystem is mounted. It is typically used + for managing NFS mounts, but here we use it for local + mounts. + + Add these lines to /etc/amd.map: + + localhost type:=auto;fs:=${map};pref:=${key}/ + +localhost/cf type:=program;fs:=/mnt/cf;\ + mount:="/sbin/mount mount /mnt/cf";\ + unmount:="/sbin/umount umount /mnt/cf" + + Next, add a line for the filesystem in + /etc/fstab. It will look like this, + assuming that in your system the reader appears as the + device /dev/ad8: + +/dev/ad8s1 /mnt/cf msdos rw,noauto 0 0 + + Note that we specify the first slice on the disk, + and the filesystem. Many digital + cameras expect their CF cards to be configured in this + way. We also need to create the mount point: + + &prompt.root; mkdir -p /mnt/cf + + To enable the automounter, add this line to + /etc/rc.conf: + + portmap_enable=YES +amd_enable="YES" +amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map" + + Once you start amd (or reboot), + any user should be able to access the CF card, simply by + doing a ls or cd on + the directory /host/localhost/cf + + Remember that amd only unmounts + the filesystem after it has been idle for some time. + This means that before you take the CF card out of the + slot, you need to stop using it (remembering to + cd out of any directories on it), and + wait. Pulling out a mounted device can cause all kinds + of trouble, including data loss and system crashes. So + you want to make sure you unmount first. If you're in a + hurry and can't wait for amd to time + out, you can ask it to unmount the filesystem immediately + by doing: + +&prompt.user; amq -u /host/localhost/cf + + This, again, is not a privileged operation and does + not require root access. + + + + Summary + + We eliminated the need for root access to read and + write files stored on CF media. We can let the + automounter do the mounting for us, or have a script that + does all the copying as well. In fact, both of these + solutions can co-exist: whenever media is inserted, new + files are immediately copied over. If the user later + wants to access the card and, say, delete some files, + they can do that and amd will take + care of mounting. + + Once you start using the file-copy script, you will + probably discover that managing multiple copies of the + same data is hard. The original photo is kept on the CF + card, the script makes another one on your local disk, + and you will also probably make a final copy in your + electronic album. To make room and reduce clutter, you + will want to delete redundant copies. It is often + easiest to do this on the PC where you can easily view + the photos on a big screen. The problem is, the files + will re-appear the next time you pop the CF card in. One + solution is to wipe the CF card clean every time you + insert it. But it is wiser to give the good photos + another chance, just in case they get lost. A trick I + find useful is to create a text file in the directory + which stores the files from the CF card, and in that file + I record the name of each file that I delete from the PC + copy. This way, I can also quickly delete the same files + from the CF card whenever it fills up. + + + + Acknowledgments + + Scott Mitchell provided greatly valuable help for + this article. Thanks to Joshua Schachter and Nadav + Eiron. + + + + Helper Script for Copying Files from CF Card + #!/bin/sh +# Dan Pelleg, March 2003 +# +# copy-flash: mount a compact-flash card, copy the contents over, unmount +# usage: copy-flash [flash-device] [target-dir] [user] + +dev=${1:-da6} +tgt=${2:-/tmp/foo} +user=${3:-root} + +[ -e "$tgt" ] || mkdir -p $tgt && chown $user $tgt +[ -e /mnt/cf ] || mkdir -p /mnt/cf + +# figure out if we were called with a device like ad8 or ata4. If it's +# the latter, figure out the usable device name +case ${dev} in + ata* ) + channel=${dev##ata} + + if [ -n ${channel} ]; then + realdev=$(atacontrol info $channel | grep ^Master | cut -d " " -f 3) + fi + ;; + + ad* | da* ) + realdev=${dev} + ;; +esac + +if [ -n "${realdev}" ]; then + # on -CURRENT we might need to wait a bit before the device node appears + if [ ! -e /dev/${realdev} ]; then + sleep 5 + fi + # if the slice doesn't yet exist, try to nudge + # things so it does. Might be necessary for some devices + # on -CURRENT + # This mount is not supposed to succeed, but it does + # sometime cause the device node to be created. + if [ ! -e /dev/${realdev}s1 ]; then + mount -t msdos /dev/${realdev} /mnt/cf && umount /mnt/cf + fi + mount -t msdos /dev/${realdev}s1 /mnt/cf && \ + su ${user} -c "cp -nRp /mnt/cf/ ${tgt}" ; \ + # play a tune to let the user know it's all over + umount /mnt/cf && echo "MLT250o3fc" > /dev/speaker +fi + + + + >Release-Note: >Audit-Trail: >Unformatted: