Ben Greear wrote:
>
> "Daniel L. Rall" wrote:
> >
> > Hello list. :)
> >
> > I rewrote the dev_alloc_name() function in the 2.2.14 Linux kernel's
> > net/core/dev.c module. It had an apparently artificial limitation on
> > number of network devices of the same type allowed (100), and was not
> > implemented in a very efficient manner (which would not be a big deal
> > under normal circumstances, as this routine wouldn't be called very
> > often). Just another drop in the bucket. :)
>
> I needed more for my VLAN implementation, and just upped the
> 100 to 8096 or so. Due to people's varying tastes, I also implemented
> a few other methods of generating VLAN device names, and did NOT
> even use the dev_alloc_name method in these instances.
>
> So:
> 1) Will that screw your patch up? (I don't think it will...)
No, my patch actually totally replaces the existing implementation
(though the API doesn't change at all). The post-patch device limit
will be memory imposed only.
> 2) I'm curious what instances of device naming this patch could help.
> For example, if you are going to have 200 devices of some type, then
> you may not want them linearly named because as soon as you blink you
> have forgotten what foo_dev198 refered to. At least from the comments
> I've read relating to VLANs, it seems that a more direct naming scheme:
> [base_dev]:[new_dev_id], ie: eth0:25 for a VLAN 25 on eth0, or something
> similar, may be more desirable.
Whelp, I didn't change the existing API at all. (I wasn't comfortable
doing that without just this type of input--thanks!) As far as naming
devices in a non-linear fashion, I don't see either the previous
implementation or my patched implementation supporting that. Your VLAN
example is partially supported by the dev_alloc_name API (but you can
only allocate a new VLAN in a linear fashion):
int result = dev_alloc_name(device, "eth0:%d");
I agree with Ben Greear's comment about being able to specify a desired
device name in dev_alloc_name() (as long as we don't duplicate existing
functionality). We could support *both* the existing linear dev_max_id
auto-increment and the addition of a caller-specified device naming
scheme by looking for the existance of the format indicator '%' in the
specified name and allocating that name. If the specified name already
exists, we return error status and do a printk(). This keeps the
existing API, and adds functionality. Here are the existing usages of
the function:
dlr@despot:linux$ find . -name '*.c' | xargs grep -n dev_alloc_name
./net/core/dev.c:309:int dev_alloc_name(struct device *device, const
char *name_fmt)
./net/core/dev.c:368: *err=dev_alloc_name(dev,name);
./net/netsyms.c:472:EXPORT_SYMBOL(dev_alloc_name);
./net/sched/sch_teql.c:463: err = dev_alloc_name(&the_master.dev,
"teql%d");./drivers/net/ppp.c:2847: if_num = dev_alloc_name(dev,
"ppp%d");
./drivers/net/ppp.c:2849: printk(KERN_ERR "ppp: dev_alloc_name failed
(%d)\n", if_num);
./drivers/net/ipddp.c:341: err=dev_alloc_name(&dev_ipddp, "ipddp%d");
./drivers/net/dummy.c:147: int err=dev_alloc_name(&dev_dummy,"dummy%d");
./drivers/net/shaper.c:674: int
err=dev_alloc_name(&dev_shape,"shaper%d");
./drivers/net/ltpc.c:1304: err=dev_alloc_name(&dev_ltpc,"lt%d");
./drivers/net/cops.c:1056: err=dev_alloc_name(&cops0_dev, "lt%d");
Do other people find this useful, or consider this additional
functionality bloat? I would be happy to add this functionality. Also,
should I be posting this to [EMAIL PROTECTED], or to
[EMAIL PROTECTED]? Or to both (as I did)?
--
Daniel Rall <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
