Re: [PATCH 1/3] revert register_chrdev_region change

From: Andries.Brouwer@cwi.nl
Date: Mon Mar 24 2003 - 15:34:14 EST


    From: Christoph Hellwig <hch@infradead.org>

> Yes, it is more elegant to register one or more ranges.
> (But ranges of what? Ranges in dev_t space? Or in kdev_t space?

    In dev_t space.

    I guess basically everyone will disagree with you on making kdev_t
    a different representation. This will end up as messy as the
    internal/external dev_t stuff on some of the SVR4 ports.

You are the first to say so. I'll think about it.

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.

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.
Such ranges correspond to kdev_t ranges, not to dev_t ranges.

Of course one can avoid the distinction by decreeing that
majors 0-255 cannot have more than 256 minors.

Andries
-
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