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]

Date:	04 Jul 2007 13:37:23 +0200
From:	Urs Thuermann <urs@...ogud.escape.de>
To:	Patrick McHardy <kaber@...sh.net>
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

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?

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.

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

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