Menu
▾
▴
projectudi-protocols — Discussions about development of protocols in UDI.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(20) |
Mar
(27) |
Apr
(14) |
May
(22) |
Jun
(6) |
Jul
(3) |
Aug
(4) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
|
From: Quick, K. <Kevin.Quick@Surgient.com> - 2002-10-02 18:46:49
|
Yes, you certainly could make the case for running the protocol modules in an adjacent environment like user-space. Of course, the protocol module itself wouldn't be able to tell. And yes, the metalanguage transport facility would be used to "bridge" the metalanguage channel between the protocol module and the driver across the environment domain boundary. Writing a bottom-side mapper to convert from UDI protocol modules to native drivers is a separate aspect, but it's possible. Given the availability of supported environments in the prototype, I'd personally rather write a UDI driver for the bottom than an OS-specific mapper. -Kevin -----Original Message----- From: Barned, Robert [mailto:rob...@lm...] Sent: Wed 02/10/02 12:48 PM To: Quick, Kevin; Barned, Robert; Project UDI Protocol Metalanguages Discussions Cc: Subject: RE: [UDI-protocols] UDI drivers and protocol modules in applicati on libraries Kevin, I was thinking that many higher level protocol modules as well as device drivers (the device might be plugged into a bus for which there is a kernel driver) there is no need to have them in the kernel it would probably be better not to have them there. These modules and drivers would communicate to modules or drivers in the kernel using some metalanguage such (e.g. the transport metalanguage). I was thinking that it would be advantageous if these modules and drivers could be truly portable. Bob > -----Original Message----- > From: Quick, Kevin [mailto:Kevin.Quick@Surgient.com] > Sent: Wednesday, October 02, 2002 12:16 PM > To: Barned, Robert; Project UDI Protocol Metalanguages Discussions > Subject: RE: [UDI-protocols] UDI drivers and protocol modules in > application libraries > > > Bob, > > I'm not sure what antecedent you intended in your reference to > "they" below, but here's an answer and tell me if it's answering > your question: > > UDI drivers are written for location independence. This means that > the only thing that they are aware of is that they are running in a > UDI environment. They have no awareness of running in a kernel > environment, user environment, or otherwise. > > There can be user-space UDI environments as well as kernel-space > UDI environments (our prototype POSIX environments are a rough > version of the former). The principle challenge to a user-space UDI > environment is support of the Physical I/O spec. (should it > choose to do > so). > > A user-space UDI environment would tend to be a little more than a > "library" because it would have independent execution contexts and > global elements (such as the Management Agent) that are not > traditionally aspects of a library. > It's a little hard to quantify because a UDI environment is > very exactly > specified > whereas a "library" is more of a common nomenclature than a precise > specification. > > Regards, > Kevin > > > -----Original Message----- > From: Barned, Robert [mailto:rob...@lm...] > Sent: Wed 02/10/02 10:53 AM > To: Project UDI Protocol Metalanguages Discussions > Cc: > Subject: [UDI-protocols] UDI drivers and protocol modules in > application libraries > All, > > Does it makes sense to implement a UDI environment as part > of an application library so that they can communicate with > kernel drivers (UDI or non-UDI), but provide functionality that > might be better to not include in the kernel? > > > Bob > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Projectudi-protocols mailing list > Pro...@li... > https://lists.sourceforge.net/lists/listinfo/projectudi-protocols > > > > ------------------------------- > This e-mail is for the sole use of the intended recipient and may > contain confidential and privileged information. Any unauthorized > review, use or disclosure is strictly prohibited. If you are not the > intended recipient of this e-mail, please notify sender and delete > all copies immediately. > ------------------------------- This e-mail is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use or disclosure is strictly prohibited. If you are not the intended recipient of this e-mail, please notify sender and delete all copies immediately. |
|
From: Barned, R. <rob...@lm...> - 2002-10-02 17:49:40
|
Kevin, I was thinking that many higher level protocol modules as well as device drivers (the device might be plugged into a bus for which there is a kernel driver) there is no need to have them in the kernel it would probably be better not to have them there. These modules and drivers would communicate to modules or drivers in the kernel using some metalanguage such (e.g. the transport metalanguage). I was thinking that it would be advantageous if these modules and drivers could be truly portable. Bob > -----Original Message----- > From: Quick, Kevin [mailto:Kevin.Quick@Surgient.com] > Sent: Wednesday, October 02, 2002 12:16 PM > To: Barned, Robert; Project UDI Protocol Metalanguages Discussions > Subject: RE: [UDI-protocols] UDI drivers and protocol modules in > application libraries > > > Bob, > > I'm not sure what antecedent you intended in your reference to > "they" below, but here's an answer and tell me if it's answering > your question: > > UDI drivers are written for location independence. This means that > the only thing that they are aware of is that they are running in a > UDI environment. They have no awareness of running in a kernel > environment, user environment, or otherwise. > > There can be user-space UDI environments as well as kernel-space > UDI environments (our prototype POSIX environments are a rough > version of the former). The principle challenge to a user-space UDI > environment is support of the Physical I/O spec. (should it > choose to do > so). > > A user-space UDI environment would tend to be a little more than a > "library" because it would have independent execution contexts and > global elements (such as the Management Agent) that are not > traditionally aspects of a library. > It's a little hard to quantify because a UDI environment is > very exactly > specified > whereas a "library" is more of a common nomenclature than a precise > specification. > > Regards, > Kevin > > > -----Original Message----- > From: Barned, Robert [mailto:rob...@lm...] > Sent: Wed 02/10/02 10:53 AM > To: Project UDI Protocol Metalanguages Discussions > Cc: > Subject: [UDI-protocols] UDI drivers and protocol modules in > application libraries > All, > > Does it makes sense to implement a UDI environment as part > of an application library so that they can communicate with > kernel drivers (UDI or non-UDI), but provide functionality that > might be better to not include in the kernel? > > > Bob > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Projectudi-protocols mailing list > Pro...@li... > https://lists.sourceforge.net/lists/listinfo/projectudi-protocols > > > > ------------------------------- > This e-mail is for the sole use of the intended recipient and may > contain confidential and privileged information. Any unauthorized > review, use or disclosure is strictly prohibited. If you are not the > intended recipient of this e-mail, please notify sender and delete > all copies immediately. > |
|
From: Quick, K. <Kevin.Quick@Surgient.com> - 2002-10-02 16:16:33
|
Bob, I'm not sure what antecedent you intended in your reference to "they" below, but here's an answer and tell me if it's answering your question: UDI drivers are written for location independence. This means that the only thing that they are aware of is that they are running in a UDI environment. They have no awareness of running in a kernel environment, user environment, or otherwise. There can be user-space UDI environments as well as kernel-space UDI environments (our prototype POSIX environments are a rough version of the former). The principle challenge to a user-space UDI environment is support of the Physical I/O spec. (should it choose to do so). A user-space UDI environment would tend to be a little more than a "library" because it would have independent execution contexts and global elements (such as the Management Agent) that are not traditionally aspects of a library. It's a little hard to quantify because a UDI environment is very exactly specified whereas a "library" is more of a common nomenclature than a precise specification. Regards, Kevin -----Original Message----- From: Barned, Robert [mailto:rob...@lm...] Sent: Wed 02/10/02 10:53 AM To: Project UDI Protocol Metalanguages Discussions Cc: Subject: [UDI-protocols] UDI drivers and protocol modules in application libraries All, Does it makes sense to implement a UDI environment as part of an application library so that they can communicate with kernel drivers (UDI or non-UDI), but provide functionality that might be better to not include in the kernel? Bob ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Projectudi-protocols mailing list Pro...@li... https://lists.sourceforge.net/lists/listinfo/projectudi-protocols ------------------------------- This e-mail is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use or disclosure is strictly prohibited. If you are not the intended recipient of this e-mail, please notify sender and delete all copies immediately. |
|
From: Barned, R. <rob...@lm...> - 2002-10-02 15:58:43
|
All, Does it makes sense to implement a UDI environment as part of an application library so that they can communicate with kernel drivers (UDI or non-UDI), but provide functionality that might be better to not include in the kernel? Bob |
|
From: Barned, R. <rob...@lm...> - 2002-01-04 14:29:36
|
To protocol list administrators, I subscribed to the protocol list (I think 2 times) please ignore this. In the future I think I want to get may home ISP on the reflector. To do this do I subscribe with a different name? Sorry to bother you. Bob |
|
From: Burkhard D. <bu...@st...> - 2001-10-04 14:48:24
|
On Wed, Oct 03, 2001 at 11:16:26AM -0500, Andy Schweig wrote: > I just realized that no one set up protocols calls for October. Call > participation has been minimal of late (myself included). Maybe we should > suspend the weekly calls until more people are actively working on or interested > in UDI protocols development. Thoughts? I'm still very much interested in advancing this. However, I do realize that I haven't been making a lot of progress recently. I'm currently doing some other stuff related to my thesis, but will have to come back to this soon. Perhaps then we could resume these calls (assuming that nobody else is actively working on anything right now). Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: Andy S. <ae...@st...> - 2001-10-03 16:16:34
|
I just realized that no one set up protocols calls for October. Call participation has been minimal of late (myself included). Maybe we should suspend the weekly calls until more people are actively working on or interested in UDI protocols development. Thoughts? |
|
From: Burkhard D. <bu...@st...> - 2001-09-26 13:10:37
|
I can't make it. See you all next week (or tomorrow), Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: <Bur...@t-...> - 2001-09-12 14:53:42
|
I have extracted the QoS stuff out, to be submitted shortly as a separate spec draft. Also, this new update now hass all NIC control operations, as I realized that the DLU might have to know about and be able to change things like the MAC address, esp. if it is to deal with multiple datalinks. Burk. -- Burkhard Daniel * ma...@bu... * http://www.burkhard.net Our lives are poems sung against the wind, with nothing but our voices to make a difference. |
|
From: Robert B. <ba...@sy...> - 2001-09-05 15:00:30
|
The following is the call information for the protocols work. Each Wednesday in September 12:00 to 1:00 Eastern Time Dial in (608)250-9281 Code 984733 Bob |
|
From: <Bur...@t-...> - 2001-08-03 13:22:16
|
Forgot the attachment. Here it is. Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 Burkhard Daniel wrote: > This folds in things we discussed during the last F2F. > > Changes are: > > - New udi_dl_cb_ctrl_t cb and udi_dlp_ctrl_req and udi_dlu_ctrl_ack > operations that expose multicast list and promiscuous mode configuration > for the NIC device > - udi_dl_tx_cb_t no longer has a qos_constraints member, so a QoS > constraints set is not delivered with each packet to be transmitted. > Instead, the default QoS for the transmit channel are used. > - New udi_dlp_tx_qos_req operation works like udi_dlp_tx_req, but takes > an extra tx_qos argument with a special set of QoS constraints. > - New udi_dlp_tx_qos_modify_req and udi_dlu_tx_qos_modify_ack operations > to change the default set of QoS constraints associated with a transmit > channel > - udi_dlp_rx_chan_req operation now takes the flag pass_whole_pkt, which > instructs the DLP to pass the entire (unprocessed) data link PDU up > (instead of removing headers and trailers and passing up the > network-level SDU). Used to enable network-level protocols that support > multicast, but where they can't tell from their (network-level) > addresses whether a given packet is multicast or not and need to look at > the datalink packet for that. > > Comments are appreciated as always. > > Burk. |
|
From: <Bur...@t-...> - 2001-08-03 13:20:04
|
his folds in things we discussed during the last F2F. Changes are: - New udi_dl_cb_ctrl_t cb and udi_dlp_ctrl_req and udi_dlu_ctrl_ack operations that expose multicast list and promiscuous mode configuration for the NIC device - udi_dl_tx_cb_t no longer has a qos_constraints member, so a QoS constraints set is not delivered with each packet to be transmitted. Instead, the default QoS for the transmit channel are used. - New udi_dlp_tx_qos_req operation works like udi_dlp_tx_req, but takes an extra tx_qos argument with a special set of QoS constraints. - New udi_dlp_tx_qos_modify_req and udi_dlu_tx_qos_modify_ack operations to change the default set of QoS constraints associated with a transmit channel - udi_dlp_rx_chan_req operation now takes the flag pass_whole_pkt, which instructs the DLP to pass the entire (unprocessed) data link PDU up (instead of removing headers and trailers and passing up the network-level SDU). Used to enable network-level protocols that support multicast, but where they can't tell from their (network-level) addresses whether a given packet is multicast or not and need to look at the datalink packet for that. Comments are appreciated as always. Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: Robert B. <ba...@sy...> - 2001-08-01 15:51:40
|
have been developing the following presentation with Russ Richards. All comments are appreciated. Thank you. Bob Barned |
|
From: Burkhard D. <bu...@st...> - 2001-08-01 14:40:55
|
I can't make it. Sorry. Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: Andy S. <ae...@st...> - 2001-07-31 14:41:32
|
The UDI Protocols conference calls for August are being hosted by STG. Dates: Wednesday, August 1, 8, 15, 22, 29 Time: 11AM - Noon CDT (GMT - 5) Phone: 512.225.3050 Code: 23156 <== THIS IS THE CORRECT CODE |
|
From: Andy S. <ae...@st...> - 2001-07-30 21:42:21
|
The UDI Protocols conference calls for August are being hosted by STG. Dates: Wednesday, August 1, 8, 15, 22, 29 Time: 11AM - Noon CDT (GMT - 5) Phone: 512.225.3050 Code: 12495 |
|
From: Robert B. <ba...@sy...> - 2001-07-09 21:52:46
|
The following is call in information for the protocols conference calls. Wednesdays: (July 11, July 18, and July 25): Start Time: Noon End Time: 2:00 pm Time Zone: Eastern Length: 2 hours No. of Ports: 6 with port expansion Dial in #: 517-267-0146 Participant Code: 564154 If you have any questions let me know. Bob (315) 456-7101 |
|
From: Burkhard D. <bu...@st...> - 2001-06-27 01:13:50
|
I won't be able to make it. I got a performance with my drama group. Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: Burkhard D. <bu...@st...> - 2001-06-20 13:45:57
|
.because tomorrow, during the F2F, we will have a protocols metalanguage discussion. Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: Burkhard D. <bu...@st...> - 2001-06-19 21:30:20
|
is attached. I have flattened out the QoS structures and renamed the members to be more expressive. Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: Andrew K. <an...@ca...> - 2001-06-07 20:06:01
|
Burkhard Daniel wrote: > * Discussion of QoS structures in the latest datalink meta proposal. > The approach of having the DLP inform the DLU about its QoS > capabilities during bind and then having the DLU pass QoS constraints > based on those capabilities during transmit channel creation or > packet transmission seems appropriate. Andy pointed out that the > members of both structures should have less acronymic names. The idea here being the the DLU could make QoS-based routing decisions, right? This sounds useful... BTW, I just poked around and found a recent IETF RFC with a summary of current QoS thinking... <http://www.ietf.org/rfc/rfc2990.txt>. Andrew -- Andrew Knutsen an...@ca... Caldera International (831) 427-7538 work: http://andrewk.pdev.sco.com personal: http://www.goldbarlodge.com |
|
From: Burkhard D. <bu...@st...> - 2001-06-07 18:20:23
|
Attendees: Bob Barned LMCO ba...@sy... Andy Schweig STG ae...@st... Burkhard Daniel STG bu...@st... Agenda: * Discussion of QoS structures in the latest datalink meta proposal. The approach of having the DLP inform the DLU about its QoS capabilities during bind and then having the DLU pass QoS constraints based on those capabilities during transmit channel creation or packet transmission seems appropriate. Andy pointed out that the members of both structures should have less acronymic names. * Discussion on how structs can be described in inline layouts. To be followed up on the tech call by Burk. [This has happened, and the answer is that there is no portable way for doing this that works for all ABIs. The safe way is to flatten out structs.] Burk to submit an updated draft with flattened structs. * Burk pointed out that he will start defining the datalink meta based on the current draft because he needs to move on with his thesis. Will update definitions as the meta draft changes. * Should there be a call on June 20th, the day before the F2F?` Consent was to decide that on short notice, i.e. if a call seems needed we should have one, otherwise we wouldn't. June Call Info: * Time: 11AM - Noon CDT (GMT - 5) Phone: 512.225.3050 Code: 84652 Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: Burkhard D. <bu...@st...> - 2001-06-05 07:03:49
|
As promised on the last call, this one has a better description of the QoS types (which are represented as inline memory). Please review & comment. Thanks, Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |
|
From: Andy S. <ae...@st...> - 2001-05-30 18:38:51
|
The UDI Protocols conference calls for June are being hosted by STG. Dates: Wednesday, June 6, 13, 20, and 27 Time: 11AM - Noon CDT (GMT - 5) Phone: 512.225.3050 Code: 84652 |
|
From: Burkhard D. <bu...@st...> - 2001-05-30 18:08:41
|
...is attached. It incorporates most of the things we talked about in the last couple of meetings. I have not marked changes this times, because that didn't work right with Word and I put in quite a few changes. So please read through the doc and tell me what you think. See you all on the call, Burk. -- Burkhard Daniel Software Technologies Group, Inc. bu...@st... * http://www.stg.com fon: +49-179-5319489 fax: +49-179-5319489 |