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
| ||
|
Date: Wed, 5 Dec 2007 23:04:46 -0700 From: Stephen Hemminger <shemminger@...ux-foundation.org> To: renzo@...unibo.it (Renzo Davoli) Cc: linux-kernel@...r.kernel.org Subject: Re: New Address Family: Inter Process Networking (IPN) On Thu, 6 Dec 2007 06:38:21 +0100 renzo@...unibo.it (Renzo Davoli) wrote: > On Wed, Dec 05, 2007 at 04:55:52PM -0500, Stephen Hemminger wrote: > > On Wed, 5 Dec 2007 17:40:55 +0100 > > renzo@...unibo.it (Renzo Davoli) wrote: > > > 0- (Constructive) comments. > > > 1- The "official" assignment of an Address Family. > > > 2- Another "grabbing hook" for interfaces (like the ones already > > > We are studying some way to register/deregister grabbing services, > > > I feel this would be the cleanest way. > > > > Post complete source code for kernel part to netdev@...r.kernel.org. > I'll do it as soon as possible. > > If you want the hooks, you need to include the full source code for inclusion > > in mainline. All the Documentation/SubmittingPatches rules apply; > > you can't just ask for "facilitators" and expect to keep your stuff out of tree. > I am sorry if I was misunderstood. > I did not want any "facilitator", nor I wanted to keep my code outside > the kernel, on the contrary. Greate > It is perfectly okay for me to provide the entire code for inclusion. > The purposes of my message were the following: > - I wanted to introduce the idea and say to the linux kernel community > that a team is working on it. > - Address family: is it okay to send a patch that add a new AF? > is there a "AF registry" somewhere? (like the device major/minor > registry or the well-known port assignment for TCP-IP). The usual process is to just add the value as part of the patchset. You then need to tell the glibc maintainers so it gets included appropriately in userspace. > - Hook: we have two different options. We can add another grabbing > inline function like those used by the bridge and macvlan or we can > design a grabbing service registration facility. Which one is preferrable? The problem with making it a registration facilties are: * risk of making it easier for non-GPL out of tree abuse * possible ordering issues: ie. by hardcoding each hook, the behaviour is defined in the case of multiple usages on the same machine. > The former is simpler, the latter is more elegant but it requires some > changes in the kernel bridge code. Not a big deal, but see above > So the former choice is between less-invasive,safer,inelegant, the > latter is more-invasive,less safe,elegant. > We need a bit of time to stabilize the code: deeply testing the existing > features and implementing some more ideas we have on it. > In the meanwhile we would be grateful if the community could kindly ask to the > questions above. I am a believer in review early and often. It is easier to just deal with the nuisance issues (style, naming, configuration) at the beginning rather than the final stage of the project. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists