James,
On Thu, 2006-07-20 at 13:15 -0700, james s. edele wrote:
> We have software that sits between the IP layer and the NIC
> driver and processes incoming and outgoing packets. It worked
> fine until the new Nemo interface with mac_rx() was implemented
> in Solaris 10.
What about this change broke your software? It would be good to
understand that first. What was the mechanism used prior to Solaris 10?
Was it STREAMS and autopush?
> Now we want to be able configure/register our driver's receive function to be
> the
> only receive callback function that mac_rx() calls back from
> the bge driver.
Why do you need to insert your software at that layer? Why not use
either a STREAMS module or the packet filtering hooks that Darren Reed
is working on?
>
> To this end some experimental code was created in our driver
> to call mac_open("/dev/bge0",..) in order to get the mac handle
> for bge.
mac_open() is called using the MAC name, not the name of the DLPI node
in the file system. The MAC name for bge0 is "bge0".
> After which we could then do a mac_rx_remove() of
> what's there and then a mac_rx_add() of our receive callback
> function.
That violates the interface between the mac module and other consumers
of that MAC. You'd first have to go find the other mac_rx_handle's
registered for that mac, and there's no safe way to do that. Even if
there were and you were able to remove them, you'd be pulling the rug
out from some other module with unexpected side-effects.
mac_rx_remove() frees the mac_rx_handle, which some other module is
still holding on to. That's a panic waiting to happen.
>
> mac_open("/dev/bge0"...) is returning EINVAL. It was found that
> the call to ddi_name_to_major() from mac_open() is returning "-1".
> ddi_name_to_major() calls mod_name_to_major() which calls
> find_mbind(). find_mbind() goes thru mb_hashtab[] looking for the
> driver name of "/dev/bge" and doesn't find it.
"bge0" is what you'd want, not "/dev/bge0". Regardless, I think the
overall approach here is going down the wrong path.
>
> Is our above objective doable? That is, using the mac_* API can
> we register our receive callback function as the only callback
> receive function for the bge driver?
I don't think it's safe nor doable.
>
> Are we using the mac_* API correctly?
That's the crux of it, that's not a proper way to use the API.
Moreover, that API is consolidation private, and isn't safe to use
outside of ON. Unless you're planning on integrating your software into
ON, your software is subject to incompatible changes in the API.
> Maybe we need to do more
> than just a mac_open("/dev/bge0") and then mac_rx_add()? If we
> are not using it correctly, what other API functions do we need
> to call?
It depends on what your software does. You could look into implementing
a STREAMS module and also look into Darren's packet filtering hooks.
Without knowing what you want to do, it's hard to say...
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
