Hi,
Our company is planning to upload our device drivers to "kernel.org".
And I am investigating "How to upload".
Our company is developing some device drivers for new chip-set device.
It is not released yet, but the sample is in the test in the specific company.
I contacted kernel.org this month.
The man recommended this mailing-list.
Would you give me your advice?
I am very glad if you help it.
We look forward to uploading the drivers to kernel.org!
[Our drivers]
We are preparing the drivers source code.
And we uploaded them to Sourceforge.net.
Please refer to below.
http://sourceforge.net/projects/generalembedded/
http://generalembedded.sourceforge.net/
Our developers will turn our drivers into a patch series and to post
them to this mailing list.
[My information]
I participated in the mailing list for the first time in my life.
I am full of fears and hopes.
This mailing list is very lively and great!
I think so.
Thank you & Best regards,
Masa <[email protected]>
El Mon, 14 Dec 2009 19:56:23 +0900
Masa <[email protected]> escribió:
Adding I hpe some usefull CC's
See also: http://www.linuxdriverproject.org/
> Hi,
>
> Our company is planning to upload our device drivers to "kernel.org".
> And I am investigating "How to upload".
>
> Our company is developing some device drivers for new chip-set device.
> It is not released yet, but the sample is in the test in the specific company.
>
> I contacted kernel.org this month.
> The man recommended this mailing-list.
>
> Would you give me your advice?
> I am very glad if you help it.
>
> We look forward to uploading the drivers to kernel.org!
>
> [Our drivers]
> We are preparing the drivers source code.
> And we uploaded them to Sourceforge.net.
> Please refer to below.
> http://sourceforge.net/projects/generalembedded/
> http://generalembedded.sourceforge.net/
>
> Our developers will turn our drivers into a patch series and to post
> them to this mailing list.
>
> [My information]
> I participated in the mailing list for the first time in my life.
> I am full of fears and hopes.
>
> This mailing list is very lively and great!
> I think so.
>
> Thank you & Best regards,
> Masa <[email protected]>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Replies are inline.
Regards,
Mithlesh Thukral
On Monday 14 December 2009 16:56:49 Alejandro Riveira Fernández wrote:
> El Mon, 14 Dec 2009 19:56:23 +0900
> Masa <[email protected]> escribió:
>
> Adding I hpe some usefull CC's
> See also: http://www.linuxdriverproject.org/
>
> > Hi,
> >
> > Our company is planning to upload our device drivers to "kernel.org".
> > And I am investigating "How to upload".
SubmittingDrivers in the Documentation/ can help you with this.
Online copy can be found at (amongst many more):
http://lxr.linux.no/#linux+v2.6.32/Documentation/SubmittingDrivers
> >
> > Our company is developing some device drivers for new chip-set device.
> > It is not released yet, but the sample is in the test in the specific
> > company.
> >
> > I contacted kernel.org this month.
> > The man recommended this mailing-list.
> >
> > Would you give me your advice?
> > I am very glad if you help it.
> >
> > We look forward to uploading the drivers to kernel.org!
> >
> > [Our drivers]
> > We are preparing the drivers source code.
> > And we uploaded them to Sourceforge.net.
> > Please refer to below.
> > http://sourceforge.net/projects/generalembedded/
> > http://generalembedded.sourceforge.net/
> >
> > Our developers will turn our drivers into a patch series and to post
> > them to this mailing list.
> >
If you intend to post the drivers as the development effort continues. so that
you can have the community feedback (and if required help) during the process
then you might in interested in Greg's Staging tree.
http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=tree
You can base your patches to the latest kernel (or git trees of respective
maintainers) and post them to the mailing list.
> > [My information]
> > I participated in the mailing list for the first time in my life.
> > I am full of fears and hopes.
> >
> > This mailing list is very lively and great!
> > I think so.
> >
> > Thank you & Best regards,
> > Masa <[email protected]>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> _______________________________________________
> devel mailing list
> [email protected]
> http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
>
On Mon, 14 Dec 2009 19:56:23 +0900
Masa <[email protected]> wrote:
> Our company is planning to upload our device drivers to "kernel.org".
> And I am investigating "How to upload".
You'll find a lot of useful information in these parts of the kernel
Documentation directory:
Documentation/HOWTO
Documentation/development-process
Documentation/SubmittingPatches
That would be the best place to start.
jon
Thanks,
> Adding I hpe some usefull CC's
> See also: http://www.linuxdriverproject.org/
Last week, I saw it.
But, I could not find the information for "How to upload".
Should I make a new topic?
I did not know Foswiki.
>From now, I started to study it.
Am Montag, 14. Dezember 2009 15:10:42 schrieb Masa:
> > Adding I hpe some usefull CC's
> > See also: http://www.linuxdriverproject.org/
> Last week, I saw it.
> But, I could not find the information for "How to upload".
You don't, technically speaking, upload.
You make a patch against a current kernel tree and mail it
to the relevant list. Then people will tell you what's wrong with your
code and how it should be improved. After you'll have fixed
the issues, the maintainer will take your patch and it'll be
incorporated into the kernel tree at kernel.org.
HTH
Oliver
Thanks,
> SubmittingDrivers in the Documentation/ can help you with this.
> Online copy can be found at (amongst many more):
> http://lxr.linux.no/#linux+v2.6.32/Documentation/SubmittingDrivers
I found it
http://lxr.linux.no/linux+v2.6.32/Documentation/SubmittingDrivers
I will read it.
> If you intend to post the drivers as the development effort continues. so that
> you can have the community feedback (and if required help) during the process
> then you might in interested in Greg's Staging tree.
> http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=tree
> You can base your patches to the latest kernel (or git trees of respective
> maintainers) and post them to the mailing list.
Oh! Do I have to base our patches to the latest kernel?
May be so.
And the community feedback is important.
It seems to need big effort and we will make every effort anyway.
Thanks,
> You'll find a lot of useful information in these parts of the kernel
> Documentation directory:
>
> Documentation/HOWTO
> Documentation/development-process
> Documentation/SubmittingPatches
>
> That would be the best place to start.
I will read the information at the kernel Documentation directory.
It is a lot of useful and good information.
On Mon, Dec 14, 2009 at 12:26:49PM +0100, Alejandro Riveira Fern??ndez wrote:
> El Mon, 14 Dec 2009 19:56:23 +0900
> Masa <[email protected]> escribi??:
>
> Adding I hpe some usefull CC's
> See also: http://www.linuxdriverproject.org/
>
> > Hi,
> >
> > Our company is planning to upload our device drivers to "kernel.org".
> > And I am investigating "How to upload".
Please read the very detailed documentation on how the Linux development
process works that is contained within the kernel in the:
Documentation/development-process/
directory.
If after reading that, you have specific questions, and you need help
with getting your code accepted, me, and the other developers on the
[email protected] mailing list will be glad to help you out.
Hope this helps,
greg k-h
> You don't, technically speaking, upload.
> You make a patch against a current kernel tree and mail it
> to the relevant list. Then people will tell you what's wrong with your
> code and how it should be improved. After you'll have fixed
> the issues, the maintainer will take your patch and it'll be
> incorporated into the kernel tree at kernel.org.
It is a useful information for me.
I understood the procedure.
I think that I may take time to solve all issues.
However, I want to give a TRY.
Thanks,
On Tue, Dec 15, 2009 at 12:15:58AM +0900, Masa wrote:
> > You don't, technically speaking, upload.
> > You make a patch against a current kernel tree and mail it
> > to the relevant list. Then people will tell you what's wrong with your
> > code and how it should be improved. After you'll have fixed
> > the issues, the maintainer will take your patch and it'll be
> > incorporated into the kernel tree at kernel.org.
>
> It is a useful information for me.
> I understood the procedure.
>
> I think that I may take time to solve all issues.
> However, I want to give a TRY.
If you need help with this process, or with cleaning up your code to
make it acceptable, please let us on the [email protected]
list help you out.
thanks,
greg k-h
Thanks,
> Please read the very detailed documentation on how the Linux development
> process works that is contained within the kernel in the:
> Documentation/development-process/
> directory.
>
> If after reading that, you have specific questions, and you need help
> with getting your code accepted, me, and the other developers on the
> [email protected] mailing list will be glad to help you out.
I see.
I will read the document.
After that, I will need your help and the other developers's with the
mailing list.
I am happy today.
Because a lot of people help me.
This mailing list is nice!
On Mon, Dec 14, 2009 at 11:45:10PM +0900, Masa wrote:
> Oh! Do I have to base our patches to the latest kernel?
> May be so.
> And the community feedback is important.
> It seems to need big effort and we will make every effort anyway.
There are resources available to help you with getting your patches
based on the latest kernel version. There are many ways in which a
company can be involved with supporting their hardware with a fully
supported Linux device driver.
One model is one where the hardware company employs an engineer who is
actively involved with Linux community and is constantly upgrading and
developing their device driver against the latest kernel, and then
group such as the Driver Backport Workgroup[1] will backport drivers
to various enterprise kernels. Some companies like this model because
they retain control over the development of the device driver, and
they can also update it to support hardware not yet released for sale;
some companies such as Intel and IBM, have been able to use this model
to assure that the latest mainstream kernel has support for a new
version of their hardware device at or before the moment it is
released for sale to the general public.
Another model is one where the company makes some combination of (1)
hardware specifications, (2) patches against an older kernel, and (3)
hardware available to developers (the Linux Foundation can help
faciliate this), and then a group such as the Linux Driver Project[2]
can help write a driver or port the driver to the latest kernel. This
is done on a volunteer basis, and so how quickly this might happen is
less under the control of the hardware company involved.
There are many other models in between these two extremes, depending
on how closely the company is willing and interested to work with the
Linux development community. For example, the upstream maintainer may
be a volunteer, who gets free hardware samples (and possibly
occasional contract work) to support the hardware, but the company is
less involved than the "full engagement" model where their engineer is
the primary mainstream developer, and but more involved than the
company dumps some specs, sample code, and some hardware and is
otherwise not involved.
A general overview of some of the issues involved in why things work
they way they do can be found here [3].
Best regards,
Theodore Y. Ts'o
Chief Technical Officer, Linux Foundation
STSM, IBM Linux Technology Center
Medford, Massachusetts
(617) 245-5616, T/L 930-1182
(781) 391-2699 (fax)
(781) 526-0121 (cell)
[1] http://www.linuxfoundation.org/collaborate/workgroups/driver-backport
[2] http://www.linuxdriverproject.org/foswiki/bin/view
[3] http://www.linuxfoundation.org/collaborate/publications/linux-driver-model
Thanks,
> If you need help with this process, or with cleaning up your code to
> make it acceptable, please let us on the [email protected]
> list help you out.
I will contact to it.
If preparations were completed.
Thank you for explaining the overview.
I will choose an appropriate model and confirm information of the URLs later.
> There are resources available to help you with getting your patches
> based on the latest kernel version. ?There are many ways in which a
> company can be involved with supporting their hardware with a fully
> supported Linux device driver.
>
> One model is one where the hardware company employs an engineer who is
> actively involved with Linux community and is constantly upgrading and
> developing their device driver against the latest kernel, and then
> group such as the Driver Backport Workgroup[1] will backport drivers
> to various enterprise kernels. ?Some companies like this model because
> they retain control over the development of the device driver, and
> they can also update it to support hardware not yet released for sale;
> some companies such as Intel and IBM, have been able to use this model
> to assure that the latest mainstream kernel has support for a new
> version of their hardware device at or before the moment it is
> released for sale to the general public.
>
> Another model is one where the company makes some combination of (1)
> hardware specifications, (2) patches against an older kernel, and (3)
> hardware available to developers (the Linux Foundation can help
> faciliate this), and then a group such as the Linux Driver Project[2]
> can help write a driver or port the driver to the latest kernel. ?This
> is done on a volunteer basis, and so how quickly this might happen is
> less under the control of the hardware company involved.
>
> There are many other models in between these two extremes, depending
> on how closely the company is willing and interested to work with the
> Linux development community. ?For example, the upstream maintainer may
> be a volunteer, who gets free hardware samples (and possibly
> occasional contract work) to support the hardware, but the company is
> less involved than the "full engagement" model where their engineer is
> the primary mainstream developer, and but more involved than the
> company dumps some specs, sample code, and some hardware and is
> otherwise not involved.
>
> A general overview of some of the issues involved in why things work
> they way they do can be found here [3].
>
> Best regards,
>
> Theodore Y. Ts'o
> Chief Technical Officer, Linux Foundation
> STSM, IBM Linux Technology Center
> Medford, Massachusetts
> (617) 245-5616, T/L 930-1182
> (781) 391-2699 (fax)
> (781) 526-0121 (cell)
>
> [1] http://www.linuxfoundation.org/collaborate/workgroups/driver-backport
> [2] http://www.linuxdriverproject.org/foswiki/bin/view
> [3] http://www.linuxfoundation.org/collaborate/publications/linux-driver-model
Thank you for your polite reply again.