Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Xen: Devel

Support for mii_xxx functions?

 

 

Xen devel RSS feed   Index | Next | Previous | View Threaded


pfisher at imaginationhouse

Oct 19, 2003, 4:39 PM

Post #1 of 10 (182 views)
Permalink
Support for mii_xxx functions?

A quick question before I dive off into (finally) trying to get the 8139too
network driver ported to xen.

It appears that xen/include/linux/mii.h is present in the xen tree, but has
the following:

#if 0
extern int mii_link_ok (struct mii_if_info *mii);
extern int mii_nway_restart (struct mii_if_info *mii);
extern int mii_ethtool_gset(struct mii_if_info *mii, struct ethtool_cmd
*ecmd);
extern int mii_ethtool_sset(struct mii_if_info *mii, struct ethtool_cmd
*ecmd);
extern void mii_check_link (struct mii_if_info *mii);
extern unsigned int mii_check_media (struct mii_if_info *mii,
unsigned int ok_to_print,
unsigned int init_media);
extern int generic_mii_ioctl(struct mii_if_info *mii_if,
struct mii_ioctl_data *mii_data, int cmd,
unsigned int *duplex_changed);
#endif

Is there a specific reason that the drivers/net/mii.c was disabled and not
included?

thanks in advance,
paul



-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Ian.Pratt at cl

Oct 20, 2003, 5:38 PM

Post #2 of 10 (180 views)
Permalink
Re: Support for mii_xxx functions? [In reply to]

> Is there a specific reason that the drivers/net/mii.c was disabled and not
> included?

From Xen, we currently don't have any way of accessing the mii
interface - we rely on the Ethernet card driver's media
autodetect routine to do the right thing. We've yet to come
across a need for any of these routines, but they could be
implemented if required -- I suspect the 3189 driver can be made
to work without them.

Best,
Ian


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


pfisher at imaginationhouse

Oct 20, 2003, 6:33 PM

Post #3 of 10 (180 views)
Permalink
RE: Support for mii_xxx functions? [In reply to]

> From: Ian Pratt [mailto:Ian.Pratt [at] cl]
> Sent: Monday, October 20, 2003 7:39 PM
>
> From Xen, we currently don't have any way of accessing the mii
> interface - we rely on the Ethernet card driver's media
> autodetect routine to do the right thing. We've yet to come
> across a need for any of these routines, but they could be
> implemented if required -- I suspect the 3189 driver can be made
> to work without them.

Uh, ok. I'll readily admit that network drivers are not my thing, but all
the routines which were commented out in mii.h do is call through the
function pointers mdio_read and mdio_write which are implemented in each
individual driver. The seem like just common code to me, which several
drivers use, such as the 8139too.c. The only external routines called out
of the mii.c code are:
- netif_carrier_ok()
- netif_carrier_on()
- netif_carrier_off()

which all seem to be used in tp3.c. Am I missing something?


paul



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Keir.Fraser at cl

Oct 21, 2003, 5:07 AM

Post #4 of 10 (182 views)
Permalink
Re: Support for mii_xxx functions? [In reply to]

> Uh, ok. I'll readily admit that network drivers are not my thing, but all
> the routines which were commented out in mii.h do is call through the
> function pointers mdio_read and mdio_write which are implemented in each
> individual driver. The seem like just common code to me, which several
> drivers use, such as the 8139too.c. The only external routines called out
> of the mii.c code are:
> - netif_carrier_ok()
> - netif_carrier_on()
> - netif_carrier_off()

Yeah, none of the drivers we've ported so far rely on teh common mii
code. It should be easy to add in though.

-- Keir


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


pfisher at imaginationhouse

Oct 21, 2003, 6:48 AM

Post #5 of 10 (180 views)
Permalink
RE: Support for mii_xxx functions? [In reply to]

> From: Keir Fraser [mailto:Keir.Fraser [at] cl]
> Sent: Tuesday, October 21, 2003 7:08 AM
>
> Yeah, none of the drivers we've ported so far rely on teh common mii
> code. It should be easy to add in though.

Thanks.

How do you want outside patches? I've managed to figure out how to get
bitkeeper to generate a changeset for adding these, which is below. Is this
how you want them? Show they be sent to this list?

thanks,
paul


This BitKeeper patch contains the following changesets:
pfisher [at] xen|ChangeSet|20031020214558|21571

