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] [day] [month] [year] [list]
Message-ID: <AANLkTinPAuqQa+KOLuaX3ZQO4NXuVoi=uWsofTiNXW04@mail.gmail.com>
Date:	Wed, 29 Sep 2010 12:27:11 -0700
From:	Raymond Liu <raymondliu3linux@...il.com>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Ben Gamari <bgamari@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: HDMI open source to handle audio/video/CEC in one driver

Hi Ben and Guennadi,

Thanks again for these important inputs.  We had a much clear picture
about what we can do and what we should do with our OEMs on the driver
for open source at this point.

Thanks,
Raymond

On Tue, Sep 28, 2010 at 4:29 PM, Guennadi Liakhovetski
<g.liakhovetski@....de> wrote:
> On Tue, 28 Sep 2010, Raymond Liu wrote:
>
>> Hi Ben and Guennadi,
>>
>> Really appreciate your inputs.
>>
>> For temporarily short term purpose (we already had a driver but it did
>> not fit into any of these you mentioned), what is the process we
>> should follow to make it an "open source"?
>
> Sorry, do not understand: if it didn't fit into any of these categories,
> what is it like? In any case, general instructions you find in the
> following files in your Linux kernel sources directory:
>
> Documentation/SubmitChecklist
> Documentation/SubmittingPatches
> Documentation/SubmittingDrivers
> Documentation/CodingStyle
>
> I know, it might seem a lot, but take a bit of time to look through them,
> not everything will be 100% relevant to each specific case, but do follow
> Documentation/CodingStyle and choose a suitable mailing list for your
> posts - this list (LKML) is too gneric for your questions, that's why
> you're getting so few to-the-topic replies.
>
> And I'm not sure what you mean by "temporarily short term purpose." As
> soon as your driver gets into the kernel, it is better, if it is designed
> to stay there for a longer time. It might not be perfect from the very
> first version, its functionality might be restricted, but for that little,
> that it does, it should already adhere to the kernel standards. You might
> also consider adding your driver under drivers/staging - if you're unable
> to follow the guidelines and want to give your driver more exposure to
> gradually fix it.
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
--
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