Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Apr 1996 13:41:01 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        joerg_wunsch@uriah.heep.sax.de
Cc:        freebsd-current@freebsd.org
Subject:   Re: devfs questions
Message-ID:  <199604072041.NAA00546@phaeton.artisoft.com>
In-Reply-To: <199604070128.DAA15372@uriah.heep.sax.de> from "J Wunsch" at Apr 7, 96 03:28:49 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > > I don't really like the current way either.  The fd0.foo entries
> > > should be symlinks to `generic' fd0a ... fd0z entries, created by
> > > the rc mechanism instead of by devfs.
> > 
> > Bletch.  The slices should not be there. You are imposing a naming
> > convention that isn't very flexible an which we would then have
> > to live with forever.
> 
> Which slices?  I'm simply implying some form of subdevices.  The
> actual meaning of them is run-time selectable.  It is already now,
> there's a mostly unused utility fdcontrol(8), you can use it to make
> your fd0.1720 device node accept 184 KB floppies instead. :-)

How do I "runtime select" it into my /etc/fstab?

The naming convention is being imposed because you are restricting
the subdevice domain to 26 entries (a..z), and that's what is bad,
not the fact that naming is necessary or desirable.  I think the
naming should wait for media recognition, and in the case of no
recognition, there should be no naming beyond the raw device
(which you would then use to format the device, which when complete
would establish a convention corresponding to the new format).


> All i want is generic names, and leave it to userland to find
> convenient names for it.  Format autodetection will never work for all
> 5E+23 different floppy formats that are available in the world.

Microsoft can, therefore any reasonably intelligent 12 year old can.

The Olympians live in Olympia, not Redmond, and it isn't the Greek
version of Olympians.  Bill Gates is not a god, despite his PR.


> > Better to force "changedisk" and suggest people buy good floppy
> > drives
> 
> This is unrelated.  Changelin support is unavailable for exotic
> drives, and i think it's also unavailable for drives 2 and 3.  I agree
> that it should be used if it is there.  (Didn't i say the floppy
> driver needs a rewrite? :-)

Yes.  But this is more of an issue of "how do I handle removable
media such that when I physically eject the 1.2M floppy and replace
it with a 360k floppy, the kernel doesn't crap its pants?".

It's possible for the floppy driver to provide the format recognition
at this gross level, and it's possible for the file system, in the
case of a device that has the "DEVF_REMOVABLE" flag but not the
"DEVF_CHANGENOTIFY" or "DEVF_EMPTYNOTIFY", to verify that the disk
has not changed underneath it before proceeding with an operation.

For those with notification, its possible to do without having to
verify for each seperate access.  Obviously, a write-run or format-run
or read-run isn't a seperate access... this is a buffer management
issue.  I don't really care if you handle a physical-but-unauthorized
media change by saying "put the disk back or all changes will be lost"
vs. just flushing the thing and forgetting about it.


> > The first thing to do is to cause 0x370 referencing code to be added
> > to the floppy driver so that this is not a problem for 95% of all 3.5"
> > disks.
> 
> There's not much different between modern 3.5in and 5.25in drives.
> All AT drives are supposed to support changeline logic, and systems
> like OS/2 do break if the drives are broken.

We shouldn't break.  We have the option of reprobing on each access
(as simple as doing a single read and seeing if we get an error, and
if we don't, comparing the data), or requiring the use of a "changedisk"
program if the volume has not been unmounted.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604072041.NAA00546>