netdev - Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <468BA83A.7070500@trash.net>
Date:	Wed, 04 Jul 2007 16:01:30 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Urs Thuermann <urs@...ogud.escape.de>
CC:	Oliver Hartkopp <oliver@...tkopp.net>,
	David Miller <davem@...emloft.net>, j.hadi123@...il.com,
	Thomas Gleixner <tglx@...utronix.de>,
	Oliver Hartkopp <oliver.hartkopp@...kswagen.de>,
	netdev@...r.kernel.org
Subject: Re: [patch 5/7] CAN: Add virtual CAN netdevice driver

Urs Thuermann wrote:
> Patrick McHardy <kaber@...sh.net> writes:
> 
> 
>>It should create as many devices as necessary to operate (similar
>>to the loopback device) by default. Optional interfaces that are
>>used for addressing reasons should be manually added by the user
>>as needed. And it should not use module parameters for that please.
> 
> 
> I have now changed vcan to use the netlink interface.  I am now
> thinking about how many interfaces should be created at module load
> time.
> 
> The PF_CAN doesn't need vcan to operate, like lo for IP.  vcan is
> mostly for doing tests when you don't have real CAN interfaces
> available, and you would normally want to have as many vcan devices as
> you would have real CAN interface on your target hardware.
> 
> This is why I also wanted to have a default of 0 vcan interfaces and
> an ioctl do add interfaces as needed.  Then we decided however to have
> a module parameter with a typical default and no ioctl().
> 
> Now, I would again think that 0 vcan interfaces should be created
> automatically and the user must create the devices he needs.  Wouldn't
> that also be a better default for dummy interfaces?  It would simplify
> dummy.c quite a bit, since dummy_init_one() could be removed
> completely and dummy_init_module() would only register the
> dummy_link_ops, right?
>
> However, this could surprise a user loading the module and not seeing
> any new interface.  Is it because of backward compatibility that you
> create one dummy interface by default?


Yes, unfortunately we can't change this.

> For this reason I also consider a default of one vcan interface to be
> created automatically.  But then 1 seems almost as arbitrarily as 4,
> since also 1 is not needed for PF_CAN to work.
> 
> I currently still prefer no default interfaces, since we would get rid
> of some code.


Me too, and you don't need to worry about compatibility.

> What is the reason you don't like a module parameter to control the
> number of default interfaces?  We still have that in our code
> currently (but I'm about to remove it).


There's nothing wrong with the parameter itself as long as its
not the only way to control things. But I don't see why you'd
need it when you can simply add them at runtime. Especially when
you don't build it as module this is a lot easier.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html