lkml.org 
[lkml]   [2001]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] lazy allocation of struct block_device


On Sat, 1 Sep 2001 Andries.Brouwer@cwi.nl wrote:

> How do you tell when inode is not opened anymore?
> ...
> When do you reset it [i_bcdev]?
>
> Now I see what you are asking - at first I thought you wondered
> about the bookkeeping for the device struct, and there is no problem there,
> but you ask about the bookkeeping for i_bcdev.
>
> 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.

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

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

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

\
 
 \ /
  Last update: 2005-03-22 13:01    [W:0.048 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site