On Monday June 12, Billy.Harvey@thrillseeker.net wrote:
> Richard Stallman writes:
> >> Thats all very nice, but what do you do for the "luser" that opens a file
> >> on the floppy using a word processor... I see that a LOT at work (plus the
> >> use of excel/photoshop/exporer/...
> >
> > When you visit a file with Emacs, Emacs opens the file, reads it all,
> > and closes it. Once that is finished, the file is not open any more.
> > When you save the file, Emacs opens it, writes the whole text, then
> > closes it. So if you removed the floppy after visiting, the save will
> > get an error, but nothing worse will happen. If you replaced it with
> > a different floppy, the save will go on the new floppy.
>
> Your post the other day about this got me to thinking, and the Emacs
> analogy above is similar to my though line and can be extended to
> floppies with (hopefully) little confusion to newbies.
>
> What is needed is a program which when called will dd the image of the
> floppy just inserted into a file, in some specified location, perhaps
> /var/floppy-`date +%s`, for example. with ownership assigned to
> whomever did the calling.
My turn for a "hey - I've got a good idea, why don't we..." posting?
I agree that the "magic" should be done at the block device level
rather than the filesystem level, but I would go about it differently.
I would create a "virtual" block device driver which needs to have a
real block device underneath it - much like "md" - the software raid
driver.
This virtual driver would present a number of devices all related to
one underlying device. The idea is that each device that it presents
represents a particular diskette which could be in the drive.
The virtual driver caches data quite aggressively, preferably in
pageable memory, but I don't really know about that.
So:
- You stick a floppy in the drive and this causes a "media change"
event on the real device.
- The virtual driver notices this event, reads the first few blocks
and sees if it already has a device representing that diskette. If
it does it creates an association with that virtual device and allows
any blocked read/writes to complete.
- If the virtual driver hasn't seen this diskette before, it allocates
it to a free virtual device and causes a "media change" event on
that device.
You then have an automounter that monitors all the virtual devices,
just as if they were normal devices, and on media-change events it
tries to mount the filesystem somewhere appropriate. Possibly you
also have a symlink from "/floppy" to the most recent "appropriate"
place, but maybe not, I'm not sure how the UI should work.
If the virtual driver gets a read/write request for the currently inserted
disk, it satisfies it directly.
If it gets a write request it either fails (EIO) or succeeds after
storing the block in cache, and flags the device as having outstanding
data (visible via some file in /proc I guess). The choice would
depend on some config option.
If it gets a read request for a different disk and the block is in the
cache, the reqeust is satisfied.
If it gets a read and the block isn't in cache, it either blocks and
puts a flag in that /proc file, or returns EIO depending on config.
Possibly it could time out and return EIO after 5 minutes. There
would need to be a way for the UI to force the driver to timeout early
(some sort of ioctl?).
The automounter would still try to unmount things that weren't in use,
and the virtual drive would need to know when devices were unmounted
so that it could consider discarding the cache.
The gui could then monitor the /proc file and pop up warnings where a
disc needed to be inserted. Identifying "which" disc might be
awkward, but thats a different problem.
Just another idea for the melting pot.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:30 EST