Deprecating / Removing floppy drive support

Cy Schubert Cy.Schubert at komquats.com
Mon Dec 4 00:23:36 UTC 2017


In message <CANCZdfq+iRDJeNFP9hKZXrDmcZZPn4jqzYZDpspiohJ+FMj9hA at mail.gmail.c
om>
, Warner Losh writes:
> --001a113dbf6a68e17b055f7557cd
> Content-Type: text/plain; charset="UTF-8"
>
> On Sun, Dec 3, 2017 at 1:05 PM, Cy Schubert <Cy.Schubert at komquats.com>
> wrote:
>
> > In message <201712031655.vB3GtIME041023 at pdx.rh.CN85.dnsmgr.net>, "Rodney
> > W.
> > Gri
> > mes" writes:
> > > > On 12/03/17 07:16, Cy Schubert wrote:
> > > > > In message <CANCZdfrYdQTtjZJ_+jSVr25wjAZXd-+
> > 4atSaeT5ahfprbtXHWw at mail.gmai
> > > l.c
> > > > > om>
> > > > > , Warner Losh writes:
> > > > >> --001a1144e7002bf7b0055f684ec8
> > > > >> Content-Type: text/plain; charset="UTF-8"
> > > > >>
> > > > >> On Sat, Dec 2, 2017 at 8:31 PM, Cy Schubert <
> > Cy.Schubert at komquats.com>
> > > > >> wrote:
> > > > >>
> > > > >>> bms@ has given me USB floppy formatting code which I'd planned to
> > merge
> > > > >>>
> > > > >> into fdformat but considering the underlying devices are so very
> > differe
> > > nt
> > > > >>> it would be a difficult marriage. I'd be willing to support a
> > ufdformat
> > > > >>> instead.
> > > > >>
> > > > >>
> > > > >> I'm keen on getting that into the tree. I have a ufd device and a
> > need t
> > > o
> > > > >> use it from time to time. If nothing else, I can be a reviewer of
> > the co
> > > de.
> > > > >> Is ufd working for you?
> > > > >
> > > > > It does work. My todo was to merge ufdformat into fdformat but as I
> > said
> > > > > they are different enough that I need to work out how best to merge
> > them.
> > > > > Having said that, now that there's discussion of removing fdc(4)
> > maybe it
> > > 's
> > > > > best to simply use ufdformat separately from fdformat that when we
> > have t
> > > he
> > > > > inclination to remove fdc(4), which may be very soon now -- it would
> > be
> > > > > much less messy. I'm open to either option.
> > > > >
> > > > >>
> > > > >>
> > > > >>>>
> > > > >>>> Normally, I'd argue we might want to have a release where it's
> > > > >>> deprecated,
> > > > >>>> but it already was unusable in 11, and barely usable in 10 and
> > has bee
> > > n a
> > > > >>>> shadow of its former self for much longer than that.
> > > > >>>
> > > > >>> The reason to keep some form of floppy support, eder fd or ufd is
> > for t
> > > he
> > > > >>> purpose of copying (dd) floppy media into image files for use with
> > > > >>> virtualbox or bhyve VMs. -- (One could say the same for CD and DVD
> > driv
> > > es.
> > > > >>> My new laptop at $JOB has no CD/DVD drive.) I digress. I think the
> > abil
> > > ity
> > > > >>> to copy media to image files for VMs might be a reason to keep
> > some for
> > > m of
> > > > >>> support fd or ufd.
> > > > >>
> > > > >>
> > > > >> I'm not sure I understand what you're saying here...
> > > > >
> > > > > What I'm saying is that maintaining some form of fdc support whether
> > it b
> > > e
> > > > > in fdc(4) or a USB floppy the ability to dd floppy images for
> > subsequent
> > > > > use in a VM would be desirable. I'm thinking of one example brought
> > to my
> > > > > attention about a month ago where a person I know needed to copy old
> > flop
> > > py
> > > > > disks to images on his hard drive in order to install an old sewing
> > machi
> > > ne
> > > > > application in a virtualbox VM running Windows.
> > > > >
> > > > > Tangentially speaking, we could make the same case for CD and DVD
> > drives
> > > > > not too many years from now...
> > > > >
> > > > > Personally, I don't care much (well maybe just a little) if fdc(4)
> > itself
> > > > > is removed however I think we need some kind of support, which USB
> > fd can
> > > > > supply if or when fdc(4) is removed. Maybe we should deprecate in 12
> > and
> > > > > remove in 13?
> > > > >
> > > > >
> > > >
> > > > Hi,
> > > >
> > > > I think as long as you can read and write USB floppy drives under
> > > > FreeBSD, this change is OK. Even though floppies are old-tech they are
> > > > still important:
> > > >
> > > > https://news.slashdot.org/story/16/05/25/2054255/us-
> > military-uses-8-inch-fl
> > > oppy-disks-to-coordinate-nuclear-force-operations
> > > >
> > > > And from time to time we see criminal cases popping up with crazy
> > people
> > > > using old C64's with floppy disks. I would feel bad if removing support
> > > > for floppies from FreeBSD would mean you would depend on a Windows
> > > > installation to read such disks.
> > > >
> > > > Further, keep this change two-step. First remove the code from GENERIC.
> > > > Then wait a year and see if anyone complains. Then delete the source
> > code.
> > > >
> > > > --HPS
> > >
> > > I was gona keep quiet on this, but, well, I just cant now.  If you remove
> > > the entry from GENERIC no one well complain, the more likely case is they
> > > well just compile a customer kernel and do there work.  So using this as
> > > a "is anyone using it" is a straw man.
> > >
> > > That being said, even an old crusty fart like me only has had to deal
> > > with a 1.44 MB floppy in nearly a year, but I was very glad that I COULD
> > > deal with it using my prefered OS.
> > >
> > > Now I have lots of hardware around so it was not hard for me to find
> > > a TEAC 1.44 drive and hook it to my forensics motherboard and deal
> > > with the image, maybe it is good I am stuck on 5.4 with that system
> > > as it sounds like someone has broken yet another part of FreeBSD
> > > in the name of some progress.
> > >
> > > **RANT ON**
> > >
> > > Data point:  OpenBSD still supports install from floppies.. so
> > > my guess is that OpenBSD has been able to keep this code running,
> > > it is a "Sad State of Affairs" that FreeBSD with 300+ developers
> > > can not manage the same.  As Eitan pointed out, its only a 1000
> > > lines so of code.   Really now, we can manage to keep the mass
> > > of clang and zfs running, but we can not keep a 1000 line fdc.c
> > > running?
> >
>
> The floppy driver itself is fine. It relies, however, on ISADMA working. It
> got broken and nobody noticed. Also, FreeBSD has SMP while OpenBSD does
> not, so that's been a much larger code velocity over all.
>
>
> > > I further know of someone who just told me they completed
> > > a converson of a stack of old 1.44MB floppies and 100MB
> > > zip disks to image files, and I am pretty sure that person
> > > is running 11.1 on a laptop, so this was probably done
> > > with the USB fd code, so I suppose we do have some form
> > > of support.   It is possible that person netbooted an
> > > older desktop to do the work, as he does have those types
> > > of abilities.
> >
>
> Reading works OK. It's writing that fails. So this datapoint is consistent
> with my experience. There's other issues that need to be fixed apart from
> ISADMA, but those are minor in comparison.

I noticed that. Took a break from outside chores to quickly test:

g_vfs_done():fd0[READ(offset=184320, length=512)]error = 5

>
>
> > > **DOUBLE RANT**
> > >
> > > Having been gone from the project for a long time and
> > > looking at it from the outside my observation is that
> > > FreeBSD is a lot of new toys that work fairly well and
> > > a collection of rotting bits that get the axe every few
> > > years.
> > >
> > > Each and everytime I have tried to move my collection
> > > of systems forward I have run into yet another thing that
> > > has simply been killed cause no one maintained it, broken
> > > cause someone added/changed something else and allowed it
> > > to sit and rot tell it was axed cause it was broken.
> > >
> > > If we, that is FreeBSD, continue on this path I can promise
> > > you our PR data base today well look like a mud puddle
> > > comparied to the ocean we shall create.
> > >
> > > Rather than spend time running around the tree finding
> > > rotting code to delete there needs to be a serious
> > > effort running around the tree FIXING the code that has
> > > rotted cause some new fangled thing borked it.
> >
>
> The trouble is that the skillsets necessary to fix the rotting code
> generally only exist in a small number of people, while just about anybody
> can wield an axe.

And, not everybody has the hardware available to test. Sure one can use 
qemu but it's not the same as real hardware.

>
> And lots of people do fix things, but people don't notice so much because
> (a) they are still working and (b) the fixes tend to be in relatively close
> proximity to the breakage. It's only when they don't that it becomes an
> issue.

Agreed.

>
>
> > > ** END RANTS**
> >
> > I've spent some time thinking about this while cleaning up the yard of old
> > leaves today. All three of my machines downstairs still have fdc(4)
> > controllers and take a poke at it.
> >
> > USB floppy does also work. The ufdformat USB floppy format (not yet
> > committed, thank you bms@) also works in 12 (it didn't in 7 due to borked
> > USB in 7). I've yet to decide whether to commit it as is or merge it into
> > the existing fdformat.
>
>
> I'd commit it as is (ufdformat). It's functionality is quite a bit
> different because the CDBs are much less expressive than the full NEC 765
> chip supports (which is itself a subset of what you can do on a floppy, but
> I digress).

I'll try to post it on phab tonight.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.




More information about the freebsd-arch mailing list