# ID:
smh22 [at] boulderdash|ChangeSet|20021120105923|56899|1ee6296af7e15a
82
# User: pfisher
# Host: xen.imaginationhouse.com
# Root: /home/pfisher/xen/xeno-unstable.bk

# Patch vers: 1.3
# Patch type: REGULAR

== ChangeSet ==
smh22 [at] boulderdash|ChangeSet|20021120105923|56899|1ee6296af7e15a
82
kaf24 [at] scramble|ChangeSet|20031017092137|05270
D 1.528 03/10/20 16:45:58-05:00 pfisher [at] xen +3 -0
B
smh22 [at] boulderdash|ChangeSet|20021120105923|56899|1ee6296af7e15a
82
C
c Enable the mii_xxx functions and add their implementation from the
c standard linux sources. These are used by several of the network
c drivers to provide generic mii processing.
K 21571
P ChangeSet
------------------------------------------------

0a0
>
pfisher [at] xen|xen/drivers/net/mii.c|20031020214552|04582|
732fcd56bab80215
pfisher [at] xen|xen/drivers/net/mii.c|20031020214553|16665
>
smh22 [at] boulderdash|xen-2.4.16/include/xeno/mii.h|20021120120209|
27029|2c4ed9538370864d
pfisher [at] xen|xen/include/xeno/mii.h|20031020214552|27076
>
smh22 [at] boulderdash|BitKeeper/etc/logging_ok|20021120120217|03192
|1a0e4366ffd1b425
pfisher [at] xen|BitKeeper/etc/logging_ok|20031020214558|157
81

== xen/drivers/net/mii.c ==
New file: xen/drivers/net/mii.c
f e 4
V 4

pfisher [at] xen|xen/drivers/net/mii.c|20031020214552|04582|
732fcd56bab80215
D 1.0 03/10/20 16:45:52-05:00 pfisher [at] xen +0 -0
B
smh22 [at] boulderdash|ChangeSet|20021120105923|56899|1ee6296af7e15a
82
c BitKeeper file /home/pfisher/xen/xeno-unstable.bk/xen/drivers/net/mii.c
K 4582
P xen/drivers/net/mii.c
R 732fcd56bab80215
X 0x821
------------------------------------------------


pfisher [at] xen|xen/drivers/net/mii.c|20031020214552|04582|
732fcd56bab80215
D 1.1 03/10/20 16:45:52-05:00 pfisher [at] xen +353 -0
B
smh22 [at] boulderdash|ChangeSet|20021120105923|56899|1ee6296af7e15a
82
C
F 1
K 16665
O -rw-rw-r--
P xen/drivers/net/mii.c
------------------------------------------------

