Paul Bristow writes:
>
> Richard Gooch wrote:
>
> > Because I believe that most (maybe even all) of the problems are
> > solvable with a few minor tweaks. So I'd prefer to start with a few
> > tweaks and see if that fixes it.
>
> I like this approach. The patch also explains why I was going crazy
> trying to squeeze the solution into ide-floppy. I didn't initially
> realise the problem was more generic than just my driver. Richard,
> you may be pleased to know that *everyone* who emailed me assumed it
> was my fault in the driver, and that devfs was perfect :-)
Obviously, you haven't received email from Al :-)
I knew that ide-floppy was setting GENHD_FL_REMOVABLE (I put it in
there in the first place, IIRC), and that's all that should have been
necessary. I designed that flag that way. So I figured that whatever
the bug was, it was probably something stupid and simple.
> >>>The solution, as I see it, is to force grok_partitions() to call
> >>>devfs_register_disc() when size==0 and the GENHD_FL_REMOVABLE flag is
> >>>set. This will cause the "disc" entry in the
> >>>/dev/ide/host*/bus*/lun*/target* directory to be created, and it will
> >>>tag that directory for media revalidation.
> >>>
> >>>If you read that directory, or attempt a lookup of some leaf node, the
> >>>media will be revalidated. If there's new media in the drive, the
> >>>normal partition handling code should be invoked, and thus the
> >>>appropriate leaf nodes will be created. Take the media out, and the
> >>>next readdir or lookup will remove partition entries (assuming the
> >>>ide-floppy driver doesn't set the size back to 0). Magic. Just the way
> >>>god^H^H^HI intended.
> >>>
> >>Nope, grok_partitions does not cause existing entries to be removed,
> >>unless the "size" is left at its original value, in which case your
> >>system log will be filled with "unable to read partition table"
> >>errors and errors from the ide layer trying to read non-existent
> >>media.
> >>
> >
> > So, let me get this right (I haven't looked closely at ide-floppy, so
> > bear with me): when there is no media present, the driver sets the
> > size to zero at revalidate time, even if previously the size was
> > non-zero?
>
> At the moment no. But it could :-)
Oh. So then the current situation is this:
- driver loaded without media -> size==0
- driver loaded with media -> size!=0
- revalidate with media -> size!=0.
Correct? So what happens now on revalidate without media? Let's say
the sequence was:
- insert media
- load driver
- remove media
- revalidate.
What does the driver do to indicate there is no media?
> > So please try the appended patch again. It doesn't claim to solve the
> > unregistering problem, but that's OK. I want to take this a step at a
> > time. A bit more tweaking should (I hope) take care of the remaining
> > problems.
>
> Working patch below... slightly tweaked
Ah, shit. Another stupid bug. You didn't even need to shift the
first_minor variable. Better patch appended.
> >>- without media in the drive at driver load time (either kernel
> >>startup or module load), no entries are created, no access is
> >>possible to the drive
> >>
> >
> > My patch should fix that.
>
> The patch does fix this, by creating the disc entries regardless.
Which is consistent with other removable media devices, I think (not
that I've ever had the hardware to check this). The main thing is that
the directory is created, with the DEVFS_FL_REMOVABLE flag set on an
entry in that directory.
> Now, the problem we still have is how to automatically revalidate
> when a user tries to mount the a partition. This is the most common
> usage case for zip drives, and is not working on my system with the
> patch below.
>
> i.e. attempting to do this
> mount /dev/ide/host0/bus1/target1/lun0/part4 /mnt/zip
> with no disc inserted will fail, even with the
> /dev/ide/host0/bus1/target1/lun0/disc entry present
>
> however, having a re-validation caused, which in ide-floppy does a
> grok_partitions again should create the part4 entry so that the mount
> succeeds
??? devfs_register_disc() should have created the "disc" entry with
the DEVFS_FL_REMOVABLE flag. That in turn means that the directory is
tagged as having removable media. So when you do an inode lookup or a
readdir(3) on the directory, a media revalidation is performed.
Please put in a printk() in fs/devfs/base.c to see what's happening.
Look for how check_disc_changed() is being called.
> The following items should be future work that we will fix during
> 2.5.
I hope a few simple tweaks to fs/partitions/check.c should fix it, in
which case it's a 2.4 thing.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
--- check.c~ Thu Oct 11 18:25:10 2001
+++ check.c Thu Dec 6 23:49:54 2001
@@ -383,6 +383,8 @@
dev->part[first_minor].nr_sects = size;
/* No such device or no minors to use for partitions */
+ if ( !size && dev->flags && (dev->flags[drive] & GENHD_FL_REMOVABLE) )
+ devfs_register_disc (dev, first_minor);
if (!size || minors == 1)
return;
|