> > 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.
>
That patch only has an effect when the drive is originally registered;
calling devfs_register_disc later does _not_ cause existing partition
entries to be removed. Once the directory has been created,
devfs_register_disc seems to be a no-op.
> 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?
A bit of oversimplification; my previous message said that my new ide-floppy
code could catch almost all media change events. That does not mean,
however, that I have the ability to get the right thing done in the device
directory for every possible type of event.
>
> > 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?
Nope, existing entries don't go away when devfs_register_disc gets called
for the second (or subsequent) times.
>
> > 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?
This is true, the IDE subsystem would remove the directories if the
_interface_ got removed, but unloading ide-floppy or ide-hd does not remove
the _interface_, only the driver handling the device(s) attached via that
interface. Yes, this should be handled by the upper layer of the IDE
subsystem, and I'll try to find a way to make that happen. However, with the
way that things stand right now, the IDE subsystem will still need some way
to tell devfs to unregister all the entries in the device directory,
_without_ removing the device directory itself. If the device directory got
removed, then there wouldn't be any code to recreate it when a module got
loaded later.
Here's the sequence of events, just to refresh your memory:
- ide module registers /dev/ide
- ide module calls ide-probe, which registers all the
/dev/ide/hostX/busX/lunX directories
- ide module calls ide-hd, ide-floppy, ide-cd (if not modules), and they
create entries _inside_ the lunX directories and /dev/discs or /dev/cdroms
links
- if ide module (top layer) is unloaded, all this disappears (as it should)
- if ide-hd, ide-floppy or ide-cd get unloaded, their entries inside the
lunX directories don't get removed, because the IDE major device is still
present
|