Bill Freeman <f@ke1g.mv.com>,
In a message on Fri, 25 Apr 2003 15:09:03 -0400 (EDT), wrote :
BF> Robert Heller writes:
BF> >
BF> >
BF> > In message <16041.28100.412845.726694@ke1g.mv.com>, Bill Freeman writes:
BF> > > I have an external prallel port generic IDE drive box that
BF> > >works with on26. Using a normal IDE disk and pd things are just fine.
BF> > >
BF> > > I'd like to use it with an ATAPI Zip drive. Using pf, fdisk
BF> > >can see it just fine, and I can, for example, eject the disk with
BF> > >eject.
BF> > >
BF> > > But, since pf was apparently written with non-partitioned
BF> > >disks (LS-120, CDs) in mind. Zip disks, however, are partitioned.
BF> >
BF> > *Normal* (internal) IDE Zip drives, show up like 'regular' IDE disks --
BF> > /dev/hdX, which can be partitioned (or not). Same is true of SCSI Zip
BF> > drives, both as true SCSI Zip drives (yes, these do exist) and as
BF> > parallel port types (which have a built-in parallel port SCSI
BF> > interface) -- they show up as 'regular' SCSI disks, eg /dev/sdX.
BF> > Shouldn't the IDE (ATAPI) Zip drive connected via your parallel-port
BF> > IDE controller also show up as just another IDE disk?
BF>
BF> By this do you mean that when the pf module recognizes the
BF> drive that it should then show up as hdX? I'll have to look closer,
No, if you attach your IDE Zip drive to a desktop computer's internal
IDE bus it shows up as /dev/hdX.
BF> but I don't think so. (The box is home, I'm at work, so I won't get a
BF> chance to try for a while). Certainly, when I stick an IDE hard drive
BF> in this box and use the pd module, it shows up as pda\d*, not, for
BF> example, hde\d*. As a point of interest, fdisk labels the partition
BF> pf0p1, which, of course, is not an existing node.
If an IDE hard drive shows up as /dev/pda*, then *I* would think that
the Zip drive should also show up as /dev/pda*. Unless the /dev/p*
devices (and corresponding drivers) are somehow confused about just
what the Zip drive is. I've only really dealt with SCSI devices --
things make much better sense with SCSI. The SCSI spec. understands
about 'removable media hard drives'. IDE is mostly a hack that has
grown out of the old hard-card 'hack'.
BF>
BF> > > Is there something short of reworking the pf driver to support
BF> > >partitioning that will get me around this?
BF> >
BF> > Can you see the Zip drive as a 'regular' IDE disk via your parallel
BF> > port IDE interface (I'm guessing /dev/pdXn)? If so, that is your
BF> > solution.
BF>
BF> No. The pd module doesn't recognize the drive. pf does and
BF> correctly reports the identity string, after which /dev/pf0 is a working
BF> argument for fdisk and eject. mount claims not to recognize the file
BF> system, since, of course, the master record with the partition table
BF> is not a valid superblock, etc.
OK, it looks like the /dev/p[df] drivers are 'brain dead' (from my point
of view) or at least it is an inherent problem with the parallel-port
IDE driver logic, and may in fact be an inherent problem with IDE over
parallel port in general. Unless there is a way to coerce the driver to
consider the Zip drive as a hard disk (some sort of module load
parameter settings in /etc/modules.conf or something). If you can
somehow *force* the paride driver to configure the Zip drive as if it
was a hard drive and NOT as a floppy disk, you might get your
partitioning. You may lose the 'eject' function (but you probably can
live with this).
I just looked at the device numbers for /dev/pf* and /dev/pd*. The
/dev/pd* devices have minor numbers just like to /dev/hd* and
/dev/dev/sd*: minor numbers are set up so the low-order 4 bits are the
partition number and the upper 4 bits are the drive number: /dev/pda is
45,0 (the whole of device 0 (a)), /dev/pda1 is 45,1 (partition #1 of device 0
(a)), /dev/pdb is 45,16 (the whole of device 1 (b)), etc. The /dev/pf's
are /dev/pf0 is 47,0; /dev/pf1 is 47,1, etc.
The only thoughts I have would be either to patch the /dev/p* drivers
(or use some sort of parameter magic in /etc/modules.conf or with
modprobe) to make it think of the Zip drive as a 'removable media hard
drive' (and use the /dev/pdXn devices) and not a 'big IDE floppy drive'
(/dev/pfN). Or in fact just toss the IDE Zip drive + parallel port IDE
box and just get a proper parallel port Zip drive (really a SCSI Zip
drive with integrated parallel port SCSI controller) and use the
parallel-port SCSI controller (ppa.o). With this driver a parallel
port (SCSI) Zip drive will show up as /dev/sdXn (X = a for first SCSI
disk, n = partition number (1-15) or blank for the whole disk), giving
all of the proper options for partitioning.
BF>
BF> > Note: you don't *have* to partition Zip carts, although it is a normal
BF> > thing to do.
BF>
BF> True, I wouldn't have to partition a Zip disk for internal use,
BF> but when someone hands me a Zip disk as a sneaker-net transfer, and her
BF> system (not Linux) uses partitioning, I need to deal with it. (Not that
BF> there aren't workarounds. Use the Zip drive on the desktop and the
BF> ethernet, for example. But it would be nice to be able to keep this
BF> box in the trunk of the car for use with the laptop.)
BF>
BF> Bill
BF>
BF> -- To unsubscribe, send mail to: linux-parport-request@torque.net --
BF> -- with the single word "unsubscribe" in the body of the message. --
BF>
BF>
\/
Robert Heller ||InterNet: heller@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || heller@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Fri Apr 25 2003 - 22:13:30 EDT