On Tue, Aug 19, 2008 at 8:19 PM, Paul Gortmaker <paul.gortmaker@xxxxxxxxx> wrote: > On Tue, Aug 19, 2008 at 2:01 PM, David VomLehn <dvomlehn@xxxxxxxxx> wrote: >> I'm working to educate our management on the need to get our platform in the >> kernel mainline. I expect I will be asked to tell them how much work this >> is. What do we need to do to add a new MIPS platform? > > Based on the phrase "educate our management" -- I would strongly suggest you > have a look at Jonathan Corbet's document that describes the process and the > eventual value-add of having things in-kernel -- with an audience of non-kernel > hackers in mind. I think this will really assist you in your efforts, > and I'm glad that > Jonathan put the time into this that he did. > > His original post can be viewed here: > > http://lkml.org/lkml/2008/7/29/363 > > or here: > > http://lwn.net/Articles/291967/ > This indeed is a very interesting document. I can hardly agree with the below point, however: +- While kernel developers strive to maintain a stable interface to user + space, the internal kernel API is in constant flux. The lack of a stable + internal interface is a deliberate design decision; it allows fundamental + improvements to be made at any time and results in higher-quality code. + But one result of that policy is that any out-of-tree code requires + constant upkeep if it is to work with new kernels. Maintaining + out-of-tree code requires significant amounts of work just to keep that + code working. so, say a developer submits a proprietary driver and it gets accepted. Then some internal kernel interface gets changed. Who now has to modify and retest the driver? Is it the person who introduces the change (how can he even do this, as he does not have the proprietary hardware available)? Or is this the original submitter - then where is the benefit of saving on upkeep? This constant change of the kernel innards is hardly a good selling point, would you agree? cheers, /vb -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html