hello Matthew. That line assures that if a device driver has unloaded
and reloaded its
bdevw or cdevw interfaces, it gets assigned the same major numbers that they
had when they
were first loaded on the system. If a device driver has never loaded its
bdevsw or cdevsw
interfaces on a system and the major number is dynamically assigned, this works
as well because
execution of the for loop exits due to there being an insufficient number of
conv structures
available when the device driver loads for the first time, so this test is
never executed.
Once the driver loads for the first time, the conv structure is initialized
with the correct
major numbers and this test will pass the next time the device driver loads its
bdevsw or
cdevsw interfaces. There is one caveat here that was always true, but will
absolutely be
enforced with this patch. That is, the caller of devsw_attach() should ensure
the bmajor and
cmajor numbers they pass into the function point to different variables in
their function, even
if they do not implement the bdevsw interface. If they fail to do this,
they'll get EINVAL
back from the devsw_attach call if they load their bdevsw or cdevsw interfaces
on the system
more than once.
-thanks
-Brian
On Feb 13, 2:47pm, matthew green wrote:
} Subject: re: devsw_detach is failing -- is this a manifestation of PR kern
} your change seems to fix a clear but to me.
}
} > - if (*bmajor < 0)
} > + if ((bdev != NULL) && (*bmajor < 0))
} > *bmajor = conv->d_bmajor;
}
} there's also this line i'm curious about, just below:
}
} if (*bmajor != conv->d_bmajor || *cmajor != conv->d_cmajor) {
} error = EINVAL;
} goto out;
}
} should the first part also depend upon either bdev != NULL or
} perhaps (*bmajor >= 0 && bdev == NULL) as the following code
} uses...
}
}
} .mrg.
>-- End of excerpt from matthew green
