From viro@math.psu.edu Sun Sep 2 01:54:52 2001
On Sat, 1 Sep 2001 Andries.Brouwer@cwi.nl wrote:
> Since the refcount is for the device struct, we cannot do anything
> until that count hits zero. Then the release method of the device struct
> is called (which frees it, or decrements a refcount for the module).
Wait a minute. You had suggested (upthread) that these objects are allocated
by partition code and contain per-partition data. Freeing them once the device
is closed looks very odd.
The partition data itself is in the gendisk chain.
A device struct contains a pointer to it.
But this is a separate discussion: what is the precise contents of
device struct and driver struct.
(I have used different versions. My main interest was always in
turning k[b]dev_t into a pointer and removing the arrays. Since some
of the arrays are 1-dimensional and some are 2-dimensional, the
mechanical conversion leads to a majorstruct that contains the integer
major and a name function and the contents of the 1-dimensional arrays,
and a minorstruct that contains the integer minor and the contents
of the 2-dimensional arrays and a pointer to the majorstruct.
People tend to panic "don't you know that there is no 1-1 corr.."
when they hear "majorstruct" so I started using "driverstruct".)
> After this i_bcdev cannot be used anymore.
> Since we don't know whether this happened already, i_bcdev must be
> recomputed on each open or mount.
... and that means that we can't make devfs-like filesystems just set
->i_bdev (or ->i_cdev) at read_super() (or lookup()) and avoid all mess
with major/minor allocation. IMO that's unfortunate, especially since
majors allocation is on the permanent freeze.
That majors allocation is frozen is not my problem.
I make life simple with a 64-bit dev_t. Everybody else already has the
disadvantages of a 64-bit dev_t, since glibc moves 64 bits around,
but not the advantage of a large namespace.
But that is a separate discussion.
Concerning devfs, I don't use it and have not really thought about it.
I think my point of view would be that devfs provides a different object.
A device node in a filesystem is a pair (pathname, dev_t).
Opening it gives the triple (pathname, dev_t, kdev_t).
What devfs provides is (pathname), after opening (pathname, kdev_t).
But I think the pointer kdev_t (or i_bcdev) must still be recomputed:
it remains true that modules can be unloaded.
> (One might invent additional data structure to avoid this recomputation,
> but data structures take memory and add the complication that they
> must be kept consistent and up-to-date. Since mounting, or opening
> a block device, are very infrequent operations, it does not matter
> that we do a possibly superfluous bdopen().)
Once you look at character devices (they have same set of problems)
frequency goes up big way.
True. I still think there would be no problem - this reopen is not expensive.
Alternatives like putting these things in a list are much worse,
since that would slow down the handling of all inodes, not only
device nodes.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:14 EST