I0 353
/*
\
mii.c: MII interface library
\
Maintained by Jeff Garzik <jgarzik [at] pobox>
Copyright 2001,2002 Jeff Garzik
\
Various code came from myson803.c and other files by
Donald Becker. Copyright:
\
Written 1998-2002 by Donald Becker.
\
This software may be used and distributed according
to the terms of the GNU General Public License (GPL),
incorporated herein by reference. Drivers based on
or derived from this code fall under the GPL and must
retain the authorship, copyright and license notice.
This file is not a complete program and may only be
used when the entire operating system is licensed
under the GPL.
\
The author may be reached as becker [at] scyld, or C/O
Scyld Computing Corporation
410 Severn Ave., Suite 210
Annapolis MD 21403
\
\
*/
\
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/netdevice.h>
#include <linux/ethtool.h>
#include <linux/mii.h>
\
int mii_ethtool_gset(struct mii_if_info *mii, struct ethtool_cmd *ecmd)
{
struct net_device *dev = mii->dev;
u32 advert, bmcr, lpa, nego;
\
ecmd->supported =
(SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full |
SUPPORTED_Autoneg | SUPPORTED_TP | SUPPORTED_MII);
\
/* only supports twisted-pair */
ecmd->port = PORT_MII;
\
/* only supports internal transceiver */
ecmd->transceiver = XCVR_INTERNAL;
\
/* this isn't fully supported at higher layers */
ecmd->phy_address = mii->phy_id;
\
ecmd->advertising = ADVERTISED_TP | ADVERTISED_MII;
advert = mii->mdio_read(dev, mii->phy_id, MII_ADVERTISE);
if (advert & ADVERTISE_10HALF)
ecmd->advertising |= ADVERTISED_10baseT_Half;
if (advert & ADVERTISE_10FULL)
ecmd->advertising |= ADVERTISED_10baseT_Full;
if (advert & ADVERTISE_100HALF)
ecmd->advertising |= ADVERTISED_100baseT_Half;
if (advert & ADVERTISE_100FULL)
ecmd->advertising |= ADVERTISED_100baseT_Full;
\
bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR);
lpa = mii->mdio_read(dev, mii->phy_id, MII_LPA);
if (bmcr & BMCR_ANENABLE) {
ecmd->advertising |= ADVERTISED_Autoneg;
ecmd->autoneg = AUTONEG_ENABLE;

nego = mii_nway_result(advert & lpa);
if (nego == LPA_100FULL || nego == LPA_100HALF)
ecmd->speed = SPEED_100;
else
ecmd->speed = SPEED_10;
if (nego == LPA_100FULL || nego == LPA_10FULL) {
ecmd->duplex = DUPLEX_FULL;
mii->full_duplex = 1;
} else {
ecmd->duplex = DUPLEX_HALF;
mii->full_duplex = 0;
}
} else {
ecmd->autoneg = AUTONEG_DISABLE;
\
ecmd->speed = (bmcr & BMCR_SPEED100) ? SPEED_100 : SPEED_10;
ecmd->duplex = (bmcr & BMCR_FULLDPLX) ? DUPLEX_FULL : DUPLEX_HALF;
}
\
/* ignore maxtxpkt, maxrxpkt for now */
\
return 0;
}
\
int mii_ethtool_sset(struct mii_if_info *mii, struct ethtool_cmd *ecmd)
{
struct net_device *dev = mii->dev;
\
if (ecmd->speed != SPEED_10 && ecmd->speed != SPEED_100)
return -EINVAL;
if (ecmd->duplex != DUPLEX_HALF && ecmd->duplex != DUPLEX_FULL)
return -EINVAL;
if (ecmd->port != PORT_MII)
return -EINVAL;
if (ecmd->transceiver != XCVR_INTERNAL)
return -EINVAL;
if (ecmd->phy_address != mii->phy_id)
return -EINVAL;
if (ecmd->autoneg != AUTONEG_DISABLE && ecmd->autoneg != AUTONEG_ENABLE)
return -EINVAL;

/* ignore supported, maxtxpkt, maxrxpkt */

if (ecmd->autoneg == AUTONEG_ENABLE) {
u32 bmcr, advert, tmp;
\
if ((ecmd->advertising & (ADVERTISED_10baseT_Half |
ADVERTISED_10baseT_Full |
ADVERTISED_100baseT_Half |
ADVERTISED_100baseT_Full)) == 0)
return -EINVAL;
\
/* advertise only what has been requested */
advert = mii->mdio_read(dev, mii->phy_id, MII_ADVERTISE);
tmp = advert & ~(ADVERTISE_ALL | ADVERTISE_100BASE4);
if (ecmd->advertising & ADVERTISED_10baseT_Half)
tmp |= ADVERTISE_10HALF;
if (ecmd->advertising & ADVERTISED_10baseT_Full)
tmp |= ADVERTISE_10FULL;
if (ecmd->advertising & ADVERTISED_100baseT_Half)
tmp |= ADVERTISE_100HALF;
if (ecmd->advertising & ADVERTISED_100baseT_Full)
tmp |= ADVERTISE_100FULL;
if (advert != tmp) {
mii->mdio_write(dev, mii->phy_id, MII_ADVERTISE, tmp);
mii->advertising = tmp;
}

/* turn on autonegotiation, and force a renegotiate */
bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR);
bmcr |= (BMCR_ANENABLE | BMCR_ANRESTART);
mii->mdio_write(dev, mii->phy_id, MII_BMCR, bmcr);
\
mii->force_media = 0;
} else {
u32 bmcr, tmp;
\
/* turn off auto negotiation, set speed and duplexity */
bmcr = mii->mdio_read(dev, mii->phy_id, MII_BMCR);
tmp = bmcr & ~(BMCR_ANENABLE | BMCR_SPEED100 | BMCR_FULLDPLX);
if (ecmd->speed == SPEED_100)
tmp |= BMCR_SPEED100;
if (ecmd->duplex == DUPLEX_FULL) {
tmp |= BMCR_FULLDPLX;
mii->full_duplex = 1;
} else
mii->full_duplex = 0;
if (bmcr != tmp)
mii->mdio_write(dev, mii->phy_id, MII_BMCR, tmp);
\
mii->force_media = 1;
}
return 0;
}
\
int mii_link_ok (struct mii_if_info *mii)
{
/* first, a dummy read, needed to latch some MII phys */
mii->mdio_read(mii->dev, mii->phy_id, MII_BMSR);
if (mii->mdio_read(mii->dev, mii->phy_id, MII_BMSR) & BMSR_LSTATUS)
return 1;
return 0;
}
\
int mii_nway_restart (struct mii_if_info *mii)
{
int bmcr;
int r = -EINVAL;
\
/* if autoneg is off, it's an error */
bmcr = mii->mdio_read(mii->dev, mii->phy_id, MII_BMCR);
\
if (bmcr & BMCR_ANENABLE) {
bmcr |= BMCR_ANRESTART;
mii->mdio_write(mii->dev, mii->phy_id, MII_BMCR, bmcr);
r = 0;
}
\
return r;
}
\
void mii_check_link (struct mii_if_info *mii)
{
int cur_link = mii_link_ok(mii);
int prev_link = netif_carrier_ok(mii->dev);
\
if (cur_link && !prev_link)
netif_carrier_on(mii->dev);
else if (prev_link && !cur_link)
netif_carrier_off(mii->dev);
}
\
unsigned int mii_check_media (struct mii_if_info *mii,
unsigned int ok_to_print,
unsigned int init_media)
{
unsigned int old_carrier, new_carrier;
int advertise, lpa, media, duplex;
\
/* if forced media, go no further */
if (mii->force_media)
return 0; /* duplex did not change */
\
/* check current and old link status */
old_carrier = netif_carrier_ok(mii->dev) ? 1 : 0;
new_carrier = (unsigned int) mii_link_ok(mii);
\
/* if carrier state did not change, this is a "bounce",
* just exit as everything is already set correctly
*/
if ((!init_media) && (old_carrier == new_carrier))
return 0; /* duplex did not change */
\
/* no carrier, nothing much to do */
if (!new_carrier) {
netif_carrier_off(mii->dev);
if (ok_to_print)
printk(KERN_INFO "%s: link down\n", mii->dev->name);
return 0; /* duplex did not change */
}
\
/*
* we have carrier, see who's on the other end
*/
netif_carrier_on(mii->dev);
\
/* get MII advertise and LPA values */
if ((!init_media) && (mii->advertising))
advertise = mii->advertising;
else {
advertise = mii->mdio_read(mii->dev, mii->phy_id, MII_ADVERTISE);
mii->advertising = advertise;
}
lpa = mii->mdio_read(mii->dev, mii->phy_id, MII_LPA);
\
/* figure out media and duplex from advertise and LPA values */
media = mii_nway_result(lpa & advertise);
duplex = (media & ADVERTISE_FULL) ? 1 : 0;
\
if (ok_to_print)
printk(KERN_INFO "%s: link up, %sMbps, %s-duplex, lpa 0x%04X\n",
mii->dev->name,
media & (ADVERTISE_100FULL | ADVERTISE_100HALF) ?
"100" : "10",
duplex ? "full" : "half",
lpa);
\
if ((init_media) || (mii->full_duplex != duplex)) {
mii->full_duplex = duplex;
return 1; /* duplex changed */
}
\
return 0; /* duplex did not change */
}
\
int generic_mii_ioctl(struct mii_if_info *mii_if,
struct mii_ioctl_data *mii_data, int cmd,
unsigned int *duplex_chg_out)
{
int rc = 0;
unsigned int duplex_changed = 0;
\
if (duplex_chg_out)
*duplex_chg_out = 0;
\
mii_data->phy_id &= mii_if->phy_id_mask;
mii_data->reg_num &= mii_if->reg_num_mask;
\
switch(cmd) {
case SIOCDEVPRIVATE: /* binary compat, remove in 2.5 */
case SIOCGMIIPHY:
mii_data->phy_id = mii_if->phy_id;
/* fall through */
\
case SIOCDEVPRIVATE + 1:/* binary compat, remove in 2.5 */
case SIOCGMIIREG:
mii_data->val_out =
mii_if->mdio_read(mii_if->dev, mii_data->phy_id,
mii_data->reg_num);
break;
\
case SIOCDEVPRIVATE + 2:/* binary compat, remove in 2.5 */
case SIOCSMIIREG: {
u16 val = mii_data->val_in;
\
if (!capable(CAP_NET_ADMIN))
return -EPERM;
\
if (mii_data->phy_id == mii_if->phy_id) {
switch(mii_data->reg_num) {
case MII_BMCR: {
unsigned int new_duplex = 0;
if (val & (BMCR_RESET|BMCR_ANENABLE))
mii_if->force_media = 0;
else
mii_if->force_media = 1;
if (mii_if->force_media &&
(val & BMCR_FULLDPLX))
new_duplex = 1;
if (mii_if->full_duplex != new_duplex) {
duplex_changed = 1;
mii_if->full_duplex = new_duplex;
}
break;
}
case MII_ADVERTISE:
mii_if->advertising = val;
break;
default:
/* do nothing */
break;
}
}
\
mii_if->mdio_write(mii_if->dev, mii_data->phy_id,
mii_data->reg_num, val);
break;
}
\
default:
rc = -EOPNOTSUPP;
break;
}
\
if ((rc == 0) && (duplex_chg_out) && (duplex_changed))
*duplex_chg_out = 1;
\
return rc;
}
\
MODULE_AUTHOR ("Jeff Garzik <jgarzik [at] pobox>");
MODULE_DESCRIPTION ("MII hardware support library");
MODULE_LICENSE("GPL");
\
EXPORT_SYMBOL(mii_link_ok);
EXPORT_SYMBOL(mii_nway_restart);
EXPORT_SYMBOL(mii_ethtool_gset);
EXPORT_SYMBOL(mii_ethtool_sset);
EXPORT_SYMBOL(mii_check_link);
EXPORT_SYMBOL(mii_check_media);
EXPORT_SYMBOL(generic_mii_ioctl);
\

== BitKeeper/etc/logging_ok ==
smh22 [at] boulderdash|BitKeeper/etc/logging_ok|20021120120217|03192
|1a0e4366ffd1b425
iap10 [at] striker|BitKeeper/etc/logging_ok|20031001155431|12496
D 1.31 03/10/20 16:45:58-05:00 pfisher [at] xen +1 -0
B
smh22 [at] boulderdash|ChangeSet|20021120105923|56899|1ee6296af7e15a
82
C
c Logging to logging [at] openlogging accepted
K 15781
O -rw-rw-r--
P BitKeeper/etc/logging_ok
------------------------------------------------

I18 1
pfisher [at] xen

== xen/include/xeno/mii.h ==
smh22 [at] boulderdash|xen-2.4.16/include/xeno/mii.h|20021120120209|
27029|2c4ed9538370864d
kaf24 [at] scramble|xen/include/xeno/mii.h|20030709162606|27971
D 1.4 03/10/20 16:45:52-05:00 pfisher [at] xen +0 -2
B
smh22 [at] boulderdash|ChangeSet|20021120105923|56899|1ee6296af7e15a
82
C
c Enable the generic mii processing routines.
K 27076
O -rw-rw-r--
P xen/include/xeno/mii.h
------------------------------------------------

D124 1
D136 1

# Patch checksum=1da1ed8f



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Keir.Fraser at cl

Oct 22, 2003, 5:57 AM

Post #6 of 10 (182 views)
Permalink
Re: Support for mii_xxx functions? [In reply to]

> > From: Keir Fraser [mailto:Keir.Fraser [at] cl]
> > Sent: Tuesday, October 21, 2003 7:08 AM
> >
> > Yeah, none of the drivers we've ported so far rely on teh common mii
> > code. It should be easy to add in though.
>
> Thanks.
>
> How do you want outside patches? I've managed to figure out how to get
> bitkeeper to generate a changeset for adding these, which is below. Is this
> how you want them? Show they be sent to this list?

Yes patchsets to xen-devel is the best way to send updates. Do you
have a driver which uses mii yet?

-- Keir


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


pfisher at imaginationhouse

Oct 22, 2003, 6:28 AM

Post #7 of 10 (180 views)
Permalink
RE: Support for mii_xxx functions? [In reply to]

> From: Keir Fraser [mailto:Keir.Fraser [at] cl]
> Sent: Wednesday, October 22, 2003 7:58 AM
>
> Yes patchsets to xen-devel is the best way to send updates. Do you
> have a driver which uses mii yet?

Not quite yet. I'm still digging throught the skbuff handling for both
transmit and receive following the porting outline that you sent. It is a
little more complicated of course...

On the transmit side I have removed NETIF_F_SG from the supported features
as suggested but the driver also does not have real hardware checksumming.
As a result it calls skb_copy_and_csum_dev() to handle the actual movement
into the transmit buffer. This interface is not (yet) supported in Xen, and
I am still digging through to see if linux version is safe just as in the
case of the mii_functions. If not I'll create a modified version that works
for the Xen environment, since at least one other driver uses it
(via-rhine).

