On Tue, Aug 14, 2007 at 12:42:06PM -0700, Garrett D'Amore wrote:
> On Tue, 2007-08-14 at 12:28 -0700, Edward Pilatowicz wrote:
> > On Tue, Aug 14, 2007 at 12:26:46PM -0600, Mark J. Nelson wrote:
> > >
> > >
> > > >> To have "qfe" devices properly represented by the "qfe" driver, while
> > > >> allowing for "hme" devices to be seen by the "hme" driver, we need some
> > > >> code.  The only differences between these two devices are:
> > > >>
> > > >>        1) qfe has a specific parent PCI bridge
> > > >>        2) different Fcode
> > > >>
> > > >> The point is that admins don't want to rename the devices for qfe to
> > > >> hme, because it will cause major conversion headaches.  And on x86, it
> > > >> would be "nice" if qfe devices were still qfe (as they are on sparc)
> > > >> rather than being known by "hme" in the x86 hardware.
> > >
> > > > Both examples sound too special to warrant for any change in the core
> > > > kernel, imho. I think if any quirks need to be implemented, they should
> > > > be confined within the driver modules. At least when devices EOL, the
> > > > ugliness goes away with the drivers; if you let ugliness into the DDI,
> > > > it's forever.
> > >
> > > In the update_drv(1M) manpage, we see that:
> > >
> > > >      -a                    Add a permission,  aliases,  privilege
> > > >                            or policy entry.
> > > >
> > > >                            With the -a option specified,  a  per-
> > > >                            mission  entry  (using the -m option),
> > > >                            or a driver's aliases entry (using the
> > > >                            -i  option), a device privilege (using
> > > >                            the -P option) or a  a  device  policy
> > > >                            (using the -p option), can be added or
> > > >                            updated. If a matching minor node per-
> > > >                            missions  entry is encountered (having
> > > >                            the same driver  name  and  the  minor
> > > >                            node),  it  is replaced. If a matching
> > > >                            aliases entry is encountered (having a
> > > >                            different  driver  name  and  the same
> > > >                            alias), an error is reported.
> > >
> > > ...the point being that "the binding mechanism doesn't know how to handle
> > > this situation."  You can't fix this in the driver, because you can't bind
> > > multiple drivers to the same alias.
> > >
> > > Why is it ugly to extend the binding mechanism to allow greater
> > > differentiation between devices?
> > >
> >
> > because the devices we're trying to differentiate between are actually
> > the same device?  the case we're actually trying to handle is when one
> > of these devices is connected a bridge/bus that we deem "special".
>
> Actually, the magic in this case is the presence of fcode.  The bridge
> is just another heuristic to detect it.  Checking Fcode contents would
> be more accurate.
>

but fcode doesn't exist on x86, or well, it exist on the card but isn't run.
so our options are to use the heuristic, which is what i said above.
<joke> or perhaps we should consider using the kernel fcode interpreter
on x86.</joke>

ed
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to