Hi Al,
Hope you are well. Haven't seen you for two months now.
People ask for 32-bit dev_t, and that causes minor changes
several places. One of these places is genhd.c.
The struct blk_probe *probes[MAX_BLKDEV]; must get size
MAX_PROBES, for some random value of MAX_PROBES, say 256
(or PROBES_HASH_SIZE or so to make clear that this is
essentially a hash), and dev_to_index() must return
for example MAJOR(dev)%MAX_PROBES.
Then there was a bug in blk_unregister_region where
the || should have been &&.
That settles this file minimally.
However, my own changes are much larger, that is why I write;
it is bad when two people undo work of each other, and I am
tempted to undo some small part of your work.
Motivation:
User space has dev_t, and MAJOR(), MINOR(), MKDEV() that operate on it.
The kernel has kdev_t, and kmajor(), kminor(), mk_kdev() that operate on it.
For backwards compatibility we must not change the structure
of already existing dev_t. Thus, for a 16-bit dev_t the
major/minor division has to be 8+8. For a larger dev_t it can
be whatever we want, like 16+16 or 12+20 or 32+32.
In all cases MKDEV is a slightly complicated operation, say
#define MKDEV(ma,mi) ((dev_t)(((((ma) & ~0xff) == 0) && (((mi) & ~0xff) == 0)) ? (((ma) << 8) | (mi)) : (((ma) << DEV_MINOR_BITS) | (mi))))
and similarly MAJOR, MINOR have to distinguish cases.
Thus, the kernel becomes smaller and faster if we use
kdev_t, kmajor, kminor, mk_kdev - the kernel-internal
representation, which is just
#define __mkdev(major, minor) (((major) << KDEV_MINOR_BITS) + (minor))
In other words, I am tempted to change some of the places where
you turned kdev_t into dev_t back to kdev_t.
Comments?
Andries
Consider blk_[un]register_region. All of its callers have MKDEV()
as first parameter.
Consider the interval setup in blk_probe. Do you want the intervals
to be in dev_t space or in kdev_t space? I would prefer the latter.
-
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 Feb 07 2003 - 22:00:09 EST