Messages in this thread |  | | Date | Wed, 31 Oct 2001 01:05:00 +0100 | From | < ( Marc) (A.) (Lehmann )> | Subject | Re: 2.4.13-ac5 && vtun not working |
| |
On Mon, Oct 29, 2001 at 05:53:12PM -0800, "David S. Miller" <davem@redhat.com> wrote: > Basically, don't pass a string lack one "%d" into dev_alloc_name > because dev_alloc_name() runs sprintf on that string with an > integer argument.
I fail to follow you - yes, dev_alloc_name calls sprintf on it, but sprintf works fine on strings without "%d", and dev_alloc_name also works fine (despite a little suboptimal).
On Mon, Oct 29, 2001 at 05:48:35PM -0800, Maksim Krasnyanskiy <maxk@qualcomm.com> wrote: > >(oh, and after reading the comments int hat file, I think that maybe tun.c > >simply shouldn't call dev_alloc_name...) > Hmm, let me check that. > I was under the assumption that it's dev.c bug :)
well, reading the part again it seems that dev_alloc_name is not "allocating a name" but just looking for a free one. If it is indeed logically allocating the devicename then it's a bug in dev.c. If it is just used to find a free existing name, then it's a bug in tun.c (and elsewhere), in that it simply shouldn't call dev_alloc_name, but instead allocates the name itself.
my personal opinion is that dev_alloc_name should work, as it would be the logical place to do this stuff, an abstraction. it could be coded more efficiently, but it doesn't seem to be a terrible important place anyways.
but I also must admit that I, well, know nothing ;)
-- -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg@goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |