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
| ||
|
Message-ID: <461AD517.2000906@trash.net> Date: Tue, 10 Apr 2007 02:06:47 +0200 From: Patrick McHardy <kaber@...sh.net> To: Johannes Berg <johannes@...solutions.net> CC: "Eric W. Biederman" <ebiederm@...ssion.com>, David Miller <davem@...emloft.net>, akpm@...ux-foundation.org, dim@...nvz.org, netdev@...r.kernel.org, jgarzik@...ox.com, containers@...ts.osdl.org, kuznet@....inr.ac.ru, shemminger@...ux-foundation.org, greearb@...delatech.com Subject: Re: [PATCH] net: Add etun driver Johannes Berg wrote: > On Mon, 2007-04-09 at 22:11 +0200, Patrick McHardy wrote: > > >>Thats why I suggested that we should create one, ideally before adding >>more sysfs/proc/ioctl/... based interfaces, which we'll have a hard time >>getting rid of again. > > > But then how would we configure initial parameters along with creating > the interface? That's something that's good to have, and I don't see how > you can allow it generically. > > Then again, you can of course always add an interface and then change > its operating parameters etc. but that isn't atomic any more. Same way as the current RTM_SETLINK message works, but with creating a new link in advance. It works fine in other subsystems, so I don't see why it would in this case as well. Some subsystems do it in an atomic fashion (network schedulers for example), some first create the object, then configure it (network classifiers in the non-compat cases). In the network device case I suppose the later should work fine since a device needs to be set UP in a second action before it really does anything. - 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
Powered by blists - more mailing lists