lkml.org 
[lkml]   [2003]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
Subjectdev_t stuff
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/

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