Re: [RFC] lazy allocation of struct block_device

Andries.Brouwer@cwi.nl
Sun, 2 Sep 2001 10:24:30 GMT


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/