[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some questions about libports and notification of ports

From: Thomas Bushnell BSG
Subject: Re: Some questions about libports and notification of ports
Date: Sat, 23 Aug 2008 10:09:39 -0700

On Sat, 2008-08-23 at 09:36 -0700, Thomas Bushnell BSG wrote:
> So you have two ports.  When the one going to the user is destroyed, you
> need to tell the device not to send any more packets.
> And we have a way to do that: by calling device_set_filter, and clearing
> out the port there.  The driver will then drop its send right for you.

Ah, I see now, the device_set_filter interface is very unusual.  I had
remembered that you could have only one filter at a time, but that's not
correct.  The only way to make the filter go away is to make the port go

So this is, as it happens, a rare case where you do need

I still insist that the correct structuring of the structs is as I

First, you still want the memory be allocated in the way that libports

struct filter_user {
  struct port_info pi;
  struct filter_setup *filter;

struct filter_device {
  struct port_info pi;
  struct filter_setup *filter;

struct filter_user and filter_device need to be distinct port classes.
They might end up being the same struct if you don't need any extra
members, of course.

struct filter_setup {
  struct mutex lock;
  struct filter_user *u; /* does NOT hold a reference */
  struct filter_device *d; /* does NOT hold a reference */

In the clean routine for filter_user, you would need to do the
  if (fu->filter->d)
    ports_destroy_right (fu->filter->d);
  fu->filter->d = 0;

The ports_destroy_right will nuke the receive right, causing the kernel
to (eventually) clean up its data structures, and the ports_port_deref
accounts for the FU->dev reference itself which is going away.

You have to be very careful to remember that you have no control over
the order the clean routines would be called and so forth.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]