Re: [PARPORT] partitions on Zip disk, ATAPI Zip drive via pf, on26, paride

From: Bill Freeman (f@ke1g.mv.com)
Date: Wed Apr 30 2003 - 12:40:14 EDT

  • Next message: Robert Heller: "Re: [PARPORT] partitions on Zip disk, ATAPI Zip drive via pf, on26, paride"

    Robert Heller writes:
    > Bill Freeman <f@ke1g.mv.com>,
    ...

    > BF> 8. I've pretty much decided that this is easy enough that I'm
    > BF> not going to sign up to "upgrade" the pf driver to handle partitions.
    >
    > You would not be able to anyway -- the pf device does not have the
    > minor number space to support partitions. ...

            I don't think that means that one *can't* do it. I agree that
    it would be a bad idea to invalidate the existing minor numbering for
    pg, but one could either support an additional major (less than
    stellar solution), or use, perhaps the high bit of the minor to select
    between the current minor numbering, and a scheme with the more usual
    low 4 bits of partition, with the remaining bits between there and the
    high bit for unit select. I'm sure that there are yet more
    possibilities. I sort of like Blaise Glassend's suggestion of
    providing an option in the loop back driver to support partitioning

    > ... What *really* should be done
    > is fix paride and/or the lower-level driver (on26) to treat Zip drives
    > as regular disks using the pd driver (eg /dev/pdXn) not as floppy
    > drives (/dev/pfN). ...

            That sounds like just another hack. There apparently really
    is a difference in how to talk to "plain" IDE versus how to talk to
    ATAPI, and pd versus pf drivers are divided along those lines. I see
    no reason that paride or all of the protocol modules should give a
    rat's fuzzy behind about what kind of IDE device with which they are
    allowing the higher level drivers to communicate. It is the pd driver
    that doesn't deal with the ATAPI zip disk. It causes no trouble for
    on26 of paride.

    >... Actually, *I'm* not convinced that there really is a
    > reason for 'IDE Floppy Drives', unless there is something totally brain
    > dead about the IDE interface spec. ...

            When you're ready to re-manufacture the existing hardware base
    gratis, then I'll pay heed to this opinion. Otherwise, I don't see
    how it helps.

    > ... In any case, it makes me very glad
    > that I have managed to mostly avoid the whole IDE mess in the first
    > place. The *only* IDE device I have to deal with is the hard drive in
    > my laptop -- ALL of the rest of my computers are 100% SCSI (Hard
    > drives, CD-ROM, tape drive, Zip drive, ORB drive, and Scanner). These
    > sorts of sillienesses don't happen in the SCSI world -- *my* Zip drive
    > is properly handled as a partitioned device (/dev/sdcN). ...

            I congratulate you upon your wealth. And I congratulate the
    developers of the SCSI drivers on their clairvoyance in not splitting
    the upper level drivers in such a way that removable media was assumed
    to be unpartitioned. But, at least until the New Hampshire high tech
    job market improves, I'll be living with the hand-me-downs that I
    have.

                                                            Bill

    -- 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 : Wed Apr 30 2003 - 13:48:34 EDT