devfs
[Top] [All Lists]

Re: Removeable Media, partitions and devfs?

To: "Richard Gooch" <rgooch@xxxxxxxxxxxxxxx>
Subject: Re: Removeable Media, partitions and devfs?
From: "Kevin P. Fleming" <kevin@xxxxxxxxxxxxx>
Date: Fri, 7 Dec 2001 11:44:36 -0700
Cc: "Paul Bristow" <paul@xxxxxxxxxxxxxxx>, <Andrej.Borsenkow@xxxxxxxxxxxxxx>, <mfedyk@xxxxxxxxxxxxx>, <devfs@xxxxxxxxxxx>
Organization: LSG, Inc.
References: <3C0C9AC5.4080504@paulbristow.net><001801c17d15$758b6760$c8aaa8c0@kevin><3C0D588F.9000806@paulbristow.net><03be01c17d20$5d1b72f0$c8aaa8c0@kevin><200112050639.fB56d0a05344@vindaloo.ras.ucalgary.ca><00e901c17dd2$8ccffe50$c8aaa8c0@kevin> <200112060633.fB66XoZ22006@vindaloo.ras.ucalgary.ca>
Sender: owner-devfs@xxxxxxxxxxx
(sorry for the delay in responding, had to rebuild the server at my office
over the last 48 hours :-()

>
> However, as I recall, at least one version of your patch completely
> unregistered a disc and then re-registered it. That's definately the
> wrong approach, as I've said before, because it opens up a race. The
> same disc could end up with a different number in /dev/discs.
>
> Apologies if your patch doesn't do this now: I haven't looked
> closely. That's partly because it's long, and I believe a short patch
> should be fine.

That's correct, it did do that at one time, but no longer does so. It
originally did so only because the code fs/partitions/check.c does not allow
for any finer control over the entries without being reorganized. And that
does make the patch seem long, when in reality it's just changing three
functions into four and documenting them.

>
> 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.
>

That's a reasonable approach, but please understand that I've already spent
quite a bit of time trying to find another solution, and I don't think there
is one. It boils down to this: right now, the block device driver is
responsible for calling grok_partitions when it wants to get the partitions
registered. As a side effect (with devfs in the kernel), the appropriate
devfs entries get created. That's all grok_partitions is responsible for,
and as a result it makes no specific attempt to remove unneeded partitions
entries. It also seems reasonable to me that if the device driver knows when
entries should be created, and has a specific function to call for that
purpose, that it should also know when entries should be removed, and should
have a function to call for that purpose.

>
> > - when media is ejected, invalid partition entries remain in the
> > directory
>
> Future work.
>
> > - when media is repartitioned, invalid partition entries remain in
> > the directory
>
> Future work, same solution as above.
>
> > - when media is reformatted, invalid partition entries remain in the
> > directory
>
> Future work, same solution as above.
>
> > - when ide-floppy (or ide-hd) modules are unloaded, the
> > disc/partition entries (and the directory) are not removed
>
> Future work.

And please note that these problems are not removable-media specific (as
best I can tell),  so they really need to be addressed for devfs to work in
a "logical" fashion.



<Prev in Thread] Current Thread [Next in Thread>