[lkml]   [2002]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] change of ->bd_op->open() semantics

On Fri, 24 May 2002, Linus Torvalds wrote:

> On Fri, 24 May 2002, Alexander Viro wrote:
> >
> > It has an additional benefit of killing the array of default
> > queues on the same pass - a thing we will need to do sooner or later
> > anyway.
> I'd like to see this, because we want to make the "find the right queue" a
> much more expensive operation (no longer some fairly simple mapping from
> major number - a more dynamic and general "register this queue for minors
> xxxx-yyyy of major zzz").
> Doing it just once at open() time allows for that to happen without any
> performance downside.

OK. Plan of company:

1) killing the last caller of get_hardsect_size() (switching it to

2) killing blk_get_queue() and switching to bdev_get_queue()

3) moving the contents of bdev_get_queue() into do_open() and check_partitions()
and caching result in new field of struct block_device; cleaning it at the
same places that reset ->bd_op, etc.; making bdev_get_queue() return cached

4) moving the call of partition-reading code into do_open() (for cases when
->bd_contains is non-NULL), killing the "set block_device fields by hand"
mess in check_partitions()

5) moving the code that sets ->bd_queue into instances of ->open() (leaving
the code in do_open() in place for a while - it's OK since it would be
conditional by ->bd_queue == NULL).

6) after the series of per-driver patches (see 5) is over, kill that code
in do_open() and kill (now unused) array.

7) deal with devfs-related fallout from (4).

(4) is needed since we really can't afford any IO-before-open() anymore and
we need lazy partition-reading to deal with that. OTOH, we can very well
do (1)--(3) and stay at that - result will still have the array, etc., but at
least we won't have recalculate the damn thing for each request.

I would prefer to go all way and move all code that chooses queue into
the ->open(), but it might make sense to split it into several series.
Your call...

Now, I've already sent a patch that does (1) and (2) (last one sent on
Wednesday), but it doesn't show up on bkbits. If there were any problems
with it - please, tell. If not - I can
* resend it, following it by (3)
* send (3) alone
* wait for 2.5.18, rediff and send (1)--(3).
Take your pick...

I'd definitely like to have a testing point between (3) and (4)--(7), so
unless you are going to release 2.5.18 right now I'd prefer to get (1)--(3)
into it...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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