On Mon, Mar 24, 2003 at 09:34:14PM +0100, Andries.Brouwer@cwi.nl wrote:
> A. On kdev_t vs. dev_t:
> kdev_t gives small and fast code, dev_t needs a conditional
> That was my main reason. I suppose you say that dev_t is a cookie
> and that the kernel should never want to ask about major and minor,
> except perhaps at filesystem interfaces. So the 1000+ invocations
> that we have now should all go away. A reasonable point of view.
Yupp. And you'll notice that we're almost there for block devices
already.
> B. On what is registered:
> The main question here is what the documented outside reality is.
> Is that phrased in terms of dev_t intervals? Or is that phrased
> in terms of (major,minor) pairs?
> Until convinced otherwise I will hold that users talk about
> (major,minor) pairs. They do ls -l and see major,minor pairs.
> They want to do mknod and need a major,minor pair.
> So I suppose that the documented reality will give a minor
> range for a given major, or give a major range.
Well, users can do that if it makes their live easier. The kernel
doesn't need nor should know about this split internally. There's
a few legacy interfaces left that hardcode this split, but it's
okay - no one expects the major/minor split to have more meaning
than __low/__high anyway - we already have far too many subsystems
that hand out ranges (or in the case of sound individual dev_t s)
to drivers.
> Of course one can avoid the distinction by decreeing that
> majors 0-255 cannot have more than 256 minors.
It might be a wise idea to not use them to avoid subtile driver
breakage unless we do a full audit, yes.
-
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 : Mon Mar 31 2003 - 22:00:17 EST