[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: Da Zheng
Subject: Re: Some questions about libports and notification of ports
Date: Wed, 27 Aug 2008 19:25:50 +0200
User-agent: Thunderbird (Macintosh/20080707)

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
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.
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.
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

reply via email to

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