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: <20090617102011.41a3ecfa@lxorguk.ukuu.org.uk>
Date:	Wed, 17 Jun 2009 10:20:11 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"Leo (Hao) Chen" <leochen@...adcom.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm@...ts.arm.linux.org.uk" <linux-arm@...ts.arm.linux.org.uk>,
	"Leo (Hao) Chen" <leochen@...adcom.com>
Subject: Re: QUESTION: new arch/arm/mach-bcmring code submission

> 1. We have a whole lot of OS-less csp (chip support package) code that is used in our drivers and arch code. We will release them as GPL but we want to keep and maintain them in our own csp directories.  Can we put them under arch/arm/mach-bcmring/csp and arch/arm/mach-bcmring/include/csp directories?  If not, what's the proper way to do that?

Difficult to tell without seeing it.

> 2. We have driver header files which are currently kept in the include/linux/broadcom directory.  Where is the proper place to put our driver header files in Linux kernel?  Any guidelines?

Headers generally go in locations according to what they are for.

Thus

	arch/arm/plat-[name]/include/plat
	arch/arm/mach-[name]/include/mach

Stuff that defines public (user space) interfaces and structures tends to
be in include/linux while there are directories such as include/net/
include/usb/ - split by function rather than platform

> 3. Do I need to submit our code to any maintainer or just submit to LKML

Core changes that affect the internals of things like arch/arm and
include/asm-arm need to go via the maintainer (see MAINTAINERS): In this
case Russell King - and see: http://www.arm.linux.org.uk

After that platform changes can begin to go in, and then drivers. If you
are new to this then initially going through another maintainer will help
with quality and correctness, but after a time a lot of stuff would go
directly (stuff that affected only bcmring drivers/code). That also is a
good reason to keep as much of the code separated cleanly from the core
code as possible.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