One the receive side the code compiles as is, but I have not yet verified if
the interface it calls -- eth_copy_and_sum() -- will work, or if I need to
changed it to somehting like this:

> vdata = map_domain_mem(skb->data);
> copy 'len' bytes to 'vdata' from NIC buffer
> unmap_domain_mem(vdata);
> skb_put(len);

as you suggested. If you (or anyone else) has any thoughts on why this (and
other) skbuff interfaces where not supported in Xen, that would help with my
digging. Remember, I'm not at all familiar with the linux kernel source so
I have to read it all to know what anything is doing... on the other hand it
is just time and code...

thanks,
paul



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Keir.Fraser at cl

Oct 24, 2003, 3:16 AM

Post #8 of 10 (180 views)
Permalink
Re: Support for mii_xxx functions? [In reply to]

> One the receive side the code compiles as is, but I have not yet verified if
> the interface it calls -- eth_copy_and_sum() -- will work, or if I need to
> changed it to somehting like this:
>
> > vdata = map_domain_mem(skb->data);
> > copy 'len' bytes to 'vdata' from NIC buffer
> > unmap_domain_mem(vdata);
> > skb_put(len);
>
> as you suggested. If you (or anyone else) has any thoughts on why this (and
> other) skbuff interfaces where not supported in Xen, that would help with my
> digging. Remember, I'm not at all familiar with the linux kernel source so
> I have to read it all to know what anything is doing... on the other hand it
> is just time and code...

You will have to change it. Any function which will access the packet
data must use map_domain_mem(), as the data pointer within the skbuff
is not usable directly by Xen.

Note that some skb_* functions already do the map_domain_mem() for you
--- any skb copying function based on skb_copy_bits() is safe.

Note also that we hope fairly soon (within the next few months) to
move all device drivers into "I/O domains" running outside of Xen in
ring 1. At that point we will hopefully be able to run Linux device
drivers unmodified, so this porting pain will no longer be necessary
:-)

-- Keir


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


pfisher at imaginationhouse

Oct 24, 2003, 8:57 AM

Post #9 of 10 (182 views)
Permalink
RE: Support for mii_xxx functions? [In reply to]

> From: xen-devel-admin [at] lists
> [mailto:xen-devel-admin [at] lists]On Behalf Of Keir Fraser
> Sent: Friday, October 24, 2003 5:16 AM
>
> You will have to change it. Any function which will access the packet
> data must use map_domain_mem(), as the data pointer within the skbuff
> is not usable directly by Xen.
>
> Note that some skb_* functions already do the map_domain_mem() for you
> --- any skb copying function based on skb_copy_bits() is safe.

I had figured that out, and just wanted to know about the (lack) of the
other interfaces.


> Note also that we hope fairly soon (within the next few months) to
> move all device drivers into "I/O domains" running outside of Xen in
> ring 1. At that point we will hopefully be able to run Linux device
> drivers unmodified, so this porting pain will no longer be necessary
> :-)

OK. Is this work being done in the BK repository? Is there a roadmap for
the work? Basically, how does one get involved in that effort? My only real
goal with porting the 8139too was to learn Xen from the inside out?


paul



-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel


Keir.Fraser at cl

Oct 25, 2003, 3:36 AM

Post #10 of 10 (180 views)
Permalink
Re: Support for mii_xxx functions? [In reply to]

> > Note also that we hope fairly soon (within the next few months) to
> > move all device drivers into "I/O domains" running outside of Xen in
> > ring 1. At that point we will hopefully be able to run Linux device
> > drivers unmodified, so this porting pain will no longer be necessary
> > :-)
>
> OK. Is this work being done in the BK repository? Is there a roadmap for
> the work? Basically, how does one get involved in that effort? My only real
> goal with porting the 8139too was to learn Xen from the inside out?

This is more an interesting point of information than something
directly useful to external users right now. It's one of the areas
we're next planning to investigate within the lab --- it will be
checked nto the BK tree as we go if possible (ie. if it doesn't
destabilise the tree too much).

However, I expect that it will be a few months at least before the
checked-in code is a viable replacement for the within-Xen drivers.

We'll keep you updated!

-- Keir


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Xen-devel mailing list
Xen-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/xen-devel

Xen devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.