Re: 2.4.13-ac5 && vtun not working

[<pcg@goof.com ( Marc) (A.) (Lehmann )>]

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                       |
                                                         |