devfs
[Top] [All Lists]

Re: Removeable Media, partitions and devfs?

To: "Kevin P. Fleming" <kevin@xxxxxxxxxxxxx>
Subject: Re: Removeable Media, partitions and devfs?
From: Richard Gooch <rgooch@xxxxxxxxxxxxxxx>
Date: Sat, 8 Dec 2001 20:02:14 -0700
Cc: "Paul Bristow" <paul@xxxxxxxxxxxxxxx>, <Andrej.Borsenkow@xxxxxxxxxxxxxx>, <mfedyk@xxxxxxxxxxxxx>, <devfs@xxxxxxxxxxx>
In-reply-to: <010501c17f4f$3816d950$c8aaa8c0@kevin>
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> <010501c17f4f$3816d950$c8aaa8c0@kevin>
Sender: owner-devfs@xxxxxxxxxxx
Kevin P. Fleming writes:
> > 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.

As always, functional change patches and documentation change patches
should be separated. Haven't you lurked on linux-kernel long enough to
know Linus hates mixed patches? :-)
I share the sentiment.

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

I specifically want the drivers to have as little knowledge about this
as possible.

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

When I use fdisk to repartition a device, removed partitions disappear
from devfs when I write the new partition table. It seems to me things
work fine with non-removable media.

                                Regards,

                                        Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current:   rgooch@xxxxxxxxxxxxxxx

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