Re: Some questions about libports and notification of ports

[Da Zheng]

Thomas Bushnell BSG wrote:
> > > If you want to serve that file, you'll be writing a trivfs translator
> > > for it. 
> > >   
> > >       
> > I'm sorry, I don't understand you.
> > The translator associated to the device file is actually written with 
> > libtrivfs.
> >     
>
> Good grief, I can't keep track of what you are talking about.
>
> I'm just about to give up, but I'm going to try.  You omit a lot of
> information.  I'm going to ask you to stop doing that.  If you want
> communication to succeed, you MUST try and give all the information, and
> not just guess that I can guess what's in your head.  I can't.
>
> Ok, so I saw code that opened these /dev/eth0 nodes.  I saw no code that
> implements them.  I said, "hey, what implements them?" and you said,
> "well, this is what they will do."  Ok, I'll try again.  What implements
> these /dev/eth0 nodes?  Is that something you've written?  Something
> that already exists? 
>
>   
> > Do you mean I should implement the IO operation? so other programs can 
> > read and write the device file to communicate with the kernel device?
> > but what we want is a translator that helps other programs get the port 
> > to the device. That's it.
> >     
>
> Um, that is *obviously* not what you are wanting.  (And please, don't
> say "what we want"; just say "what I'm trying to implement".  I can
> hardly keep track of what you are working on because it seems to change
> from message to message.)
>
> If you only wanted "the port to the device", it would be a simple
> translator that held the device master port and handed out the Mach
> device port.
>
> Obviously you do NOT want simply to "help other programs get the port to
> the device."  Please help me understand.  What *exactly* is your
> project?
>   
I'm sorry I make you confused and waste you so much time.
Let me start from the first beginning.

I wrote two translators. One is a filter translator named eth-filter. 
The other is the translator that does simply help other programs get the 
port to the device, and it is named as devnode. Maybe it's the place 
where you got confused.

eth-filter sits between the ethernet interface and the user programs 
such as pfinet, and filters the packets.
The code I put in my previous mails is from eth-filter.

I started to talk about devnode because you asked me about device_file 
in the code of eth-filter.
kern_return_t
ds_device_open (....)
{
....
if (device_file == NULL)
  return D_NO_SUCH_DEVICE;

master_device = file_name_lookup (device_file, 0, 0);
if (master_device == MACH_PORT_NULL)
  return errno;

proxy = (struct proxy *)calloc (1, sizeof (*proxy));
if (proxy == NULL)
  {
    mach_port_deallocate (mach_task_self (), master_device);
    return D_NO_MEMORY;
  }

err = device_open (master_device, mode, name, &proxy->device_port);
....
}

device_file used by eth-filter is created by devnode. It is actually a 
new way provided by devnode to open the device.
Compared with the original way of opening the device by using 
get_privileged_ports and device_open,
the new way is:
to call file_name_lookup() to get the port to the devnode translator,
and to call device_open() to get the port to the device.
If the device file doesn't exist, I just simply assume that the device 
doesn't exist.

devnode is implemented with libtrivfs and it implemets the server-side 
of RPC routines in device.defs (actually, only device_open is really 
implemented).
What it does is exactly as you said "held the device master port and 
handed out the Mach device port"
Here is the implementation of device_open.
kern_return_t
ds_device_open (mach_port_t master_port, mach_port_t reply_port,
               mach_msg_type_name_t reply_portPoly,
               dev_mode_t mode, dev_name_t name, mach_port_t *device,
               mach_msg_type_name_t *devicetype)
{
 error_t err;

 debug ("ds_device_open is called\n");

 if ((user_device_name && strcmp (user_device_name, name))
     || device_name == NULL)
     return D_NO_SUCH_DEVICE;

 err = device_open (master_device, mode, device_name, device);
 *devicetype = MACH_MSG_TYPE_MOVE_SEND;
 return err;
}

Because the way provided by devnode to open the device is a little weird 
for me and also confused you, I asked you to give some suggestions for 
its design and showed you the message 
http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg00005.html.

I hope it's clear for you now.
And sorry again for the trouble.

Zheng Da