linux-kernel - Re: QUESTION: new arch/arm/mach-bcmring code submission

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:	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/