Correct on all counts. Part of what was holding things up was all of
the nonsense related to partition handling. To a lesser degree the cdrom
driver is being held up for similar reasons.
The proper cleanup is to eliminate those damned arrays (and make the
access SMP safe at the same time) that live in ll_rw_blk.c. There would
need to be a generic SMP safe way of obtaining the same information (things
like filesystems need to know this info, for example), and then add SMP safe
ways for low-level drivers to update the sizes of things as required.
The arrays you mention above are just inserted into the even messier
arrays that live in ll_rw_blk.c - as things currently stand, it really isn't
possible to clean up the arrays in sd.c without solving the larger problem
of the mess of arrays in ll_rw_blk.c.
I believe it was Jens who had been talking about folding some of this
information into the request_queue_t, and I don't know where this went if
anywhere. Maybe there was some problem that couldn't be easily resolved.
Another design goal of messing with this would be to do it in such a way
that support for a larger dev_t is possible.
Once the basic design is complete, the actual changes shouldn't be too
hard - just tedious.
-Eric
-
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/