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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 27 Oct 2014 17:27:11 -0700
From:	Pravin Shelar <>
To:	Thomas Graf <>
Cc:	"" <>,
	netdev <>
Subject: Re: [PATCH] ovs: Turn vports with dependencies into separate modules

On Mon, Oct 27, 2014 at 2:47 PM, Thomas Graf <> wrote:
> On 10/27/14 at 10:14am, Pravin Shelar wrote:
>> On Fri, Oct 24, 2014 at 2:57 PM, Thomas Graf <> wrote:
>> > I was refering to how many other kernel APIs have been designed, a
>> > registration API allowing a vport to be implemented exclusively in the
>> > scope of a single file tends to be cleaner than having to touch multiple
>> > files and maintaining an init list.
>> >
>> This has never been issue in openvswitch. Plus we do not need loadable
>> vport module to fix this issue.
>> > It also allows for OVS to be built into vmlinuz while vports can
>> > remain as modules even if vxlan itself is built as a module.
>> >
>> What is problem with current OVS built into kernel?
> What I mean specifically is the following dependency logic which will
> no longer be required:
> The patch also brings additional flexibility to users of
> distributions. Distros typically ship something like an allmodconfig
> so a user can either run openvswitch.ko with all encaps compiled in
> or not run openvswitch.ko. With vports as module, a user can blacklist
> a certain encap type.
> Another advantage is obviously that users can run additional vport
> types on top of their distribution kernels.
> Is there anything specific that you are concerned with in regard
> to this proposed change?

OVS vport code is not alot and making it plugable module does not save
much space. Even with this patch user can not load any vport type
since we still need to define the type in kernel interface and add the
support in userspace netdev layer. Therefore this patch adds
complexity without much gain.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists