[PATCH] specifically mention zero TX queues in error msg
To be consistent with subsequent error message specifically mentioning
zero RX queues, add a reference to TX queues to the error message.
Signed-off-by: Robert P. J. Day
---
diff --git a/net/core/dev.c b/net/core/dev.c
index 325fc5088370..a5d0c2244fb5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -8867,7 +8867,7 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv,
const char *name,
BUG_ON(strlen(name) >= sizeof(dev->name));
if (txqs < 1) {
- pr_err("alloc_netdev: Unable to allocate device with zero
queues\n");
+ pr_err("alloc_netdev: Unable to allocate device with zero TX
queues\n");
return NULL;
}
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
any reason for "!!netif_carrier_ok" and "!!netif_dormant" in net-sysfs.c?
another pedantic oddity -- is there a reason for these two double
negations in net/core/net-sysfs.c?
static ssize_t carrier_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct net_device *netdev = to_net_dev(dev);
if (netif_running(netdev))
return sprintf(buf, fmt_dec, !!netif_carrier_ok(netdev));
...
static ssize_t dormant_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct net_device *netdev = to_net_dev(dev);
if (netif_running(netdev))
return sprintf(buf, fmt_dec, !!netif_dormant(netdev));
i understand the normal rationale for !! in assuring a final boolean
value of precisely either 0 or 1 (here for the sake of printing), but
given that those two routines are declared with a return value of
"bool" in netdevice.h, i don't see any way that they can return
anything *other* than 0 or 1. i realize it can't possibly hurt, but
whenever i see this construct, i normally assume there's a *reason*
for it, but i can't see what it's doing in those two places.
rday
--
========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
Re: confusing comment, explanation of @IFF_RUNNING in if.h
On Mon, 27 Aug 2018, Oliver Hartkopp wrote: > "released upon production" means usually: Oh, we put that driver in > a tar-ball on a CD that's shipped with the product and which will > get no further visibility nor (security) maintenance. > > Robert, please tell your manager that creating a driver is no rocket > science and also brings no "costumer differentiation" which needs to > be covered under NDA. > > Posting drivers and bring it into mainline Linux heavily increases > the quality due to the review process and all the people that are > willing to help you to get better. At the end your driver gets > long-term maintenance and other people can benefit from it - as your > boss is getting benefit from using Linux right now. > > When something is "released upon production" it will not be in a > quality that it could go into the kernel - and no one will have the > time/money/ambition to spend effort on it then. You have just > produced one of the numerous dead out-of-tree drivers. That would be > just sad. i make these arguments on a regular basis with all of my clients but, as a contractor, i have little influence. but i will continue to make them. rday -- ==== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?
On Sun, 26 Aug 2018, Stephen Hemminger wrote:
> On Sun, 26 Aug 2018 11:14:33 -0400 (EDT)
> "Robert P. J. Day" wrote:
>
> > apologies for the constant pleas for assistance, but i think i'm
> > zeroing in on the problem that started all this. recap: custom
> > FPGA-based linux box with multiple ports, where the current symptom is
> > that there is no userspace notification when someone simply unplugs
> > one of the ports ("ifconfig" shows that interface still RUNNING).
> >
> > as i read it, an active ethernet interface should be both UP (the
> > administrative state) and RUNNING (the RFC 2863-defined operational
> > state). if i unplug, i've verified on a standard net port on my laptop
> > that the interface is still UP, but no longer RUNNING, which makes
> > perfect sense. i plug back in, interface starts RUNNING again. so
> > where's the problem?
> >
> > i can see that whether ifconfig shows an interface RUNNING is
> > defined in net/core/dev.c:
> >
> > unsigned int dev_get_flags(const struct net_device *dev)
> > {
> > unsigned int flags;
> >
> > flags = (dev->flags & ~(IFF_PROMISC |
> > IFF_ALLMULTI |
> > IFF_RUNNING |
> > IFF_LOWER_UP |
> > IFF_DORMANT)) |
> > (dev->gflags & (IFF_PROMISC |
> > IFF_ALLMULTI));
> >
> > if (netif_running(dev)) {
> > if (netif_oper_up(dev))
> > flags |= IFF_RUNNING; < THERE
> > if (netif_carrier_ok(dev))
> > flags |= IFF_LOWER_UP;
> > if (netif_dormant(dev))
> > flags |= IFF_DORMANT;
> > }
> >
> > return flags;
> > }
> >
> > where netif_oper_up() is defined as:
> >
> > static inline bool netif_oper_up(const struct net_device *dev)
> > {
> > return (dev->operstate == IF_OPER_UP ||
> > dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
> > }
> >
> > so i am simply assuming that the underlying problem is that,
> > somewhere down below, the unplugging of a port is somehow not setting
> > dev->operstate to its proper value of IF_OPER_DOWN.
> >
> > that would clearly explain everything, and i'm about to dig even
> > further to see where the event of unplugging a port *should* be
> > recognized, but does this sound like a reasonable diagnosis? there
> > have been other problems with the programming of the FPGA, so it would
> > surprise absolutely no one to learn that this aspect was
> > misprogrammed.
> >
> > rday
> >
>
> There is no reason drivers should ever muck with flags directly.
> You probably are looking for netif_detach
i assume you mean netif_device_detach; i'll check into that.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
Re: confusing comment, explanation of @IFF_RUNNING in if.h
On Sun, 26 Aug 2018, Stephen Hemminger wrote: > On Sun, 26 Aug 2018 15:20:24 -0400 (EDT) > "Robert P. J. Day" wrote: > > > On Sun, 26 Aug 2018, Andrew Lunn wrote: > > > > > > i ask since, in my testing, when the interface should have been > > > > up, the attribute file "operstate" for that interface showed > > > > "unknown", and i wondered how worried i should be about that. > > > > > > Hi Robert > > > > > > You should probably post the driver for review. A well written > > > driver should not even need to care about any of this. phylib and > > > the netdev driver code does all the work. It only gets interesting > > > when you don't have a PHY, e.g. a stacked device, like bonding, or a > > > virtual device like tun/tap. > > > > i wish, but i'm on contract, and proprietary, and NDA and all that. > > so i am reduced to crawling through the code, trying to figure out > > what is misconfigured that is causing all this grief. > > > > rday > > > > So you expect FOSS developers to help you with proprietary licensed > driver. Good Luck with that. sorry, i'm sure this will all be released upon production, just not while it's in the midst of development. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: confusing comment, explanation of @IFF_RUNNING in if.h
On Sun, 26 Aug 2018, Andrew Lunn wrote: > On Sun, Aug 26, 2018 at 03:20:24PM -0400, Robert P. J. Day wrote: > > On Sun, 26 Aug 2018, Andrew Lunn wrote: > > > > > > i ask since, in my testing, when the interface should have been > > > > up, the attribute file "operstate" for that interface showed > > > > "unknown", and i wondered how worried i should be about that. > > > > > > Hi Robert > > > > > > You should probably post the driver for review. A well written > > > driver should not even need to care about any of this. phylib and > > > the netdev driver code does all the work. It only gets interesting > > > when you don't have a PHY, e.g. a stacked device, like bonding, or a > > > virtual device like tun/tap. > > > > i wish, but i'm on contract, and proprietary, and NDA and all that. > > so i am reduced to crawling through the code, trying to figure out > > what is misconfigured that is causing all this grief. > > I would say proprietary and NDA is causing you all this grief. > > There is also the point that if you are not going to contribute the > code to mainline, why should we help you? > > The code is GPL after all, so you can post it. i'm confident that it will *eventually* be GPLed (i can't imagine there is any other outcome), but for now, there's nothing i can do. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?
On Sun, 26 Aug 2018, Andrew Lunn wrote:
> On Sun, Aug 26, 2018 at 11:14:33AM -0400, Robert P. J. Day wrote:
> >
> > apologies for the constant pleas for assistance, but i think i'm
> > zeroing in on the problem that started all this. recap: custom
> > FPGA-based linux box with multiple ports, where the current
> > symptom is that there is no userspace notification when someone
> > simply unplugs one of the ports ("ifconfig" shows that interface
> > still RUNNING).
>
> What are you using for a PHY? Are you using phylib or phylink? I
> strongly suggest you do, and then you don't need to care about any
> of this.
i'm not sure i'm even allowed to talk about that given the NDA --
i'll just muddle through following the code until i figure out what is
failing to notify userspace. le *sigh*.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
Re: confusing comment, explanation of @IFF_RUNNING in if.h
On Sun, 26 Aug 2018, Andrew Lunn wrote: > > i ask since, in my testing, when the interface should have been > > up, the attribute file "operstate" for that interface showed > > "unknown", and i wondered how worried i should be about that. > > Hi Robert > > You should probably post the driver for review. A well written > driver should not even need to care about any of this. phylib and > the netdev driver code does all the work. It only gets interesting > when you don't have a PHY, e.g. a stacked device, like bonding, or a > virtual device like tun/tap. i wish, but i'm on contract, and proprietary, and NDA and all that. so i am reduced to crawling through the code, trying to figure out what is misconfigured that is causing all this grief. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
followup: what's responsible for setting netdev->operstate to IF_OPER_DOWN?
apologies for the constant pleas for assistance, but i think i'm
zeroing in on the problem that started all this. recap: custom
FPGA-based linux box with multiple ports, where the current symptom is
that there is no userspace notification when someone simply unplugs
one of the ports ("ifconfig" shows that interface still RUNNING).
as i read it, an active ethernet interface should be both UP (the
administrative state) and RUNNING (the RFC 2863-defined operational
state). if i unplug, i've verified on a standard net port on my laptop
that the interface is still UP, but no longer RUNNING, which makes
perfect sense. i plug back in, interface starts RUNNING again. so
where's the problem?
i can see that whether ifconfig shows an interface RUNNING is
defined in net/core/dev.c:
unsigned int dev_get_flags(const struct net_device *dev)
{
unsigned int flags;
flags = (dev->flags & ~(IFF_PROMISC |
IFF_ALLMULTI |
IFF_RUNNING |
IFF_LOWER_UP |
IFF_DORMANT)) |
(dev->gflags & (IFF_PROMISC |
IFF_ALLMULTI));
if (netif_running(dev)) {
if (netif_oper_up(dev))
flags |= IFF_RUNNING; < THERE
if (netif_carrier_ok(dev))
flags |= IFF_LOWER_UP;
if (netif_dormant(dev))
flags |= IFF_DORMANT;
}
return flags;
}
where netif_oper_up() is defined as:
static inline bool netif_oper_up(const struct net_device *dev)
{
return (dev->operstate == IF_OPER_UP ||
dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
}
so i am simply assuming that the underlying problem is that,
somewhere down below, the unplugging of a port is somehow not setting
dev->operstate to its proper value of IF_OPER_DOWN.
that would clearly explain everything, and i'm about to dig even
further to see where the event of unplugging a port *should* be
recognized, but does this sound like a reasonable diagnosis? there
have been other problems with the programming of the FPGA, so it would
surprise absolutely no one to learn that this aspect was
misprogrammed.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
confusing comment, explanation of @IFF_RUNNING in if.h
more annoying pedantry ... from include/uapi/linux/if.h:
* @IFF_RUNNING: interface RFC2863 OPER_UP. Volatile.
however, both the code in net/core/dev.c:
/**
* netif_oper_up - test if device is operational
* @dev: network device
*
* Check if carrier is operational
*/
static inline bool netif_oper_up(const struct net_device *dev)
{
return (dev->operstate == IF_OPER_UP ||
dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
}
and the explanation in operstates.txt:
ifinfomsg::if_flags & IFF_RUNNING:
Interface is in RFC2863 operational state UP or UNKNOWN.
suggests IFF_RUNNING represents *either* of the operational states UP
or UNKNOWN, not just UP as the comment in if.h claims. is this
misleading? or is this a deliberate explanation somehow taking into
account that the UNKNOWN state is for backward compatibility (whatever
that means)?
i ask since, in my testing, when the interface should have been up,
the attribute file "operstate" for that interface showed "unknown",
and i wondered how worried i should be about that.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
want to clarify understanding of IFF_{UP,RUNNING} and "volatile"
if you can tolerate another question on the topic, based on an
earlier post by stephen hemminger, i wrote a userspace program that
opened a netlink socket to track the status changes for an interface,
and i just want to clarify how the up/running status of an interface
is determined, as i think i'm finally getting the hang of this.
as stephen mentioned, ifconfig gets its info (ultimately) from
dev_get_flags() in net/core/dev.c:
unsigned int dev_get_flags(const struct net_device *dev)
{
unsigned int flags;
flags = (dev->flags & ~(IFF_PROMISC |
IFF_ALLMULTI |
IFF_RUNNING |
IFF_LOWER_UP |
IFF_DORMANT)) |
(dev->gflags & (IFF_PROMISC |
IFF_ALLMULTI));
if (netif_running(dev)) {
if (netif_oper_up(dev))
flags |= IFF_RUNNING;
if (netif_carrier_ok(dev))
flags |= IFF_LOWER_UP;
if (netif_dormant(dev))
flags |= IFF_DORMANT;
}
return flags;
}
i don't care (yet) about IFF_{PROMISC,ALLMULTI} so i'll ignore those.
so, as i read it, whether or not the interface is *administratively*
up is read directly from the IFF_UP bit in dev->flags. so far, so
good. on the other hand, all of IFF_{RUNNING,LOWER_UP,DORMANT} are not
read from dev->flags, but instead are "volatile" and are determined
via those function calls.
so i'm guessing that shows the difference between the
administrative and the operational states of an interface -- the
administrative state of "up" is something selected by, say, ifconfig,
and can therefore be stored in the flags field, while the operational
state (running) is volatile and must be determined at each query.
this suggests that volatile flags such as running or dormant have no
value if read from dev->flags -- the code above doesn't even look at
them in that location and instead invokes the respective functions. do
i have that about right, before i crawl further down this rabbit hole?
it's all starting to make sense.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
[PATCH] correct comments for flags, priv flags in netdevice.h
Correct the references for both flags and priv flags since they both
refer to the incorrect file which contains their explanations.
Signed-off-by: Robert P. J. Day
---
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index ca5ab98053c8..f01f3473bb91 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1586,9 +1586,9 @@ enum netdev_priv_flags {
* @header_ops:Includes callbacks for creating,parsing,caching,etc
* of Layer 2 headers.
*
- * @flags: Interface flags (a la BSD)
- * @priv_flags:Like 'flags' but invisible to userspace,
- * see if.h for the definitions
+ * @flags: Interface flags (a la BSD), see if.h for definitions
+ * @priv_flags:Like 'flags' but invisible to userspace, see
+ * definitions earlier in this file
* @gflags:Global flags ( kept as legacy )
* @padded:How much padding added by alloc_netdev()
* @operstate: RFC2863 operstate
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
Re: is "volatile" the cause of ifconfig flags not matching sysfs flags?
On Wed, 22 Aug 2018, Stephen Hemminger wrote: > On Wed, 22 Aug 2018 18:32:36 -0400 (EDT) > "Robert P. J. Day" wrote: > > > almost certainly another dumb question, but i was poking around the > > sysfs, particularly /sys/class/net//*, to familiarize myself > > with what i can glean (or set) re interfaces under /sys, and i noticed > > "flags", but what i get there doesn't match what i get by running > > ifconfig. > > > > specifically, if i list the flags for my wireless interface under > > /sys: > > > > $ cat flags > > 0x1003 > > $ > > > > but with ifconfig: > > > > $ ifconfig wlp2s0 > > wlp2s0: flags=4163 mtu 1500 > > > > > > do those two "flags" values represent the same set of flags? and > > does the obvious difference have to do with some of those flags being > > "volatile" as dewscribed in include/uapi/linux/if.h? or am i just > > totally misreading this? > > > > rday > > > > sysfs reports netdevice->if_flags where as ifconfig is getting hex > value from SIOCGIFFLAGS which does: > dev_get_flags(dev) > > The value in sysfs is more intended for internal debugging, where > all the normal userspace API's return a more limited set of > historical values. so the history aside, those values ultimately represent the same flags? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
is "volatile" the cause of ifconfig flags not matching sysfs flags?
almost certainly another dumb question, but i was poking around the sysfs, particularly /sys/class/net//*, to familiarize myself with what i can glean (or set) re interfaces under /sys, and i noticed "flags", but what i get there doesn't match what i get by running ifconfig. specifically, if i list the flags for my wireless interface under /sys: $ cat flags 0x1003 $ but with ifconfig: $ ifconfig wlp2s0 wlp2s0: flags=4163 mtu 1500 do those two "flags" values represent the same set of flags? and does the obvious difference have to do with some of those flags being "volatile" as dewscribed in include/uapi/linux/if.h? or am i just totally misreading this? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: how to (cross)connect two (physical) eth ports for ping test?
On Sat, 18 Aug 2018, Willy Tarreau wrote: > On Sat, Aug 18, 2018 at 09:10:25PM +0200, Andrew Lunn wrote: > > On Sat, Aug 18, 2018 at 01:39:50PM -0400, Robert P. J. Day wrote: > > > > > > (i'm sure this has been explained many times before, so a link > > > covering this will almost certainly do just fine.) > > > > > > i want to loop one physical ethernet port into another, and just > > > ping the daylights from one to the other for stress testing. my fedora > > > laptop doesn't actually have two unused ethernet ports, so i just want > > > to emulate this by slapping a couple startech USB/net adapters into > > > two empty USB ports, setting this up, then doing it all over again > > > monday morning on the actual target system, which does have multiple > > > ethernet ports. > > > > > > so if someone can point me to the recipe, that would be great and > > > you can stop reading. > > > > > > as far as my tentative solution goes, i assume i need to put at > > > least one of the physical ports in a network namespace via "ip netns", > > > then ping from the netns to the root namespace. or, going one step > > > further, perhaps putting both interfaces into two new namespaces, and > > > setting up forwarding. > > > > Namespaces is a good solution. Something like this should work: > > > > ip netns add namespace1 > > ip netns add namespace2 > > > > ip link set eth1 netns namespace1 > > ip link set eth2 netns namespace2 > > > > ip netns exec namespace1 \ > > ip addr add 10.42.42.42/24 dev eth1 > > > > ip netns exec namespace1 \ > > ip link set eth1 up > > > > ip netns exec namespace2 \ > > ip addr add 10.42.42.24/24 dev eth2 > > > > ip netns exec namespace2 \ > > ip link set eth2 up > > > > ip netns exec namespace1 \ > > ping 10.42.42.24 > > > > You might also want to consider iperf3 for stress testing, depending > > on the sort of stress you need. > > FWIW I have a setup somewhere involving ip rule + ip route which > achieves the same without involving namespaces. It's a bit hackish > but sometimes convenient. I can dig if someone is interested. sure, i'm interested ... always educational to see different solutions. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
how to (cross)connect two (physical) eth ports for ping test?
(i'm sure this has been explained many times before, so a link covering this will almost certainly do just fine.) i want to loop one physical ethernet port into another, and just ping the daylights from one to the other for stress testing. my fedora laptop doesn't actually have two unused ethernet ports, so i just want to emulate this by slapping a couple startech USB/net adapters into two empty USB ports, setting this up, then doing it all over again monday morning on the actual target system, which does have multiple ethernet ports. so if someone can point me to the recipe, that would be great and you can stop reading. as far as my tentative solution goes, i assume i need to put at least one of the physical ports in a network namespace via "ip netns", then ping from the netns to the root namespace. or, going one step further, perhaps putting both interfaces into two new namespaces, and setting up forwarding. anyway, a recipe for this would be just ducky. thank you kindly. rday -- ======== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
drivers/net/ethernet/atheros/atlx/atl2.c uses dead MODULE_PARM
just noticed this in that ATLX source file: #ifndef module_param_array /* Module Parameters are always initialized to -1, so that the driver * can tell the difference between no user specified value or the * user asking for the default value. * The true default values are loaded in when atl2_check_options is called. * * This is a GCC extension to ANSI C. * See the item "Labeled Elements in Initializers" in the section * "Extensions to the C Language Family" of the GCC documentation. */ #define ATL2_PARAM(X, desc) \ static const int X[ATL2_MAX_NIC + 1] = ATL2_PARAM_INIT; \ MODULE_PARM(X, "1-" __MODULE_STRING(ATL2_MAX_NIC) "i"); \ ... snip ... the macro "MODULE_PARM" isn't even defined anymore, so that usage of MODULE_PARM is not going to work well if the C preprocessor ever gets ahold of it. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: consequences of setting net_device_ops ndo_change_carrier()?
On Sun, 5 Aug 2018, Andrew Lunn wrote: > On Sat, Aug 04, 2018 at 07:06:58AM -0400, Robert P. J. Day wrote: > > > > i'll try to keep this (relatively) short as there may be a > > simple answer to this, or it could just be a stupid question -- > > sort of related to previous question (thank you, florian). > > > > currently messing with networking device involving FPGA and some > > quad-port transceivers, and noticed that, when one unplugs or > > plugs a device into one of the ports, there is no change in the > > contents of the corresponding sysfs files > > /sys/class/net//carrier (or operstate, for that matter, > > which might be related to this as well). > > Hi Robert > > As other have pointed out, ndo_change_carrier is not what you want > here. i think i see that now ... based on the really adamant comment in netdevice.h: "Devices that determine carrier state from physical hardware properties (eg network cables) or protocol-dependent mechanisms (eg USB_CDC_NOTIFY_NETWORK_CONNECTION) should NOT implement this function." the impression i got was that implementing that routine for a physical device would actually cause problems, but it seems only that it would be a strange thing to do, but wouldn't necessarily cause problems if you chose not to take advantage of it. which brings me back to one of my original questions -- why *would* someone implement it? as some sort of debugging feature? in any event, i'm convinced that that's not where the problem lies. > You should have a PHY device of some sort. Either a traditional > copper PHY, or an SFP module. There should be a driver for this PHY. > This could be one of those in drivers/net/phy. Or it could be > firmware running, running on a little microcontroller inside your > FPGA? in my case, it's properly in drivers/net/phy, so at least that part is normal. back to investigating ... rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: consequences of setting net_device_ops ndo_change_carrier()?
On Sat, 4 Aug 2018, Stephen Hemminger wrote: ... big snip ... > ndo_change_carrier is not the droid your looking for. > > The purpose of ndo_change_carrier was for testing network devices > (ie dummy), and also for cases like network tunnels where the > sofrware carrier state may be controlled by a userspace daemon. > > Real network devices call netif_carrier_on and netif_carrier_off > when they notice change in carrier state in hardware. Typically, > this is when an interrupt happens. i had actually come to just that conclusion, as i was digging through the code, and couldn't immediately see why setting ndo_change_carrier() would cause a problem. in fact, to help my admittedly painful newbie-level debugging, i started a wiki page to track this (i document *everything* on wiki pages): http://crashcourse.ca/dokuwiki/doku.php?id=ndo_change_carrier so i am reduced to concluding that the drivers in question are simply not calling correctly the very routines you mention. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
for newbies, it would be useful to document values of netdev_state_t
i'm sure this is second nature for the experts here, but in
netdevice.h:
/* These flag bits are private to the generic network queueing
* layer; they may not be explicitly referenced by any other
* code.
*/
enum netdev_state_t {
__LINK_STATE_START,
__LINK_STATE_PRESENT,
__LINK_STATE_NOCARRIER,
__LINK_STATE_LINKWATCH_PENDING,
__LINK_STATE_DORMANT,
};
it would be handy to have a short explanation of what each state
represents, perhaps what combinations are possible and how one moves
from one state to another.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
Re: consequences of setting net_device_ops ndo_change_carrier()?
On Sat, 4 Aug 2018, Jiri Pirko wrote:
> Sat, Aug 04, 2018 at 01:06:58PM CEST, rpj...@crashcourse.ca wrote:
> >
> > i'll try to keep this (relatively) short as there may be a simple
> >answer to this, or it could just be a stupid question -- sort of
> >related to previous question (thank you, florian).
> >
> > currently messing with networking device involving FPGA and some
> >quad-port transceivers, and noticed that, when one unplugs or plugs
> >a device into one of the ports, there is no change in the contents
> >of the corresponding sysfs files /sys/class/net//carrier
> >(or operstate, for that matter, which might be related to this as
> >well). doing this with a "regular" port on my linux laptop
> >certainly confirmed that the carrier file would switch between 0
> >and 1, and operstate would switch between up and down, so i know
> >what behaviour i was *expecting* if things were ostensibly working
> >properly.
> >
> > long story short, i pawed through the driver code only to stumble
>
> What driver? Has to be out of tree as I don't see any in the
> existing kernel using .ndo_change_carrier (aside of team and dummy)
yes, currently proprietary and in-house under development, so i have
to be a little vague about certain details.
> >over this in the ethernet driver for the device:
> >
> > static const struct net_device_ops netdev_netdev_ops = {
> > ... snip ...
> >.ndo_change_carrier = netdev_change_carrier,
> > ... snip ...
> > };
> >
> >and
> >
> > static int
> > netdev_change_carrier(struct net_device *dev, bool new_carrier)
> > {
> >if (new_carrier)
> >netif_carrier_on(dev);
> >else
> >netif_carrier_off(dev);
> >return 0;
> > }
> >
> >as i mentioned before, i am really new to kernel networking code,
> >so i did a quick search and found this in netdevice.h:
> >
> >* int (*ndo_change_carrier)(struct net_device *dev, bool new_carrier);
> > * Called to change device carrier. Soft-devices (like dummy, team, etc)
> > * which do not represent real hardware may define this to allow their
> > * userspace components to manage their virtual carrier state. Devices
> > * that determine carrier state from physical hardware properties (eg
> > * network cables) or protocol-dependent mechanisms (eg
> > * USB_CDC_NOTIFY_NETWORK_CONNECTION) should NOT implement this
> > function.
> > *
> >
> >although i still don't fully understand the purpose of that field,
> >it makes me *very* nervous to read that that routine is for "soft"
> >devices, and ***not*** for devices that attempt to determine
> >carrier state from physical hardware properties. i searched the
> >kernel code base for other drivers that set that field, and found
> >only what is mentioned in that comment -- dummy.c, of_dummy_mac.c
> >and team.c.
> >
> > the testers for this unit are complaining that they are somehow
> >not being notified when they plug and unplug devices from the ports
> >-- is this why? what would be the purpose of assigning a routine to
> >that field? as i read it (and i could be wrong), my impression is
> >that you can have the driver *either* determine the carrier state
> >from physical properties, *or* allow userspace control, but not
> >both, is that correct?
>
> Correct. Your device is physical device, it knows how to get the
> state of the carrier itself.
that's what i *thought*, good to have confirmation.
> >
> > i'm about to ask the original authors why they did the above, but
>
> I guess that the reason is that they had no clue what they are doing
> :)
given that i've been immersed in networking code for only a few
days, i was not about to draw any conclusion like that. :-) i'm going
to continue perusing the code just to feel more confident about my
eventual conclusion, but it would seem that there is no compelling
reason for setting ndo_change_carrier() for actual physical devices,
and that is quite possibly the cause of the weird behaviour the
testers are seeing. thanks muchly.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
consequences of setting net_device_ops ndo_change_carrier()?
i'll try to keep this (relatively) short as there may be a simple
answer to this, or it could just be a stupid question -- sort of
related to previous question (thank you, florian).
currently messing with networking device involving FPGA and some
quad-port transceivers, and noticed that, when one unplugs or plugs a
device into one of the ports, there is no change in the contents of
the corresponding sysfs files /sys/class/net//carrier (or
operstate, for that matter, which might be related to this as well).
doing this with a "regular" port on my linux laptop certainly
confirmed that the carrier file would switch between 0 and 1, and
operstate would switch between up and down, so i know what behaviour i
was *expecting* if things were ostensibly working properly.
long story short, i pawed through the driver code only to stumble
over this in the ethernet driver for the device:
static const struct net_device_ops netdev_netdev_ops = {
... snip ...
.ndo_change_carrier = netdev_change_carrier,
... snip ...
};
and
static int
netdev_change_carrier(struct net_device *dev, bool new_carrier)
{
if (new_carrier)
netif_carrier_on(dev);
else
netif_carrier_off(dev);
return 0;
}
as i mentioned before, i am really new to kernel networking code, so i
did a quick search and found this in netdevice.h:
* int (*ndo_change_carrier)(struct net_device *dev, bool new_carrier);
* Called to change device carrier. Soft-devices (like dummy, team, etc)
* which do not represent real hardware may define this to allow their
* userspace components to manage their virtual carrier state. Devices
* that determine carrier state from physical hardware properties (eg
* network cables) or protocol-dependent mechanisms (eg
* USB_CDC_NOTIFY_NETWORK_CONNECTION) should NOT implement this function.
*
although i still don't fully understand the purpose of that field, it
makes me *very* nervous to read that that routine is for "soft"
devices, and ***not*** for devices that attempt to determine carrier
state from physical hardware properties. i searched the kernel code
base for other drivers that set that field, and found only what is
mentioned in that comment -- dummy.c, of_dummy_mac.c and team.c.
the testers for this unit are complaining that they are somehow not
being notified when they plug and unplug devices from the ports -- is
this why? what would be the purpose of assigning a routine to that
field? as i read it (and i could be wrong), my impression is that you
can have the driver *either* determine the carrier state from physical
properties, *or* allow userspace control, but not both, is that
correct?
i'm about to ask the original authors why they did the above, but
i'd like to feel that it's not a stupid question if there's something
really clever going on here. is this just a development debugging
feature that would normally be removed at production? or what?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
Re: how PHY driver is notified that cable is unplugged? (possibly related to IFF_RUNNING flag)
On Wed, 1 Aug 2018, Florian Fainelli wrote:
> On 08/01/2018 05:58 AM, rpj...@crashcourse.ca wrote:
> >
> > (warning that i have a few questions that are probably trivial
> > until i get up to speed with networking code.)
> >
> > a colleague asked for advice about the following -- apparently a
> > new PHY driver works properly when being brought up with "ifconfig
> > up", part of that process apparently setting the
> > IFF_RUNNING net_device flags bit. so far, so good.
> >
> > now, when the cable is physically unplugged, the claim is that
> > there is no obvious status change for that port, accompanied by
> > the suggestion that it is that IFF_RUNNING flag bit that is not
> > being unset.
> >
> > asking a more general question, where can i read up on the
> > proper protocol for a driver being notified of, and properly
> > handling, physical disconnection on that port? and, of course, the
> > cable being plugged back in.
>
> The basic mechanism used by the PHY library is to read the standard
> Basic Mode Status Register and check the Link status bit to
> determine what the state of the link is set. This event can be
> triggered either through polling, or the use of an interrupt that
> the PHY is generating.
>
> Once the link state is determined, because the PHY device is
> "connected" to a network device, the PHY library can call
> netif_carrier_{on,off} against the network device attached to the
> PHY and that propagates through the networking stack and sets the
> appropriate bits, including IFF_RUNNING.
yup, that agrees with the code i was perusing, thanks for
clarifying. more questions coming shortly, hopefully tougher.
rday
[PATCH] phy: Move "device present" masks earlier in file
Move the "device present" mask bits up immediately after the MMD device definitions, since it makes no sense to have them further down in the file. This is purely a cosmetic change for readability. Signed-off-by: Robert P. J. Day --- since the *only* thing that actually uses the MMD definitions in that file are the mask bits, it only makes sense to put them next to each other -- there should be no functional change. diff --git a/include/uapi/linux/mdio.h b/include/uapi/linux/mdio.h index d435b00d64ad..4897f17b0639 100644 --- a/include/uapi/linux/mdio.h +++ b/include/uapi/linux/mdio.h @@ -27,6 +27,17 @@ #define MDIO_MMD_VEND1 30 /* Vendor specific 1 */ #define MDIO_MMD_VEND2 31 /* Vendor specific 2 */ +/* Device present mask bits. */ +#define MDIO_DEVS_PRESENT(devad) (1 << (devad)) +#define MDIO_DEVS_PMAPMD MDIO_DEVS_PRESENT(MDIO_MMD_PMAPMD) +#define MDIO_DEVS_WIS MDIO_DEVS_PRESENT(MDIO_MMD_WIS) +#define MDIO_DEVS_PCS MDIO_DEVS_PRESENT(MDIO_MMD_PCS) +#define MDIO_DEVS_PHYXS MDIO_DEVS_PRESENT(MDIO_MMD_PHYXS) +#define MDIO_DEVS_DTEXS MDIO_DEVS_PRESENT(MDIO_MMD_DTEXS) +#define MDIO_DEVS_TC MDIO_DEVS_PRESENT(MDIO_MMD_TC) +#define MDIO_DEVS_AN MDIO_DEVS_PRESENT(MDIO_MMD_AN) +#define MDIO_DEVS_C22EXT MDIO_DEVS_PRESENT(MDIO_MMD_C22EXT) + /* Generic MDIO registers. */ #define MDIO_CTRL1 MII_BMCR #define MDIO_STAT1 MII_BMSR @@ -113,17 +124,6 @@ #define MDIO_PMA_SPEED_10 0x0040 /* 10M capable */ #define MDIO_PCS_SPEED_10P2B 0x0002 /* 10PASS-TS/2BASE-TL capable */ -/* Device present registers. */ -#define MDIO_DEVS_PRESENT(devad) (1 << (devad)) -#define MDIO_DEVS_PMAPMD MDIO_DEVS_PRESENT(MDIO_MMD_PMAPMD) -#define MDIO_DEVS_WIS MDIO_DEVS_PRESENT(MDIO_MMD_WIS) -#define MDIO_DEVS_PCS MDIO_DEVS_PRESENT(MDIO_MMD_PCS) -#define MDIO_DEVS_PHYXS MDIO_DEVS_PRESENT(MDIO_MMD_PHYXS) -#define MDIO_DEVS_DTEXS MDIO_DEVS_PRESENT(MDIO_MMD_DTEXS) -#define MDIO_DEVS_TC MDIO_DEVS_PRESENT(MDIO_MMD_TC) -#define MDIO_DEVS_AN MDIO_DEVS_PRESENT(MDIO_MMD_AN) -#define MDIO_DEVS_C22EXT MDIO_DEVS_PRESENT(MDIO_MMD_C22EXT) - /* Control register 2. */ #define MDIO_PMA_CTRL2_TYPE0x000f /* PMA/PMD type selection */ #define MDIO_PMA_CTRL2_10GBCX4 0x /* 10GBASE-CX4 type */ -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [PATCH 1/4] xfrm_hash: kmalloc + memset conversion to kzalloc
On Mon, 26 Nov 2007, Joonwoo Park wrote:
xfrm_hash: kmalloc + memset conversion to kzalloc
Signed-off-by: Joonwoo Park [EMAIL PROTECTED]
Thanks.
Joonwoo
---
diff --git a/net/xfrm/xfrm_hash.c b/net/xfrm/xfrm_hash.c
index 55ab579..37795bd 100644
--- a/net/xfrm/xfrm_hash.c
+++ b/net/xfrm/xfrm_hash.c
@@ -17,16 +17,17 @@ struct hlist_head *xfrm_hash_alloc(unsigned int sz)
struct hlist_head *n;
if (sz = PAGE_SIZE)
- n = kmalloc(sz, GFP_KERNEL);
- else if (hashdist)
- n = __vmalloc(sz, GFP_KERNEL, PAGE_KERNEL);
- else
- n = (struct hlist_head *)
- __get_free_pages(GFP_KERNEL | __GFP_NOWARN,
- get_order(sz));
-
- if (n)
- memset(n, 0, sz);
+ n = kzalloc(sz, GFP_KERNEL);
+ else {
+ if (hashdist)
i believe the more common standard for the above is:
else if (hashdist) {
to reduce the level of overall indentation, no?
rday
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] atm/ambassador: kmalloc + memset conversion to kzalloc
On Mon, 26 Nov 2007, Joonwoo Park wrote:
atm/ambassador: kmalloc + memset conversion to kzalloc
Signed-off-by: Joonwoo Park [EMAIL PROTECTED]
Thanks.
Joonwoo
---
diff --git a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c
index b34b382..4f99ba3 100644
--- a/drivers/atm/ambassador.c
+++ b/drivers/atm/ambassador.c
@@ -2163,7 +2163,6 @@ static int __devinit amb_init (amb_dev * dev)
static void setup_dev(amb_dev *dev, struct pci_dev *pci_dev)
{
unsigned char pool;
- memset (dev, 0, sizeof(amb_dev));
// set up known dev items straight away
dev-pci_dev = pci_dev;
@@ -2253,7 +2252,7 @@ static int __devinit amb_probe(struct pci_dev *pci_dev,
const struct pci_device_
goto out_disable;
}
- dev = kmalloc (sizeof(amb_dev), GFP_KERNEL);
+ dev = kzalloc(sizeof(amb_dev), GFP_KERNEL);
if (!dev) {
PRINTK (KERN_ERR, out of memory!);
err = -ENOMEM;
---
i'm not sure the above is a safe thing to do, as you're zeroing that
area, then making a function call and assuming, upon entry to the
function call, that the caller has done the right thing. i don't see
how you can count on that, depending on who else might want to call
that routine and whether they get sloppy about it. unless you're
prepared to guarantee that there will never be another call to
setup_dev() from elsewhere.
rday
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] atm/ambassador: kmalloc + memset conversion to kzalloc
On Mon, 26 Nov 2007, Joonwoo Park wrote: 2007/11/26, Robert P. J. Day [EMAIL PROTECTED]: i'm not sure the above is a safe thing to do, as you're zeroing that area, then making a function call and assuming, upon entry to the function call, that the caller has done the right thing. i don't see how you can count on that, depending on who else might want to call that routine and whether they get sloppy about it. unless you're prepared to guarantee that there will never be another call to setup_dev() from elsewhere. Thanks for your response. But setup_dev is static function and only amb_init calls it. i realized that. but all you can say is that only amb_init() calls setup_dev() *currently*. when you're not looking, someone else might (for whatever reason) call setup_dev() from elsewhere, and *that* call might not zero that memory area. IMHO, the only safe transforms of kmalloc+memset - kzalloc are those in which the flow of control is unmistakable and invariant. splitting that across a function call seems like a dangerous thing to do. (except, of course, in the case, where the kzalloc() is added inside the function -- then all callers are entitled to simplify *their* code. but that's different.) in any event, i just thought i'd point it out. if you're absolutely sure there will never be another call to setup_dev() from somewhere else, then, yes, it's safe. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] atm/ambassador: kmalloc + memset conversion to kzalloc
On Mon, 26 Nov 2007, Joonwoo Park wrote: 2007/11/26, Robert P. J. Day [EMAIL PROTECTED]: i realized that. but all you can say is that only amb_init() calls setup_dev() *currently*. when you're not looking, someone else might (for whatever reason) call setup_dev() from elsewhere, and *that* call might not zero that memory area. IMHO, the only safe transforms of kmalloc+memset - kzalloc are those in which the flow of control is unmistakable and invariant. splitting that across a function call seems like a dangerous thing to do. (except, of course, in the case, where the kzalloc() is added inside the function -- then all callers are entitled to simplify *their* code. but that's different.) in any event, i just thought i'd point it out. if you're absolutely sure there will never be another call to setup_dev() from somewhere else, then, yes, it's safe. I understood your opinions. and partially agree with you. But isn't it a unfounded fear? i don't know, i just thought i'd mention it. if no one thinks it's an issue, it's certainly fine with me. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] NET: Officially deprecate ether= in favour of netdev=.
Given that it's well established that the ether= kernel parameter is
deprecated in favour of the newer netdev=, might as well make it
official.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
Documentation/feature-removal-schedule.txt |6 ++
Documentation/kernel-parameters.txt|2 ++
Documentation/m68k/kernel-options.txt |6 +-
Documentation/networking/3c505.txt |3 ++-
drivers/net/3c59x.c|3 ++-
drivers/net/atp.c |2 +-
drivers/net/es3210.c |5 +
net/ethernet/eth.c | 13 -
8 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/feature-removal-schedule.txt
index 20c4c8b..5c041fd 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -333,3 +333,9 @@ Why:This driver has been marked obsolete for many
years.
Who: Stephen Hemminger [EMAIL PROTECTED]
---
+
+What: ether= boot-time option
+When: September 2008
+Why: Obsoleted by newer and equivalent netdev= option.
+Who: Robert P. J. Day [EMAIL PROTECTED] or whoever else wants to
+ do it when the time comes.
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 33121d6..8b2676b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -623,6 +623,8 @@ and is between 256 and 4096 characters. It is defined in
the file
ether= [HW,NET] Ethernet cards parameters
This option is obsoleted by the netdev= option, which
has equivalent usage. See its documentation for details.
+ ether= has been scheduled for removal -- see the file
+ Documentation/feature-removal-schedule.txt.
eurwdt= [HW,WDT] Eurotech CPU-1220/1410 onboard watchdog.
Format: io[,irq]
diff --git a/Documentation/m68k/kernel-options.txt
b/Documentation/m68k/kernel-options.txt
index 248589e..9aab529 100644
--- a/Documentation/m68k/kernel-options.txt
+++ b/Documentation/m68k/kernel-options.txt
@@ -218,7 +218,7 @@ drive (with root=).
3) General Device Options (Amiga and Atari)
===
-3.1) ether=
+3.1) ether= [Equivalently, netdev=]
---
Syntax: ether=[irq[,base_addr[,mem_start[,mem_end,dev-name
@@ -233,6 +233,10 @@ Linux/m68k (ariadne, a2065, hydra) don't use them because
Zorro boards
are really Plug-'n-Play, so the ether= option is useless altogether
for Linux/m68k.
+ NOTE: The ether= option is deprecated in favour of the newer
+netdev= option. ether= has been scheduled for removal -- see the
+file Documentation/feature-removal-schedule.txt for details.
+
3.2) hd=
diff --git a/Documentation/networking/3c505.txt
b/Documentation/networking/3c505.txt
index 72f38b1..0498775 100644
--- a/Documentation/networking/3c505.txt
+++ b/Documentation/networking/3c505.txt
@@ -5,7 +5,8 @@ The default DMA channel is 6; this is _not_ autoprobed, so you
must
make sure you configure it correctly. If loading the driver as a
module, you can do this with modprobe 3c505 dma=n. If the driver is
linked statically into the kernel, you must either use an ether=
-statement on the command line, or change the definition of ELP_DMA in 3c505.h.
+(or equivalent and preferred netdev=) statement on the command line,
+or change the definition of ELP_DMA in 3c505.h.
The driver will warn you if it has to fall back on the compiled in
default DMA channel.
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 6f8e7d4..8268962 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -1046,7 +1046,8 @@ static int __devinit vortex_probe1(struct device *gendev,
if (dev-mem_start) {
/*
* The 'options' param is passed in as the third arg to the
-* LILO 'ether=' argument for non-modular use
+* LILO 'ether=' (or equivalent and preferred 'netdev=')
argument
+* for non-modular use
*/
option = dev-mem_start;
}
diff --git a/drivers/net/atp.c b/drivers/net/atp.c
index 62f09e5..1cf5c17 100644
--- a/drivers/net/atp.c
+++ b/drivers/net/atp.c
@@ -114,7 +114,7 @@ static int xcvr[NUM_UNITS]; /* The
data transfer mode. */
The data transfer mode is stored in the 'dev-if_port' field. Its
default
value is '4'. It may be overridden at boot-time using the third
parameter
- to the ether=... initialization.
+ to the ether=... (or equivalent and preferred netdev=...)
initialization.
The header file atp.h provides inline functions that encapsulate the
register and data access methods. These functions are hand
Re: [PATCH] NET: Officially deprecate ether= in favour of netdev=.
On Wed, 14 Nov 2007, Stephen Hemminger wrote: ... relevant patch snipped ... Why bother. I would removing it? i tried that once, and a number of people promptly had kittens over the thought of simply yanking a working kernel parameter without giving everyone at least a year's notice. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PCMCIA NET: Use roundup_pow_of_two() macro instead of grotesque loop.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- i'm just going to assume that loop is rounding up to the next power of two, right? diff --git a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c index db6a97d..07eae16 100644 --- a/drivers/net/pcmcia/pcnet_cs.c +++ b/drivers/net/pcmcia/pcnet_cs.c @@ -38,6 +38,7 @@ #include linux/delay.h #include linux/ethtool.h #include linux/netdevice.h +#include linux/log2.h #include ../8390.h #include pcmcia/cs_types.h @@ -1484,8 +1485,7 @@ static int setup_shmem_window(struct pcmcia_device *link, int start_pg, window_size = 32 * 1024; /* Make sure it's a power of two. */ -while ((window_size (window_size - 1)) != 0) - window_size += window_size ~(window_size - 1); +window_size = roundup_pow_of_two(window_size); /* Allocate a memory window */ req.Attributes = WIN_DATA_WIDTH_16|WIN_MEMORY_TYPE_CM|WIN_ENABLE; -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
net/bluetooth/hci_sock.c:352: error: storage size of 'ctv' isn't known
latest git pull, make allyesconfig on i386: ... CC net/bluetooth/hci_sock.o net/bluetooth/hci_sock.c: In function âhci_sock_cmsgâ: net/bluetooth/hci_sock.c:352: error: storage size of âctvâ isnât known net/bluetooth/hci_sock.c:352: warning: unused variable âctvâ make[2]: *** [net/bluetooth/hci_sock.o] Error 1 make[1]: *** [net/bluetooth] Error 2 make: *** [net] Error 2 rday p.s. dumb question -- what locale should i be using to get those quotes to not make such a mess of my screen? thanks. -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca
dscc4.c tests for #ifndef MODULE even though it must be modular
from drivers/net/wan/dscc4.c:
=
#ifndef MODULE
static int __init dscc4_setup(char *str)
{
int *args[] = { debug, quartz, NULL }, **p = args;
while (*p (get_option(str, *p) == 2))
p++;
return 1;
}
__setup(dscc4.setup=, dscc4_setup);
#endif
=
but from drivers/net/wan/Kconfig:
...
config DSCC4
tristate Etinc PCISYNC serial board support
depends on HDLC PCI m
...
if i read this correctly, doesn't the depends on of m mean that
that Kconfig selection can be *at most* modular, so that that
preprocessor conditional can never be satisfied? a quick test under
make menuconfig seems to confirm that.
besides, the kernel parm being defined in that call to __setup()
really violates the spirit of defining kernel parms. :-)
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
possibly dead CONFIG variables, perhaps fixable for 2.6.23?
/arm/configs/pnx4008_defconfig:264:CONFIG_IP_VS_PROTO_TCP=y net/ipv4/ipvs/ip_vs_ctl.c:1881:#ifdef CONFIG_IP_VS_PROTO_TCP net/ipv4/ipvs/ip_vs_ctl.c:2161:#ifdef CONFIG_IP_VS_PROTO_TCP net/ipv4/ipvs/ip_vs_core.c:54:#ifdef CONFIG_IP_VS_PROTO_TCP net/ipv4/ipvs/ip_vs_proto.c:207:#ifdef CONFIG_IP_VS_PROTO_TCP net/ipv4/ipvs/Makefile:7:ip_vs_proto-objs-$(CONFIG_IP_VS_PROTO_TCP) += ip_vs_proto_tcp.o net/ipv4/ipvs/Kconfig:62:config IP_VS_PROTO_TCP net/ipv4/ipvs/Kconfig:212:depends on IP_VS_PROTO_TCP == IP_VS_PROTO_UDP == arch/mips/configs/ip22_defconfig:303:CONFIG_IP_VS_PROTO_UDP=y arch/mips/configs/malta_defconfig:337:CONFIG_IP_VS_PROTO_UDP=y arch/mips/configs/atlas_defconfig:342:CONFIG_IP_VS_PROTO_UDP=y arch/mips/defconfig:303:CONFIG_IP_VS_PROTO_UDP=y arch/arm/configs/ixp4xx_defconfig:271:# CONFIG_IP_VS_PROTO_UDP is not set arch/arm/configs/pnx4008_defconfig:265:CONFIG_IP_VS_PROTO_UDP=y net/ipv4/ipvs/ip_vs_ctl.c:1893:#ifdef CONFIG_IP_VS_PROTO_UDP net/ipv4/ipvs/ip_vs_ctl.c:2167:#ifdef CONFIG_IP_VS_PROTO_UDP net/ipv4/ipvs/ip_vs_proto.c:210:#ifdef CONFIG_IP_VS_PROTO_UDP net/ipv4/ipvs/Makefile:8:ip_vs_proto-objs-$(CONFIG_IP_VS_PROTO_UDP) += ip_vs_proto_udp.o net/ipv4/ipvs/Kconfig:68:config IP_VS_PROTO_UDP == IP_VS_SH_TAB_BITS == net/ipv4/ipvs/ip_vs_sh.c:55:#ifndef CONFIG_IP_VS_SH_TAB_BITS net/ipv4/ipvs/ip_vs_sh.c:56:#define CONFIG_IP_VS_SH_TAB_BITS8 net/ipv4/ipvs/ip_vs_sh.c:58:#define IP_VS_SH_TAB_BITS CONFIG_IP_VS_SH_TAB_BITS net/ipv4/ipvs/ip_vs_sh.c:58:#define IP_VS_SH_TAB_BITS CONFIG_IP_VS_SH_TAB_BITS net/ipv4/ipvs/ip_vs_sh.c:59:#define IP_VS_SH_TAB_SIZE (1 IP_VS_SH_TAB_BITS) == IRDA_DYNAMIC_WINDOW == include/net/irda/irlap.h:41:#define CONFIG_IRDA_DYNAMIC_WINDOW 1 include/net/irda/irlap.h:181:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW include/net/irda/irlap.h:184:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */ net/irda/irlap.c:1026:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW net/irda/irlap.c:1035:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */ net/irda/irlap.c:1158:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW net/irda/irlap.c:1162:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */ net/irda/qos.c:99:#ifndef CONFIG_IRDA_DYNAMIC_WINDOW net/irda/qos.c:385:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW net/irda/qos.c:409:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */ net/irda/qos.c:730:#ifndef CONFIG_IRDA_DYNAMIC_WINDOW net/irda/irlap_frame.c:832:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW net/irda/irlap_frame.c:842:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */ net/irda/irlap_frame.c:924:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW net/irda/irlap_frame.c:927:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */ net/irda/irlap_event.c:994:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW net/irda/irlap_event.c:1056:#else /* CONFIG_IRDA_DYNAMIC_WINDOW */ net/irda/irlap_event.c:1060:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */ net/irda/irlap_event.c:1101:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW net/irda/irlap_event.c:1104:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */ net/irda/irlap_event.c:1745:#ifdef CONFIG_IRDA_DYNAMIC_WINDOW net/irda/irlap_event.c:1793:#else /* CONFIG_IRDA_DYNAMIC_WINDOW */ net/irda/irlap_event.c:1797:#endif /* CONFIG_IRDA_DYNAMIC_WINDOW */ == IRLAN_SEND_GRATUITOUS_ARP == net/irda/irlan/irlan_common.c:62:#undef CONFIG_IRLAN_SEND_GRATUITOUS_ARP net/irda/irlan/irlan_common.c:398:#ifdef CONFIG_IRLAN_SEND_GRATUITOUS_ARP == WANPIPE_MULTPPP == net/wanrouter/wanmain.c:568:#ifdef CONFIG_WANPIPE_MULTPPP net/wanrouter/wanmain.c:589:#ifdef CONFIG_WANPIPE_MULTPPP net/wanrouter/wanmain.c:662:#ifdef CONFIG_WANPIPE_MULTPPP rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] NET: Officially deprecate ether= and schedule for removal.
Officially deprecate the boot-time ether= option in favour of
netdev=, update the documentation accordingly in various places, and
schedule removal for September of 2008.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
i realize that some people have strong feelings about removing
options because of backward compatibility, so i'm easy regarding this
submission. i just had the patch lying around so i figured i'd send
it on and someone higher up the food chain can make the call one way
or the other.
compile and boot-time tested on i386 with make defconfig.
Documentation/feature-removal-schedule.txt |6 ++
Documentation/kernel-parameters.txt|2 ++
Documentation/m68k/kernel-options.txt |6 +-
Documentation/networking/3c505.txt |3 ++-
drivers/net/3c59x.c|3 ++-
drivers/net/atp.c |2 +-
drivers/net/es3210.c |5 +
net/ethernet/eth.c | 13 -
8 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/feature-removal-schedule.txt
index b9a3fdc..656a71a 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -298,3 +298,9 @@ Why:All mthca hardware also supports MSI-X, which
provides
Who: Roland Dreier [EMAIL PROTECTED]
---
+
+What: ether= boot-time option
+When: September 2008
+Why: Obsoleted by newer and equivalent netdev= option.
+Who: Robert P. J. Day [EMAIL PROTECTED] or whoever else wants to
+ do it when the time comes.
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index b41cde3..47a9cf1 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -621,6 +621,8 @@ and is between 256 and 4096 characters. It is defined in
the file
ether= [HW,NET] Ethernet cards parameters
This option is obsoleted by the netdev= option, which
has equivalent usage. See its documentation for details.
+ ether= has been scheduled for removal -- see the file
+ Documentation/feature-removal-schedule.txt.
eurwdt= [HW,WDT] Eurotech CPU-1220/1410 onboard watchdog.
Format: io[,irq]
diff --git a/Documentation/m68k/kernel-options.txt
b/Documentation/m68k/kernel-options.txt
index 59108ce..3ec32d2 100644
--- a/Documentation/m68k/kernel-options.txt
+++ b/Documentation/m68k/kernel-options.txt
@@ -218,7 +218,7 @@ drive (with root=).
3) General Device Options (Amiga and Atari)
===
-3.1) ether=
+3.1) ether= [Equivalently, netdev=]
---
Syntax: ether=[irq[,base_addr[,mem_start[,mem_end,dev-name
@@ -233,6 +233,10 @@ Linux/m68k (ariadne, a2065, hydra) don't use them because
Zorro boards
are really Plug-'n-Play, so the ether= option is useless altogether
for Linux/m68k.
+ NOTE: The ether= option is deprecated in favour of the newer
+netdev= option. ether= has been scheduled for removal -- see the
+file Documentation/feature-removal-schedule.txt for details.
+
3.2) hd=
diff --git a/Documentation/networking/3c505.txt
b/Documentation/networking/3c505.txt
index b9d5b72..d79d31d 100644
--- a/Documentation/networking/3c505.txt
+++ b/Documentation/networking/3c505.txt
@@ -5,7 +5,8 @@ The default DMA channel is 6; this is _not_ autoprobed, so you
must
make sure you configure it correctly. If loading the driver as a
module, you can do this with modprobe 3c505 dma=n. If the driver is
linked statically into the kernel, you must either use an ether=
-statement on the command line, or change the definition of ELP_DMA in 3c505.h.
+(or equivalent and preferred netdev=) statement on the command line,
+or change the definition of ELP_DMA in 3c505.h.
The driver will warn you if it has to fall back on the compiled in
default DMA channel.
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index a8c0f43..0ae3561 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -1043,7 +1043,8 @@ static int __devinit vortex_probe1(struct device *gendev,
if (dev-mem_start) {
/*
* The 'options' param is passed in as the third arg to the
-* LILO 'ether=' argument for non-modular use
+* LILO 'ether=' (or equivalent and preferred 'netdev=')
argument
+* for non-modular use
*/
option = dev-mem_start;
}
diff --git a/drivers/net/atp.c b/drivers/net/atp.c
index 82d78ff..d9cd8bb 100644
--- a/drivers/net/atp.c
+++ b/drivers/net/atp.c
@@ -114,7 +114,7 @@ static int xcvr[NUM_UNITS]; /* The
data transfer mode. */
The data transfer mode is stored in the 'dev-if_port
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Fri, 31 Aug 2007, Randy Dunlap wrote:
On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:
What about something like this? I'm not sure if the addition to
sym_init is desirable... I also had to prefix _ to the name for
now otherwise it conflicts badly with the current symbols. It
probably should stop depends on _BROKEN etc. too.
Hi Simon,
(sorry for the delay)
I like this patch very much... I just can't get it to build (on
2.6.23-rc4).
i got a patch from simon a while back, and it failed with
shift/reduce conflicts. is that what you're seeing?
while (1) {
printf(%*s%s , indent - 1, , menu-prompt-text);
+ switch (sym-maturity) {
+ case M_EXPERIMENTAL:
+ printf((EXPERIMENTAL) );
+ break;
+ case M_DEPRECATED:
+ printf((DEPRECATED) );
+ break;
+ case M_OBSOLETE:
+ printf((OBSOLETE) );
+ break;
+ case M_BROKEN:
+ printf((BROKEN) );
+ break;
+ default:
+ break;
+ }
if (sym-name)
printf((%s) , sym-name);
type = sym_get_type(sym);
for now, simon, why not just reduce this to supporting only DEPRECATED
and OBSOLETE so that it can be at least tested as proof of concept?
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Sat, 1 Sep 2007, Sam Ravnborg wrote:
On Sat, Sep 01, 2007 at 06:44:06AM -0400, Robert P. J. Day wrote:
while (1) {
printf(%*s%s , indent - 1, , menu-prompt-text);
+ switch (sym-maturity) {
+ case M_EXPERIMENTAL:
+ printf((EXPERIMENTAL) );
+ break;
+ case M_DEPRECATED:
+ printf((DEPRECATED) );
+ break;
+ case M_OBSOLETE:
+ printf((OBSOLETE) );
+ break;
+ case M_BROKEN:
+ printf((BROKEN) );
+ break;
+ default:
+ break;
+ }
if (sym-name)
printf((%s) , sym-name);
type = sym_get_type(sym);
for now, simon, why not just reduce this to supporting only DEPRECATED
and OBSOLETE so that it can be at least tested as proof of concept?
The principle with letting a dependency add text to the promts are good.
But the implementation done by Simon with a language extension is not good.
A simple and better approach would be to use the newly added option
support for this and let the backend generate the promtps.
I have not yet tried to cook up a patch for it, but it should be
quite generaic and doable.
config EXPERIMENTAL
option appendprompt= (EXPERIMENTAL)
config DEPRECATED
option appendprompt= (DEPRECATED)
but this is deviating from the basic principle that these things are
not regular Kconfig config settings -- they are a new beast
entirely, and need a new infrastructure to support them.
put another way, they are not a normal kernel feature to be selected
or deselected. they are, rather, *attributes* that can be *applied*
to kernel features, in the same way as is done with bool or
string. making these things regular config directives defeats the
whole purpose.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Fri, 31 Aug 2007, Randy Dunlap wrote: On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote: On 19/07/07 17:19, Robert P. J. Day wrote: On Thu, 19 Jul 2007, Randy Dunlap wrote: I think that Stefan means a patch to the kconfig source code, not the the Kconfig files. Good luck. I'd still like to see it. yes, i understand what he wanted now. as a first step (that theoretically shouldn't change any behaviour), i'd patch the Kconfig structure to add a new attribute (maturity) which would be allowed to be set to *exactly one* of a pre-defined set of values (say, OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING). and that's it, nothing more. don't try to do anything with any of that just yet, just add the infrastructure to support the (optional) association of a maturity level with a config option. that's step one. What about something like this? I'm not sure if the addition to sym_init is desirable... I also had to prefix _ to the name for now otherwise it conflicts badly with the current symbols. It probably should stop depends on _BROKEN etc. too. i'm sure i'm going to get shouted down here, but i really disagree with BROKEN being considered a maturity level. IMHO, things like EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for what i think are obvious reasons. something like BROKEN, though, has *nothing* to do with maturity. a feature can be any of those maturity levels, and simultaneously be BROKEN. i consider BROKEN to be what i call a status, and different status levels might be the default of normal, or KIND_OF_FLAKY or TOTALLY_BORKED -- that's where BROKEN would fit in. *please* don't start mixing these different attributes. it's just going to make an irreversible mess of things. leave BROKEN out of this for the time being. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Fri, 31 Aug 2007, Jeff Garzik wrote: Robert P. J. Day wrote: i'm sure i'm going to get shouted down here, but i really disagree with BROKEN being considered a maturity level. IMHO, things like EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for what i think are obvious reasons. something like BROKEN, though, has *nothing* to do with maturity. a feature can be any of those maturity levels, and simultaneously be BROKEN. i consider BROKEN to be what i call a status, and different status levels might be the default of normal, or KIND_OF_FLAKY or TOTALLY_BORKED -- that's where BROKEN would fit in. BROKEN is definitely a maturity level. no. it's not. end of discussion. you're wrong. the concept of maturity level reflects where in the life cycle some feature is. it will typically start as bleeding edge or experimental or something like that, eventually stabilize to be normal (which would be the obvious default), after which, when its value starts to run out and it begins showing its age, it becomes deprecated and eventually obsolete it's a natural and obvious progression. on the other hand, a feature can be broken at *any* point in that life cycle -- that's why it is absolutely *not* a maturity level. please don't fight with me on this, jeff. you're simply wrong. In contrast, OBSOLETE and DEPRECATED reflect high-level status not code quality/maturity. you have this so backwards, i can't begin to think how to explain it to you. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Fri, 31 Aug 2007, Randy Dunlap wrote: What I like about the patch is that it associates some kconfig symbol with prompt strings, so that we don't have to edit (EXPERIMENTAL) all the darn time (e.g.). I'd be quite happy with calling it status rather than maturity, and with being able to use multiple of the status tags at one time, such as config FOO depends on BAR status OBSOLETE BROKEN g ... i already made my point in my earlier post. i'd really, really like it if *this* attribute remained as maturity. an entirely *separate* attribute could be defined as a feature status, which would be entirely orthogonal to maturity level, so that the above would be written as maturity OBSOLETE status BROKEN there's a reason for this -- any feature should have exactly *one* value for any attribute. that is, in terms of maturity, a feature could be EXPERIMENTAL *or* DEPRECATED *or* OBSOLETE. it ***can't*** be more than one, as in both DEPRECATED *and* OBSOLETE. to allow that flexibility is to descend into absurdity. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Fri, 31 Aug 2007, Jeff Garzik wrote: 'deprecrated' and 'obsolete' are matters of discussed opinion, describing the utility of the code in question. 'broken' describes the state of the code itself. Clear difference. precisely. thank you for making my point for me. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
is traffic shaper genuinely obsolete?
given drivers/net/Kconfig: ... config SHAPER tristate Traffic Shaper (OBSOLETE) ... is that traffic shaper really obsolete to the point where it can be tossed. i have a patch ... rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is traffic shaper genuinely obsolete?
On Tue, 28 Aug 2007, David Miller wrote: From: Robert P. J. Day [EMAIL PROTECTED] Date: Tue, 28 Aug 2007 05:54:57 -0400 (EDT) given drivers/net/Kconfig: ... config SHAPER tristate Traffic Shaper (OBSOLETE) ... is that traffic shaper really obsolete to the point where it can be tossed. i have a patch ... It's already in the scheduled-to-be-deleted list in the net-2.6.24 tree. Stephen Hemminger posted that patch a few days ago. whoops, ok. rday - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KJ] replacing kmalloc with kzalloc in drivers/net/sb1250-mac.c
On Mon, 13 Aug 2007, Surya Prabhakar N wrote: Hi, Replacing kmalloc with kzalloc and cleaning up memset in drivers/net/sb1250-mac.c Signed-off-by: Surya Prabhakar [EMAIL PROTECTED] --- diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c index e7fdcf1..2dca5a7 100644 --- a/drivers/net/sb1250-mac.c +++ b/drivers/net/sb1250-mac.c @@ -760,7 +760,7 @@ static void sbdma_initctx(sbmacdma_t *d, d-sbdma_dscrtable_unaligned = d-sbdma_dscrtable = (sbdmadscr_t *) ^^^ - kmalloc((d-sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL); + kzalloc((d-sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL); i'm fairly sure you can drop all of those superfluous casts when calling one of those memory allocation routines. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IP_VS should depend on EXPERIMENTAL ?
as a short followup to my previous post, at the *very least*, a cleanup that could be done now is to find all entries which have an actual dependency on EXPERIMENTAL but don't advertise themselves as such: ... config MA600_DONGLE tristate Mobile Action MA600 dongle depends on IRTTY_SIR DONGLE IRDA EXPERIMENTAL ... and determine which of those should have the dependency on EXPERIMENTAL removed. no, don't go adding (EXPERIMENTAL) to the prompt -- just deal with *only* those for which the dependency is clearly out of date and not relevant anymore, and delete it. that would be, at least, a place to start. and, yes, there's piles of potential (net/ipv4/Kconfig): config TCP_CONG_HSTCP tristate High Speed TCP depends on EXPERIMENTAL ... config TCP_CONG_HYBLA tristate TCP-Hybla congestion control algorithm depends on EXPERIMENTAL ... config TCP_CONG_VEGAS tristate TCP Vegas depends on EXPERIMENTAL ... ... etc etc ... rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IP_VS should depend on EXPERIMENTAL ?
On Fri, 20 Jul 2007, Gabriel C wrote: Robert P. J. Day wrote: On Fri, 20 Jul 2007, Gabriel C wrote: Hi, IP_VS has : .. tristate IP virtual server support (EXPERIMENTAL) .. but it does not depend on EXPERIMENTAL. Signed-off-by: Gabriel Craciunescu [EMAIL PROTECTED] --- net/ipv4/ipvs/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv4/ipvs/Kconfig b/net/ipv4/ipvs/Kconfig index 09d0c3f..3c594ec 100644 --- a/net/ipv4/ipvs/Kconfig +++ b/net/ipv4/ipvs/Kconfig @@ -3,7 +3,7 @@ # menuconfig IP_VS tristate IP virtual server support (EXPERIMENTAL) - depends on NETFILTER + depends on NETFILTER EXPERIMENTAL ---help--- IP Virtual Server support will let you build a high-performance virtual server based on cluster of two or more real servers. This there's maturity-level inconsistency like that in a few places, like when stuff is tagged as EXPERIMENTAL, but labelled as OBSOLETE: [ a lot examples ] I know that and there are a lot more things depending on 'EXPERIMENTAL' and not having EXPERIMENTAL visible all over the tree but that patch I've made for the _net_ part got NACK'ed while your maturity idea and I rm -rf'ed all the other. This one has a missing depends on EXPERIMENTAL while saying it is. So *could* we please stop this maturity stuff for now ? I don't see it in .23 nor .24 if at all. this has *nothing* to do with the aforementioned maturity levels. i understand entirely the inconsistency above. what i'm suggesting is that it might very well be more appropriate to *drop the dependency* rather than munge the prompt to add the qualifier. i think it's safe to say that there's *piles* of stuff in the Kconfig files that is still saddled with an EXPERIMENTAL dependency that's been around for years and has stabilized nicely. i mean, seriously, is IP virtual server support still experimental in any way? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IP_VS should depend on EXPERIMENTAL ?
On Fri, 20 Jul 2007, Gabriel C wrote: Hi, IP_VS has : .. tristate IP virtual server support (EXPERIMENTAL) .. but it does not depend on EXPERIMENTAL. Signed-off-by: Gabriel Craciunescu [EMAIL PROTECTED] --- net/ipv4/ipvs/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv4/ipvs/Kconfig b/net/ipv4/ipvs/Kconfig index 09d0c3f..3c594ec 100644 --- a/net/ipv4/ipvs/Kconfig +++ b/net/ipv4/ipvs/Kconfig @@ -3,7 +3,7 @@ # menuconfig IP_VS tristate IP virtual server support (EXPERIMENTAL) - depends on NETFILTER + depends on NETFILTER EXPERIMENTAL ---help--- IP Virtual Server support will let you build a high-performance virtual server based on cluster of two or more real servers. This there's maturity-level inconsistency like that in a few places, like when stuff is tagged as EXPERIMENTAL, but labelled as OBSOLETE: ./net/ipv6/netfilter/Kconfig-config IP6_NF_QUEUE ./net/ipv6/netfilter/Kconfig- tristate IP6 Userspace queueing via NETLINK (OBSOLETE) ./net/ipv6/netfilter/Kconfig: depends on INET IPV6 NETFILTER EXPERIMENTAL and other examples: ./net/ipv6/netfilter/Kconfig-config IP6_NF_IPTABLES ./net/ipv6/netfilter/Kconfig- tristate IP6 tables support (required for filtering) ./net/ipv6/netfilter/Kconfig: depends on INET IPV6 EXPERIMENTAL ... ./net/ipv6/Kconfig-config IPV6_MULTIPLE_TABLES ./net/ipv6/Kconfig- bool IPv6: Multiple Routing Tables ./net/ipv6/Kconfig: depends on IPV6 EXPERIMENTAL ... ./net/ipv4/Kconfig-config TCP_CONG_HSTCP ./net/ipv4/Kconfig- tristate High Speed TCP ./net/ipv4/Kconfig: depends on EXPERIMENTAL ... ./net/rxrpc/Kconfig-config AF_RXRPC ./net/rxrpc/Kconfig-tristate RxRPC session sockets ./net/rxrpc/Kconfig:depends on INET EXPERIMENTAL ... it might be a better investment in time to look through the Kconfig files, and decide which entries currently marked as EXPERIMENTAL really *shouldn't* be, and remove those silly dependencies. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IP_VS should depend on EXPERIMENTAL ?
On Fri, 20 Jul 2007, Gabriel C wrote: Robert P. J. Day wrote: this has *nothing* to do with the aforementioned maturity levels. i understand entirely the inconsistency above. what i'm suggesting is that it might very well be more appropriate to *drop the dependency* rather than munge the prompt to add the qualifier. This is a thing the author/maintainer/subsystem maintainer should and need do. They know when something is not EXPERIMENTAL anymore. agreed (sort of). all i'm saying (and after this, i'll shut the heck up about it) is that, if you find a Kconfig entry of the form: config FUBAR prompt whatever depends on ... EXPERIMENTAL and you want to make that selection consistent, you have two possibilities: 1) add (EXPERIMENTAL) to the prompt to match the dependency, or 2) drop the dependency on EXPERIMENTAL to match the prompt i contend that, *for now*, it's a better investment in time to find entries like that that are *clearly* not experimental any more, and drop the dependency. not only will that make it consistent, but it's unlikely that you'll ever have to *revert* that decision. OTOH, it's quite possible that, after you add the prompt suffix of (EXPERIMENTAL) for consistency, the feature maintainer might come by tomorrow and say something like, nah, that feature's been around for years, it's as stable as it gets, and will undo the patch you just made, wasting your time and effort. lastly, i'm not convinced that it's *only* the feature maintainer that can make that decision. surely, there's enough clever people here who can look at any given feature and say, yeah, i've been using that for years, it's rock solid, it's stupid to keep that dependent on EXPERIMENTAL. all i'm saying is, if you want to put some time in here, it's better invested in *removing* what are clearly ridiculous dependencies on EXPERIMENTAL, rather than *adding* even more of that labelling to the tree. rday p.s. even if a given Kconfig entry *is* consistent, as in: config SNAFU bool ... (EXPERIMENTAL) depends on ... EXPERIMENTAL ... it's clear that there's a pile of *that* stuff for which all references to EXPERIMENTAL can be dropped. all in all, given the possible cleanup here, i'm thinking that going in and *adding* more EXPERIMENTAL clutter to the Kconfig files is going in exactly the wrong direction. -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Thu, 19 Jul 2007, Adrian Bunk wrote: ... I would consider it more ugly to special case this and that in the kconfig code when plain dependencies already offer exactly the same functionality... well, this is the *third* time i've proposed adding this kind of feature so, at this point, i've really given up caring about it. if someone wants to do this, have at it. i have better things to do than to keep suggesting it and getting nowhere with it. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Thu, 19 Jul 2007, Stefan Richter wrote: Robert P. J. Day wrote: On Thu, 19 Jul 2007, Adrian Bunk wrote: ... I would consider it more ugly to special case this and that in the kconfig code when plain dependencies already offer exactly the same functionality... well, this is the *third* time i've proposed adding this kind of feature so, at this point, i've really given up caring about it. if someone wants to do this, have at it. i have better things to do than to keep suggesting it and getting nowhere with it. For better or worse, it can often be observed that feature requests don't set anything in motion until a first patch is sent. Even a patch that is far from perfect can get things going really quickly. (If the requested feature makes sense to other people.) i *did* submit a preliminary patch once upon a time, and it (predictably) went nowhere. so, if someone else wants to pick this up and do something with it, you have my blessing. life's too short to keep wasting time on this. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Thu, 19 Jul 2007, Randy Dunlap wrote: On Thu, 19 Jul 2007 05:25:30 -0400 (EDT) Robert P. J. Day wrote: On Thu, 19 Jul 2007, Stefan Richter wrote: Robert P. J. Day wrote: On Thu, 19 Jul 2007, Adrian Bunk wrote: ... I would consider it more ugly to special case this and that in the kconfig code when plain dependencies already offer exactly the same functionality... well, this is the *third* time i've proposed adding this kind of feature so, at this point, i've really given up caring about it. if someone wants to do this, have at it. i have better things to do than to keep suggesting it and getting nowhere with it. For better or worse, it can often be observed that feature requests don't set anything in motion until a first patch is sent. Even a patch that is far from perfect can get things going really quickly. (If the requested feature makes sense to other people.) i *did* submit a preliminary patch once upon a time, and it (predictably) went nowhere. so, if someone else wants to pick this up and do something with it, you have my blessing. life's too short to keep wasting time on this. I think that Stefan means a patch to the kconfig source code, not the the Kconfig files. Good luck. I'd still like to see it. yes, i understand what he wanted now. as a first step (that theoretically shouldn't change any behaviour), i'd patch the Kconfig structure to add a new attribute (maturity) which would be allowed to be set to *exactly one* of a pre-defined set of values (say, OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING). and that's it, nothing more. don't try to do anything with any of that just yet, just add the infrastructure to support the (optional) association of a maturity level with a config option. that's step one. rday p.s. and, yes, i really meant it when i said that an option could have one, and *only* one, maturity level. if you start arguing this point, i swear, i will hunt you down and give you *such* a wedgie. -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Thu, 19 Jul 2007, Simon Arlott wrote: On 19/07/07 17:19, Robert P. J. Day wrote: On Thu, 19 Jul 2007, Randy Dunlap wrote: I think that Stefan means a patch to the kconfig source code, not the the Kconfig files. Good luck. I'd still like to see it. yes, i understand what he wanted now. as a first step (that theoretically shouldn't change any behaviour), i'd patch the Kconfig structure to add a new attribute (maturity) which would be allowed to be set to *exactly one* of a pre-defined set of values (say, OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING). and that's it, nothing more. don't try to do anything with any of that just yet, just add the infrastructure to support the (optional) association of a maturity level with a config option. that's step one. What about something like this? I'm not sure if the addition to sym_init is desirable... I also had to prefix _ to the name for now otherwise it conflicts badly with the current symbols. It probably should stop depends on _BROKEN etc. too. --- diff --git a/init/Kconfig b/init/Kconfig diff --git a/net/Kconfig b/net/Kconfig index cdba08c..5e2f4db 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -6,6 +6,7 @@ menu Networking config NET bool Networking support + maturity _BROKEN just as a bit of a digression, BROKEN is not what i would call a maturity level, and i would explicitly *not* allow that as a possible maturity because that just makes a mess of the design. i specifically wanted to define a maturity level so that any feature could be categorized as belonging to *at most* one maturity level. that is, you can't be both EXPERIMENTAL and DEPRECATED at the same time -- that just makes no sense. once you tag some features with a maturity level, then part of the build would involve selecting which subset of maturity levels you wanted to see. by default, you'd get to see those features that weren't tagged at all, but you might also make a selection like this: [*] EXPERIMENTAL [*] DEPRECATED [ ] OBSOLETE in other words, you wanted the choice of stuff in the first two categories, but not the third. (you would, of course, always get to choose from non-tagged stuff, which would be your *normal* content, exactly as it is now). so what about BROKEN? i would invent a whole new attribute for that, called maybe status: config FUBAR depends on ... maturity DEPRECATED status BROKEN ... status is a totally orthogonal attribute to maturity. status might be one of BROKEN, BROKEN_ON_SMP, FLAKEY_AS HELL, etc. and, once again, any feature can fall into *at most* one status category. once you have the infrastructure to support a single attribute like maturity, you get any additional ones for free. and rather than defining all those things as simple dependencies, by creating new objects called attributes, you can play all sorts of interesting new games, and the attribute infrastructure can enforce that you're using it properly. now i'll go away and read the rest of your post. :-) rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, 18 Jul 2007, Gabriel C wrote: Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus. rather than add all that extraneous dreck to the Kconfig files, i *really* wish folks would give serious thought to my earlier suggestion about a maturity level attribute that could be used to not only add a parenthesized maturity level during display, but could also be used to activate/deactivate entire levels in one operation. there's no point adding all that redundant content when it can all be done automatically. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, 18 Jul 2007, Randy Dunlap wrote: On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote: On Wed, 18 Jul 2007, Gabriel C wrote: Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus. rather than add all that extraneous dreck to the Kconfig files, i *really* wish folks would give serious thought to my earlier suggestion about a maturity level attribute that could be used to not only add a parenthesized maturity level during display, but could also be used to activate/deactivate entire levels in one operation. there's no point adding all that redundant content when it can all be done automatically. I like it. Are there any kconfig patches to support this plan? once upon a time, i'd proposed just adding a couple new config entries, but i eventually decided that a better approach would be to define a whole new Kconfig directive, as in: config FUBAR maturity EXPERIMENTAL (or DEPRECATED or OBSOLETE or ...) that would require extra processing in the parser, but it would allow the maturity attribute to be used for all sorts of new and wacky things, such as automatically displaying it at the end of a config selection, or deselecting everything OBSOLETE in a build, etc. how hard would it be to add processing like that to the Kconfig infrastructure? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, 18 Jul 2007, Jeff Garzik wrote: Randy Dunlap wrote: On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote: there's no point adding all that redundant content when it can all be done automatically. I like it. Are there any kconfig patches to support this plan? Speaking specifically to adding 'EXPERIMENTAL', I distinctly remember at some point in the past the config system was smart enough to print (EXPERIMENTAL) if that entry depended on CONFIG_EXPERIMENTAL. We should head in that direction. there's one point i want to re-iterate. i'd prefer to see EXPERIMENTAL stop being a dependency, as in: depends on SNAFU FUBAR EXPERIMENTAL EXPERIMENTAL is not a dependency in the true sense of the word -- it is more of an attribute, and i think it would far more sense to see entries like: depends on SNAFU FUBAR maturity EXPERIMENTAL sure, it's more work, but i think the cost is worth it in terms of flexibility (particularly if *i'm* not the one doing the work. :-) rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, 18 Jul 2007, Adrian Bunk wrote: On Wed, Jul 18, 2007 at 04:51:33PM -0400, Robert P. J. Day wrote: On Wed, 18 Jul 2007, Jeff Garzik wrote: Randy Dunlap wrote: On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote: there's no point adding all that redundant content when it can all be done automatically. I like it. Are there any kconfig patches to support this plan? Speaking specifically to adding 'EXPERIMENTAL', I distinctly remember at some point in the past the config system was smart enough to print (EXPERIMENTAL) if that entry depended on CONFIG_EXPERIMENTAL. We should head in that direction. there's one point i want to re-iterate. i'd prefer to see EXPERIMENTAL stop being a dependency, as in: depends on SNAFU FUBAR EXPERIMENTAL EXPERIMENTAL is not a dependency in the true sense of the word -- it is more of an attribute, and i think it would far more sense to see entries like: depends on SNAFU FUBAR maturity EXPERIMENTAL Plus some special case in the kconfig code that you can somewhere select the maturity levels you want to use (currently it's a normal option kconfig doesn't have to know anything about). i already described that here: http://readlist.com/lists/vger.kernel.org/linux-kernel/66/334172.html where the top-level config would look something like: [*] Activate maturity attributes [*] EXPERIMENTAL [*] DEPRECATED [*] OBSOLETE [*] BROKEN whereupon you could select any combination of the attributes you want displayed *beyond the regular ones* during the config process. Remind me, would there be any big advantage after such a change besides being able to automatically print (EXPERIMENTAL) at the end of the prompt? defining a new Kconfig attribute means you can process it differently from regular dependencies. and if it's added as a general feature, it can be used for other possible attributes beyond just a maturity level. if you leave these maturity levels as regular dependencies, you're going to have to brute force and manually process them, and why make it that ugly? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, 18 Jul 2007, Adrian Bunk wrote: If you are not doing it, noone might do it. And discusing improvements noone will implement is somehow pointless... sure, i'm willing to help, but i don't think doing *nothing* about it is an option. you may not like gabriel's proposed patch, but you have to admit that he has a valid objection that should be addressed. so you can address it the manual and brute force way, or you can invest a little more time and do it right. but, either way, i think you have to deal with it. now it's just time to make a choice. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] CXGB3: Replace kcalloc(1,...) with kmalloc() in cxgb3_offload.c.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- diff --git a/drivers/net/cxgb3/cxgb3_offload.c b/drivers/net/cxgb3/cxgb3_offload.c index ebcf35e..999bc41 100644 --- a/drivers/net/cxgb3/cxgb3_offload.c +++ b/drivers/net/cxgb3/cxgb3_offload.c @@ -1105,7 +1105,7 @@ int cxgb3_offload_activate(struct adapter *adapter) struct mtutab mtutab; unsigned int l2t_capacity; - t = kcalloc(1, sizeof(*t), GFP_KERNEL); + t = kcalloc(sizeof(*t), GFP_KERNEL); if (!t) return -ENOMEM; -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
call to schedule_timeout() with wrong state in af_inet.c
based on a trivial check i added to kernel/timer.c, it seems that
schedule_timeout() is being called with a current state of
TASK_RUNNING, which shouldn't happen. this appears to be the
offending snippet of code:
net/ipv4/af_inet.c (inet_wait_for_connect)
==
...
while ((1 sk-sk_state) (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
release_sock(sk);
timeo = schedule_timeout(timeo);
lock_sock(sk);
...
at least, that's what *seems* to be the problem, based on dumping
the hex address and checking it against /proc/kallsyms.
the diagnostic shows up whenever i run fetchmail, for instance:
Jul 7 14:42:07 localhost kernel: Bad schedule_timeout state: 0 from fetchmail,
c0388732
that last value is the value of __builtin_return_address(0), and i
cross-checked that against /proc/kallsyms:
...
c038845d T inet_bind
c0388615 T inet_stream_connect
c0388814 T inet_accept
c03888b5 T inet_sock_destruct
...
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] RPC: Remove Makefile reference to obsolete RXRPC config variable.
Since there is no Kconfig variable RXRPC anywhere in the tree, and the variable AF_RXRPC performs exactly the same function, remove the reference to CONFIG_RXRPC from net/Makefile. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- diff --git a/net/Makefile b/net/Makefile index 34e5b2d..a87a889 100644 --- a/net/Makefile +++ b/net/Makefile @@ -37,7 +37,6 @@ obj-$(CONFIG_AX25)+= ax25/ obj-$(CONFIG_IRDA) += irda/ obj-$(CONFIG_BT) += bluetooth/ obj-$(CONFIG_SUNRPC) += sunrpc/ -obj-$(CONFIG_RXRPC)+= rxrpc/ obj-$(CONFIG_AF_RXRPC) += rxrpc/ obj-$(CONFIG_ATM) += atm/ obj-$(CONFIG_DECNET) += decnet/ -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KJ] [KJ PATCH] Replacing alloc_pages(gfp, 0) with alloc_page(gfp) in net/core/pktgen.c
On Wed, 13 Jun 2007, psr wrote:
On 6/13/07, Shani Moideen [EMAIL PROTECTED] wrote:
Replacing alloc_pages(gfp,0) with alloc_page(gfp)
in net/core/pktgen.c
Signed-off-by: Shani Moideen [EMAIL PROTECTED]
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index b92a322..2600c7f 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2414,7 +2414,7 @@ static struct sk_buff *fill_packet_ipv4(struct
net_device *odev,
i = 0;
while (datalen 0) {
- struct page *page = alloc_pages(GFP_KERNEL, 0);
+ struct page *page = alloc_page(GFP_KERNEL);
Does this makes any difference anyway? Both are same eventually?
What is the rational behind this? Can you please help me
understanding this?
since this is one of the TO DO items i added to the list of things at
the wiki:
http://fsdev.net/wiki/index.php?title=Memory_allocation_cleanup
i'll just toss in my $0.02. if a short (more convenient) form of a
routine has been defined, it should be used. if you have no plans to
use it, it shouldn't have been defined in the first place.
in short, make a consistent decision and go with it.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Remove long-dead commented-out MODULE_PARM reference.
Remove the useless comment referring to the obsolete MODULE_PARM macro. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- diff --git a/drivers/net/fealnx.c b/drivers/net/fealnx.c index abe9b08..2351092 100644 --- a/drivers/net/fealnx.c +++ b/drivers/net/fealnx.c @@ -111,7 +111,6 @@ MODULE_AUTHOR(Myson or whoever); MODULE_DESCRIPTION(Myson MTD-8xx 100/10M Ethernet PCI Adapter Driver); MODULE_LICENSE(GPL); module_param(max_interrupt_work, int, 0); -//MODULE_PARM(min_pci_latency, i); module_param(debug, int, 0); module_param(rx_copybreak, int, 0); module_param(multicast_filter_limit, int, 0); -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
finding your own dead CONFIG_ variables
while there's still a pile of possible dead CONFIG_ variables under the fs/ and drivers/ directories i haven't posted yet, you don't need to wait for me to generate them. take a minute and run the script yourself: http://fsdev.net/wiki/index.php?title=Dead_CONFIG_variables a couple of examples: $ ../dead_config.sh net/wanrouter == WANPIPE_MULTPPP == net/wanrouter/wanmain.c:#ifdef CONFIG_WANPIPE_MULTPPP net/wanrouter/wanmain.c:#ifdef CONFIG_WANPIPE_MULTPPP net/wanrouter/wanmain.c:#ifdef CONFIG_WANPIPE_MULTPPP $ ../dead_config.sh drivers/net/wireless == BCM947XX == drivers/net/wireless/bcm43xx/bcm43xx_dma.c:663:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx_main.h:36:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx_main.c:64:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx_main.c:145:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx_main.c:789:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx_main.c:799:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx_main.c:1228:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx_main.c:1390://FIXME: Do we _really_ want #ifndef CONFIG_BCM947XX here? drivers/net/wireless/bcm43xx/bcm43xx_main.c:1392:#ifndef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx_main.c:2143:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx_main.c:2155:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx_main.c:2648:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx_main.c:4147:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx.h:661:#ifdef CONFIG_BCM947XX drivers/net/wireless/bcm43xx/bcm43xx.h:792:#ifdef CONFIG_BCM947XX $ go wild. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: finding your own dead CONFIG_ variables
On Thu, 3 May 2007, Satyam Sharma wrote: http://fsdev.net/wiki/index.php?title=Dead_CONFIG_variables kcfiles=$(find . -name Kconfig*) Suggest: configfiles=$(find . -name 'Kconfig*' -or -name '*defconfig*') Some CONFIG_ options exist that are not declared anywhere in the Kconfig files but defined directly in the arch/.../*defconfig* files. it's my understanding that entries in any defconfig files are *automatically* pruned at some point once a CONFIG_ variable no longer exists in any Kconfig file, so i'm not going to be touching those files. also, adding that extra check wouldn't add anything useful to the output. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: finding your own dead CONFIG_ variables
On Thu, 3 May 2007, Arnd Bergmann wrote: On Thursday 03 May 2007, Robert P. J. Day wrote: Suggest: configfiles=$(find . -name 'Kconfig*' -or -name '*defconfig*') Some CONFIG_ options exist that are not declared anywhere in the Kconfig files but defined directly in the arch/.../*defconfig* files. it's my understanding that entries in any defconfig files are *automatically* pruned at some point once a CONFIG_ variable no longer exists in any Kconfig file, so i'm not going to be touching those files. also, adding that extra check wouldn't add anything useful to the output. An interesting category would be a symbol that is - used in a source file - defined in an old defconfig - not present in any Kconfig* file If any of these exist, I would consider them _worse_ than the ones found by your initial script, because some functionality that once was there has been recently removed. hmm ... i see your point now -- not present in any Kconfig file but still being selected by a defconfig file that might still be affecting the eventual build. that's an easy enough change to make but, as i've mentioned before, this output could be reduced substantially if developers stopped using CONFIG_ prefixed macro names for their own non-Kconfig variables (*cough* MTD *cough* :-). but, again, some of that issue might disappear if those defconfig files were auto-regenerated on a timely basis (if that is, in fact, how they're kept up to date). rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page
dead CONFIG_ variables: net/
/af_packet.c:1030:#ifdef CONFIG_SOCK_PACKET
net/packet/af_packet.c:1049:#ifdef CONFIG_SOCK_PACKET
net/packet/af_packet.c:1172:#ifdef CONFIG_SOCK_PACKET
net/packet/af_packet.c:1859:#ifdef CONFIG_SOCK_PACKET
include/asm-mips/socket.h:89: * @SOCK_PACKET - linux specific way of getting
packets at the dev level.
include/asm-mips/socket.h:99: SOCK_PACKET = 10,
include/asm-mips/socket.h:102:#define SOCK_MAX (SOCK_PACKET + 1)
include/linux/net.h:76: * @SOCK_PACKET: linux specific way of getting packets
at the dev level.
include/linux/net.h:90: SOCK_PACKET = 10,
include/linux/net.h:93:#define SOCK_MAX (SOCK_PACKET + 1)
net/packet/af_packet.c:310: * The SOCK_PACKET socket receives _all_
frames.
net/packet/af_packet.c:359: return(-ENOTCONN); /* SOCK_PACKET
must be sent giving an address */
net/packet/af_packet.c:1003: * Create a packet of type SOCK_PACKET.
net/packet/af_packet.c:1017: sock-type != SOCK_PACKET
net/packet/af_packet.c:1031:if (sock-type == SOCK_PACKET)
net/packet/af_packet.c:1050:if (sock-type == SOCK_PACKET)
net/packet/af_packet.c:1119:if (sock-type == SOCK_PACKET)
net/socket.c:1094: if (family == PF_INET type == SOCK_PACKET) {
net/socket.c:1098: printk(KERN_INFO %s uses obsolete
(PF_INET,SOCK_PACKET)\n,
== WANPIPE_MULTPPP ==
net/wanrouter/wanmain.c:569:#ifdef CONFIG_WANPIPE_MULTPPP
net/wanrouter/wanmain.c:590:#ifdef CONFIG_WANPIPE_MULTPPP
net/wanrouter/wanmain.c:663:#ifdef CONFIG_WANPIPE_MULTPPP
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
dead CONFIG_ variables: drivers/net/
drivers/net/sb1250-mac.c:2898:#ifdef CONFIG_SBMAC_COALESCE == SH_HICOSH4 == drivers/net/cs89x0.h:440:#ifdef CONFIG_SH_HICOSH4 drivers/net/cs89x0.c:178:#elif defined(CONFIG_SH_HICOSH4) drivers/net/cs89x0.c:570:#ifdef CONFIG_SH_HICOSH4 drivers/net/cs89x0.c:641:#ifdef CONFIG_SH_HICOSH4 drivers/net/cs89x0.c:726:#ifdef CONFIG_SH_HICOSH4 /* no EEPROM on HiCO, don't hazzle with it here */ drivers/net/cs89x0.c:1280:#if !defined(CONFIG_SH_HICOSH4) !defined(CONFIG_ARCH_PNX010X) /* uses irq#1, so this won't work */ == SIS190_NAPI == drivers/net/sis190.c:50:#ifdef CONFIG_SIS190_NAPI drivers/net/sis190.c:61:#ifdef CONFIG_SIS190_NAPI == USE_INTERNAL_TIMER == drivers/net/irda/w83977af_ir.c:68:#undef CONFIG_USE_INTERNAL_TIMER /* Just cannot make that timer work */ drivers/net/irda/w83977af_ir.c:536:#ifdef CONFIG_USE_INTERNAL_TIMER drivers/net/irda/w83977af_ir.c:563:#ifdef CONFIG_USE_INTERNAL_TIMER drivers/net/irda/w83977af_ir.c:879:#ifdef CONFIG_USE_INTERNAL_TIMER == USE_W977_PNP == drivers/net/irda/w83977af_ir.c:69:#define CONFIG_USE_W977_PNP/* Currently needed */ drivers/net/irda/w83977af_ir.c:283:#ifdef CONFIG_USE_W977_PNP drivers/net/irda/w83977af_ir.c:293:#endif /* CONFIG_USE_W977_PNP */ drivers/net/irda/w83977af_ir.c:323:#ifdef CONFIG_USE_W977_PNP drivers/net/irda/w83977af_ir.c:349:#endif /* CONFIG_USE_W977_PNP */ rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
{Spam?} Re: {Spam?} Re: {Spam?} [PATCH] NET: Remove obsolete traffic shaper code.
On Sun, 15 Apr 2007, Ian McDonald wrote: On 4/15/07, Robert P. J. Day [EMAIL PROTECTED] wrote: in fact, according to this: http://lkml.org/lkml/2006/1/13/139 that notice was put in the feature removal file well over a year ago, during 2.6.15. so that would seem to be more than adequate time for everyone to prepare for it. but it must have been deleted from that file since then as well. Yes and that was never merged and so was resent on January 19th, 2006: http://www.nabble.com/-2.6-patch--schedule-SHAPER-for-removal-t949871.html At that point people debated about it being too short notice and the patch never went in. I therefore think we can't just remove with NO notice. i have no dog in this fight one way or the other. i was just in a housecleaning mood and the shaper stuff looked old and relatively dead, that's all. if there's a good reason to keep it, fine. but it seems fairly clear that this *is* a dead feature: === $ git show 3b6a792f6ace33584897d1af08630c9acc0ce221 commit 3b6a792f6ace33584897d1af08630c9acc0ce221 Author: Jiri Slaby [EMAIL PROTECTED] Date: Mon Nov 6 14:34:48 2006 -0800 [NET]: kconfig, correct traffic shaper As Patrick McHardy [EMAIL PROTECTED] suggested, Traffic Shaper is now obsolete and alternative to it is no longer CBQ, since its problems with virtual devices, alter Kconfig text to reflect this -- put a link to the traffic schedulers as a whole. Signed-off-by: Jiri Slaby [EMAIL PROTECTED] Acked-by: Patrick McHardy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] == so given that the discussion of getting rid of this feature started well over a year ago, coupled with the fact that its own Kconfig entry has listed it as OBSOLETE for over five months now, plus that it has very few references left in the tree, well, maybe it's not outrageous to think that it really can be tossed. but, like i said, i have no vested interest in this one way or the other, except for a fondness for getting rid of dead stuff. rday p.s. if it shouldn't be removed, maybe someone would like to add an entry to the feature removal file for it. -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
{Spam?} [PATCH] NET: Remove obsolete traffic shaper code.
Remove the obsolete code for the traffic shaper. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- nothing seems to be using this, it's labelled OBSOLETE in the Kconfig file, and there is not a single test for CONFIG_SHAPER anywhere in the tree. time to die. Documentation/networking/shaper.txt | 48 - arch/um/config.release |1 drivers/net/Kconfig | 17 drivers/net/Makefile|1 drivers/net/shaper.c| 651 -- 5 files changed, 718 deletions(-) diff --git a/Documentation/networking/shaper.txt b/Documentation/networking/shaper.txt deleted file mode 100644 index 6c4ebb6..000 --- a/Documentation/networking/shaper.txt +++ /dev/null @@ -1,48 +0,0 @@ -Traffic Shaper For Linux - -This is the current BETA release of the traffic shaper for Linux. It works -within the following limits: - -o Minimum shaping speed is currently about 9600 baud (it can only -shape down to 1 byte per clock tick) - -o Maximum is about 256K, it will go above this but get a bit blocky. - -o If you ifconfig the master device that a shaper is attached to down -then your machine will follow. - -o The shaper must be a module. - - -Setup: - - A shaper device is configured using the shapeconfig program. -Typically you will do something like this - -shapecfg attach shaper0 eth1 -shapecfg speed shaper0 64000 -ifconfig shaper0 myhost netmask 255.255.255.240 broadcast 1.2.3.4.255 up -route add -net some.network netmask a.b.c.d dev shaper0 - -The shaper should have the same IP address as the device it is attached to -for normal use. - -Gotchas: - - The shaper shapes transmitted traffic. It's rather impossible to -shape received traffic except at the end (or a router) transmitting it. - - Gated/routed/rwhod/mrouted all see the shaper as an additional device -and will treat it as such unless patched. Note that for mrouted you can run -mrouted tunnels via a traffic shaper to control bandwidth usage. - - The shaper is device/route based. This makes it very easy to use -with any setup BUT less flexible. You may need to use iproute2 to set up -multiple route tables to get the flexibility. - - There is no borrowing or sharing scheme. This is a simple -traffic limiter. We implement Van Jacobson and Sally Floyd's CBQ -architecture into Linux 2.2. This is the preferred solution. Shaper is -for simple or back compatible setups. - -Alan diff --git a/arch/um/config.release b/arch/um/config.release index fc68bcb..4495b90 100644 --- a/arch/um/config.release +++ b/arch/um/config.release @@ -174,7 +174,6 @@ CONFIG_SLIP_SMART=y # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set -CONFIG_SHAPER=m # # Wan interfaces diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index c3f9f59..a21f004 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2899,23 +2899,6 @@ config NET_FC adaptor below. You also should have said Y to SCSI support and SCSI generic support. -config SHAPER - tristate Traffic Shaper (OBSOLETE) - depends on EXPERIMENTAL - ---help--- - The traffic shaper is a virtual network device that allows you to - limit the rate of outgoing data flow over some other network device. - The traffic that you want to slow down can then be routed through - these virtual devices. See - file:Documentation/networking/shaper.txt for more information. - - An alternative to this traffic shaper are traffic schedulers which - you'll get if you say Y to QoS and/or fair queuing in - Networking options. - - To compile this driver as a module, choose M here: the module - will be called shaper. If unsure, say N. - config NETCONSOLE tristate Network console logging support (EXPERIMENTAL) depends on EXPERIMENTAL diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 33af833..30721ea 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -85,7 +85,6 @@ obj-$(CONFIG_NET_SB1000) += sb1000.o obj-$(CONFIG_MAC8390) += mac8390.o obj-$(CONFIG_APNE) += apne.o 8390.o obj-$(CONFIG_PCMCIA_PCNET) += 8390.o -obj-$(CONFIG_SHAPER) += shaper.o obj-$(CONFIG_HP100) += hp100.o obj-$(CONFIG_SMC9194) += smc9194.o obj-$(CONFIG_FEC) += fec.o diff --git a/drivers/net/shaper.c b/drivers/net/shaper.c deleted file mode 100644 index e886e8d..000 --- a/drivers/net/shaper.c +++ /dev/null @@ -1,651 +0,0 @@ -/* - * Simple traffic shaper for Linux NET3. - * - * (c) Copyright 1996 Alan Cox [EMAIL PROTECTED], All Rights Reserved. - * http://www.redhat.com - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version - * 2 of the License, or (at your option) any
{Spam?} Re: {Spam?} [PATCH] NET: Remove obsolete traffic shaper code.
On Sun, 15 Apr 2007, Rene Herman wrote:
On 04/15/2007 01:30 AM, Robert P. J. Day wrote:
Remove the obsolete code for the traffic shaper.
Why are all your messages getting a {Spam?} subject prefix?
i have no idea, that's a recent development. is that happening with
anyone else?
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
{Spam?} Re: {Spam?} [PATCH] NET: Remove obsolete traffic shaper code.
(i'm betting that the mail server i use back in canada is going to tag
this yet again with {Spam?} since i'm in california at the moment
and i'll just bet it's freaking out seeing stuff coming from a totally
unknown IP address. i've already sent an email to the admins about
this. sorry.)
On Sun, 15 Apr 2007, Ian McDonald wrote:
On 4/15/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
Remove the obsolete code for the traffic shaper.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
Apart from the merits of removing this which I can't comment on, I
thought the usual procedure was to place a removal in
Documentation/feature-removal-schedule.txt to notify people of what
is going to be removed. Then wait the period you determine there and
then remove.
in fact, according to this:
http://lkml.org/lkml/2006/1/13/139
that notice was put in the feature removal file well over a year ago,
during 2.6.15. so that would seem to be more than adequate time for
everyone to prepare for it. but it must have been deleted from that
file since then as well.
i probably should have mentioned that in my initial posting.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] 3C509: Remove unnecessary include of linux/pm_legacy.h
Remove the apparently redundant include of linux/pm_legacy.h. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- compile-tested on x86, in preparation for the day when the legacy PM code goes away. diff --git a/drivers/net/3c509.c b/drivers/net/3c509.c index f791bf0..a8ea346 100644 --- a/drivers/net/3c509.c +++ b/drivers/net/3c509.c @@ -83,7 +83,6 @@ static int max_interrupt_work = 10; #include linux/netdevice.h #include linux/etherdevice.h #include linux/pm.h -#include linux/pm_legacy.h #include linux/skbuff.h #include linux/delay.h /* for udelay() */ #include linux/spinlock.h -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] NET: Remove dead net/sched/Makefile entry for sch_hpfq.o.
Remove the worthless net/sched/Makefile entry for the non-existent source file sch_hpfq.c. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- diff --git a/net/sched/Makefile b/net/sched/Makefile index ff2d6e5..020767a 100644 --- a/net/sched/Makefile +++ b/net/sched/Makefile @@ -17,7 +17,6 @@ obj-$(CONFIG_NET_ACT_SIMP)+= act_simple.o obj-$(CONFIG_NET_SCH_FIFO) += sch_fifo.o obj-$(CONFIG_NET_SCH_CBQ) += sch_cbq.o obj-$(CONFIG_NET_SCH_HTB) += sch_htb.o -obj-$(CONFIG_NET_SCH_HPFQ) += sch_hpfq.o obj-$(CONFIG_NET_SCH_HFSC) += sch_hfsc.o obj-$(CONFIG_NET_SCH_RED) += sch_red.o obj-$(CONFIG_NET_SCH_GRED) += sch_gred.o -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Rename IPW2100 debugging macros to not look like config options.
Rename some internal ipw2100 debugging macros to not look like
user-settable kernel config settings.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
make some renames based on short conversation with [EMAIL PROTECTED]:
CONFIG_IPW2100_RX_DEBUG - IPW2100_RX_DEBUG
CONFIG_IPW2100_DEBUG_C3 - IPW2100_DEBUG_C3
CONFIG_IPW2100_TX_POWER - IPW2100_TX_POWER
diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
index b85857a..d0639a4 100644
--- a/drivers/net/wireless/ipw2100.c
+++ b/drivers/net/wireless/ipw2100.c
@@ -175,7 +175,7 @@ that only one external action is invoked at a time.
/* Debugging stuff */
#ifdef CONFIG_IPW2100_DEBUG
-#define CONFIG_IPW2100_RX_DEBUG/* Reception debugging */
+#define IPW2100_RX_DEBUG /* Reception debugging */
#endif
MODULE_DESCRIPTION(DRV_DESCRIPTION);
@@ -2239,7 +2239,7 @@ static void ipw2100_snapshot_free(struct ipw2100_priv
*priv)
priv-snapshot[0] = NULL;
}
-#ifdef CONFIG_IPW2100_DEBUG_C3
+#ifdef IPW2100_DEBUG_C3
static int ipw2100_snapshot_alloc(struct ipw2100_priv *priv)
{
int i;
@@ -2314,13 +2314,13 @@ static u32 ipw2100_match_buf(struct ipw2100_priv *priv,
u8 * in_buf,
* The size of the constructed ethernet
*
*/
-#ifdef CONFIG_IPW2100_RX_DEBUG
+#ifdef IPW2100_RX_DEBUG
static u8 packet_data[IPW_RX_NIC_BUFFER_LENGTH];
#endif
static void ipw2100_corruption_detected(struct ipw2100_priv *priv, int i)
{
-#ifdef CONFIG_IPW2100_DEBUG_C3
+#ifdef IPW2100_DEBUG_C3
struct ipw2100_status *status = priv-status_queue.drv[i];
u32 match, reg;
int j;
@@ -2342,7 +2342,7 @@ static void ipw2100_corruption_detected(struct
ipw2100_priv *priv, int i)
}
#endif
-#ifdef CONFIG_IPW2100_DEBUG_C3
+#ifdef IPW2100_DEBUG_C3
/* Halt the fimrware so we can get a good image */
write_register(priv-net_dev, IPW_REG_RESET_REG,
IPW_AUX_HOST_RESET_REG_STOP_MASTER);
@@ -2413,7 +2413,7 @@ static void isr_rx(struct ipw2100_priv *priv, int i,
skb_put(packet-skb, status-frame_size);
-#ifdef CONFIG_IPW2100_RX_DEBUG
+#ifdef IPW2100_RX_DEBUG
/* Make a copy of the frame so we can dump it to the logs if
* ieee80211_rx fails */
memcpy(packet_data, packet-skb-data,
@@ -2421,7 +2421,7 @@ static void isr_rx(struct ipw2100_priv *priv, int i,
#endif
if (!ieee80211_rx(priv-ieee, packet-skb, stats)) {
-#ifdef CONFIG_IPW2100_RX_DEBUG
+#ifdef IPW2100_RX_DEBUG
IPW_DEBUG_DROP(%s: Non consumed packet:\n,
priv-net_dev-name);
printk_buf(IPW_DL_DROP, packet_data, status-frame_size);
@@ -4912,7 +4912,7 @@ static int ipw2100_set_power_mode(struct ipw2100_priv
*priv, int power_level)
else
priv-power_mode = IPW_POWER_ENABLED | power_level;
-#ifdef CONFIG_IPW2100_TX_POWER
+#ifdef IPW2100_TX_POWER
if (priv-port_type == IBSS priv-adhoc_power != DFTL_IBSS_TX_POWER)
{
/* Set beacon interval */
cmd.host_command = TX_POWER_INDEX;
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://www.fsdev.dreamhosters.com/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ixgb: Delete IXGB_DBG() macro and call pr_debug() directly.
On Tue, 10 Oct 2006, Auke Kok wrote: Robert P. J. Day wrote: ... snip ... if someone wants to tell me what, in the context of ixgb_main.c, i would use as that dev argument [for dev_dbg], i'm all for that. (CC netdev since it's a network driver topic). all our macro's (e100, e1000, ixgb) use adapter-netdev-name inserted through the DPRINTK macro. if you'd really want to clean it all up, you'd have to replace all DPRINTK() calls with dev_dbg(adapter-netdev-name, ) which would just make it more lengthy and uncomfortable to read. which puts this in a bigger perspective. I suppose the nicest way to do program these is to do something like this: #define ixgb_dbg(args...) dev_dbg(adapter-netdev-name, args) #define ixgb_err(args...) dev_err(adapter-netdev-name, args) #define ixgb_info(args...) dev_info(adapter-netdev-name, args) and use those consistently throughout the driver, ditto for e100/e1000. I'll look into it and see what I can do. um, yeah. i'm rapidly getting out of my comfort zone here. this seemed like such a simple submission six hours ago. :-) live and learn. rday - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
