Kevin P. Fleming writes:
>
> ----- Original Message -----
> From: "Richard Gooch" <rgooch@xxxxxxxxxxxxxxx>
> To: "Kevin P. Fleming" <kevin@xxxxxxxxxxxxx>
> Cc: "Paul Bristow" <paul@xxxxxxxxxxxxxxx>;
> <Andrej.Borsenkow@xxxxxxxxxxxxxx>; <mfedyk@xxxxxxxxxxxxx>;
> <devfs@xxxxxxxxxxx>
> Sent: Saturday, December 08, 2001 8:03 PM
> Subject: Re: Removeable Media, partitions and devfs?
>
>
> > Kevin P. Fleming writes:
> > > > > 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 :-)
> > >
> > > Are you sure that's a reasonable thing to do? It seems that the size
> > > variable should accurately reflect the size of the device at that
> > > moment, and if it doesn't who's to say that won't cause other side
> > > effects in the grok_partitions and related code in the future? Seems
> > > a bit risky to me, "overloading" this variable to make sure that the
> > > devfs code works in the way we all want it to.
> >
> > Actually, that variable was already overloaded to stop
> > grok_partitions() from reading a partition table.
> >
>
> OK, with the new ide-floppy media change detection, this is exactly
> what happens. If check_media_change gets called and there is
> currently no media in the drive, or unformatted media in the drive,
> then a "size" of 0 is passed to grok_partitions.
>
> This leads to existing partX entries not being removed, as
> grok_partitions does not make any attempt to update the partition
> information. If I forcibly pass a non-zero size, grok_partitions
> cleans up the old entries, but only after generating at least two
> IDE I/O errors in the system log as it tries to read the partition
> table from the disk. If I had other partition methods compiled in my
> kernel, I'm sure it would generate even more errors.
You shouldn't need to pass a non-zero size. That's what my tiny patch
is meant to solve. If size==0 and the media is removable, it creates
the device directory and "disc" entry, *without reading the partition
table*. Thus there should be no errors.
>From your previous message, it appeared that all but one problem (new
media of the same size) was solved when using my patch. Is that not
the case?
> Any suggestions on how you want see this handled? This is (somewhat)
> where I arrived previously, in that the driver knows that the
> partition entries need to be removed, but has no direct way to cause
> that to happen.
Doesn't my patch fix this?
> Also, remember that we still have the problem where the disc
> directory and its entries are not removed when ide-floppy or ide-hd
> are unloaded, leading to an oops if you try to access any of those
> entries (since the ops pointers that devfs stored are no longer
> valid).
I thought that the generic IDE layer was handling directory removal?
I note that ide_unregister() makes a call to devfs_unregister(). This
appears to be called when an interface is unregistered. Is there some
code path that is called when an IDE upper-level driver (i.e. hd,
floppy, tape, etc.) is removed? If not, someone should add that.
Who knows their way around the IDE code to know the best place to do
this?
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|