[illumos-Developer] [REVIEW] 260 some drivers erroneously discount a major of 0

[Garrett D'Amore]

On Fri, 2010-10-01 at 13:42 -0400, Gordon Ross wrote:
> On Fri, Oct 1, 2010 at 11:04 AM, Garrett D'Amore <garrett at damore.org> wrote:
> > dump(7d) uses major 0 on my system.  I think we just have recognize that
> > 0 is a valid major number.
> 
> Yes, zero is valid.  Unfortunately, the real world contains lots of code that
> uses default initialization (to zero) so uninitialized major or dev_t values
> are unfortunately likely to hit that slot in the devopsp vector.  I suggest
> that it's a small price to pay to reserve slot zero to avoid accidents with
> such (admittedly incorrect) drivers and such.

But we don't have to make "all" drivers work correctly.  In fact, the
only driver(s) that have to work are those that are likely to be
assigned this number -- so the base drivers like dump. :-)

I think we can own that much of the problem at least (making sure our
own drivers are not busted.)

In fact, its really the installation scripts that are busted, not the
drivers themselves (generally).

	- Garrett

> 
> Gordon
> 
> 
> >        - Garrett
> >
> > On Thu, 2010-09-30 at 21:52 -0400, Gordon Ross wrote:
> >> Looks fine to me.
> >>
> >> I wonder if there is any reasonable way on an existing system to move
> >> whatever driver might be using major zero to some other major number?
> >> If so, you could skip the 2nd and 3rd file changes.
> >>
> >> On Tue, Sep 28, 2010 at 1:36 AM, Richard Lowe <richlowe at richlowe.net> wrote:
> >> >
> >> > I'd like review of:
> >> >   260 some drivers erroneously discount a major of 0
> >> >
> >> > webrev: http://richlowe.net/webrevs/il-maj0/
> >> >
> >> > This bug is the same as:
> >> >  6975280 t_kopen() fails if transport major device = 0
> >> >
> >> > As noted in the bug (#260), the change to add_drv prevents major 0 being
> >> > given to drivers (it means, for new images, major numbers will start
> >> > from 1), this is due to the impossibility of auditing every driver for
> >> > assumptions regarding (dev_t)0 (especially those from 3rd parties), and
> >> > the apparently fairly widespread assumption that such a dev_t is
> >> > invalid.  The only code I found with such assumptions is t_kopen, and in
> >> > addition sv, as mentioned in the bug.
> >> >
> >> > I've tested this via add_drv -b, with an empty name_to_major, to verify
> >> > that the first driver it adds gets major 1, with a partially complete
> >> > name_to_major, to make sure that the 'gap' at 0 is not filled, and by
> >> > wiring tcp(7D) to major 0 to test the circumstances mentioned in 6975280
> >> > (both before and after).
> >> >
> >> > I have not yet found a good way to test 'sv', though the change seems
> >> > obvious I'm entirely willing to (and would prefer to) revert it, unless
> >> > a volunteer can come up with a reasonable way to test it.  You would
> >> > need the device underlying sv to have both a major and minor number of
> >> > 0.
> >> >
> >> > Garrett has already looked at this, and given some general sense of
> >> > assent.
> >> >
> >> > If you plan to look at this but require more time, please say so,
> >> > so that I know to wait for you.
> >> >
> >> > -- Rich
> >> >
> >> > _______________________________________________
> >> > Developer mailing list
> >> > Developer at lists.illumos.org
> >> > http://lists.illumos.org/m/listinfo/developer
> >> >
> >>
> >> _______________________________________________
> >> Developer mailing list
> >> Developer at lists.illumos.org
> >> http://lists.illumos.org/m/listinfo/developer
> >
> >
> >