Kevin P. Fleming writes:
> > Someone else reported having problems, and it looks to me like the
> > media revalidation isn't working. It used to. Check the list
> > archives, I asked for people to insert debugging printk()'s to find
> > out what's going wrong. I don't have hardware to check this.
> >
> > Regards,
> >
> > Richard....
> > Permanent: rgooch@xxxxxxxxxxxxx
> > Current: rgooch@xxxxxxxxxxxxxxx
> >
>
>
> OK, after a spending a few hours, here's what I've found (all based on
> 2.4.17-pre6):
>
> - ide-probe.c does not contain any code to set the "removable" flag for
> ide-floppy devices. the ide-floppy driver would carry it over into the
> gendisk structure if it was there... so after adding that, the previously
> posted patch _does_ cause the directory and whole-disc device to be created
> on my system, even with no media in the drive when the driver loads
>
> - when the removable flag set properly, devfs does appear to force a "media
> change" check on every readdir or access to the contents of the directory.
> unfortunately, ide-floppy currently contains (nearly) no media change logic.
> this makes the resulting behavior less than optimal :-)
>
> - yes, removing partitions does seem to get the device directory in sync
> now; I don't know when that changed, but it works even for removable media,
> so that problem is gone
>
> - ejecting and formatting media _would_ cause a revalidation to occur, if
> ide-floppy signaled that the media had been changed
>
> So, I spent a couple of hours getting some rudimentary media change logic
> into ide-floppy. It's not complete yet, but should be tomorrow. It will
> report a media change under any of the following circumstances:
>
> - the media was previously ejected
> - the media was previously formatted
> - the media is a different size than at the last media change check
> - the media is (now) unformatted but was at the last media change check
> - there is no media in the drive but was at the last media change check
>
> This should cover almost all cases, except for the most important
> one: when the user manually ejects the media and replaces it with
> identically sized media. There is no way to currently catch that,
> since the media is not serialized. There are ATA commands to monitor
> this sort of thing, but they will require Andre's new ide subsystem
> for implementation without tons of new code.
OK, so that's not a devfs-related problem, right? Changing calls to
devfs won't help with this last problem?
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|